是否有任何Ruby/Python特性阻碍了V8引擎优化(例如inline caching)的实现?
Python是由谷歌的人共同开发的,所以它不应该被软件专利阻止.
或者这是谷歌投入V8项目的资源问题.
是否有任何Ruby/Python特性阻碍了V8引擎优化(例如inline caching)的实现?
Python是由谷歌的人共同开发的,所以它不应该被软件专利阻止.
或者这是谷歌投入V8项目的资源问题.
是什么阻止了Ruby和Python获得Javascript V8速度?
没有什么
好吧,好吧:钱.(还有时间、人力、资源,但如果你有钱,你可以买到这些.)
V8 has a team of brilliant, highly-specialized, highly-experienced (and thus highly-paid) engineers working on it, that have decades of experience (I'm talking individually – collectively it's more like centuries) in creating high-performance execution engines for dynamic OO languages. They are basically the same people who also created the Sun HotSpot JVM (among many others).
首席开发人员Lars Bak已经在VM上工作了25年(所有这些VM一直到V8),这基本上就是他的整个(职业)生活.有些编写Ruby VM的人甚至不到25岁.
是否有任何Ruby/Python特性阻碍了V8引擎的优化实现(例如内联缓存)?
考虑到至少IronRuby、JRuby、MagLev、MacRuby和Rubinius拥有单态(IronRuby)或多态内联缓存,答案显然是否定的.
现代Ruby实现已经进行了大量优化.例如,对于某些操作,Rubinius的Hash
类比YARV的快.现在,这听起来并不令人兴奋,直到你意识到Rubinius的Hash
类是用Hash
%纯Ruby实现的,而YARV的是用Hash
%手工优化的C实现的.
所以,至少在某些情况下,Rubinius可以生成比GCC更好的代码!
或者,这更多的是Google在V8项目中投入的资源问题.
对不仅仅是谷歌.V8的源代码已经有25年的历史了.在V8上工作的人还创建了Self VM(迄今为止是有史以来最快的动态OO语言执行引擎之一)、Animorphic Smalltalk VM(迄今为止是有史以来最快的Smalltalk执行引擎之一),热点JVM(有史以来创建的最快的JVM,可能是最快的VM周期)和OOVM(有史以来创建的最高效的Smalltalk VM之一).
事实上,V8的首席开发人员拉尔斯·贝克(Lars Bak)已经完成了其中every single one个项目,以及其他一些项目.