Bir programlama dilinin “hızını” ne belirler?


38

Bir programın iki ayrı dilde yazıldığını varsayalım, derleyicileri aynı bayt kodunu oluşturursa, neden X dili ve Y dili olsunlar, neden Y dili yerine X dilini kullanmalıyım? Bir dilin diğerinden daha hızlı olduğunu ne tanımlar?

Bunu soruyorum çünkü çoğu zaman insanların şöyle şeyler söylediğini görürsünüz: "C en hızlı dildir, ATS C kadar hızlı bir dildir". Programlama dilleri için "hızlı" tanımını anlamaya çalışıyordum.


21
Bir program diğerinden daha hızlıysa, aynı bayt koduna sahip olamayacakları anlamına gelir.
svick

5
Diller sadece birinin program yazmak için kullandığı bir kavramdır, bu nedenle bir dilin hızı hakkında konuşamazsınız .
Juho

1
@Raphael Konu dışı, belirsiz ve çok geniş olduğunu hissediyorum. Konu Yazılım Mühendisliği için daha uygun olsa da , orada "çok geniş" olarak kapanacağından şüpheleniyorum.
David Richerby

2
Uygulama bir yana, "hız", uygulanması derleme yürütülmesi ve hata ayıklama için farklı hızlar vardır, belirsiz ve genel olarak diğerlerine (Aksi hepimiz kullanarak olurdu bazı off ticaret olacağız programlama dilini)
Nick T

Yukarıdaki gibi. Diller aynı bayt kodunu oluşturmaz. Bazı dillerin bayt koduna ayrıştırılması daha kolaydır. Bazıları daha yüksek bir soyutlama seviyesine sahiptir.
superluminary,

Yanıtlar:


23

Bir dilin üzerinde X dili seçmek için düşünülebilecek birçok neden vardır. Y Program okunabilirliği, programlama kolaylığı, birçok platforma taşınabilirlik, iyi programlama ortamlarının varlığı bu gibi nedenler olabilir. Ancak, sadece soruda istendiği şekilde icra hızını dikkate alacağım. Sorunun, örneğin, gelişme hızını dikkate almadığı görülüyor.

İki dil aynı bayt kodunu derleyebilir, ancak aynı kodun üretileceği anlamına gelmez,

Aslında bayt kodu yalnızca belirli bir sanal makine için koddur. Mühendislik avantajlarına sahip, ancak doğrudan belirli bir donanım için derleme ile temel farklılıklar getirmiyor. Dolayısıyla, aynı makinede doğrudan yürütme için derlenmiş iki dili karşılaştırmayı düşünebilirsiniz.

Bu, göreceli dil hızının, ilk derleyicilere dayanan eski bir konu olduğunu söyledi.

Uzun yıllar boyunca, bu ilk zamanlarda, profesyonel el yazısıyla yazılmış kodun derlenmiş koddan daha hızlı olduğunu düşündü. Başka bir deyişle, makine dili Cobol veya Fortran gibi yüksek seviyeli dillerden daha hızlı kabul edildi. Ve hem daha hızlı hem de genellikle daha küçüktü. Yüksek seviyeli diller hâlâ gelişti, çünkü bilgisayar bilimcisi olmayan birçok insan için kullanımı çok daha kolaydı. Hatta yüksek seviyeli dilleri kullanmanın bir adı bile vardı: Oluşturulan kodun büyüklüğünü (bu zamanlarda çok önemli bir sorun olan) ya da gerçekte yürütülen talimatların sayısını etkileyebilecek genişleme oranı. Konsept esas olarak deneyseldi, ancak derleyici bugün standartlara göre oldukça basit bir fikirli iş yaptığı için ilk önce oran 1'den büyüktü.

Böylece makine dili, söylenenden daha hızlıydı, Fortran.

Elbette, bu derleyiciler yıllar geçtikçe değişti, montaj dilinde programlama artık çok nadirdi. Çoğu uygulama için, derleme dili programları, derleyicileri optimize ederek oluşturulan kodla yetersiz rekabet eder.

Bu, bir ana meselenin, ele alınan dil için mevcut derleyicilerin kalitesi, kaynak kodu analiz etme ve buna göre optimize etme olduğunu göstermektedir.

