什么阻止Ruby,Python来获得Javascript V8的速度?

有没有任何Ruby / Pythonfunction阻止优化的实现(例如内联caching )V8引擎?

Python由Google合作开发,所以不应该被软件专利所阻挡。

或者这是Google投入V8项目的资源问题。

什么阻止Ruby,Python来获得Javascript V8的速度?

没有。

那么,好吧:钱。 (时间,人,资源,但如果你有钱,你可以买这些。)

V8拥有一支精干,高度专业化,经验丰富(因而薪水高)的工程师队伍,拥有数十年的经验(我个人正在谈论 – 几乎是几个世纪以来)创造高性能的执行用于dynamicOO语言的引擎。 他们基本上是同样创build了Sun HotSpot JVM的人(等等)。

首席开发人员Lars Bak已经从事虚拟机工作了25年(所有这些虚拟机已经领导到V8),这基本上是他整个(专业)的生活。 一些编写Ruby虚拟机的人甚至不到25岁。

有没有任何Ruby / Pythonfunction阻止优化的实现(例如内联caching)V8引擎?

鉴于至lessIronRuby,JRuby,MagLev,MacRuby和Rubinius有单态(IronRuby)或多态内联caching,答案显然不是。

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

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

或者这是Google投入V8项目的资源问题。

是。 不只是Google。 V8的源代码现在已经25年了。 在V8上工作的人也创build了Self VM(到目前为止创build的最快的dynamicOO语言执行引擎之一),Anomorphic Smalltalk VM(迄今为止创build的最快的Smalltalk执行引擎之一),HotSpot JVM(曾经创build的最快的JVM,可能是最快的VM周期)和OOVM(创build的最有效的Smalltalk VM之一)。

事实上,V8的首席开发人员Lars Bak曾为其中每一个人员,以及其他一些人员工作。

高度优化JavaScript解释器有更多的动力,这就是为什么我们看到Mozilla,Google和Microsoft之间投入了如此多的资源。 JavaScript必须被实时下载,parsing,编译和运行,而一个(通常是不耐烦的)人在等待它,它必须在一个人正在与之交互时运行,而且这是在一个不受控制的客户端环境可以是电脑,电话或烤面包机。 为了有效地在这些条件下运行,它必须是有效率的。

Python和Ruby运行在由开发者/部署者控制的环境中。 一个健壮的服务器或桌面系统通常在限制因素将是内存或磁盘I / O,而不是执行时间的东西。 或者可以使用像caching这样的非引擎优化。 对于这些语言来说,将重点放在语言和库特性设置上来优化速度可能更有意义。

这样做的好处是,我们有两个伟大的高性能开源JavaScript引擎,可以和正在重新使用各种应用程序,如Node.js。

其中很大一部分与社区有关。 Python和Ruby大部分没有企业支持。 没有人能够得到报酬来全职工作在Python和Ruby上(特别是他们没有得到报酬一直在CPython或MRI上工作)。 另一方面,V8则得到了世界上最强大的IT公司的支持。

此外,V8可以更快,因为对于V8人来说唯一的事情就是翻译 – 他们没有标准的图书馆可以工作,不用担心语言devise。 他们只是写翻译。 而已。

这与知识产权法无关。 Google合作伙伴也不是Python合作开发的(它的创build者和其他一些提交者一起工作,但是他们没有从Python获得报酬)。

Python速度的另一个障碍是Python 3.它的采用似乎是语言开发人员的主要关注点 – 直到其他实现迎头赶上,才冻结了新语言function的开发。

在技​​术细节方面,我对Ruby不是很了解,但是Python有很多可以使用优化的地方(而Google的项目Unladen Swallow在开始实施之前就已经开始实施了)。 以下是他们计划的一些优化 。 如果JIT a la PyPy被实现为CPython,我可以看到Python在未来获得了V8的速度,但是在未来几年似乎不太可能(现在的重点是Python 3的采用,而不是JIT)。

许多人也认为,Ruby和Python可以从删除他们各自的全局解释器锁中受益匪浅。

您还必须明白,Python和Ruby比JS更重的语言 – 他们提供了更多的标准库,语言function和结构的方式。 仅仅面向对象的类系统就会增加很多的重量(我认为是一个很好的方法)。 我几乎把Javascript看作一种被embedded的语言,就像Lua(在很多方面它们是相似的)。 Ruby和Python有更丰富的特性,而且expression性通常是以速度为代价的。

性能似乎不是核心Python开发人员的主要焦点,他们似乎认为“足够快”足够好,而且帮助程序员提高生产力的function比帮助计算机更快运行代码的function更重要。

然而,事实上,现在有一个(现在已经被放弃的)Google项目,可以生产一个与标准解释器兼容的更快的Python解释器。 PyPy是另一个计划,旨在生产更快的Python。 还有Psyco ,PyPy的前身,它可以在不改变整个解释器的情况下为许多Python脚本提供性能提升, Cython可以使用非常像Python语法的东西为Python编写高性能C库。

误导性的问题。 V8是JavaScript的一个JIT(即时编译器)实现,在其最stream行的非浏览器实现Node.js中,它是围绕事件循环构build的。 CPython不是一个JIT&没有完成。 但是这些在PyPy项目中最常见的Python存在 – 一个CPython 2.7(不久将是3.0+)兼容的JIT。 例如,有一些像Tornado这样的服务器库。 运行Tornado和Node.js的PyPy之间存在真实世界的testing,性能差异很小。

我只是遇到了这个问题,这也是没有提到的性能差异的一个重大技术原因。 Python有一个非常大的强大的软件扩展生态系统,但是这些扩展中的大多数都是用C或其他低级语言编写的,因此性能非常强大,并且与CPython API息息相关。

