4 ms·

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

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.

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.