Bu yetenek, bazılarının, derleyici için çalışmayı kolaylaştırmak amacıyla kaynağın yapısal ve matematiksel özelliklerini vurgulamak için dilin özelliklerini genişletmesine bağlı olabilir. Örneğin, bir dil, derleyicinin bu özellikleri optimizasyon amacıyla kullanmasına izin verecek şekilde, kullanıcı tanımlı fonksiyonların cebirsel özellikleri ile ilgili ifadelerin eklenmesine izin verebilir.

Derleme işlemi daha kolay olabilir; bu nedenle, dilin programlama paradigması, kodu ister gerçek ister sanal makine olsun, kodu zorlayacak makinelerin özelliklerine daha yakın olduğunda daha iyi kod üretebilir.

Diğer bir nokta, dilde uygulanan paradigmaların programlanan problem türüne kapalı olup olmadığıdır. Belirli programlama paradigmaları için uzmanlaşmış bir programlama dilinin, bu paradigma ile ilgili çok verimli özellikleri derlemesi beklenir. Bu nedenle, bir programlama dilinin seçimi, açıklığa ve hıza göre, programlanan soruna uyarlanmış bir programlama dilinin seçimine bağlı olabilir.

C'nin sistem programlaması için popülaritesi muhtemelen C'nin makine mimarisine yakın olmasından ve bu sistem programlamasının da doğrudan bu mimariyle ilgili olmasından kaynaklanmaktadır.

Mantıksal programlama ve kısıtlama çözümleme dilleri kullanılarak daha hızlı çalıştırma ile başka bir problem daha kolay programlanacaktır .

Karmaşık reaktif sistemler , bu sistemler hakkında çok özel bilgiler içeren ve çok hızlı kod üreten Esterel gibi özel senkronize programlama dilleri ile çok verimli bir şekilde programlanabilir .

Veya aşırı bir örnek almak gerekirse, bazı diller, ayrıştırıcıları programlamak için kullanılan sözdizimi açıklama dilleri gibi oldukça uzmanlaşmıştır. Bir ayrıştırıcı jeneratör şey ama böyle diller için bir derleyici. Elbette Turing tam değil, ama bu derleyiciler uzmanlık alanlarına göre oldukça iyi: verimli ayrıştırma programları üretiyorlar. Bilginin sınırlı olduğu alan, optimizasyon teknikleri çok özel ve çok ince bir şekilde ayarlanabilir. Bu ayrıştırıcı jeneratörler, başka bir dilde kod yazarak elde edilebileceklerden çok daha iyidir. Sınırlı bir problem sınıfı için mükemmel ve hızlı kod üreten derleyicilere sahip çok sayıda özel dil vardır.

Bu nedenle, büyük bir sistem yazarken, tek bir dile güvenmemek, sistemin farklı bileşenleri için en iyi dili seçmeniz tavsiye edilebilir. Bu, elbette, uyumluluk sorunlarını da beraberinde getirir.

Genellikle önemli olan bir başka nokta, programlanan konular için verimli kütüphanelerin varlığıdır.

Son olarak, hız tek kriter değildir ve kod güvenliği (hatalı girdi veya sistem hatalarına karşı esneklik için örnek olarak), bellek kullanımı, programlama kolaylığı (paradigma uyumluluğu gerçekten yardımcı olabilirse de) kod güvenliği gibi diğer kriterlerle çelişebilir ), nesne kodu boyutu, programın bakımı, vb.

Hız her zaman en önemli parametre değildir. Ayrıca, ortalama karmaşıklık ya da daha kötü durum karmaşıklığı olabilen karmaşıklık gibi farklı görüşler de alabilir. Ayrıca, daha küçük bir programda olduğu gibi büyük bir sistemde, hızın kritik olduğu kısımlar ve önemsiz olduğu yerler var. Ve bunu önceden belirlemek her zaman kolay değildir.


Teşekkürler. Onun gibi bir şey. İçin bakıyordum. Konu için malzeme bulmak zordu. Bu yeterince açık.
Rodrigo Valente

@ RodrigoAraújoValente Teşekkürler, Bu soruya bakmak isteyebilirsiniz . Ekstremist bir görüş, L dili için bir derleyicinin, L için bir tercümanı programın kaynak koduyla hiçbir şey yapmadan paketleyebilmesidir. Ardından, paketin hesaplamasını optimize etmeye çalışarak daha iyisini yapabilirsiniz (kısmi değerlendirme). Ne kadar çok optimize edersen ve dil o kadar hızlı olur. O zaman soru şudur: optimize etmenize yardımcı olacak ne var? Cevaplar uzmanlık alanıyla ilgili iyi bilgiler, programcıdan yardım, karmaşık analiz, vb. Bilgileri içerebilir ...
babou

