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ı: 1195

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

Giriş

Java, sıklıkla “yavaş” olarak nitelenen bir dil. Hatta pek çok zaman bu durum bir suçlama ve geyik malzemesi olarak da kullanılıyor. Garip olan şu ki bu kanıya sahip olanlar, bu durumu gerçekmiş gibi sunuyorlar. Aslında bunu iddia edenlerin temelde iyi dayanağı var:

• Java native çalışmadığı için yavaş olması da zaten normaldir, beklenendir. Bu yüzden Java hiç bir zaman C/C++’ın hızına erişemez.
• Biz Java ile uygulama geliştirdik ve yavaş çalıştı/çalışıyor.

Aslında analitik olarak gidip, öncelikle yavaş ya da hızlı olmak nedir ona bakmak gereklidir. Uygulamalarda farklı şeylerin performanslarından bahsedebiliriz:

• Ayağa kalkma zamanı (startup time), bir uygulamanın başladıktan sonra cevap verecek hale gelinceye kadar geçen zamanıdır.
• Harcanan bellek (memory footprint), uygulamanın bellek tüketimi demektir.
• Cevap verme süresi (response time, responsiveness), uygulamanın kullanıcıların uygulama üzerinde yaptıkları bilgi girişi, tıklama vs. gibi hareketlerine cevap veriş süresidir.
• İş üretme (throughput), uygulamanın birim zamanda çıkardığı iştir.
• Ölçeklenirlik (scalability), uygulamanın yükü arttıkça davranışının değişmesini temsil eden özelliktir.

Bir de şu soruyu sormak lazım: Yavaş ya da hızlı olan nedir? Yani dilin mi hızlı ya da yavaş olmasından bahsedebiliriz yoksa uygulamanın mı? Buna şöyle bir soruyla cevap verelim: Aşağıdakilerden hangisinin performans yönünden kalitesi, bir uygulamanın yavaş ya da hızlı olmasını daha çok belirler?

• Dilin kendisi
• Yazılımın mimarisi
• Üzerinde çalışılan donanım

Yazılım mimarisi, uygulamaların performanslarını belirlemede muhtemelen en fazla etkiye sahip olandır. Bu amaçla Facebook gibi yüksek ölçeklenirlik gerektiren uygulamaların mimarilerini inceleyebilirsiniz. Ayrıca konu ile ilgili buradaki yazıma bakabilirsiniz.

Performans Çalışmaları

Performans ile ilgili çalışmalar genelde 3 başlık altında ele alınır:

• Monitoring (gözlemleme): Sistemin davranışını, ona müdahele etmeden ve yük getirmeyecek şekilde, gözlemlemektir. Sistemin tamamı için söz konusudur ve daha çok önleyici amaçlar için kullanılır.
• Profiling (tarama): Az ya da çok müdahele ederek ve sistemin davranışı ile ilgili veri toplamaktır. Muhtemelen sistemin sıkıntılı olduğu düşünülen tarafları için yapılır ve problem olduğunda başvurulur. Sampling (örnekleme) adında daha az müdahele eden şekli de vardır.
• Tuning (ince ayar): Performansı iyileştirmek amacıyla, kodda, ortamda vs. yapılan ince ayar çalışmalarıdır. Tuning, genelde sistemin bütününden ziyade belli alanlara odaklıdır. Örneğin:
  • Uygulamanın veri tabanı iletişimi ve sorguların (SQL) iyileştirilmesi,
  • Kullanıcı arayüzlerinin inceltilmesi,
  • Sistemin ayağa kalkarken yaptığı işlerin azaltılması,
  • Sistemin XML işlemesinin iyileştirilmesi,

Tuning doğası gereği  farklı yerlere ve şekillerde uygulanabilir. Bir kaç örnek vermek gerekirse:

• Bazen sadece algoritmiktir: Kullanılan algoritma iyileştirilir ya da değiştirilir.
• Bazen belli kod parçalarına (aspect) uygulanır: Oturuma konan nesnelerin azaltılması (örneğin HttpSession temizlemesi), veri tabanı iletişimi için Statement yerine PreparedStatement kullanılması, loglama, sorgulama (querying) ya da transaction performansının iyileştirilmesi gibi işlemler bu cinstendir.
• Bazen teknolojiye uygulanır: JSF 1.2’yi JSF 2 ile değiştirmek ya da Java’in sürümünü arttırıp örneğin 1.5’ten 1.8’e çıkarmak gibi.
• Bazen yazılımın mimarisine uygulanır: Cache kullanımına geçilmesi, nesne havuzu (object pool) kullanılması ya da yazılımın topolojisinde değişiklik yapılması gibi değişiklikler bu cinsten iyileştirmelerdir. Mimari iyileştirmelerin hem maliyeti yüksektir hem de yüksek risklidirler ama iyi tespit edilip uygulandıklarında ciddi ilerlemeler sağlarlar.
• Bazen veriye uygulanır: Veri tabanındaki verinin denormalize edilmesi ya da veri tabanlarının sağladığı optimizasyon imkanlarının kullanılması gibi.
• Bazen donanıma uygulanır: Daha güçlü donanıma geçilmesi ya da kısmi yapılan RAM artışı gibi iyileştirmelerdir.
• Bazen JVM’e uygulanır: Java’ya özel olarak JVM’in davranışını değiştirmek amacıyla pek çok parametre kullanılır. Bu parametrelerin yüksek performans sağlaması amacıyla optimum noktaya getirilmesi, JVM tuning olarak adlandırılır.

Tuning yapmadan önce, neyin problemli olduğu ve ne şekilde iyileştirilmesi gerektiği kesinleştirilmelidir aksi taktirde daha kötü durumla düşmek isten bile değildir. Bu noktada Donald Knuth’ın sözünü hatırlamakta fayda vardır:

Premature optimization is the root of all evil.

Ayrıca tuning yapılmadan önce, tuning ile kazanılacak performans artışının ne olacağı da kestirilmelidir. Diğer bir deyişle atılan taş, ürkütülen kurbağaya değmelidir.

Bir sonraki yazıda yukarıda Java’nın yavaş olduğundan bahsedenlerin ilk dayanağını ele alacağız.

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