有很多众所周知的技术(JIT,现代垃圾收集器等)可以用来加速CPython的实现,但都需要对API进行重大更改,从而破坏了过程中的大部分扩展。 CPython会更快,但是很多让Python如此吸引人的东西(广泛的软件堆栈)将会丢失。 举个例子来说,有几个更快的Python实现,但与CPython相比,它们几乎没有牵引力。

由于不同的devise优先级和用例目标,我相信。

一般来说,脚本(又名dynamic)语言的主要目的是成为本地函数调用之间的“粘合剂”。 这些原生function应:a)覆盖大部分关键/经常使用的区域; b)尽可能有效。

下面是一个例子: jQuerysorting导致iOS Safari冻结由于过度使用get-by-selector调用而导致的冻结。 如果get-by-selector将在本地代码中实现,并且实际上不会有这样的问题。

考虑经常使用V8演示的演示的光线跟踪器演示。 在Python世界中,它可以用本地代码实现,因为Python为本机扩展提供了所有的function。 但是在V8领域(客户端沙箱)中,除了使虚拟机尽可能有效之外,没有别的select。 所以唯一的select是通过使用脚本代码来看到ray-tracer的实现。

所以不同的优先事项和动机。

在Sciter中,我通过本地实现了几乎完整的jQurey核心进行了testing。 在像ScIDE (由HTML / CSS / Script构成的IDE)这样的实际任务上,我认为这样的解决scheme比任何虚拟机优化都更有效。

正如其他人所提到的,Python具有PyPyforms的高性能JIT编译器。

制定有意义的基准总是微妙的,但是我碰巧有一个用不同语言编写的K-means的简单基准 – 你可以在这里find它。 其中一个约束就是各种语言都应该实现相同的algorithm,并且应该努力做到简单和习惯(与速度优化相反)。 我已经写了所有的实现,所以我知道我没有欺骗,虽然我不能要求所有的语言,我写的是惯用的(我只有一些这些传递知识)。

我没有要求任何明确的结论,但PyPy是我得到的最快的实现之一,远胜于Node。 相反,CPython处于排名的最低端。

声明不完全正确

就像V8只是JS的实现一样,CPython只是Python的一个实现。 Pypy的performance与V8相匹配 。

此外,还有性能问题:由于V8本身是非阻塞的,所以Web dev会导致性能更高的项目,因为您可以节省IO等待时间。 而V8主要用于IO关键的开发Web,因此将它与类似的项目进行比较。 但是,除了web开发之外,还可以在许多其他领域使用Python。 甚至可以使用C扩展来完成许多任务,比如科学计算或者encryption,并且可以通过眩目的perf来压缩数据。

但是在networking上,大多数stream行的Python和Ruby项目都是阻塞的。 特别是,Python具有同步WSGI标准的遗产,像着名的Django这样的框架就是基于它的。

你可以编写asynchronousPython(比如Twisted,Tornado,gevent或者asyncio)或者Ruby。 但这并不经常。 最好的工具仍然阻塞。

然而,他们是为什么Ruby和Python中的默认实现不如V8那么快的原因。

经验

就像JörgW Mittag指出的那样,从事V8工作的人是VM天才。 Python是一群热情的人开发的,在很多领域都非常擅长,但是并不是专门针对VM调优的。

资源

Python软件基金会的资金非常less:每年投入Python 不到4万美元。 当你认为谷歌,Facebook或者苹果这样的大玩家都在使用Python的时候,这有点疯狂,但是这是一个丑陋的事实:大部分的工作都是免费的。 在Java之前,这个语言就是由志愿者手工制作的。

他们是聪明和忠诚的志愿者,但是当他们发现他们需要更多的果汁时,他们不能要求30万人才能聘请这方面的顶尖专家。 他们必须四处寻找一个免费的人。

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

目标

即使有最新的现代function,写Javascript是可怕的。 你有范围问题,很less的集合,可怕的string和数组操作,除了date,math和正则expression式几乎没有stdlist,即使是非常常见的操作也没有语法糖。

但在V8中,你有速度。

这是因为速度是Google的主要目标,因为它是Chrome中页面呈现的瓶颈。

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

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

直到最近,JavaScript实现的唯一用户已经是Web浏览器。 由于安全要求,只有networking浏览器供应商才有权通过编写绑定到运行时来扩展function。 因此,不需要保持绑定的C API向后兼容,允许Web浏览器开发者在JavaScript运行时发展时更新其源代码; 他们正在一起工作。 即使V8也是这个游戏的后来者,也是由一位非常有经验的开发人员领导的,它已经改变了API,因为它变得更好。

OTOH Ruby(主要)在服务器端使用。 许多stream行的ruby扩展都被写成C绑定(考虑一个RDBMS驱动)。 换句话说,如果不维护兼容性,Ruby将永远不会成功。

今天,差距还是有的。 使用node.js的开发人员抱怨说,由于V8会随着时间的推移而改变API(这是node.js被分叉的原因之一),所以很难保持它们的本地扩展向后兼容。 IIRCruby在这方面仍然采取更保守的方法。

由于JIT,曲轴,types推理器和数据优化代码,V8是快速的。 标记的指针,双打的NaN标记。 当然,它在中间正常的编译器优化。

普通的ruby,python和perl引擎都不做这些,只是一些小的基本优化。

接近的唯一的主要是luajit,它甚至不进行types推断,不断的折叠,NaN标记或整数,而是使用类似的小代码和数据结构,而不是像坏语言一样胖。 我的原型dynamic语言potion和p2与luajit有相似的function,并且胜过v8。 使用可选的types系统“渐进式打字”,您可以轻松超越v8,因为您可以绕过曲轴。 看飞镖。

已知的优化后端,如pypy或jruby仍然受到各种过度工程技术。