"Aynı bytecode" ile, "aynı türde çalıştırılabilir gösterim" anlamına geldiğini tahmin ediyorum . Açıkçası aynı çalıştırılabilirler aynı hızda çalışacaktır (aynı çalıştırma sistemini varsayarsak). (Muhtemelen buna bir bilgi / iletişim perspektifinden bakacaktım. Teorik olarak , bir programcı program ve donanım hakkında her şeyi bilir, oysa bir dil genellikle iletişimi kısıtlar (hangi düzenlemelere izin verildiğini veya yararlı olduğunu sınırlar) ve derleyici bilmeyebilir mikro mimari detaylar Derleme ve derleyici geliştirme, geliştirme ve eğitime çözüm sunuyor ...
Paul A. Clayton

Bu daha sonra, insanların genellikle hangi bilgisayarların genellikle iyi olduklarına (örneğin, kayıt tutma ve "aritmetik") karşı genel olarak neyin iyi olduğunu (örneğin genel kalıpları tanıyarak) alır. Ek olarak, çalışma zamanı bilgilerinin iletişimi çoğu zaman bilgisayar dostudur (profil kılavuzlu optimizasyon, programlama dili aracılığıyla iletilen bazı bilgi eksikliklerinin üstesinden gelebilir). Dinamik optimizasyon insan programcıları ile pratik olmaz ...
Paul A. Clayton

(aynı şekilde tüm yazılımların belirli bir donanımı hedef alan yetenekli programcılar tarafından montaj halinde yazılması söylenebilir olsa da, yazılım optimize edildiğinde sadece donanım değişmeyecek, yazılım eskimiş olacaktır.)
Paul A. Clayton

16

Her şey sonunda CPU'da * çalıştırılırken, farklı diller arasında çeşitli farklılıklar vardır. İşte bazı örnekler.

Yorumlanan diller Bazı diller derlenmek yerine yorumlanır , örneğin Python, Ruby ve Matlab. Bu, Python ve Ruby kodunun makine kodunu derlemediği, ancak anında yorumlandığı anlamına gelir. Python ve Ruby'yi sanal bir makinede derlemek mümkündür (bir sonraki noktaya bakınız). Ayrıca bu soruya bakınız . Yorumlama genellikle çeşitli nedenlerden dolayı derlenmiş koddan daha yavaştır. Yorumun kendisi yavaş olmakla kalmaz, aynı zamanda optimizasyon yapmak da zordur. Bununla birlikte, kodunuz çoğu zaman kütüphane işlevlerinde (Matlab durumunda) harcıyorsa, performans zarar görmez.

Sanal makine Bazı diller , daha sonra yorumlanan, icat edilen bir "makine kodu" olan bytecode'da derlenmiştir . En önemli örneklerden bazıları Java ve C #. Bayt kodu anında makine koduna dönüştürülebilirken, kod muhtemelen daha yavaş çalışacaktır. Java durumunda, taşınabilirlik için sanal bir makine kullanılır. C # durumunda, güvenlik gibi başka endişeler olabilir.

Genel gider Bazı diller verimlilik için ticarette işlem yapar. Örneğin, Pascal'ın bazı sürümleri, sınırların dışındaki bir diziye erişmediğinizi kontrol eder. C # kodu "yönetiliyor" ve bunun bir bedeli var. Diğer bir yaygın örnek, programlayıcı için zaman kazandıran, ancak bellek yönetimindeki eller kadar verimli olmayan çöp toplamadır. İstisna yönetimi veya nesne yönelimli programlamayı desteklemek için altyapı gibi başka genel gider kaynakları da vardır.

* Aslında, günümüzde yüksek performanslı sistemler GPU'larda ve hatta FPGA'larda kod çalıştırmaktadır.


Öyleyse, daha fazla performansa ihtiyacım olursa derlenmiş dilleri kullanmalı mıyım? Ve paradigmalar hakkında? Oop yerine işlevsel seçmek için bir neden var mı?
Rodrigo Valente

Çöp toplama ile ilgili düşünceniz biraz basittir. Ayrılan bellek artık kullanılmadığında, statik olarak her zaman karar verilemez. Karar verilebilir olsa bile, hata yapmadan belirlemek çok zor olabilir. Bu nedenle, GC bazen gereklidir ve genellikle daha güvenlidir (kontrol sınırları gibi). Ayrıca, açıkça bırakılan yayınlarla birleştirilebilir.
babou

@ RodrigoAraújoValente Bağlıdır. Crappy kod genellikle crappy kodunu derler. Belki kod Eğer Python yazabilirsiniz aslında kodu daha hızlı olduğunu sen C. yazabilirsiniz
Raphael

nit: bağlantılı olduğunuz soru ile açıklandığı gibi, python aslında "anında" yorumlu değil :) :)
Eevee

