Bir önceki yazıda, bu günlüğü takip eden C++ severlerin, C++’ın performans ölçümleriyle ilgili olarak yaptığı itirazlar üzerine, benim ve C++ uzmanı bir arkadaşımın yaptığı yeni ölçümleri yayınlamıştım. Bu son yazıya bilgin ve yetkin arkadaşım Binnur da yorumda bulundu. Bu seriden daha önce yayınlanmış bir başka yazıya yine bilgin ve yetkin bir başka arkadaşım Yaşar da yorumuyla katkıda bulunmuştu. Ben bu yorumları bu yazıda bir araya getirip size topluca sunmak istedim.

Binnur’un Java Yavaş mı? : Java’nın Performansı Üzerine – IV yazısına yorumları:

İlk yorumu:

1. Java kodunun başarımını jmh ile ölçmek daha doğru olurdu. Güzel bir haber: jmh, jdk 9’un içinden hazır çıkacak.

2. -O3 seçeneği ile derleyici kodu en iyiler ancak artık hata ayıklayamazsınız. Kullanılan en iyileme teknikleri durağan tekniklerdir. Derleyici kodun ancak durağan analizini yapabilir ve hızlandırmak için yapabilecekleri bu nedenle kısıtlıdır. Ancak java’da en iyileme kararları yürütme zamanında dinamik olarak verilir. JIT derleyici metodun tek şekilli, iki şekilli ya da çok şekilli olmasına göre değişik en iyileme tekniklerini uygulayabilir. Örneğin tek şekilli bir metodu inline edebilir. Bir metoduntek şekilli, iki şekilli ya da çok şekilli olması yürütme zamanında uygulamanın aldığı şekle göre zamanla değişen bir durumdur. C++’da derleyici virtual tanımlı metodun tek şekilli mi, iki şekilli mi yoksa çok şekilli mi olduğunu bilemez. Bu nedenle virtual tanımlı bir metodu her zaman virtual table üzerinden bağlamak zorundadır. Açıkçası bunu c++ geliştiricisi de bilemez, hatta kaliteli bir nesneye dayalı tasarımda bilmemelidir de. Bu JIT derleyicinin yapabildiklerine ilişkin basit bir örnek. Daha başka bir çok dinamik en iyileme tekniği bulunuyor.

Benim “Ben C++’ın da run-timeda performansını arttırıcı, senin dynamic iyileme (optimization) yapan yapıların geliştirildiğini okumuştum bir yerlerde. Senin bilgi var mıdır? Paylaşabilir misin?” şeklindeki sorum üzerine ikinci yorumu:

1. Profile guided optimization
https://msdn.microsoft.com/en-us/library/e7k32f4k.aspx

2. Burada Java’da yazılmış bir uygulamanın, C++’da yazılmış bir uygulama kadar hızlı koşabildiğini ve bazen de şartlar oluşursa daha hızlı koşabildiğini bilmek gerekir. Kötü bir algoritma seçimini, yanlış bir mimari kararı hangi dilde kodlarsanız kodlayın yavaştır.

