是什么阻碍了Ruby和Python获得V8的Javascript速度?

什么都没有。

好吧，钱。(还有时间、人力和资源，但如果你有钱，这些都是可以买到的。)

V8有一个优秀的、高度专业化的、经验丰富的(因此薪酬很高的)工程师团队，他们在为动态OO语言创建高性能执行引擎方面有几十年的经验(我是单独说的——总的来说更像是几百年的经验)。他们基本上是创建Sun HotSpot JVM(以及其他许多JVM)的同一群人。

首席开发人员Lars Bak已经在vm上工作了25年(所有这些vm都已经发展到V8)，这基本上是他的整个(职业)生涯。一些编写Ruby vm的人甚至不到25岁。

是否有Ruby / Python特性阻碍了V8引擎的优化实现(例如内联缓存)?

考虑到至少IronRuby、JRuby、MagLev、MacRuby和Rubinius都有单态(IronRuby)或多态内联缓存，答案显然是否定的。

现代Ruby实现已经做了大量的优化。例如，对于某些操作，Rubinius的Hash类比YARV的更快。现在，这听起来并不令人兴奋，直到您意识到Rubinius的Hash类是100%纯Ruby实现的，而YARV的Hash类是100%手工优化的C实现的。

所以，至少在某些情况下，Rubinius可以生成比GCC更好的代码!

或者这是谷歌在V8项目中投入的资源问题。

是的。不只是谷歌。V8的源代码已经有25年的历史了。在V8上工作的人还创建了Self VM(迄今为止创建的最快的动态OO语言执行引擎之一)，Animorphic Smalltalk VM(迄今为止创建的最快的Smalltalk执行引擎之一)，HotSpot JVM(有史以来创建的最快的JVM，可能是最快的VM时期)和OOVM(有史以来创建的最高效的Smalltalk VM之一)。

事实上，V8的首席开发人员Lars Bak参与了其中的每一个项目，以及其他一些项目。

性能似乎并不是核心Python开发人员的主要关注点，他们似乎觉得“足够快”就足够好了，而且帮助程序员提高工作效率的功能比帮助计算机更快地运行代码的功能更重要。

然而，确实有一个谷歌项目unladen-swallow(现在已被放弃)，目的是生产一个与标准解释器兼容的更快的Python解释器。PyPy是另一个旨在生成更快Python的项目。还有Psyco，它是PyPy的前身，它可以在不更改整个解释器的情况下为许多Python脚本提供性能提升，还有Cython，它允许您使用非常类似于Python语法的东西为Python编写高性能C库。

正如其他人所提到的，Python有一个PyPy形式的高性能JIT编译器。

Making meaningful benchmarks is always subtle, but I happen to have a simple benchmark of K-means written in different languages - you can find it here. One of the constraints was that the various languages should all implement the same algorithm and should strive to be simple and idiomatic (as opposed to optimized for speed). I have written all the implementations, so I know I have not cheated, although I cannot claim for all languages that what I have written is idiomatic (I only have a passing knowledge of some of those).

我没有任何明确的结论，但PyPy是我得到的最快的实现之一，比Node好得多。相反，CPython位于排名最慢的一端。

这很大程度上与社区有关。Python和Ruby在很大程度上没有企业支持。没有人会因为全职从事Python和Ruby而获得报酬(特别是他们不会因为一直从事CPython或MRI而获得报酬)。另一方面，V8得到了世界上最强大的IT公司的支持。

此外，V8可以更快，因为对V8的人来说唯一重要的事情是解释器——他们没有标准库可以工作，不需要考虑语言设计。他们只编写解释器。就是这样。

这与知识产权法无关。Python也不是由谷歌的人共同开发的(它的创建者和其他一些提交者一起在那里工作，但他们没有为Python工作而获得报酬)。

Python速度的另一个障碍是Python 3。它的采用似乎是语言开发人员最关心的问题——以至于他们冻结了新语言特性的开发，直到其他实现赶上来。

