【问题标题】:Performance of Java 1.6 vs C++?Java 1.6 与 C++ 的性能?
【发布时间】:2009-10-05 01:13:05
【问题描述】:

随着 Java 1.6 的发布,我们是否可以说 Java 1.6 的性能几乎等同于 C++ 代码,或者与 C++ 相比,Java 的性能方面仍有很多改进空间?

谢谢。

【问题讨论】:

标签: java c++ performance


【解决方案1】:

Debian likes to conduct benchmarks on this sort of thing。在他们的案例中,Java 的速度似乎是 C++ 的一半,消耗的内存是 C++ 的 2-18 倍。

【讨论】:

  • 这应该与一粒盐一起服用。首先,您可以根据需要编写程序。我知道 haskell 做得很好,但代码不是惯用的,所以你永远不会使用的廉价技巧出现了。其次,它只使用小程序。很少有有趣的 Java 和 C++ 程序少于 10000 行代码。许多超过 100 万个 LOC。
  • 这是一个很好的观点,但我还应该提供一个计数器,如果 95/5 规则为真(“95% 的时间花在 5% 的代码中”),那么就是5% 应作为基准。无论如何,即使是一个百万行的程序也是由许多单独的 100 行函数组成的。
  • @Crashworks 仅适用于在给定环境中优化给定程序 - 如果您将垃圾收集环境与使用自动指针的环境进行比较,使用细粒度总线锁定使线程安全,或不可变与可变字符串处理,你会得到整个程序的效果以及特定的瓶颈。
  • “Debian” 非常友好地在许多其他开源项目中托管基准测试游戏 - “Debian” 不做基准测试游戏。
  • @Paul Biggar - 出于基准游戏网站上列出的所有原因,不同编程语言之间的任何性能比较都应持保留态度 - shootout.alioth.debian.org/u32q/…
【解决方案2】:

编写良好的 Java 程序永远不会像编写良好的 C 或 C++ 程序那样快。虚拟机是不可减少的开销。 但是,大部分代码都写得不好。

Java 是一种比 C++ 更简单的语言,并且为缺乏经验的程序员提供了一个更宽容的环境 - 因此,如果您的程序员缺乏经验(而且成本低廉),那么 Java 的性能可能会比 C++“更好”。

shared_ptrs 在 C++ 中提供了类似的宽容环境,因此对于没有经验的程序员或从 Java 迁移的程序员来说,它们非常诱人,但它们的性能开销与 Java 的垃圾收集一样差或更差。我见过大型 C++ 程序,其中每个变量都是 shared_ptr,它们的性能非常糟糕。

我的看法

就我个人而言,我认为大型项目需要为大部分代码选择一种“简单”的编程语言,并为需要优化的部分选择一种“快速”的编程语言。 Java 可能是“简单”语言的一个不错的选择,尤其是因为目前有大量的 Java 程序员 - 在未来,我认为 甚至 更简单的语言(如 Python)将开始占据主导地位。

如果您已经知道 C++ 是一种“快速”语言,那么它是一个合理的选择,但我认为它过于复杂最终会让它被淘汰,而 C 将继续扮演这个角色。

【讨论】:

  • @alex a shared_ptr 是智能指针,而不是垃圾收集器。您将始终在编译时知道 shared_ptr 何时进行清理,但您不一定知道垃圾收集器何时介入以执行其操作。当你编写一个飞行控制系统时,你最不想要的就是垃圾收集器会在你的飞机紧急着陆时突然出现并开始剧烈旋转。两者工作不一样,表现也不一样
  • 关键是 99% 的应用程序都不是针对飞行控制系统的,所以差别不大。是的,shared_ptr 开销,对于单独分配的引用计数器,以及每个副本本身的线程安全引用计数,通常最终会比现代分代 GC 更昂贵。
  • wilhelmtell: 1) 我从未说过 shared_ptr 是垃圾收集器。 2) 我认为没有人会用 Java(或 C++)编写飞行控制系统。
  • @alex,C++ 用于许多关键任务系统,包括具有硬实时约束的嵌入式系统。
  • 无效:我知道。可怕,不是吗?
【解决方案3】:

我预计大多数应用程序的大部分时间 C++ 会比 Java 快。

在某些情况下,对于给定的任务,会有一些 C++ 比 Java 慢。这种情况非常少见,而且总是由于应用程序的实施不善或更普遍地重构不善造成的。

在大多数情况下,性能差异被 Java 提供的灵活性、易用性、库的可用性和可移植性所抵消。

在极少数情况下,性能非常关键,以至于用 Java 开发将是一个糟糕的选择在这些情况下,普通 C 通常是比 C++ 更好的选择

