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

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