Bir programlama dilinin "hızını" ne yönetir?
Bir programlama dilinin "hızı" diye bir şey yoktur. Belirli bir programda, belirli bir ortamda çalışan belirli bir yürütme motorunun belirli bir uygulamasının belirli bir sürümü tarafından yürütülen belirli bir program yazıcısının hızı vardır.
Farklı uygulamalar kullanarak aynı makinede aynı dilde yazılmış aynı kodu çalıştırırken büyük performans farklılıkları olabilir. Hatta aynı uygulamanın farklı versiyonlarını kullanmak. Örneğin, aynı ECMAScript benchmarkını 10 yıl önceki SpiderMonkey sürümünü kullanarak aynı makinede çalıştırmak, bu yılın bir versiyonuna göre muhtemelen 2 × - 5 ×, belki de 10 × arasında bir performans artışı sağlayacaktır. Bu ECMAScript'in ECMAScript'ten 2 kat daha hızlı olduğu anlamına mı geliyor, çünkü aynı programı aynı makinede çalıştırmak, yeni uygulamada 2 kat daha hızlı mı? Bu mantıklı değil.
Bunun bellek yönetimi ile bir ilgisi var mı?
Pek sayılmaz.
Bu neden oluyor?
Kaynaklar. Para. Microsoft, muhtemelen derleyici programcıları için kahve yapan tüm PHP, Ruby ve Python topluluğunun VM'lerde çalışan insanlardan daha fazla istihdam ediyor.
Performansı bir şekilde etkileyen bir programlama dilinin az ya da çok özelliği için de bir çözüm vardır. Örneğin, C (burada C'yi, bazıları C'den önce bile var olan benzer dillerin sınıfı için bir stand-in olarak kullanıyorum) bellek güvenli değildir, böylece aynı anda çalışan birden fazla C programı birbirimizin hafızası. Böylece, sanal bellek yarattık ve tüm C programlarının bir dolaylı katmandan geçmesini sağladık, böylece makinede çalışan tek kişi olduklarını iddia edebilirler. Ancak, bu yavaştır ve bu yüzden MMU'yu icat ediyoruz ve hızlandırmak için donanıma sanal bellek uyguluyoruz.
Fakat! Hafızaya dayanıklı diller hepsine ihtiyaç duymaz! Sanal belleğe sahip olmak onlara bir bit yardımcı olmuyor. Aslında daha da kötüsü: sadece sanal bellek değil, aynı zamanda donanıma güvenli dillere yardımcı olmakla kalmaz, hatta donanımda kullanıldığında bile sanal bellek de performansı etkiler. Çöp toplayıcılarının performansına özellikle zarar verebilir (bu, bellekte güvenli dillerin önemli bir kullanımıdır).
Başka bir örnek: modern ana akım genel amaçlı CPU'lar, önbellek kayıplarının sıklığını azaltmak için karmaşık hileler kullanır. Bu numaraların çoğu, hangi kodun yürütüleceğini ve gelecekte hangi belleğe ihtiyaç duyulacağını tahmin etmeye çalışmakla ilgilidir. Bununla birlikte, yüksek çalışma zamanı dereceli polimorfizmi olan diller için (örn. OO dilleri), bu erişim modellerini tahmin etmek gerçekten, gerçekten zordur.
Ancak, başka bir yol daha var: önbellek kaçırma toplam maliyeti, bireysel önbellek kaçırma maliyeti ile çarpılan önbellek kaçırma sayısıdır. Yaygın CPU'lar özlüyor sayılarını azaltmaya çalışırlar, ancak tek bir özledim maliyetini düşürebilirseniz ne olur?
Azul Vega-3 CPU, sanallaştırılmış JVM'leri çalıştırmak için özel olarak tasarlanmıştır ve çöp toplama ve kaçış tespitine (statik kaçış analizine dinamik eşdeğer) ve güçlü bellek kontrolörlerine ve tüm sisteme yardımcı olmak için bazı özel talimatlar içeren çok güçlü bir MMU'ya sahiptir. 20000'den fazla olağanüstü önbellek özeti uçuşta hala ilerleme kaydedebilir. Ne yazık ki, çoğu dile özgü CPU gibi, tasarımı basit bir şekilde kullanılmış ve "dev" Intel, AMD, IBM ve benzeri kullanıcılar tarafından kaba bir şekilde zorlanmıştır.
CPU mimarisi, bir dilin yüksek performanslı bir uygulamasına sahip olmanın ne kadar kolay ya da ne kadar zor olduğu üzerinde etkili olan bir örnektir. Modern mainstream CPU programlama modeli için uygun olan C, C ++, D, Rust gibi bir dil, Java, ECMAScript, Python, Ruby gibi CPU'yu "dövmek" ve CPU'yu atlatmak isteyen bir dilden daha hızlı yapmak için daha kolay olacaktır PHP.
Gerçekten, hepsi para meselesi. ECMAScript’te yüksek performanslı bir algoritma geliştirmek için eşit miktarda para harcıyorsanız, ECMAScript’in yüksek performanslı bir uygulaması olan ECMAScript’te tasarlanmış yüksek performanslı bir işletim sistemi olan ECMAScript için tasarlanmış yüksek performanslı bir CPU’dur. C benzeri dilleri hızlı yapmak için on yıllardır, o zaman muhtemelen eşit performans göreceksiniz. Sadece, şu anda, ECMAScript benzeri dilleri hızlı yapmaktan çok C-benzeri dilleri hızlı yapmak için çok daha fazla para harcandı ve C-benzeri dillerin varsayımları MMU'lardan ve CPU'lardan işletim sistemlerine kadar tüm yığına yapıldı. sanal bellek sistemleri kütüphanelere ve çerçevelere kadar.
Şahsen, en çok Ruby'ye aşinayım (genellikle "yavaş dil" olarak kabul edilir), bu yüzden iki örnek vereceğim: HashRubinius'taki sınıf (Ruby'deki merkezi veri yapılarından biri, anahtar-değer sözlüğü) Ruby uygulaması% 100 saf Ruby ile yazılmıştır ve yaklaşık olarak aynı performansa sahiptir.HashYARV sınıfında (en çok kullanılan uygulama), C dilinde yazılmıştır. Ayrıca YARV için C uzantısı olarak yazılmış bir görüntü işleme kitaplığı vardır; tonlarca dinamik ve yansıtıcı Ruby hilesi kullanan C'yi desteklemiyor; Oracle Labs'ın Truffle AST tercüman çerçevesi ve Graal JIT derleme çerçevesini kullanan deneysel bir JRuby şubesi, YARV'ın orijinal olarak optimize edilmiş C versiyonunu çalıştırabildiği kadar saf Ruby "geri çekilme versiyonunu" uygulayabilir. Bu basitçe (her şeyden başka bir şey değil) dinamik çalışma zamanı optimizasyonları, JIT derlemesi ve kısmi değerlendirme ile gerçekten akıllı şeyler yapan gerçekten zeki insanlar tarafından elde edilir.