şükela:  tümü | bugün
  • kodun çalışma süresini kısaltırken, derlenmiş dosya boyutunu arttıran bir işlemdir.
  • assembly'ye kadar yolu vardir.. neredeyse sonu olmayan bir istir.. 1990larin sonuna kadar cip ureticileri surekli daha guclu islemciler urettiklerinden kod optimizasyonuna gerek kalmadan varolan kodlar daha hizli calisiyordu. ancak son 10 yilda gavurlarin deyisi ile belese kod hizlandirma sona erdiginden kod optimizasyon teknikleri ayri bir onem kazanmistir. ozellikle donanimin farkinda olan * kod optimizasyonlari cok gozdedir. buna gore eger makinenin cache'inin buyuklugunu, turlu turlu latency'lerini bilirsen kodunu ona gore optimize edebilirsin. atlas, spiral gibi library'ler donanimini inceler ve en optimize algoritmalari ve onlarin en verimli implementasyonlarini kullanir. o yuzden mesela 2 matrisi carpacaksaniz cok kasmayin optimizasyon yapacam diye onun yerine gidin lapack falan kullanin.
  • basli basina compiler design alaninda bir disiplindir.

    olay programi tasarlama evrenizden baslar, siz adam gibi tasarimla gelirseniz az kodla cok verimli isler yaparsiniz. sonra kod yazmayi bilmeniz lazim, adam gibi kod yazarsaniz yine ayni durum olusur.

    sonra compiler devreye girer, cesitli optimizasyonlar yapar. code inlining olur, tail recursion olur... compiler optimization adi verilen alanda belki de yuzlerce profesor aktif olarak calisiyor buna su dakikalarda. uzerine yazilmis onlarca kitap var.

    gunun sonunda kodunuz machine instruction (assembly code)'a cevrildigi icin orada da instruction set'e ozgu optimizasyonlar yapilabilir. misal vakt-i zamaninda c'de bulunan register keyword'unden tutun 2'nin kuvvetleriyle carpma isleminin shift'lerle yapilabilmesine kadar burada da bir bilim dali soz konusu.

    butun bu asamalarin amaci aslinda uretilen assembly code'un makineyle verimli ve kisa surede calisabilmesidir. gunumuzde optimizasyonlarin amaci kodun boyutundan cok hizindan kazanma amaciyla yapilmaktadir.
  • ekşios'un bu sayfayı açamaması bayağı düşündürücü. sırf bana mı oluyor anlamadım.

    düzgün yazılamayan programlar arasında iphone 4'teki foursquare ve facebook başı çekiyor. ikisinin de açılması ve menülerinde gezinmesi çok uzun sürmekte. hele foursquare'in yazılımcılarının "programı biraz daha hızlandırdık hehe" tarzı yazılarını okudukça ağızlarına çakasım geliyor. böyle optimizasyon mu olur lan, kontrol de mi etmediniz hiç? tarayıcıdan girsem daha çabuk görüyorum işimi.

    doğru bilgi, alet ve ekiple yapılmayan optimizasyonlar müşteri için gereksiz sıkıntı yaratır. yazılımcı işi baştan sıkı tutarsa sonradan çıkacak masraflar büyük ölçüde engellenmiş olur*.
  • linux üzerinde perf stat komutunu kullanarak yaptığınız optimizasyon iyi mi oluyor, yoksa o fonksiyonu inline etmeseydiniz daha mı iyiydi görebilirsiniz:

    386.831.067.306 instructions # 2,39 insn per cycle
    70.763.704.150 branches # 1421,021 m/sec
    16.562.341 branch-misses # 0,02% of all branches

    gibisinden bir çıktısı var (gonderdiğiniz argümanlara göre daha fazla bilgiye de erişebilirsiniz)

    bu çıktıları her değişiklikte karşılaştırıp ilerlemiş miyim yoksa işleri daha mı olunmaz bir hale sokmuşum kontrol ediyorum. örneğin bir sonraki değişiklik şuna benzer bir sonuç verdi:

    377.271.528.625 instructions # 2,40 insn per cycle
    66.664.375.074 branches # 1387,126 m/sec
    15.798.651 branch-misses # 0,02% of all branches

    demek ki iyi yolda ilerliyoruz gibi...

    edit: imla