Programlama Dilleri Benchmark Karşılaştırmaları

Birçok programa dili arasında ayrıntılı performans karşılaştırmalarını görebileceğiniz takdire şayan bir site. CPU Time, hafıza kullanımı ve kod uzunluğu başta olmak üzere bir çok kritere göre karşılaştırma mevcut. (Ruby'nin python'dan hızlı olduğunu iddia edenler mi vardı? ;-)

http://shootout.alioth.debian.org/

Görüşler

roktas
yaklaşık 19 yıl önce

Bu konular çok netamelidir. Bildiğim en sağlıklı yorumlara sahip, alanında artık klâsikleşmiş bir paper'ı da (haberdar olmayanlar için) ben vereyim, büyük üstad Brian Kernighan'dan:

Timing Trials, or, the Trials of Timing: Experiments with Scripting and User-Interface Languages

Bu cs.bell-labs klâsiğinde sonuç olarak bakın ne söyleniyor:

Comparisons are a mainstay of computer literature. Conferences, journals, and magazines are full of tables and colorful charts that compare execution time or memory usage of one or more programs on different machines or implementations. In light of the variability in results that we saw, however, we wonder whether similar variation lurks behind published benchmark studies as well. It does seem wise to take all such experiments including these with a large grain of salt.

Rakamlara inanmayın, ama rakamsız da kalmayın. ;-)

librid
yaklaşık 19 yıl önce

Ruby'nin Python'dan hızlı olduğunu iddia eden yoktu fakat Ruby 2.0'ın Python'a nal toplatacağını iddia edenler var :-)
YARV isimli yeni Ruby VM, Ruby cvs'e eklenince o benchmarklara bir daha bakarız. Sonuç sizi üzebilir, yol yakınken Ruby öğrenmeye başlamanızı samimiyetle tavsiye ederim ;-)

anonim
yaklaşık 19 yıl önce

Yabancı ruby fanlarının sitelerinde ruby daha hızlı diyenler var. Ama ben zaten farklı programa dillerini öğrenmeyi hoby haline getirmiş bir kişi olarak ruby öğrenmeye karşı değilim. Zaten python programcıları ruby öğrenirken zorlukda çekmez; aralarındaki benzerlikler oldukça fazla özellikle de söz dizimi. Bakalım ruby 2.0'da durum ne olacak. Dediğiniz gibi olursa ben değil Python'un yaratıcısı Guido bey düşünsün.

librid
yaklaşık 19 yıl önce

YARV 0.3.2'yi indirip, kullandığım dağıtımla gelen paketlerin ayarları ile aynı olması amacıyla -march=i386, -mtune=i686 ile derledim ve beraberinde gelen (haberde linki verilen shootout.alioth.debian.org'dan alınmış) bazı benchmarkları denedim (YARV kendi deposunda Ruby 1.9 ile birleştirilmiş durumda). Sonuçlar şöyle (Küçük sonuçlar daha iyi):

ackermann:
----------------
Perl: 53.394 saniye
mzscheme: 19.598 saniye
Python: 52.854 saniye
YARV: 12.080 saniye

fibonacci:
-------------
Perl: 42.512 s
mzscheme: 7.602 s
Python: 15.595 s
YARV: 10.174 s

tak:
----
Perl: 93.649 s
mzscheme: 11.965 s
Python: 22.505 s
YARV: 12.297 s

librid
yaklaşık 19 yıl önce

Not: Testlerden önce sistem runlevel 1'e düşürülerek arkaplandaki tüm prosesler sonlandırıldı bu yüzden rakamlarda yanılma payı düşük.

FZ
yaklaşık 19 yıl önce

Perl 6 çıksın bir hele, sonra yine bençmark yapalım ;-)

librid
yaklaşık 19 yıl önce

Keşke Perl 6 yakında çıkacak olsaydı... Bazı ciddi Perl'cüler Perl 6 çıkana kadar Ruby kullanmaya başladılar bile ;-)