Yorumlanan bölümde bahsettiğiniz dillerin hiçbiri anında yorumlanmaz. Python bytecode'a derlenir, Ruby AST'ye derlendi, ama şimdi bytecode'a derlendiğine inanıyorum. Matlab, inanıyorum ki şimdi JIT derlendi. Aslında, en azından bir tür sanal makine sunumunu derlemek yerine, hareket halindeki şeyleri yorumlayan hiçbir niş olmayan dil uygulaması bilmiyorum.
Winston Ewert

5

Y yerine X'i seçmek için farklı faktörler vardır.

  • Öğrenme kolaylığı
  • Anlayış kolaylığı
  • Gelişme hızı
  • Doğru kodun uygulanmasında yardım
  • Derlenmiş kodun performansı
  • Desteklenen platform ortamları
  • taşınabilirlik
  • Amaca uygun

Bazı diller, C # veya Python gibi iş projeleri geliştirmek için uygundur, ancak bir kısmı da C ++ gibi sistem programlaması için iyidir.

Hangi platformda çalışacağınızı ve hangi uygulamayı yaratacağınızı belirlemelisiniz.


1
Peki, derlenmiş kodun performansını nasıl belirleyebilirim? Temelde bu soruyu yapmamı sağlayan şey buydu.
Rodrigo Valente

6
Bu cevabın kesinlikle iyi bir tavsiyesi var, ancak bir dil için bir seçim faktörü olarak hız ile ilgili olan soruyu nasıl cevapladığını göremiyorum.
babou

RodrigoAraújoValente @ Hatta olmayabilir edilmesi (dil yorumlanır ise) kodu derlenmiş.
Raphael

1
"İyi kütüphaneler" ve "İyi araçlar" eklemek isteyebilirsiniz.
Raphael

@ RodrigoAraújoValente Siz çalıştırın ve profilleyin.
Kyle,

2

Herhangi bir platformla alabileceğiniz "en hızlı" programlama dili, uğraştığınız yonga setinin birleştirme dilidir. Bu seviyede çeviri yok. Bununla birlikte, yonga setinin, özellikle paralel işler yapabilen talimatları nasıl yerine getirdiği hakkında biraz bilgi sahibi olmak gerekir.

C'den montaja dönüşüm çok bire yakındır, bire yakındır ancak daha okunaklıdır. Bununla birlikte, taşınabilirliği geliştirmek için standart kütüphanelerden ötürü çok fazla katmanı vardır. Derleyicinin montaj koduna ulaşmak için yapması gereken pek çok şey yoktur ve daha güçlü optimizasyonlar genellikle makineye özgü değişiklikler yapmak için vardır.

C ++ daha zengin bir dil ekler. Ancak, dil çok fazla karmaşıklık eklediğinden, derleyicinin platform için en uygun kodu oluşturması zorlaşır.

Sonra ölçeğin diğer tarafına gideriz. Yorumlanan diller Bunlar en yavaş olma eğilimindedir çünkü işi yapmanın yanı sıra kodu çözmek ve makine aramalarına dönüştürmek için biraz zaman harcanır.

O zaman aramızda olanlar var. Genellikle platform için optimize edilmiş sanal bir makine katmanına sahiptirler. Ve derleyici, sanal makinenin çalışması için kod oluşturacaktır. Bazen bu bir anda perl veya pascal, ruby ​​veya Python gibi olur. Veya java gibi birkaç aşamada.

Bu sanal makinelerin bazıları, ara bayt kodunu çevirmekten ziyade makine düzeyinde kod oluşturarak çalışma süresini hızlandıran bir JIT derleyicisi kavramını da ekliyor.

Bazı sanal makineler, bayt kodundan makine koduna daha az çeviri yapılmasına izin veren düşük düzeydedir. Taşınabilirliği korurken işler hızlanır.


