5 ms·

I think this is a false dichotomy. You can make almost any language fast by writing very non-idiomatic code. The advantage of something like Java is that you ca

I think this is a false dichotomy. You can make almost any language fast by writing very non-idiomatic code. The advantage of something like Java is that you can write readable, "normal" code that runs at nearly the speed of optimized C. I see these comparisons all the time and they inevitably jump through a ton of hoops to make a language like Python perform like Java/C#/Go/rust. IMO the big advantage of these language is that they're fast for the majority of normal, totally unoptimized code. I can write REST endpoints in Java/C# that do a hundred thousand requests per second using a mainstream framework with no optimization. That's important in the real world where I'm usually working on large ancient projects with somewhat poor code quality

shaklee3 8y ago
Standard Java does not run at the speed of optimized C, except for a couple cherry-picked benchmarks.
- spricket 8y ago
  I converted the authors c version of the code to Java and ran it through JMH, on my machine it runs about 30% slower. (This is before he added the metaprogramming that essentially precalculates some of the matrices at compile-time). That's also without making any attempt at optimizing, basically a straight conversion that took ten minutes. It's not the speed of C but it's pretty close. And it has memory safety.
  - shaklee3 8y ago
    We can agree to disagree, but I don't consider 30% to be close. Maybe for applications that aren't time-sensitive, but I rarely deal with those.
gnulinux 8y ago
If you write a simple for loop incrementing `i` then yeah Java runs almost as fast as C. In whole programs where GC unpredictably runs and does all sorts of nasty things like dirtying pages and pressuring the cache, you won't get anything close to C. Citation needed.
- spricket 8y ago
  This was true until a few years ago. Java 11 has a new ultra-low-pause GC that's almost entirely multi-threaded and mostly predictable. There's plenty of semi-realistic benchmarks out there. I like TechEmpower the best since they test an entire web framework + database. Several java implementations are right up there with C, along with .NET Core, Go, and Rust. In the vast majority of cases the extra 20-50% speed of C isn't worth the dangers.
bhauer 8y ago
Agreed. This is a point I make routinely when discussing the performance of platforms and frameworks: all else being equal, selecting a high-performance platform and framework affords you, as the application developer, the luxury to defer optimization of your code. It's an inversion of the instinct people have with our culture's commandment about deferring premature optimization. The instinct is that selecting for performance at the start of a project is premature. I argue that selecting a platform is precisely the time to consider performance because it is a decision that is extremely high-friction to change later. Therefore, it's timely, not premature. By selecting a high-performance platform, you set the performance ceiling and baseline performance of your application high. This gives you the freedom to develop application code in a sub-optimal manner—deferring its optimization until such time that it is necessary, perhaps forever. With a lower-performance platform, you will run into a performance hurdle event that requires optimization effort earlier and the level of effort to raise your performance ceiling will be greater than it would be had you selected a higher-performance platform at the start. The key, of course, is all else being equal. That's not always the case for all teams, but it is still often the case. The key is knowing when your team can manage to adopt a high-performance platform and being careful about that decision.
- jungler 8y ago
  "high-performance" is a qualifier worthy of question, though. If the goal were to write one algorithm to be the fastest implementation, performance would usually equate to having low level control. If the goal were to do automatic optimization of a wide variety of similar algorithms, then we're in the "actually writing a compiler" territory and then there is little to be gained from defaulting to low-level control.

shaklee3 8y ago

Standard Java does not run at the speed of optimized C, except for a couple cherry-picked benchmarks.

spricket 8y ago
I converted the authors c version of the code to Java and ran it through JMH, on my machine it runs about 30% slower. (This is before he added the metaprogramming that essentially precalculates some of the matrices at compile-time). That's also without making any attempt at optimizing, basically a straight conversion that took ten minutes. It's not the speed of C but it's pretty close. And it has memory safety.
- shaklee3 8y ago
  We can agree to disagree, but I don't consider 30% to be close. Maybe for applications that aren't time-sensitive, but I rarely deal with those.

gnulinux 8y ago

If you write a simple for loop incrementing `i` then yeah Java runs almost as fast as C. In whole programs where GC unpredictably runs and does all sorts of nasty things like dirtying pages and pressuring the cache, you won't get anything close to C. Citation needed.

spricket 8y ago
This was true until a few years ago. Java 11 has a new ultra-low-pause GC that's almost entirely multi-threaded and mostly predictable. There's plenty of semi-realistic benchmarks out there. I like TechEmpower the best since they test an entire web framework + database. Several java implementations are right up there with C, along with .NET Core, Go, and Rust. In the vast majority of cases the extra 20-50% speed of C isn't worth the dangers.

bhauer 8y ago

Agreed. This is a point I make routinely when discussing the performance of platforms and frameworks: all else being equal, selecting a high-performance platform and framework affords you, as the application developer, the luxury to defer optimization of your code. It's an inversion of the instinct people have with our culture's commandment about deferring premature optimization. The instinct is that selecting for performance at the start of a project is premature. I argue that selecting a platform is precisely the time to consider performance because it is a decision that is extremely high-friction to change later. Therefore, it's timely, not premature. By selecting a high-performance platform, you set the performance ceiling and baseline performance of your application high. This gives you the freedom to develop application code in a sub-optimal manner—deferring its optimization until such time that it is necessary, perhaps forever. With a lower-performance platform, you will run into a performance hurdle event that requires optimization effort earlier and the level of effort to raise your performance ceiling will be greater than it would be had you selected a higher-performance platform at the start. The key, of course, is all else being equal. That's not always the case for all teams, but it is still often the case. The key is knowing when your team can manage to adopt a high-performance platform and being careful about that decision.

jungler 8y ago
"high-performance" is a qualifier worthy of question, though. If the goal were to write one algorithm to be the fastest implementation, performance would usually equate to having low level control. If the goal were to do automatic optimization of a wide variety of similar algorithms, then we're in the "actually writing a compiler" territory and then there is little to be gained from defaulting to low-level control.