3 ms·

Java running faster than C (2007)

11 points by DanielRibeiro 14y ago

alexchamberlain 14y ago
The problem is you don't need to actually do the calculations to determine the output of the program. It can all be optimised away to print statements. Is there any evidence iterate is actually running?
yxhuvud 14y ago
Please put a year on old posts. This one is from 2007.
fla 14y ago
What's the point of posting this five years old article without any context ?
ghh 14y ago
This text is from 2007, and compares execution speed of Java to C on one single CPU-bound benchmark. At http://shootout.alioth.debian.org/ http://shootout.alioth.debian.org/, an up-to-date list of the most popular languages are benchmarked. Tests are standardized, and code is optimized for the tested language and particular benchmark. Also, for each benchmark, not only execution speed, but also memory consumption and code size are measured, and the processor architecture is taken into account too.
- igouy 14y ago
  And coincidentally, the benchmarks game mandelbrot test shows a Scala program that performs well ;-) http://shootout.alioth.debian.org/u64q/performance.php?test=mandelbrot http://shootout.alioth.debian.org/u64q/performance.php?test=...
bnegreve 14y ago
Comparing execution times is actually very irrelevant. Speed is a matter of control. Any language with a VM and a garbage collector will be considered as "slow" because you can't always control what is going on. With C you can, and thus you can always write an ad-hoc implementation that will have the best performances on you execution platform. It is a great feature of C, now I don't think we need another language like this. There is nothing else to say.
- thirsteh 14y ago
  You can never get real-time with a higher-level language, but 99,9% of people don't need hard real-time. At most they need soft real-time. There is no reason to have to get there.
- bunderbunder 14y ago
  It's not so simple, and for the vast majority of use who don't have strong real-time requirements there are a couple other things to say: The two big managed languages (Java and C#) are now getting fast enough that there is only one place where slower performance can be assumed. That's the startup time - bootstrapping the managed runtime and JITing the code takes a while, so languages like C will always rule for execution patterns along the lines of a CGI script. It can also be said that they'll always be bigger memory hogs, which is something to think about when you're working in a constrained environment. That's a side effect of the garbage collector - objects aren't cleaned up right away, so there's always a "queue" of objects that are waiting for cleanup that's just sitting around occupying RAM. However, in terms of overall performance the story gets murky. In many real-world applications C or C++ is unlikely to outperform the managed languages (certainly not by a significant margin) unless significant spent on careful optimization. All that work increases both initial development and continuing maintenance costs, though, so it is unlikely to be worthwhile unless you're in a situation where a small amount of execution time really is worth a large amount of money. This is a difference you're never going to be seeing on the benchmark sites, though. Benchmarks are by necessity small programs, which means that are easy to carefully optimize to an extent that doesn't necessarily reflect what is practical in the real world.
dguaraglia 14y ago
Jesus, when will people stop posting this kind of "X faster than C" benchmarks? They are completely misleading and irrelevant. Next time someone is tempted please remember: - You are comparing apples to oranges (interpreters to compiled languages, bigint libraries to hardware-level ints, etc.) - What a C compiler does on one particular architecture running under a particular OS is not representative of C performance - You are most probably benchmarking just a tiny subset of what the language can do, and in most cases that subset is irrelevant in 99% of uses (e.g. "float comparison faster in Blub". Who cares if most people are using Blub to build webpages?) - Finally and most importantly: WHO CARES? Unless it affects a part of the code I'm using extensively it will only affect performance tangentially, if at all. EDIT: formatting

11 points by DanielRibeiro 14y ago

The problem is you don't need to actually do the calculations to determine the output of the program. It can all be optimised away to print statements. Is there any evidence iterate is actually running?

yxhuvud 14y ago

Please put a year on old posts. This one is from 2007.

fla 14y ago

What's the point of posting this five years old article without any context ?

ghh 14y ago

This text is from 2007, and compares execution speed of Java to C on one single CPU-bound benchmark. At http://shootout.alioth.debian.org/ http://shootout.alioth.debian.org/, an up-to-date list of the most popular languages are benchmarked. Tests are standardized, and code is optimized for the tested language and particular benchmark. Also, for each benchmark, not only execution speed, but also memory consumption and code size are measured, and the processor architecture is taken into account too.

igouy 14y ago
And coincidentally, the benchmarks game mandelbrot test shows a Scala program that performs well ;-) http://shootout.alioth.debian.org/u64q/performance.php?test=mandelbrot http://shootout.alioth.debian.org/u64q/performance.php?test=...

bnegreve 14y ago

Comparing execution times is actually very irrelevant. Speed is a matter of control. Any language with a VM and a garbage collector will be considered as "slow" because you can't always control what is going on. With C you can, and thus you can always write an ad-hoc implementation that will have the best performances on you execution platform. It is a great feature of C, now I don't think we need another language like this. There is nothing else to say.

thirsteh 14y ago
You can never get real-time with a higher-level language, but 99,9% of people don't need hard real-time. At most they need soft real-time. There is no reason to have to get there.
bunderbunder 14y ago
It's not so simple, and for the vast majority of use who don't have strong real-time requirements there are a couple other things to say: The two big managed languages (Java and C#) are now getting fast enough that there is only one place where slower performance can be assumed. That's the startup time - bootstrapping the managed runtime and JITing the code takes a while, so languages like C will always rule for execution patterns along the lines of a CGI script. It can also be said that they'll always be bigger memory hogs, which is something to think about when you're working in a constrained environment. That's a side effect of the garbage collector - objects aren't cleaned up right away, so there's always a "queue" of objects that are waiting for cleanup that's just sitting around occupying RAM. However, in terms of overall performance the story gets murky. In many real-world applications C or C++ is unlikely to outperform the managed languages (certainly not by a significant margin) unless significant spent on careful optimization. All that work increases both initial development and continuing maintenance costs, though, so it is unlikely to be worthwhile unless you're in a situation where a small amount of execution time really is worth a large amount of money. This is a difference you're never going to be seeing on the benchmark sites, though. Benchmarks are by necessity small programs, which means that are easy to carefully optimize to an extent that doesn't necessarily reflect what is practical in the real world.

dguaraglia 14y ago

Jesus, when will people stop posting this kind of "X faster than C" benchmarks? They are completely misleading and irrelevant. Next time someone is tempted please remember: - You are comparing apples to oranges (interpreters to compiled languages, bigint libraries to hardware-level ints, etc.) - What a C compiler does on one particular architecture running under a particular OS is not representative of C performance - You are most probably benchmarking just a tiny subset of what the language can do, and in most cases that subset is irrelevant in 99% of uses (e.g. "float comparison faster in Blub". Who cares if most people are using Blub to build webpages?) - Finally and most importantly: WHO CARES? Unless it affects a part of the code I'm using extensively it will only affect performance tangentially, if at all. EDIT: formatting