什么是更快 - Java 或 C#（或好的旧 C）？

What is faster- Java or C# (or good old C)?

提问by Rexsung

I'm currently deciding on a platform to build a scientific computational product on, and am deciding on either C#, Java, or plain C with Intel compiler on Core2 Quad CPU's. It's mostly integer arithmetic.

我目前正在决定使用一个平台来构建科学计算产品，并且正在决定使用 C#、Java 或在 Core2 Quad CPU 上使用 Intel 编译器的普通 C。它主要是整数算术。

My benchmarks so far show Java and C are about on par with each other, and .NET/C# trails by about 5%- however a number of my coworkers are claiming that .NET with the right optimizations will beat both of these given enough time for the JIT to do its work.

到目前为止，我的基准测试表明 Java 和 C 大致相当，而 .NET/C# 落后约 5%——但是我的一些同事声称，如果有足够的时间，具有正确优化的 .NET 将击败这两者以便 JIT 完成其工作。

I always assume that the JIT would have done it's job within a few minutes of the app starting (Probably a few seconds in my case, as it's mostly tight loops), so I'm not sure whether to believe them

我总是假设 JIT 会在应用程序启动后的几分钟内完成它的工作（在我的情况下可能是几秒钟，因为它主要是紧凑的循环），所以我不确定是否相信他们

Can anyone shed any light on the situation? Would .NET beat Java? (Or am I best just sticking with C at this point?).

任何人都可以对这种情况有所了解吗？.NET 会打败 Java 吗？（或者我最好在这一点上坚持使用 C？）。

The code is highly multithreaded and data sets are several terabytes in size.

代码是高度多线程的，数据集的大小有几个 TB。

Haskell/Erlang etc are not options in this case as there is a significant quantity of existing legacy C code that will be ported to the new system, and porting C to Java/C# is a lot simpler than to Haskell or Erlang. (Unless of course these provide a significant speedup).

在这种情况下，Haskell/Erlang 等不是选项，因为有大量现有的遗留 C 代码将被移植到新系统，并且将 C 移植到 Java/C# 比 Haskell 或 Erlang 简单得多。（当然，除非这些提供了显着的加速）。

Edit: We are considering moving to C# or Java because they may, in theory, be faster. Every percent we can shave off our processing time saves us tens of thousands of dollars per year. At this point we are just trying to evaluate whether C, Java, or c# would be faster.

编辑：我们正在考虑转向 C# 或 Java，因为它们理论上可能更快。我们可以减少处理时间的每一个百分比每年为我们节省数万美元。在这一点上，我们只是试图评估 C、Java 或 c# 是否会更快。

采纳答案by Daniel Earwicker

The key piece of information in the question is this:

问题中的关键信息是：

Every percent we can shave off our processing time saves us tens of thousands of dollars per year

我们可以减少处理时间的每一个百分比每年为我们节省数万美元

So you need to consider how much it will costto shave each percent off. If that optimization effort costs tens of thousands of dollars per year, then it isn't worth doing. You could make a bigger saving by firing a programmer.

因此，您需要考虑削减每个百分比的成本。如果这种优化工作每年要花费数万美元，那么它就不值得做。你可以通过解雇程序员来节省更多。

With the right skills (which today are rarer and therefore more expensive) you can hand-craft assembler to get the fastest possible code. With slightly less rare (and expensive) skills, you can do almost as well with some really ugly-looking C code. And so on. The more performance you squeeze out of it, the more it will cost you in development effort, and there will be diminishing returns for ever greater effort. If the profit from this stays at "tens of thousands of dollars per year" then there will come a point where it is no longer worth the effort. In fact I would hazard a guess you're already at that point because "tens of thousands of dollars per year" is in the range of one salary, and probably not enough to buy the skills required to hand-optimize a complex program.

有了正确的技能（如今这种技能很少见，因此也更昂贵），您可以手工制作汇编程序以获得尽可能快的代码。使用稍微少见（和昂贵）的技能，您几乎可以用一些非常难看的 C 代码来做。等等。您从中榨取的性能越多，开发工作所需的成本就越高，而且付出越多，回报就会越递减。如果由此带来的利润保持在“每年数万美元”，那么就会到了不再值得付出努力的地步。事实上，我敢猜测您已经到了那个时候，因为“每年数万美元”在一份薪水的范围内，并且可能不足以购买手动优化复杂程序所需的技能。

I would guess that if you have code already written in C, the effort of rewriting it all as a direct translation in another language will be 90% wasted effort. It will very likely perform slower simply because you won't be taking advantage of the capabilities of the platform, but instead working against them, e.g. trying to use Java as if it was C.

我猜想，如果您已经用 C 编写了代码，那么将其全部重写为另一种语言的直接翻译将浪费 90% 的精力。它的执行速度很可能会变慢，因为您不会利用平台的功能，而是针对它们工作，例如尝试像使用 C 一样使用 Java。