roktas
yaklaşık 19 yıl önce

tak: ---- Perl: 93.649 s mzscheme: 11.965 s Python: 22.505 s YARV: 12.297 s

Bu kısım ilgimi çekti. Perl:Python arasında 93s:22s ~ 1:4'lük bir hız farkı gösteriyor. Olabilir tabii, çok da anormal bir fark değil (10 kat olsa o zaman gerçek bir sorun var diyebilirdim). Günlük işler Takeuchi (tak) problemiyle dolu değil gerçi ama; AMD Athlon 32, i386 mimarisinde, benim yaptığım basit test bu kadar büyük bir fark vermedi: 'time perl5.8.7 tac.pl':'time python2.4 tac.py' ~ 18s:10s, yani 1:1.8'lik bir fark gözledim. Not olarak geçeyim.

librid
yaklaşık 19 yıl önce

Evet ordaki orantısız farklılık benim de dikkatimi çekti ama Python YARV karşılaştırmasına yoğunlaştığım için fazla önemsememiştim :-) Tekrar baktım, burdaki sorun makinanın 256MB hafızasının Perl programı (tak.pl) için yeterli gelmemesiymiş. Makine swap kullanmaya başlayınca haliyle böyle abartılı bir farklılık meydana geliyor. Makinenizin hafızası sanıyorum 256'dan fazla ki doğru ölçüm yapabilmişsiniz. Perl'in ismini de böylece temize çıkarmış olalım :-)

roktas
yaklaşık 19 yıl önce

Hmm, emin misiniz buna? Sizin makinedeki özel durumu bilemem, ama oradan yola çıkarak bu test hatasının nedeni hakkında, her 256 MB'lik (ve daha küçük bellekli) makine için böyle bir genelleme yapmak hiç doğru olmaz. 256 MB bu uygulama için _çok_ büyük bir rakam. Perl'ün, bu kadar bellek bir yana, çok daha küçük belleklerde paşa paşa çalıştığını bilirim. Debian GNU/Linux dağıtımında her sisteme kurulan temel bir bileşenden bahsediyoruz. ;-)

roktas
yaklaşık 19 yıl önce

Tamam, şimdi gözledim. Test boyunca boş bellek hızla azalıyor (Python ve Ruby'de olmayan bir durum). Bu bana bir hata gibi geliyor ama, perl5-porters'a soracağım.

librid
yaklaşık 19 yıl önce

Hay Allah, tam ben yanıt yazarken siz de düzeltme yapmışsınız :-) Bence sormak için boşuna vakit kaybetmeyin sorun büyük ihtimalle Perl'den değil tak.pl'nin yazılış tarzından kaynaklanıyor.

librid
yaklaşık 19 yıl önce

Evet eminim. Durumun benim makineme özel olmadığını iddia etmiyorum çünkü benimkinde olduğu gibi iki tane bash shell çalıştırmayan veya dietlibc vb. kullanılan başka bir 256MB'lık makinede belki de swap'e ihtiyaç duymadan program sonlanabilirdi fakat benim makinem bir süre sonra swap kullanmaya başlıyor. Genelleme yapmak bu yüzden doğru olmayabilir haklısınız. Zaten amaç ordaki uyduruk bir tak.pl'nin kaç en az MB'lık bir makinede çalıştığını bulmak değil neden o rakam böyle büyük çıkmış onu anlamaya çalışmak. İnanmıyorsanız hafıza kullanımnı grafik olarak gösteren appletlerden birini açın ve YARV paketinden çıkan tak.pl yi çalıştırın. Siz zaten Paul Graham'ın o yazısında Ruby'den bahsettiğine de inanmamıştınız değil mi? :-) Lütfen gördüğünüz şeyi buraya da yazın ki insanlar bir kaç satır kodla bilgisayarın hafızasını doldurabilmenin kullanılan dil ortamının düşük hafızalı makinelerde çalışabilmesi durumunda mümkün olmadığı gibi saçma bir fikre kapılmasınlar.