关于技术细节，我不太了解Ruby，但是Python有很多地方可以使用优化(Unladen Swallow，一个谷歌项目，在失败之前就开始实现这些)。这是他们计划的一些优化。如果CPython实现了像PyPy一样的JIT，我可以看到Python在未来达到V8的速度，但这在未来几年似乎不太可能(现在的重点是采用Python 3，而不是JIT)。

许多人还认为Ruby和Python可以从移除它们各自的全局解释器锁中获益良多。

You also have to understand that Python and Ruby are both much heavier languages than JS -- they provide far more in the way of standard library, language features, and structure. The class system of object-orientation alone adds a great deal of weight (in a good way, I think). I almost think of Javascript as a language designed to be embedded, like Lua (and in many ways, they are similar). Ruby and Python have a much richer set of features, and that expressiveness is usually going to come at the cost of speed.

这种说法并不完全正确

就像V8只是JS的一个实现一样，CPython只是Python的一个实现。Pypy的性能与V8相当。

此外，还有感知性能的问题:由于V8本身是非阻塞的，Web开发会导致更高性能的项目，因为您节省了IO等待时间。V8主要用于开发Web，其中IO是关键，所以他们将它与类似的项目进行比较。但是，除了web开发，你还可以在许多其他领域使用Python。你甚至可以在许多任务中使用C扩展，比如科学计算或加密，并以出色的性能处理数据。

但是在网络上，大多数流行的Python和Ruby项目都是阻塞的。尤其是Python，它继承了同步WSGI标准，像著名的Django这样的框架就是基于它的。

你可以编写异步Python(比如Twisted、Tornado、gevent或asyncio)或Ruby。但这种做法并不常见。最好的工具仍然是阻塞的。

然而，这也是Ruby和Python的默认实现速度不如V8的原因之一。

经验

就像Jörg W Mittag指出的那样，V8的开发者都是VM天才。Python是由一群充满激情的人开发的，在很多领域都很出色，但在VM调优方面并不专业。

资源

Python软件基金会只有很少的钱:每年在Python上的投资不到4万美元。当你认为像谷歌、Facebook或苹果这样的大公司都在使用Python时，这有点疯狂，但这是丑陋的事实:大多数工作都是免费完成的。在Java之前就存在的支持Youtube的语言是由志愿者手工制作的。

他们是聪明和敬业的志愿者，但当他们发现自己在某个领域需要更多的能量时，他们不能要求30万美元来雇佣一个该领域的顶级专家。他们必须四处寻找愿意免费做这件事的人。

虽然这是有效的，但这意味着你必须非常小心你的优先级。因此，现在我们需要看看:

目标

即使拥有最新的现代特性，编写Javascript也很糟糕。你有范围问题，很少的集合，糟糕的字符串和数组操作，除了日期，数学和正则表达式之外几乎没有标准列表，甚至对于非常常见的操作也没有语法糖。

但在V8引擎中，你有速度。

这是因为，速度是谷歌的主要目标，因为它是Chrome页面渲染的瓶颈。

在Python中，可用性是主要目标。因为这几乎从来都不是项目的瓶颈。这里的稀缺资源是开发人员的时间。它是为开发人员优化的。

因为JavaScript实现不需要关心其绑定的向后兼容性。

Until recently the only users of the JavaScript implementations have been web browsers. Due to security requirements, only the web browser vendors had the privilege to extend the functionality by writing bindings to the runtimes. Thus there was no need keep the C API of the bindings backwards compatible, it was permissible to request the web browser developers update their source code as the JavaScript runtimes evolved; they were working together anyways. Even V8, which was a latecomer to the game, and also lead by a very very experienced developer, have changed the API as it became better.

OTOH Ruby(主要)用于服务器端。许多流行的ruby扩展被编写为C绑定(考虑RDBMS驱动程序)。换句话说，如果不保持兼容性，Ruby就永远不会成功。

今天，这种差异在某种程度上仍然存在。使用node.js的开发人员抱怨很难保持他们的本机扩展向后兼容，因为V8会随着时间改变API(这也是node.js被分叉的原因之一)。IIRC ruby在这方面仍然采取更为保守的方法。