目前,性能/易用性/开发易用性权衡的最佳选择是 C#。可移植性在这里是一个大问题。

【讨论】:

    【解决方案4】:

    我发现 Java 的表现非常好。

    但是,为什么没有人解决我最大的抱怨?

    Java 使用 五倍 的内存是 C++ 程序执行相同工作的内存。至少!

    一旦使用,Java 会保留它

    拜托,拜托,为什么没有人为 Java 编写一个使用最少 RAM 的垃圾收集器?它可以压缩堆并将内存返回给操作系统。与其使用一堆可笑的 -Xm* 选项,不如使用所需的内存,然后还给它

    实际上,我确信某些嵌入式系统 JVM 会这样做,但桌面或服务器系统都不会这样做。

    这种内存问题使得 Java 应用程序都想表现得好像它们拥有整个计算机系统一样,没有人愿意运行多个应用程序,并且 RAM 是免费的并且可以无限升级。

    因此,无论性能多么出色,我都不会用 Java 编写实用程序之类的东西。只需要应用巨大的服务器应用程序。

    【讨论】:

    • 你看过哪些JVM? AS/400 JVM 就是这样做的。 (以及很久以前的微软)。
    • 我认为这并不完全正确。我编写了一个小测试程序来检查这一点,并在 Windows 上使用 Sun 的 JVM 运行它。测试程序分配了一个巨大的列表,然后将其清空。在几次调用 System#gc 之后,工作集减少了,但似乎涉及到时间因素;内存不会立即减少。 JVisualVM 显示堆大小减少,Windows 任务管理器显示物理内存使用减少。
    • 反正也没关系。进程不需要释放可分页 RAM;现代硬盘足够大(对于所有实际目的,免费且无限)。而且 JVM 很少使用不可分页的内存。
    • 在任何现代操作系统上,将内存归还给操作系统都将收效甚微。如果 java 没有主动使用该内存,那么如果系统需要更多内存,它将很快被分页。将该内存返回给操作系统只会让系统做一些工作而没有什么好处。
    • 同样值得注意的是,虽然它可能并不总是正确的,但一个普遍的想法是“如果一个程序使用一次 X 内存,它可能会再次使用 X 内存”。因此,将内存释放到操作系统的成本可能不值得。
    【解决方案5】:

    您正在开发什么程序?

    比较 C++ 和 Java 的速度就像比较螺丝刀和锤子,毫无意义。在我们生活的世界中,超级计算机和烤面包机都需要编程,您需要专注于您的特定需求。

    我将 C++ 用于在嵌入式系统上运行的硬实时软件。我不会梦想将严重损坏的 Java 用于实时规范至少再过 5 年,届时它有望成熟。我同样不愿意将 C++ 用于数据库、云访问中间件应用程序(实际上我不知道我刚才所说的内容,但我知道 Java 适合“那种东西”)

    您会使用没有后备箱空间的法拉利来搬运您的物品吗?你会带一辆小型货车参加拉力赛吗?

    人们必须明白,仅仅因为它们是编程语言,并不意味着它们在有意义的方面具有可比性。

    【讨论】:

      【解决方案6】:

      没有。除非你衡量它,否则你可能不会说出来。

      【讨论】:

      • 看,已经测量过了。
      • Debian Shootout 是一小部分玩具基准测试。最大的是什么,300 行?
      • @Paul Biggar - OP 是否询问过大于 300 行的程序?
      【解决方案7】:

      对于大多数用途而言,性能通常“足够好”。问题是您想要准确比较什么,以及您是否已应用分析器来查找和修复代码中的热点。

      基于 Sun 代码的 JVM 仍然需要支付高额的启动税(我仍然想知道他们为什么不能对其进行快照并从那里重新启动),但 Sun 的方法一直是正确性第一,速度第二,而且他们花了 10 年才达到标准。

      所以答案是“视情况而定”:)

      【讨论】:

        【解决方案8】:

        对于大多数应用程序来说,几乎可以肯定地编写一个 C++ 程序,该程序的性能比在 java 中实现相同目标的程序要好得多。

        但是,如果程序没有针对速度进行优化,那么 java 可能会同样快或更快,因为编译器/JIT 能够进行 C++ 环境无法做到的优化。

        基本上,如果您愿意花费大量时间来理解和编码以提高性能,那么您最终在 c++ 中可能会比在 java 中做得更好,但在相同的时间和精力下,java 很可能会“赢”。

        不过,与往常一样,算法改进往往会产生与语言一样多的差异。

        【讨论】:

          猜你喜欢
          • 2011-08-04
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2023-03-27
          • 2011-01-21
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多