roktas
yaklaşık 19 yıl önce

Pes valla, korkmaya başladım. Bir harfi yanlış yazsak hesabını soracaksınız gelecekte. :-) Çoktan unuttuğum bir Graham konusunu çıkartmışsınız ortaya. Amacım size özel bir kusur keşfetmek değil, hiç kimse için yapmam bunu. Altı üstü sohbet ediyoruz burada. Ne bu benchmark'ları ne de burada dönüp duran "tartışmaları" _bu denli_ ciddiye almayın. Basit bir öneri sadece, çok kişisel algılamayın.

yilmaz
yaklaşık 19 yıl önce

Hız artık o kadar önemli mi?
Şimdi nereye dönüp baksak (MS sayesinde) her yer xeon 2,8 server olmuş. Desktoplar 1,0 ghz altında yok nerdeyse ram desen en ufak 256 var.
Programlama dilinin yada vm nin hızlı olup olmaması o kadar önemli mi?

ttk
yaklaşık 19 yıl önce

Merhaba

Ms sayesinde artık demode olan ama hızı "hız da hız" diye tepinmeyen kullanıcılar için yeterli olan işlemci ve anakartları ucuza almak mümkün oluyor. 128 Mb Ram + PII 350mhz 15 GB diskli bir makinada çok rahat mesela window 2000 prof. veya yeterli sayılabilecek hızda Knoppix (Debian'ın yavrusu - diske yükleyerek denemiştim, 2.4 veya 2.6 çekirdekli bir sürümü idi) çalışabiliyor. Sistemin kaportasına da "MS sağolsun" çıkartması yapıştırsak tamam olacak :)

anonim
yaklaşık 19 yıl önce

Aslında hız meselesi uygulamaya göre değişir. Sistem yazılımları programlarken hafıza yönetimi ve cpu kullanımı çok önemlidir. Örnek olarak Linux'da KDE ve GNOME arasındaki hız farkı iyi sistemlerde bilr fark ediliyor. Ancak bir muhasaba yada otomasyon uygulaması için hız farkı yeni sistemlerde fark edilmeyecektir. Bu yüzden bu tarz uygulamalar için hafıza yönetimi tür tanımlamaları gibi işlerle programcıyı yormayacak bir dil kullanmak daha akıllıca olacaktır.

roktas
yaklaşık 19 yıl önce

Hız artık o kadar önemli mi? Şimdi nereye dönüp baksak (MS sayesinde) her yer xeon 2,8 server olmuş. Desktoplar 1,0 ghz altında yok nerdeyse ram desen en ufak 256 var.

... ve o canavarlar makinelerde OpenOffice'i başlatırken çay almaya gidiyorum hâlâ ;-)

tongucyumruk
yaklaşık 19 yıl önce

"Hızlı ve gelişmiş bilgisayarlar tembel programcılar üretir."
Robert Hummel

ileriseviye.org sağolsun...

Zebani
yaklaşık 19 yıl önce

Yav çok güldüm valla. ;-) Ne de olsa zaman da, hız da göreceli. Bakınız Albert Einstein. :)

Anduril
yaklaşık 19 yıl önce

Hadi oradan da optik bilgisayarlara girelim :)

Görüş belirtmek için giriş yapın...

İlgili Yazılar

All Plan ve Cinema 4d Türkiye tanıtımı başladı

redogre
17 Haziran 2001, 1 dakika okuma süresi

All plan den hatırlayacağınız Alman Nemetschek firması Cinema 4D adlı 3 boyutlu çizim programını da bünyesine kattı. Aluplan firmasının Türkiye'ye getirdiği Allplan ve Cinema 4D programlarının tanıtımını ve eğitimini FGA Mimarlık veriyor. Firmanın sitesinde hem programlarla ilgili bilgi hem, tutorial lar hem de patch ler var.

