如果我不得不猜测,我很确定答案是Clojure,但我不确定为什么。逻辑上(对我而言)看起来ClojureScript应该更快:
两者都是“动态的”,但是ClojureScript
而Clojure:
那么Clojure如何比ClojureScript更快?当说JavaScript是动态的并且Clojure是动态的时,“动态”是否意味着不同的东西?我没看到什么?
(当然如果ClojureScript 确实更快,那么上述推理是否正确?)
我想,Clojure编译成什么......至少是问题的一部分。我知道JVM部分不能只是一个简单的解释器(否则ClojureScript会更快),但Clojure无法编译成常规字节码,因为JVM中没有“动态”。那么ClojureScript的编译/执行方式与Clojure的编译/执行方式之间的差异,以及Java编译/执行的简单性以及各自隐含的性能差异有何不同?
答案 0 :(得分:30)
实际上,V8是用C ++编写的。但是,与JVM基本相同,JVM是用C. V8 JIT编写的Javascript代码并执行JIT代码。同样,JVM JIT编译(或热点编译)字节码(非Java)并执行生成的代码。
Bytecode不像Java那样是静态的。事实上它可能非常有活力。另一方面,Java主要是静态的,将Java与字节码混淆是不正确的。 java编译器将Java源代码转换为字节码,JVM执行字节码。有关更多信息,我建议您查看John Rose的博客(example)。那里有很多好消息。另外,尝试通过Cliff Click寻找谈话(如this one)。
同样,Clojure代码直接编译为字节码,然后JVM使用该字节码执行相同的过程。编译Clojure通常在运行时完成,这不是最快的过程。同样,Clojurescript到Javascript的翻译也不快。 V8将Javascript翻译成可执行形式显然非常快。 Clojure可以提前编译为字节码,这可以消除大量的启动开销。
正如你所说,说JVM解释字节码也是不正确的。 1.0版本发布于17年前!
传统上,有两种编译模式。第一种模式是JIT(即时)编译器。字节码直接转换为机器码。 Java的JIT编译执行速度很快,并且不会生成高度优化的代码。它运行正常。
第二种模式称为热点编译器。热点编译器非常复杂。它在解释模式下非常快速地启动程序,并在程序运行时对其进行分析。当它检测到热点(代码中频繁执行的点)时,它会编译它们。 JIT编译器必须快速,因为没有任何执行,除非它是JIT',热点编译器可以花费额外的时间来优化它编译的代码中的snot。
此外,它可以返回并稍后重新访问该代码,并在必要和可能的情况下对其应用更多优化。这是热点编译器可以开始击败编译的C / C ++的点。因为它具有代码的运行时知识,所以它可以应用静态C / C ++编译器无法执行的优化。例如,它可以内联虚函数。
Hotspot还有另外一个功能,据我所知,没有其他环境,它还可以在必要时取消优化代码。例如,如果代码不断地采用单个分支,并且已经优化并且运行时条件发生变化而迫使代码向下(另一个(未优化的)分支并且性能突然变得非常糟糕)。 Hotspot可以优化该功能并再次开始分析,以弄清楚如何使其更好地运行。
热点的缺点是它开始有点慢。 Java 7 JVM的一个变化是将JIT编译器和热点编译器结合起来。这种模式是新的,并且它不是默认模式,但是一旦初始启动应该是好的,然后它就可以开始JVM非常擅长的advanced optimizations。
干杯!
答案 1 :(得分:25)
这个问题很难准确回答,没有参考特定的基准测试任务(甚至是特定版本的Clojure或ClojureScript)。
话虽如此,在大多数情况下,我希望Clojure会更快一些。原因:
当然,可以用任何语言编写快速或慢速代码。这将比语言实现之间的根本区别更加不同。
更重要的是,您在Clojure和ClojureScript之间的选择在任何情况下都不应该与性能有关。两者都提供了引人注目的生主要决定因素应该是:
答案 2 :(得分:1)
这不是一个历史评论的答案:HotSpot VM和V8 js引擎的起源都可以追溯到Sun Microsystems的Self项目,我认为该项目的原型很多跑得和他们一样快。比较它们时要考虑的事情。我会将此作为评论发布,但声誉系统阻止了我。