Java运行时性能与本机C/C++；密码？ 在java中，我已经比用C++或C变得越来越舒服了。我希望能够得到一个使用JVM解释器的性能冲击的感觉，而不是相反地执行相同的“项目”。我意识到这里有一定程度的主观性；计划的质量在很大程度上取决于良好的实施。一般来说，我对以下几个方面感兴趣：

在使用解释器时，必须有一些开销基线。有什么经验法则需要记住吗？10% 15%? （我凭空得出这些数字）我偶尔读过一篇博客，说Java代码几乎和本地代码一样快，但我认为这可能是有偏见的

JVM垃圾收集器是否会给运行时性能增加大量开销？我知道Cocoa应用程序已经开始使用垃圾收集模型，我同意它使编程变得更简单，但代价是什么

从Java进行系统调用的开销是多少？例如，创建与C套接字API相反的套接字对象

最后，我记得在某个地方读到JVM实现是单线程的。如果这是真的（我对此持怀疑态度），这是否意味着Java线程真的不是真的线程？java线程通常与底层内核提供的线程相对应吗？Java应用程序是否与本机应用程序从多核/多cpu中获益的方式相同

任何了解JVM和java程序性能复杂性的开发人员的建议都将不胜感激。谢谢。

---

等等。事实是——这没关系。瓶颈和缓慢的软件是由开发人员造成的，而不是由语言造成的（至少现在是这样）。

事实上，虚拟机可以在运行时根据只有在运行时可用的信息进行大量优化，而C/C++编译器无法做到这一点。因此，在大多数情况下，JVM至少与本机程序一样快

Brian Goetz在他的演讲中回答了大部分问题（如果不是所有问题的话）。

java和c#（以及objective-c）的速度都不如本机代码快。但是，只有当你遇到一个没有工程时间限制的问题时，这才重要。因为你有时间用高级语言设计出更好的算法

因此，基本上，如果你正在开发一款年生产100万台或电池供电的设备，你不会使用java或c来构建其核心功能。不过，您可以添加一个lisp解释器来简化定制。微软不会将c#作为SQL server的核心，因为性能才是最重要的。另一方面，VisualStudio是微软希望用户拥有高端硬件的地方，它可以用来展示速度慢但生产率高的技术

---

请注意，我目前使用Pharo Smalltalk进行大部分编程，它比java、c#或objective-c慢得多，甚至不是最快的Smalltalk之一。生产力胜过绩效。

要解决您的每一点：

• 解释代码的开销远远高于10-15%（我估计大约是3x-5x或更高）。为了降低到10-15%，您必须使用某种形式的机器代码编译步骤（即JIT）。（试着在JIT关闭的情况下运行JVM，您会看到性能像石头一样下降。）
• 垃圾收集确实会对性能产生影响，但我要说，每个人都认为它是值得的。如果您可以负担字节码编译/解释开销，那么您也可以负担gc开销
• 如果您想知道的话，Java中的套接字编程要比C/C++中容易得多。在性能方面，套接字I/O开销超过了Java执行开销
• 大多数现代JVM都有真正的线程，即每个Java线程都由一个内核线程执行，从而允许Java线程利用现代多核CPU

---

这个问题没有一个简单的答案。编写C风格C++是可能的（甚至是一个好主意），但是一旦你尝试在C中继承继承，事情就变得丑陋了。所以忽略C++，并与java -VS -C++进行交互，因为它们彼此更接近。 要真正了解它，您需要用两种语言以类似的方式编写两个相对较大的应用程序。如果您这样做，那么您是使用STL和Java集合类，还是编写自己的类并在不同语言之间进行移植？如果您使用本机实现，那么这取决于哪个实现更快，如果您使用自己的实现，那么您没有测试应用程序的实际速度
我认为您需要编写尽可能类似的应用程序，但在有意义的地方使用特定于语言的库/习惯用法。C++和java代码，虽然类似，但有不同的做事方式——在C++中，在爪哇很容易的事情可能是非常困难的，反之亦然。 现代GC实现不会增加那么多开销，如果愿意，您可以切换到进行比较：-）
<> P>有一些事情，java运行时可以做的事情，C++编译器通常不做，比如内嵌虚拟方法的能力。 对于系统类型的东西，Java通常求助于调用C，因此存在开销（尽管JNI比以前快）
线程依赖于实现。Sun过去使用“绿色线程；用于Solaris”，但这早已不复存在。据我所知，大多数（所有？）现代虚拟机都使用本机线程

---

简而言之，我认为java和VC++之间的开销不存在一个好的度量，任何你发现的都可能是不代表真实世界的微基准（不幸的是）。
< P> java不是解释的语言，而且没有几个版本。java字节码是在T上的。