Bir programcı gözüyle DNA

tongucyumruk
18 Ocak 2003, 1 dakika okuma süresi

"Eğer bir çekiçseniz, herşey bir çivi gibi gözükecektir".

Sanıyorum özellikle bu siteyi takip eden programcıların çoğu en az bir kez biyolojik yapılarla bilgisayarlar arasında bir bağlantı kurmaya çalışmıştır. Bu site DNA'dan başlayıp proteinlere uzanarak bilgisayar kavramları ile bu kavramların biyolojik karşılıkları konusunda oldukça detaylı bir inceleme içeriyor. Eğer kendini 4'lük sistemde (T, G, C, A) çalışan bir robot olarak ifade edenlerdenseniz bir uğramanızda fayda var.

Özgür Dünya ve Müzik Eğitimi: GNU Solfege

FZ
19 Ekim 2005, 1 dakika okuma süresi

Son kiii üç dört!

GNU Solfege, GNU/Linux ve MS Windows sistemler üzerinde çalışan bir solfej ve kulak eğitimi yazılımı.

Melodik ve armonik aralıklarını tanımak, aralık boylarını kıyaslamak, bilgisayarın gösterdiği aralıkları söylemek, akorları tanımak, akorları söylemek gibi konularda kullanıcıyı eğitmeyi amaçlayan program sonsuz sabırlı bir müzik eğitmeni olarak görevini yerine getirmeye çalışıyor.

Yazılımın dokümantasyonunu okuyup daha çok bilgi sahibi olabilir, ekran görüntülerine bakabilir ya da UNIX Review dergisinden Marcel Gagné'nin GNU Solfege eleştirisine göz atabilirsiniz.

Magento 1.0 Kararlı Sürümü Yayında

sempsteen
3 Nisan 2008, 1 dakika okuma süresi

Oldukça başarılı bir geliştirme süreci geçiren, Zend Framework üzerine kurulu, piyasadaki rakiplerine uzak ara fark atan, açık kaynak kodlu e-ticaret platformu Magento'nun uzun süredir beklenen 1.0 kararlı sürümü bugün (10 dk önce) yayınlandı.

Açık Kodlu Özgür Bir Yazılım Projesi: FlightGear Uçuş Simülatörü

FZ
16 Ocak 2004, 1 dakika okuma süresi

1995 yılında havacılık simülasyonları konusunda uzmanlaşmış Curtis Olson isimli bir mühedis Microsoft Flight Simulator´a bir eklenti (add-on) yapmaya çalışırken vaktinin büyük bir kısmını asıl iş yerine bu yazılımın dosya formatlarını, iç yapısını, işleyişini, vs. anlamak için enerji harcayarak geçirdiğini fark etti. Ve kendine şöyle dedi: Oturup kendi uçuş simülatörümü yazmaya başlasam, bunu açık kodlu ve GPL lisanslı olarak kamuoyuna sunsam ve sonra...

Olson´un bu çabası ABD´de çılgın bir mühendisin delidolu idealizmi olarak algılanmadı tahmin edebileceğiniz gibi. Proje başladıktan kısa bir süre NASA´daki uzay mekiği programının önemli mühendislerinden biri olan Jon Berndt de projeye destek vermeye başladı. Bu katılımı takiben, bir başka mühendis Tony Peden de projeye katılmakta tereddüt etmedi. Ve gerisi büyük hızla geldi.

FlightGear isimli bu özgür yazılım projesine destek veren deneyimli programcı ve mühendislerin yaş ortalaması 35´in üstünde. Hepsi de kendi alanlarındaki mühendislik ve fizik konularında usta isimler. Geliştirdikleri sistem uç noktadaki havacılık mühendisliği modellerini, grafik (OpenGL) ve ağ programlama tekniklerini kullanıyor. Herkesi sistemlerini incelemeye ve katkıda bulunmaya davet ediyorlar.