Also within your existing code, there will be parts that make a crucial contribution to the running time (they run frequently), and other parts that are totally irrelevant (they run rarely). So if you have some idea for speeding up the program, there is no economic sense in wasting time applying it to the parts of the program that don't affect the running time.

同样在您现有的代码中，会有对运行时间有重要贡献的部分（它们经常运行），以及其他完全不相关的部分（它们很少运行）。因此，如果您有一些加速程序的想法，那么浪费时间将其应用于不影响运行时间的程序部分是没有经济意义的。

So use a profiler to find the hot spots, and see where time is being wasted in the existing code.

因此，使用分析器来查找热点，并查看现有代码中浪费时间的地方。

Update when I noticed the reference to the code being "multithreaded"

当我注意到对“多线程”代码的引用时更新

In that case, if you focus your effort on removing bottlenecks so that your program can scale well over a large number of cores, then it will automatically get faster every year at a rate that will dwarf any other optimization you can make. This time next year, quad cores will be standard on desktops. The year after that, 8 cores will be getting cheaper (I bought one over a year ago for a few thousand dollars), and I would predict that a 32 core machine will cost less than a developer by that time.

在这种情况下，如果您专注于消除瓶颈，以便您的程序可以在大量内核上很好地扩展，那么它每年都会自动变得更快，其速度将使您可以进行的任何其他优化相形见绌。明年的这个时候，四核将成为台式机的标准配置。再过一年，8 核会越来越便宜（我一年多前花了几千美元买了一个），我预测到那时 32 核机器的成本将低于开发人员。

回答by mezoid

If there is already a significant quantity of legacy C code that will be added to the system then why move to C# and Java?

如果已经有大量遗留 C 代码将添加到系统中，那么为什么要转向 C# 和 Java？

In response to your latest edit about wanting to take advantage of any improvements in processing speed....then your best bet would be to stick to C as it runs closer to the hardware than C# and Java which have the overhead of a runtime environment to deal with. The closer to the hardware you can get the faster you should be able to run. Higher Level languages such as C# and Java will result in quicker development times...but C...or better yet Assembly will result in quicker processing time...but longer development time.

为了回应你关于想要利用处理速度的任何改进的最新编辑......那么你最好的选择是坚持使用 C，因为它比 C# 和 Java 运行更接近硬件，而 C# 和 Java 具有运行时环境的开销来处理。离硬件越近，运行速度就应该越快。C# 和 Java 等高级语言将导致更快的开发时间……但 C……或更好的汇编语言将导致更快的处理时间……但更长的开发时间。

回答by Marc Gravell

I'm sorry, but that is not a simple question. It would depend a loton what exactly was going on. C# is certainly no slouch, and you'd be hard-pressed to say "java is faster" or "C# is faster". C is a very different beast... it maybe has the potential to be faster - ifyou get it right; but in most cases it'll be about the same, but much harder to write.

对不起，但这不是一个简单的问题。这将取决于一个很多关于究竟发生了什么事情。C# 肯定不会懈怠，您很难说“java 更快”或“C# 更快”。C 是一个非常不同的野兽......它可能有更快的潜力 -如果你做对了；但在大多数情况下，它会大致相同，但更难写。

It also depends howyou do it - locking strategies, howyou do the parallelization, the main code body, etc.

这也取决于如何你这样做-锁定策略，怎么你做的并行化，主要的代码主体等。

Re JIT - you could use NGEN to flatten this, but yes; if you are hitting the same code it should be JITted very early on.

Re JIT - 您可以使用 NGEN 将其展平，但是可以；如果你使用相同的代码，它应该很早就被 JITted。

One very useful feature of C#/Java (over C) is that they have the potential to make better use of the local CPU (optimizations etc), without you having to worry about it.

C#/Java（在 C 之上）的一个非常有用的特性是它们有可能更好地利用本地 CPU（优化等），而您不必担心。

Also - with .NET, consider things like "Parallel Extensions" (to be bundled in 4.0), which gives you a much stronger threading story (compared to .NET without PFX).

此外 - 使用 .NET，考虑诸如“并行扩展”（将捆绑在 4.0 中）之类的东西，它为您提供了更强大的线程故事（与没有 PFX 的 .NET 相比）。

回答by TofuBeer