Tarihsel olarak, C, makine koduna kolay çeviri sağlamak için tasarlanmıştır. Bununla birlikte, gittikçe artan oranda, C'yi etkin C koduna dönüştürmek, bir derleyicinin bir programcının ne yapmaya çalıştığını bulmasını ve daha sonra bu niyeti makine koduna çevirmesini gerektirir. Örneğin, tarihsel olarak, birçok makinedeki makine kodu eşdeğeri , birçok işlemciden *p++=*q++;daha hızlıdır array1[i]=array2[i];ancak çoğu işlemcide tersi doğrudur ve bu nedenle, derleyiciler, eski kod stilini ikincisine dönüştürür - en sonunda "sığ" bir dönüşüm.
supercat

Bu genellikle -O0yaparsanız herhangi bir optimizasyon yapmaz. Optimizasyonlar, derleyici ile elde ettiğiniz bir ikramiyedir, ancak kendi içindeki dil bir veya bir tanesine montaj için çevrilebilir.
Arşimet Trajano

2

Henüz belirtilmeyen bir nokta, bazı dillerde aynı kod parçasını birçok kez çalıştırmanın her zaman aynı eylem sırasını gerçekleştireceğidir; bu nedenle bilgisayarın kod bölümünün ne yapması gerektiğini yalnızca bir kez belirlemesi gerekir. JavaScript'in "katı kullanımı" lehçesinin en büyük yararlarından biri, JavaScript motorunun bir kod parçasının ne yaptığını öğrenmesi, bir sonraki çalıştırılışında bu bilgileri kullanabilmesidir; "sıkı kullan" olmadan yapamazsınız.

Örneğin, "kullanımı sıkı" yokluğunda, şöyle bir kod parçası:

function f() { return x; }

bir dış arama bağlamında bir değişken veya X varsa, hemen arama bağlamında X değişkenini döndürebilir veya döndürebilir Undefined. Daha kötüsü, şöyle bir döngüde:

for (i=0; i<40; i+=1) { g(i); }

