是否有可能比C中的同一程序（优化）更快地获得Java程序？

Question

关于在编译时生成C / C ++优化的事实，并且在运行时生成Java优化。是否有可能比C中的同一程序（优化）更快地获得Java程序？

我知道运行时优化可能比编译时更好。因此，我想知道这些优化的好处是否可以与运行JVM的开销进行比较。

Answer 1

理论上，是的。 实际上，这种可能性很小。

一个基本假设是C / C ++为二进制操作码目标编译一次，并且Java是针对它运行的特定机器编译的。这应该给Java带来优势。但实际情况是，即使C / C ++也可以有几个优化路径，在运行时动态选择，并获得特定目标编译的大部分好处。

相反，正如Rekin所述，Java JVM需要动态分析Java程序以了解要优化的内容和方式。分析本身就是一项昂贵的操作，并且无法从Java JVM中获取开销。另一方面，为当前工作负载选择正确的优化集可以提供优势。实际上，大多数C程序（但不是全部）都可以很好地适应他们的任务，并且没有什么可以优化使用分析技术。

Java中还有其他一些影响使这些编译问题相形见绌。可能在第一个位置是垃圾收集器。

垃圾收集器的第一个任务是简化编程，处理并避免C / C ++中最令人讨厌的重复错误之一，即内存泄漏。仅此功能就可以证明在许多工业环境中大量使用Java。

然而，它有成本。一个非常大的。根据研究，有必要提供大约5倍的严格必要内存，以确保垃圾收集器以最小的开销工作。因此，每当缺少这么多的内存时，GC开销就会变得很重要，从而使性能陷入困境。

相反，在某些情况下，可能会发生释放内存分配费用的算法可能允许更改算法，并采用更好，更快的算法。在这种情况下，Java可以获得优势，并且比C程序更快。

但正如你猜测的那样，这种情况并不常见......

Answer 2

C / C ++程序专门为特定平台编写并直接编译成机器代码，它们必然会更接近它们运行的​​软件/硬件平台。因此他们会更快。

Java优化内置于JVM中，并且通过及时（JTI）处理字节码的方式实现了最佳优化（就执行程序的速度而言）。虽然JTI证明了更多的内存密集型。

因此，比较这些策略清楚地表明C / C ++本机代码会更快;因为即使使用JTI，JVM仍然需要一些开销才能将字节码转换为本机代码。

但这是依赖平台支付的价格，而java更便携。

从when is java faster than c++ (or when is JIT faster then precompiled)?获取，我发现了Java执行可能优于C / C ++的一些场景

  

许多小内存分配/解除分配。主要的JVM都有   非常高效的内存子系统，以及垃圾收集都可以   比要求明确释放更有效（加上它可以转移   内存地址等，如果它真的想要）。

     

通过深层次的方法调用进行高效访问。 JVM是   非常善于消除任何不必要的东西，通常更好   我的经验比大多数C ++编译器（包括gcc和icc）。在某种程度上   这是因为它可以在运行时进行动态分析（即它可以   过度优化，只有在检测到问题时才会优化。）

     

将功能封装到小的短期对象中。

Answer 3

JVM的开销很大。它必须加载几个类，它们存在于zip（jar）文件中并且需要被提取。

对于每个加载的类，都会运行一些静态分析方法，以查看是否存在无法访问的代码，操作数堆栈类型问题和其他问题。

然后，分析器会一直运行以确定哪些代码部分值得优化，通常这意味着这些方法在优化之前需要调用几千次。

除此之外，你还得到垃圾收集器。

我无法想象一个正确编写的C程序，为其运行的平台编译，胜过Java等价物。也许只有当你遇到一些罕见的角落情况时，JVM才会进行一些优化，并且C编译器没有实现特定的优化。

Answer 4

我看到Java比C运行得更快，因为资源有限，上市时间更重要。在这种情况下，您没有尽可能多的时间来编写代码，就像在C和C ++中一样，您最终可能会做的事情效率低于JVM为您所做的事情。即如果您需要JVM已经完成的那些事情，它可以更快。

如果你有一台拥有足够资源的机器，那么开发人员的时间就会更加昂贵/关键，你可以在更短的时间内找到一个工作稳定的系统，并有时间分析/优化，而C团队可能仍在修复所有核心转储。你的里程会有所不同。

对于资源有限的设备，C仍占主导地位，因为您可以控制资源分配。 BTW大多数手机现在运行Java（或Objective-C）。