It is going to depend very much on what you are doing specifically. I have Java code that beats C code. I have Java code that is much slower than C++ code (I don't do C#/.NET so cannot speak to those).

这将在很大程度上取决于您具体在做什么。我有胜过 C 代码的 Java 代码。我有比 C++ 代码慢得多的 Java 代码（我不使用 C#/.NET，因此无法与之交谈）。

So, it depends on what you are doing, I am sure you can find something that is faster in language X than language Y.

所以，这取决于你在做什么，我相信你可以在语言 X 中找到比语言 Y 更快的东西。

Have you tried running the C# code through a profiler to see where it is taking the most time (same with Java and C while you are at it). Perhaps you need to do something different.

您是否尝试过通过分析器运行 C# 代码以查看它花费最多时间的地方（在您使用 Java 和 C 时也是如此）。也许你需要做一些不同的事情。

The Java HotSpot VM is more mature (roots of it going back to at least 1994) than the .NET one, so it may come down to the code generation abilities of both for that.

Java HotSpot VM 比 .NET 更成熟（它的根源至少可以追溯到 1994 年），因此这可能归结为两者的代码生成能力。

回答by Nathan

I would go with C# (or Java) because your developmenttime will probably be much faster than with C. If you end up needing extra speed then you can always rewrite a section in C and call it as a module.

我会选择 C#（或 Java），因为你的开发时间可能比 C 快得多。如果你最终需要额外的速度，那么你总是可以用 C 重写一个部分并将其称为模块。

回答by Dhana

Actually it is 'Assembly language'.

实际上它是“汇编语言”。

回答by Darren Clark

I'm honestly surprised at those benchmarks.

老实说，我对这些基准感到惊讶。

In a computationally intensive product I would place a large wager on C to perform faster. You might write code that leaks memory like a sieve, and has interesting threading related defects, but it should be faster.

在计算密集型产品中，我会在 C 上押下大赌注以提高性能。您可能会编写像筛子一样泄漏内存的代码，并且具有有趣的线程相关缺陷，但它应该更快。

The only reason I could think that Java or C# would be faster is due to a short run length on the test. If little or no GC happened, you'll avoid the overhead of actually deallocating memory. If the process is iterative or parallel, try sticking a GC.Collect wherever you think you're done a bunch of objects(after setting things to null or otherwise removing references).

我认为 Java 或 C# 会更快的唯一原因是测试的运行时间较短。如果很少或没有 GC 发生，您将避免实际释放内存的开销。如果该过程是迭代或并行的，请尝试在您认为已完成一堆对象的任何地方粘贴 GC.Collect（在将事物设置为 null 或以其他方式删除引用之后）。

Also, if you're dealing with terabytes of data, my opinion is you're going to be much better off with deterministic memory allocation that you get with C. If you deallocate roughly close to when you allocate your heap will stay largely unfragmented. With a GC environment you may very well end up with your program using far more memory after a decent run length than you would guess, just because of fragmentation.

此外，如果您正在处理数 TB 的数据，我的观点是，使用 C 获得的确定性内存分配会更好。如果您在大约接近分配时解除分配，您的堆将在很大程度上保持不碎片化。在 GC 环境中，您的程序很可能会在一段合适的运行长度后使用比您想象的多得多的内存，这仅仅是因为碎片。

To me this sounds like the sort of project where C would be the appropriate language, but would require a bit of extra attention to memory allocation/deallocation. My bet is that C# or Java will fail if run on a full data set.

对我来说，这听起来像是 C 将是合适语言的那种项目，但需要额外注意内存分配/释放。我敢打赌，如果在完整数据集上运行，C# 或 Java 将失败。

回答by Magnus Johansson

If you are using a highly multithreaded code, I would recommend you to take a look at the upcoming Task Parallel Library (TPL) for .NET and the Parallel Pattern Library (PPL)for native C++ applications. That will save you a lot of issues with thread/dead lockíng and all other issues that you would spend a lot of time digging into and solving for yourself. For my self, I truly believe that the memory management in the managed world will be more efficient and beat the native code in the long term.

如果您使用的是高度多线程的代码，我建议您查看即将推出的用于 .NET 的任务并行库 (TPL) 和用于本机 C++ 应用程序的并行模式库 (PPL)。这将为您节省很多线程/死锁问题以及您需要花费大量时间自己研究和解决的所有其他问题。就我自己而言，我真的相信托管世界中的内存管理将更有效，并在长期内击败本机代码。

回答by J-16 SDiZ

Depends on what kind of application you are writing. Try The Computer Language Benchmarks Game

取决于你正在编写什么样的应用程序。试试计算机语言基准游戏

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=csharp&lang2=java&box=1http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=csharp&lang2=java&box=1

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=csharp&lang2=java&box=1 http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=csharp&lang2 =java&box=1

回答by Friedrich

If much of your code is in C why not keep it? In principal and by design it's obvious that C is faster. They may close the gap over time but they always have more level os indirection and "safety". C is fast because it's "unsafe". Just think about bound checking. Interfacing to C is supported in every langauge. And so I can not see why one would not like to just wrap the C code up if it's still working and use it in whatever language you like

如果你的大部分代码都是用 C 编写的，为什么不保留它呢？原则上和设计上，很明显 C 更快。随着时间的推移，他们可能会缩小差距，但他们总是有更多的间接性和“安全性”。C 很快，因为它“不安全”。想想边界检查。每种语言都支持与 C 的接口。所以我不明白为什么如果 C 代码仍然有效并且用你喜欢的任何语言使用它，为什么不喜欢把它包装起来