JavaScript motorunun bu konuda [veya g()onunla ne yapabileceğini bilmesi imümkün gdeğildir. Yana gveya iyasal şekilde değişiklik olabilir iiçin bitti şey var, JavaScript motoru basitçe eğer ikisinden biri işlev çağrılarının görmek için döngü kontrolü sürecine her geçişte sayısal toplama ve döngüde sayısal karşılaştırma, ancak zorunluluk bir dizeye kullanamaz iveya g. Buna karşılık, "katı kullanım" [biraz mantıklı] lehçesinde JavaScipt motoru yukarıdaki kodu inceleyebilir ve döngüden geçen her geçişin aynı sayısal değişkeni kullanacağını ve aynı işlevi çalıştıracağını bilir. Bu nedenle sadece tanımlaması ive çalışması gerekirg bir kez, döngü boyunca her geçişte onları aramak zorunda kalmak yerine - önemli bir zaman tasarrufu.


2

Burada oldukça profesyonel cevaplar var, bu onlara çok yakın değil ama sizin için sezgisel olabilir.

Bir görevi olabildiğince hızlı bir şekilde yapmanız gerektiğinde, onu derleme içinde yürüten kodu yazmak isteyeceğinizi defalarca duymuş olabilirsiniz. Çünkü sadece görevi tamamlamak için ihtiyaç duyduğunuz ve başka bir şey yapmamanız gereken komutları yerine getiriyorsunuz. Yüksek seviyede bir dilde bu görevi birkaç satırda uygulayabiliyorsanız, derleyicinin yine de onları makine diline çevirmesi gerekir. Bu çeviri doğrudan yazabileceğiniz gibi her zaman minimalist değildir. Bu, makinenin yedekleyebileceğiniz komutları çalıştırmak için birçok saat harcayacağı anlamına gelir.

Derleyiciler bugün çok karmaşık olmasına rağmen, en iyi montaj programcılarının yapabilecekleri kadar etkili değillerdir.

Bu doğrultuda devam etmeyen, gereksiz komutlar, dil seviyesi yükseldikçe (genellikle) miktarlarında büyür. (Bu tüm yüksek seviyeli diller için% 100 doğru değildir)

Bana göre, belirli bir kod parçası için, X'in makine kodu Y'den daha kısaysa, X dili Y diline (çalışma zamanında) göre daha hızlıdır.


Montaj tamamen kayalar. Yine de en iyi derleyicileri geride bırakmak gerçek bir sanatçıyı gerektirir.
Johan,

1

Bu soruyu kesin olarak cevaplamak zordur, çünkü çok karmaşık ve çok boyutludur (neredeyse otomobil markalarını yanlış kriterler ile karşılaştırmak gibi) ancak Rosetta kodu olarak bilinen mükemmel bir kod deposu ( wikipedia bakış ) dahil olmak üzere yeni bilimsel çalışmalar var . Nanz ve Furia tarafından yapılan bu 2014 araştırması , bu soruyu, aşağıdaki tipik kriterlere ve tipik olarak öznel kod niteliklerinin nadir bir nicel analizine dayanarak oldukça kesin ve bilimsel olarak incelemektedir. Özet, nesnel temelli bulgular ve genellemeler içermektedir. (Umarım bu sonuçlara dayanan diğer çalışmalar gelecekte yapılabilir.)

  • MM1. Hangi programlama dilleri daha kısa kod için?

  • RQ2. Hangi programlama dilleri daha küçük çalıştırılabilir dosyalara derlenir?

  • RQ3. Hangi programlama dilleri daha iyi çalışma zamanı performansına sahip?

  • RQ4. Hangi programlama dilleri belleği daha verimli kullanır?

  • RQ5. Hangi programlama dilleri daha az başarısızlığa açıktır?

Özet — Bazen programlama dilleri konusundaki tartışmalar bilimsel olmaktan daha dindardır. Hangi dilin daha özlü ya da verimli olduğu ya da geliştiricileri daha verimli hale getirdiği konusundaki sorular hevesle tartışılıyor ve cevapları çoğu zaman fıkralara ve doğrulanmamış inançlara dayanıyor. Bu çalışmada, analiz için geniş bir veri seti sunan, çeşitli dillerdeki ortak programlama görevlerine yönelik bir çözüm kodu olan Rosetta Code'un kullanılmayan araştırma potansiyelini kullanıyoruz. Çalışmamız, büyük programlama paradigmalarını temsil eden yaygın olarak kullanılan 8 dilde 745 göreve karşılık gelen 7,087 çözüm programına dayanmaktadır (işlemsel: C ve Go; nesne yönelimli: C # ve Java; işlevsel: F # ve Haskell; komut dosyası: Python ve Ruby). İstatistiksel analizimiz, en önemlisi, şunu göstermektedir: işlevsel ve betik dilleri usule dayalı ve nesne yönelimli dillerden daha özlüdür; C, büyük girdilerde ham hız söz konusu olduğunda yenmek zordur, ancak orta büyüklükteki girdiler üzerindeki performans farkları daha az belirgindir ve yorumlanan dillerin bile rekabetçi olmasını sağlar; Derleme zamanında daha fazla hataya yakalanabilen, güçlü şekilde yazılmış diller, çalışma zamanı başarısızlıklarına yorumlanmış veya zayıf yazılmış dillerden daha az eğilimlidir. Geliştiriciler, dil tasarımcıları ve eğitimciler için bu sonuçların sonuçlarını tartışıyoruz. Derleme zamanında daha fazla hata yakalanabiliyorsa, çalışma zamanı başarısızlıklarına yorumlanmış veya zayıf yazılmış dillerden daha az eğilimlidir. Geliştiriciler, dil tasarımcıları ve eğitimciler için bu sonuçların sonuçlarını tartışıyoruz. Derleme zamanında daha fazla hata yakalanabiliyorsa, çalışma zamanı başarısızlıklarına yorumlanmış veya zayıf yazılmış dillerden daha az eğilimlidir. Geliştiriciler, dil tasarımcıları ve eğitimciler için bu sonuçların sonuçlarını tartışıyoruz.


0

Bilgisayar dilleri, bilgisayarın ne yapması gerektiğini açıklamak için bir komutlar soyutlamasıdır.

Hatta bilgisayar dilinde yazabilir Pythonve bir C derleyicisi (cython) ile derleyebilirsiniz.

Bunu akılda tutarak bilgisayar dillerinin hızları karşılaştırılamaz.

Ancak, aynı dilin derleyicilerini bir dereceye kadar karşılaştırabilirsiniz. Örneğin, GNU Cderleyici ve Intel Cderleyici. (Derleyici karşılaştırma ölçütü arayın)


2
Soru hakkında yorum yapmak istiyorsanız, lütfen cevabınızı değil yorum kutusunu kullanın. Bunun Computer Science Yığın Borsası olduğunu ve bilgisayar biliminin programlama olmadığını, tıpkı edebiyatın kelime işlemesi olmadığını unutmayın. Programlama soruları Yazılım Mühendisliği veya Yığın Taşması ile ilgilidir .
David Richerby
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.