3. Tüm popüler diller (Java, C#, Objective C gibi) altta LLVM kullanır: http://llvm.org
Debug jvm edinebilirseniz, LLVM IR’leri konsoldan okuyabilir ve neler olup bittiğini izleyebilirsiniz.

4. C++ tarafında derleyici olarak clang ve intel compiler’ın performansına bakabilirsiniz. Muhtemelen hem VS hem de gcc’den daha iyi sonuç verecektir. C++’da hızlandırma için daha çok eğer algoritma elverişli ise paralelleştirme çözümlerine bakmak gerekir: OpenMP, Cilk, CUDA, OpenCL.

Binnur’un daha önce yayınlamış olduğum Java’nın Performansı: Java Yavaş mı? başlıklı yazıya yaptığı yorumlar:

İlk yorumu:

Selam Akın,

Performans ile ilgili olarak C++ ve Java karşılaştırmanda, tam tersini düşünüyorum. Deneyimsiz C++ ve Java geliştiricisinin yazdığı iki uygulama için, Java uygulamasının daha yüksek başarımla çalışması beklenmelidir. C++11 soyutlama konusunda çok yol aldı. Üstelik seçimlik bir çöp toplayıcımız var. C++’ın dil olarak en üstün tarafı Template ve STL ile sağlanan üretken programlama. Her ikisinin de ortak problemi Heap. Birinde bellekten yer almak yavaş (c++), diğerinde temizlemesi. Java’nın en güçlü yönü, Java dilinin kendisi değil, uygulamaların üzerinde çalıştığı JVM. C++ derleyicisi en fazla durağan en iyileme yapıyor (-O3), Jvm ise devingen en iyileme yapıyor. Dolayısı ile yapabildikleri çok daha fazla.

İkinci yorumu:

Burada ironik bir durum var: JVM, C/C++’da yazılmıştır. Java başarımını bir ölçüde C’ye ve deneyimli C geliştiricilerine borçlu

Şimdi de Yaşar’ın yazdıklarına geçelim. Yaşar’ın bu seriden  Java Yavaş mı? : Java’nın Performansı Üzerine – II başlıklı yazıya yaptığı yorum.

Yazdığınız çok doğru. Ufak iki şey yumurtlayasım geldi ama:

1. “Yorumlanan” deyince, doğru, ama yorumlama bir ara seviyede oluyor. Yani, “bytecode” dediğimiz, aslında var olmayan bir makinanın (bir ara yaptılardı sanki ama) komutları (instruction) çalıştırılıyor. Yani, direkt olarak kaynak kod yorumlanmıyor. Çok bir şey farkedeceğinden değil; ancak tamamen yorumlanarak çalışan dillerde, bir derleme adımı olmuyor. Javada ise, işimize de gelen bir derleme adımı var ki, bizi belli açılardan vaktiyle hizaya sokuyor.

Yorum yazıya doğru gidiyor ama, şunu da belirtmek lazım: Dilin yorumlanması veya derlenmesi, bir gerçeklenme problemi. Mesela, Javascript’in tanımında “yorumlanan” lafı geçiyor. Ancak mesela V8 önce derlemeyi tercih ediyor.

2. “Java yavaş mı” sorusunun cevabı, biraz “hadeleyn” civarında. Gerçekten de bu sözlerin doğruluk payı taşıdığı zamanlar, geçen yüzyıldaydı.

Saf Java koduna karşı, saf C kodu durumunda, verdiğiniz örnekler durumu gösteriyor.

İlginçlik, enteresan donanımlarda çıkıyor ortaya. Mesela, GPU kullanımı meselesi var. Paralel veri parçaları üzerinde hesaplama ağırlıklı işler için, GPU, CPU’yu dövüyor. (Bitcoin mining ile uğraşan var mı?) Öyle bir mesele için, JVM içinde bir şey yapmak mümkün olmayabiliyor. Elbette bu tip şeyler için de Java projeleri var. Ancak nihayetinde birinin o “native code”u yazması gerekiyor bir noktada.

Java’nın bugün ulaştığı bu yüksek verimlilik de, yıllar içinde hem derleme optimizasyonları (JIT derlemeden bahsediyorum) hem de muhtelif platformlardaki JVM’lerin daha kaliteli ve altta yatan donanımı daha iyi kullanmasının eseri.

Bunu, zamanında C kodu içine assembler yazılması durumuna benzetiyorum. Linux’un ilk kernel kodlarında, bunlar bol miktarda vardı. Esas sebep, derleme için kullanılan (o zaman tek opsiyon) GCC’nin, o kadar da iyi optimizasyon yapamamasıydı. Modern GCC versiyonlarında, optimizasyonlar o kadar kudretli hale geldi ki, elle GCC’nin ürettiği koddan daha hızlı kod üretmek neredeyse imkansız hale geldi. Kernel kodundaki pek çok assembler kısmı da bu sebepten sökülüp atıldı.

Şimdi aynı vaziyet, Java için gerçekleşiyor. Yani, çok da şaşılacak bir durum yok aslında.

Binnur Kurt veYaşar Safkan’ın yazdıklarına bloglarından ve twitter hesaplarından ulaşabilirsiniz:

• Binnur Kurt’un blogu: http://binkurt.blogspot.com.tr/ ve Twitter hesabı: https://twitter.com/bnnrkrt
• Yaşar Safkan’ın blogu: http://www.safkan.org/blog/ ve Twitter hesabı: https://twitter.com/yasarsafkan

Okumak güzeldir. Bileni okumak daha güzeldir.

Bol okumalar 🙂

Toplam görüntülenme sayısı: 909

Bir önceki yazıda Monte Carlo simulasyonu ile Pi sayısını hesaplama ve asal sayı bulma amaçlı iki algoritma üzerinden C++ ile Java’nın performanslarını karşılaştırmıştım. Sağolsun bazı okurlarım düşüncelerini iletirken, iki okurum da iki algortimayı kendi makinaların da deneyip sonuçlarını benimle paylaştılar. İki okurumun da sonuçları, benim elde ettiğimin tersine çıkmış durumda, yani onların elde ettiği ölçümlerde bu iki algoritmada C++, Java’dan daha hızlı çalışmış. Hatta kendileri benim bu sonuçları alırken nasıl bir konfigürasyona sahip olduğumu da sordular. Bu durumda ben de bu serinin dördüncüsü olarak yazdığım yazıyı bir öteye itip, araya bu yazıyı aldım.

Öncelikle açıkçası şunu ifade etmem gerekir ki benim “Java Yavaş mı? : Java’nın Performansı Üzerine” yazı dizisinde ispatlamaya çalıştığım şey Java’nın C++’tan hızlı olduğu değildir. Derdim hangisinin hızlı olup olmadığını da anlamak değildir. Bu yazılarda anlatmaya çalıştığım şey öncelikle “hız” kavramının muğlaklığı ve “dilin hızı” ile “uygulamanın hızı” kavramlarının arasındaki fark ve bu noktada mimarinin önemidir. Ve malesef bunlar, bu işin pratiğini yapanların kafasında çok da aydınlanmış kavramlar da değiller. Sonrasında ise hedefim, Java’nın yavaş olduğu iddiasının içinin dolu olmadığını göstermektir. Bunu da olabildiğince delilli yapmaya çalışıyorum, bu blogda devamlı yaptığım gibi. Zaten aşırı ideolojik bir ülkede olmamızdan dolayı üzerine kafa patlatılmış, delilli cümlelerle konuşma yerine kahvehane seviyesinde, bilgilesizce edinilmiş fikirlerle tartıştığımız için, bu dizide ben “Java yavaş” cümlesinin de tam da bu cinsten bir ifade ve delilsiz ve mesnetsiz bir inanış olduğu göstermeye çalışıyorum. Öte yandan 90’lı yılların başından bu yana bu sektörde olan birisi olarak zaten sadece iki algoritma çalıştırmakla diller arasında gerçek bir performans kıyaslaması olamayacağını biliyorum.

Bu açıklamadan sonra şimdi ben kendi kullandığım configürasyonlardan bahsedeyim.

• Makinam, 16 GB RAM ve 8 çekirdekli i7 CPU’ya sahip, üzerinde El Capitan OS çalışan bir MacBook Pro.
• C++ için  GNU g++ (GCC) 4.9.2 20141029 kullandım. Derleme komutu ise: g++ -O3 -std=c++11 -o SieveOfAtkin.out SieveOfAtkin.cpp
• Java için ise Java(TM) SE Runtime Environment (build 1.8.0_45-b14), Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode). Java ile compile ederken de çalıştırıken de hiç bir flag kullanmadım, tamamen varsayılan seçenekler geçerliydi.

