What blocks Ruby, Python to get Javascript V8 speed?
是否有任何Ruby/python特性阻止了V8引擎的优化实现(例如内联缓存)？
python是由谷歌人共同开发的，所以它不应该被软件专利所阻止。
或者这是谷歌投入V8项目的资源问题。
What blocks Ruby, Python to get Javascript V8 speed?
没有什么。
好吧，好吧：钱。(时间、人员、资源，但如果你有钱，你可以买这些。)
V8拥有一支由才华横溢、高度专业化、经验丰富(因而报酬丰厚)的工程师组成的团队，他们在为动态OO语言创建高性能执行引擎方面拥有数十年的经验(我单独讨论，总的来说更像几个世纪)。他们基本上都是创建Sun Hotspot JVM的人(包括许多其他人)。
LarsBak，主要的开发人员，已经在虚拟机上工作了25年(所有这些虚拟机都已经领先于V8)，这基本上是他的整个(专业)生活。一些写RubyVMS的人甚至还不到25岁。
Are there any Ruby / Python features that are blocking implementation of optimizations (e.g. inline caching) V8 engine has?
考虑到至少IronRuby、JRuby、Maglev、MacRuby和Rubinius具有单态(IronRuby)或多态内联缓存，答案显然是否定的。
现代Ruby实现已经做了大量的优化。例如，在某些操作中，Rubinius的
所以，至少在某些情况下，Rubinius可以生成比GCC更好的代码！
Or this is rather matter of resources put into the V8 project by Google.
对。不仅仅是谷歌。V8源代码的沿袭已经有25年的历史了。在V8上工作的人们还创建了self-vm(到今天为止，这是有史以来最快的动态OO语言执行引擎之一)、animorphic smalltalk vm(到今天为止，这是有史以来最快的smalltalk执行引擎之一)、hotspot jvm(有史以来最快的jvm，可能是最快的vm周期)和oovm(mos之一)。高效的smalltalk vms)。
事实上，V8的主要开发人员拉尔斯?贝克(LarsBak)对其中的每一个都进行了开发，另外还有其他一些。
对于高度优化JavaScript解释器有着更多的动力，这就是为什么我们看到在Mozilla、Google和Microsoft之间有如此多的资源投入到解释器中。Javascript必须实时下载、解析、编译和运行，而一个(通常不耐烦的)人正在等待它，它必须在一个人与它交互时运行，并且它是在一个不受控制的客户端环境中进行的，该环境可以是计算机、电话或烤面包机。为了在这些条件下有效运行，它必须是有效的。
python和ruby运行在由开发人员/部署人员控制的环境中。一个强大的服务器或桌面系统，通常限制因素是内存或磁盘I/O，而不是执行时间。或者可以使用诸如缓存之类的非引擎优化。对于这些语言，关注语言和库特性集而不是速度优化可能更有意义。
这样做的另一个好处是，我们有两个高性能的开源JavaScript引擎，可以并且正在为各种应用程序(如node.js)重新设计。
其中很大一部分与社区有关。python和ruby在很大程度上没有公司的支持。在python和ruby上全职工作没人能得到报酬(尤其是在cpython或mri上全职工作，他们也得不到报酬)。另一方面，V8得到了世界上最强大的IT公司的支持。
此外，V8可以更快，因为对V8用户来说唯一重要的是解释器——他们没有标准的库来工作，也不关心语言设计。他们只是写翻译。就是这样。
它与知识产权法无关。python也不是google合作开发的(它的创建者和其他一些提交者一起在那里工作，但是他们在python上工作得不到报酬)。
Python速度的另一个障碍是Python3。它的采用似乎是语言开发人员的主要关注点——以至于他们冻结了新语言特性的开发，直到其他实现赶上。
关于技术细节，我对Ruby不太了解，但是Python有很多地方可以使用优化(而且，Unladen Swallow，一个Google项目，在咬牙切齿之前就开始实现这些优化)。下面是他们计划的一些优化。如果为cpython实现了jit-a-la-pypy，我可以看到python在未来获得V8速度，但这在未来几年似乎不太可能实现(现在的重点是采用python3，而不是jit)。
许多人还认为Ruby和Python可以从移除各自的全局解释器锁中获益匪浅。
您还必须了解，Python和Ruby都比JS重得多——它们在标准库、语言特性和结构方面提供的要多得多。仅仅是面向对象的类系统就增加了大量的权重(我认为这是一个很好的方法)。我几乎认为JavaScript是一种被设计成嵌入式的语言，比如Lua(在很多方面，它们是相似的)。Ruby和Python有一组更丰富的特性，而这种表现力通常以牺牲速度为代价。
性能似乎不是核心Python开发人员的主要关注点，他们似乎认为"足够快"就足够好了，帮助程序员提高效率的功能比帮助计算机更快地运行代码的功能更重要。
然而，确实有一个(现在已经废弃的)谷歌项目，unladen swallow，用于生成与标准解释器兼容的更快的python解释器。Pypy是另一个旨在生成更快的Python的项目。还有psyco，pypypy的前身，它可以在不改变整个解释器的情况下提高许多python脚本的性能；还有cython，它允许您使用类似于python语法的东西为python编写高性能的C库。
误导性问题。V8是一个Javascript的JIT(实时编译器)实现，在它最流行的非浏览器实现node.js中，它是围绕事件循环构建的。cpython不是一个jit¬事件。但这些都存在于pypy项目中——一个与cpython 2.7(很快将是3.0+兼容的jit)中。例如，有很多事件服务器库，比如Tornado。pypy运行的tornado与node.js之间存在实际测试，性能差异很小。
因为我相信不同的设计优先级和用例目标。
一般来说，编写脚本(也称为动态)语言的主要目的是在本地函数调用之间形成"粘合剂"。这些本地功能应a)覆盖最关键/最常用的区域，b)尽可能有效。
下面是一个例子：jquery排序导致iOS Safari冻结这里的冻结是由过度使用get-by选择器调用引起的。如果get by selector将在本机代码中实现，并且有效地实现，那么它根本就不会有这样的问题。
考虑Ray Tracer演示，它是V8演示中经常使用的演示。在Python世界中，它可以用本机代码实现，因为Python为本机扩展提供了所有工具。但是在V8领域(客户端沙盒)，除了使虚拟机尽可能[次]有效之外，您没有其他选择。所以唯一的选择就是使用脚本代码来实现光线跟踪器。
所以不同的优先事项和动机。
在Sciter中，我通过在本地实现几乎完整的jqurey核心进行了测试。在scide(由html/css/script组成的IDE)这样的实际任务中，我相信这种解决方案比任何VM优化都能更好地工作。
我刚刚遇到这个问题，还有一个很大的技术原因导致了性能差异，但没有提到。python有一个非常大的强大软件扩展生态系统，但是这些扩展中的大多数都是用C语言或其他低级语言编写的，以提高性能，并且与cpythonapi紧密相连。
有许多著名的技术(JIT、现代垃圾收集器等)可以用来加速cpython的实现，但所有这些都需要对API进行实质性的更改，从而破坏了过程中的大部分扩展。cpython会更快，但是让python如此有吸引力的许多东西(大量的软件栈)都会丢失。举个例子，有几种更快的Python实现，但与cpython相比，它们没有什么吸引力。
这句话不完全正确
就像V8只是JS的一个实现一样，CPython只是Python的一个实现。Pypy的性能与V8相匹配。
此外，还存在感知性能的问题：由于V8本身是非阻塞的，因此Web开发人员会导致性能更高的项目，因为您保存了IO等待。V8主要用于开发Web，其中IO是关键，因此他们将其与类似的项目进行比较。但是，除了Web开发之外，您可以在许多其他领域使用Python，甚至可以在许多任务中使用C扩展，例如科学计算或加密，以及以惊人的性能处理数据。
但是在Web上，最流行的Python和Ruby项目是阻塞的。尤其是python具有同步wsgi标准的遗留功能，像著名的django这样的框架就是基于它的。
您可以编写异步python(如twisted、tornado、gevent或asyncio)或ruby。但这并不是经常做的。最好的工具还在阻塞。
然而，这也是为什么Ruby和Python中的默认实现没有V8那么快的原因。
经验像J一样？rg w mittag指出，从事V8引擎的人都是虚拟机天才。python是由一群充满激情的开发人员开发的，在很多领域都很好，但并不是专门针对vm调优的。
资源Python软件基金会的资金非常少：投资Python一年不到40K。当你认为像谷歌、Facebook或苹果这样的大公司都在使用python时，这有点疯狂，但这是一个丑陋的事实：大多数工作都是免费的。在YouTube上存在并在Java之前存在的语言是由志愿者手工制作的。
他们是聪明而敬业的志愿者，但当他们发现自己在某一领域需要更多的果汁时，他们就不能要求30万人来雇佣这一领域的顶尖专家。他们必须四处寻找免费的人。
虽然这是可行的，但这意味着你必须非常小心你的优先事项。因此，现在我们需要看看：
目标即使有了最新的现代特性，编写JavaScript也很糟糕。你有范围问题，很少集合，糟糕的字符串和数组操作，除了日期、数学和正则表达式之外几乎没有stdlist，甚至对于非常常见的操作也没有语法上的优势。
但在V8中，你有速度。
这是因为，速度是谷歌的主要目标，因为它是在Chrome中呈现页面的瓶颈。
在Python中，可用性是主要目标。因为它几乎不是项目的瓶颈。这里的稀缺资源是开发时间。它针对开发人员进行了优化。
正如其他人所提到的，python有一个pypy形式的性能jit编译器。
制定有意义的基准总是很微妙的，但我恰好有一个用不同语言编写的简单的k-means基准——您可以在这里找到它。其中一个限制是，各种语言都应实现相同的算法，并应力求简单和惯用(而不是优化速度)。我已经写了所有的实现，所以我知道我没有作弊，尽管我不能声称所有的语言我写的是惯用的(我只知道其中的一些)。
我没有任何明确的结论，但是Pypy是我得到的最快的实现之一，远远好于node。相反，CPython是排名中最慢的。
的V8引擎是一crankshaft几乎尽职，JIT，类型推理机和数据优化的代码。标记指针，双南飞渡。当然，它也和正常的基准中的编译器。
Perl，Python和Ruby的平原上，引擎也不要那些小的，只是基本的基准。
这是唯一的专业luajit close是VM，它甚至没有做的推理类型，常折叠，但NOR南标注小整数，使用类似的代码和数据结构，如语言不是脂肪浴。动态语言的原型和我有相似的特征，药水和P2为luajit和outperform V8引擎。一个可选的"渐进式的系统，准确的测试"，你可以很容易outperform V8引擎，你可以crankshaft旁路。海镖。
为优化在后端或JRuby，样pypy遭受过安静的从各种工程技术。
因为JavaScript实现不需要关心它们绑定的向后兼容性。
直到最近，JavaScript实现的唯一用户都是Web浏览器。由于安全性要求，只有Web浏览器供应商有权通过向运行时写入绑定来扩展功能。因此，不需要保持绑定的C API向后兼容，可以请求Web浏览器开发人员随着JavaScript运行时的发展更新其源代码；他们无论如何都在一起工作。即使是V8，这是一个迟到的游戏，也是由一个非常有经验的开发人员领导，已经改变了API，因为它变得更好。
OthRuby主要用于服务器端。许多流行的Ruby扩展被写成C绑定(考虑RDBMS驱动程序)。换句话说，如果没有保持兼容性，Ruby将永远不会成功。
今天，这种差异在某种程度上仍然存在。使用node.js的开发人员抱怨说，随着时间的推移，V8会改变API(这也是node.js被分叉的原因之一)，很难保持其本机扩展向后兼容。IIRC Ruby在这方面仍然采取了一种更加保守的方法。