Sieve Of Atkin algoritması için farklı n girdisi için mili saniye cinsinden yukarıdaki Java ve C++ konfigürasyonlarının sonuçları aşağıdadır. 5 defa çalıştırma sonucunda elde edilen ortalama çalışma süreleri şunlardır:

Yukarıdaki tablodaki ölçümlerden Java için olanları tekrar etmedim, verileri daha önceki ölçümlerdir. Sadece C++ ölçümlerini tekrar ettim, çünkü okurlardan C++ ölçümlerine itiraz edenler olmuştu. Makinamdaki C++ derleyicisini yeniledim. C++ kodunu Compile ederken de “-O3” flagini kullandım. Bu şekilde C++ ölçümlerinin ciddi olarak iyileştiği görülüyor. Bu sonuçları Java açısından yorumlarsak, Java’nın yavaş olmadığı, C++ ile başa-baş bir performans sergilediği görülüyor.

Daha önceki ve şimdiki C++ ölçümlerini kıyaslamak gerekirse, kullandığım farklı opsiyonlarla performanslar aşağıdaki gibi olmaktadır. Bu sonuçlardan özellikle “-O3” performans flaginin ciddi bir etiye sahip olduğu anlaşılıyor. Fakat merak ettiğim şey neden bu flagin varsayılan halde geçerli olmadığı? Uzun süredir C++ ile ilgilenmediğim için belli ki bu konulara detaylıca bakmam gerekli.

Öte taraftan benzer ölçümleri uzun süre C ve C++ ile çalışmış bir arkadaşımdan da yapmasını istedim. Sağolsun Sieve of Atkin algoritması için detaylı ölçümler yapmış. Her farklı n girdisi için 3 ayrı çalıştırma yapmış ve ortalamasını ile beraber kaydetmiş. Elde ettiği ölçümler aşağıdaki gibi:

Arkadaşım, n = 10^9 için bir kaç farklı C++ compilerı kullanarak çok farklı sonuçlar elde etmiş.

Arkadaşımın ölçümleri elde ettiği makinasının konfigürasyonu da şöyle:

• Intel Core i7-2670QM CPU @ 2.2GHz 8 GB Bellek
• 64 Bit Windows 7 İşletim Sistemi (service Pack 1)

Yukarıdaki ölçümler, farklı makinalarda ve farklı compilerlarla yapılmış olması açısından Java’nın performansı noktasında daha objektif sonuçlar verdiği kesin. Benzer şekilde, bu sonuçlar Java ile C++’ın algoritmik performanslarının kıyaslanabilir olduğunu gösteriyor. Elde ettiğimiz sonuçlar, bu iki dil arasında CPU’yu çalıştırma noktasında çok da fazla bir performansının farkının olmadığını, eğer varsa da, girdi arttıkça performansın Java lehine ilerlediğini gösteriyor. Sonraki yazılarda bu fark üzerine konuşacağız.

Bol performanslı günler dilerim.

Toplam görüntülenme sayısı: 1203

Bir önceki yazıdan devam edelim ve şimdi de Monte Carlo simulasyonu ile PI’ye yakınsamayı ele alalım.

Önce MonteCarloPI.cpp

/* 
 * File:   MonteCarloPI1.cpp
 * Author: akin
 * 
 * Created on October 7, 2015, 12:39 AM
 */

#include <iostream>
#include <stdlib.h>
#include <ctime>

namespace MonteCarloPI1 {
    
    using namespace std;

    int n;

    int main() {
        cout.precision(10);

        int dotsInCircle = 0;
        cout << "Number of points: " << endl;
        cin >> n;

        clock_t start = clock();

        for (int i = 0; i < n; i++) {
            double x = static_cast<double> (rand()) / static_cast<double> (RAND_MAX);
            double y = static_cast<double> (rand()) / static_cast<double> (RAND_MAX);

            double distance = x * x + y * y;
            if (distance <= 1.0)
                dotsInCircle++;
        }

        clock_t end = clock();
        int time = (int) (1000 * (end - start) / CLOCKS_PER_SEC);

        double myPi = (double) 4 * dotsInCircle / n;

        cout << "My PI is: " << myPi << endl;
        cout << "Time is: " << time << " ms." << endl;

        return 0;
    }
}

ve şimdi de MonteCarloPI.java

package org.javaturk.performance.algorithm.pi;

import java.util.Scanner;

import org.apache.commons.math.random.BitsStreamGenerator;
import org.apache.commons.math.random.MersenneTwister;

/**
 * Monte Carlo simulation to get closer to PI. It uses MersenneTwister to
 * produce random numbers. The implementation of this algorithm comes with
 * Apache's commons Math library.
 * 
 * @author akin
 *
 */
public class MonteCarloPI {
	private static long n;
	private static BitsStreamGenerator randomData = new MersenneTwister();

	public static void main(String[] args) {
		System.out.println("*** MonteCarloPI2 ***");
		System.out.print("Number of points: ");
		Scanner in = new Scanner(System.in);
		n = in.nextLong();
		calculatePI();
	}

	public static void calculatePI() {
		int dotsInCircle = 0;
		double start = System.currentTimeMillis();
		for (int i = 0; i < n; i++) {
			double x = randomData.nextDouble();
			double y = randomData.nextDouble();
			double distance = x * x + y * y;
			if (distance <= 1)
				dotsInCircle++;
		}
		double finish = System.currentTimeMillis();
		double seconds = (finish-start);
		double myPI = (double) 4*dotsInCircle/n;
		System.out.println("My PI is: " + myPI + " and Java's PI is: " + Math.PI);
		System.out.println("Time is: " + seconds);
	}
}

Monte Carlo simulasyonu ile PI’ye yakınsamak görüldüğü gibi çok daha basit ama çok güzel bir algoritmadır. Random veri oluşturmak dışında son derece basit bir for bloğu içinde bir if cümleciğinden oluşuyor. Random veri için Java’da Apache Commons Math’de bulunan MersenneTwister gerçekleştirmesini kullandım. Buna karşın C++’daki random veri üretimi ise standart kütüphanedeki gerçekleştirmeyi kullandım. Bu farklılığın performansa etkisinin ne kadar olacağını pek kestiremiyorum şu anda, daha fazla araştırmak gerekli.

Bu programın MacBook Pro’mdaki ölçümleri ise şöyle:

Bu ölçümlerin de bir önceki SieveOfAtkin‘deki ölçümleri destekliyor olduğu açıktır.

Bu ölçümlerde bir şey dikkatinizi çekiyor mu? Girdi sayısı artarken performans ölçümlerinin Java lehine değişiyor olması bir tesadüf müdür acaba?

Toplam görüntülenme sayısı: 636