4 ms·

Brings back nostalgic memories from Java days in the 2000s. "Java will be faster than C" for exactly the same reasons laid out in the article. And here we are,

Brings back nostalgic memories from Java days in the 2000s. "Java will be faster than C" for exactly the same reasons laid out in the article. And here we are, 20 years later.

carlmr 1y ago
I dunno, I was there in the 2000s and can't remember anyone saying that. I remember a lot of people saying Java's slightly slower execution will not matter that much when processing hardware gets better.
- Sesse__ 1y ago
  I was there in the 2000s and remember several people saying that.
- holowoodman 1y ago
  There were tons of people making those claims. https://stackoverflow.com/questions/64582/c-java-performance-for-neural-networks https://stackoverflow.com/questions/64582/c-java-performance... Especially profile-guided-optimization was hailed as the next big thing, only JIT-ed languages were the ones to be fast, because after some warmup time they would adapt to your data and hardware. Java is still dog-slow...
- chubot 1y ago
  I was also there in the 2000's and I remember people saying Java can be just as fast as C And in particular that garbage collection can be faster than malloc/free. This is technically true in the case you have a naive C program. There are tons of C programs out there, and some are slow. (But there are more slow Java programs out there) But it's 100% clear now that GC has a significant cost, and while you can optimize a bad C program, it can be very hard in many cases to optimize the cost of GC away. C offers more freedom and thus more footguns, but the freedom also means you don't really have a performance cap. And I prefer GC -- most programs I write will have GC; I just recognize the performance cap, and design accordingly. (In fact I wrote a GC for a subset of C++ for https://oils.pub https://oils.pub -- I actually think this is a language with nicer performance properties than Java, mainy due to being AOT)
  - gf000 1y ago
    If you bring parallel processing into the picture (shared memory model), then the achievable performance caps per dev work change significantly though. I will very easily write a faster parallelizable program in Java, before I get the C one even remotely correct and then we haven't even taken into account every future maintenance cost. Also, the way C devs often hide the cost is simply.. less efficient code like copying stuff right and left, etc, which can actually be more "bravely" avoided in managed languages.
    - holowoodman 1y ago
      Then pray tell, how come that the most parallel and most demanding computations like weather simulations, fluid dynamics and stuff like that avoid superior Java like the plague? Shouldn't it have been a blessing with its easier parallelizable code? The reality is that it's quite the opposite. Java boxed types, lack of control over memory layouts leading to page flapping and false sharing, lack of fast synchronisation primitives, lack of a compiler capable of hinted or automatic loop parallelization lead to Java being totally unsuitable here. The crown goes to FORTRAN in that regard, with C and C++ being second and third places. Of course theoretically a magic fairy-tale Java compiler could look at the code, recognize all the aforementioned problems and fix them. Of course the language would allow for this to happen totally without changing semantics. But no Java compiler even comes close...
    - carlmr 1y ago
      >I will very easily write a faster parallelizable program in Java, before I get the C one even remotely correct and then we haven't even taken into account every future maintenance cost. Even better in Rust. You get great memory safety guarantees from the borrow checker helping guide your parallelization, while still being fast and GCless. It's the best of both worlds. >Also, the way C devs often hide the cost is simply.. less efficient code like copying stuff right and left, etc, which can actually be more "bravely" avoided in managed languages. I'd say Rust is again the easiest way to avoid unnecessary copies without sacrificing safety.
      - 1y ago
- mrkeen 1y ago
  Look at your sibling comments. Some people are still saying it now.
- CalChris 1y ago
  I was there in the 90s and people at Sun were saying that Java would be faster than C++. This kind of talk even begat Jikes, a Java-in-Java JVM from IBM.
pegasus 1y ago
Yes, 20 years later, the JVM is considered a marvel of engineering, and, surprisingly, some of those marketing claims have in fact come true. Or at least, more than would be expected after doing the hype-correction always called for in such situations. Yes, Java can be faster in certain contexts: the kind of contexts Java is usually employed in addressing these days. Stuff like enterprise backend systems and big data processing, where startup time or precise memory control are not important. Then there's GraalVM which allows for AOT compilation, etc.
- holowoodman 1y ago
  I'd like to see those numbers please. While there have been improvements, Java performance work seems to have stopped after 2011 or so. Mobile CPUs became fast enough for Android, so no movement there. And commercial software got stuck on numerous proprietary Java VMs that didn't improve after the Oracle takeover of SUN. Alterative VMs improved, but didn't get adopted, fragemented and in the end didn't really raise the bar a lot. To this day, Java applications are the slowest and most memory hungry long-running server applications by far. Only some scripting languages are worse, but only by performance, almost never by memory.
  - pegasus 1y ago
    Seriously? Since 2011, so since Java 7, stagnation in performance? That's a startling claim. I'd like to see some numbers as well. I'll start the first round with this article: https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html Note: this is comparing to Java 17 to Java 8 (released in 2014), and we are now at Java 24!
    - holowoodman 1y ago
      That is garbage collection performance, something that only GC languages even have to consider as additional overhead. It also doesn't even try to compare against anything non-Java. There are no serious Java performance comparisons on stuff like transaction throughput, which would be what the "long running server application" usecase should aim for. You yourself claimed that enterprise data processing is what you are talking about. There are benchmarks that even with long warmup times make Java come up far worse than all the compiled languages (even Golang nowadays). https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javavm-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Imho, people have stopped benchmarking Java ages ago, since it is known to be hopeless.
yccs27 1y ago
TFA only talks about having strong or weak static guarantees. There's more that typically comes with a "high-level" language like Java: Nonzero-cost abstractions like boxed objects, automatic memory management and more.

Brings back nostalgic memories from Java days in the 2000s. "Java will be faster than C" for exactly the same reasons laid out in the article. And here we are, 20 years later.

carlmr 1y ago

I dunno, I was there in the 2000s and can't remember anyone saying that. I remember a lot of people saying Java's slightly slower execution will not matter that much when processing hardware gets better.

Sesse__ 1y ago
I was there in the 2000s and remember several people saying that.
holowoodman 1y ago
There were tons of people making those claims. https://stackoverflow.com/questions/64582/c-java-performance-for-neural-networks https://stackoverflow.com/questions/64582/c-java-performance... Especially profile-guided-optimization was hailed as the next big thing, only JIT-ed languages were the ones to be fast, because after some warmup time they would adapt to your data and hardware. Java is still dog-slow...
chubot 1y ago
I was also there in the 2000's and I remember people saying Java can be just as fast as C And in particular that garbage collection can be faster than malloc/free. This is technically true in the case you have a naive C program. There are tons of C programs out there, and some are slow. (But there are more slow Java programs out there) But it's 100% clear now that GC has a significant cost, and while you can optimize a bad C program, it can be very hard in many cases to optimize the cost of GC away. C offers more freedom and thus more footguns, but the freedom also means you don't really have a performance cap. And I prefer GC -- most programs I write will have GC; I just recognize the performance cap, and design accordingly. (In fact I wrote a GC for a subset of C++ for https://oils.pub https://oils.pub -- I actually think this is a language with nicer performance properties than Java, mainy due to being AOT)
- gf000 1y ago
  If you bring parallel processing into the picture (shared memory model), then the achievable performance caps per dev work change significantly though. I will very easily write a faster parallelizable program in Java, before I get the C one even remotely correct and then we haven't even taken into account every future maintenance cost. Also, the way C devs often hide the cost is simply.. less efficient code like copying stuff right and left, etc, which can actually be more "bravely" avoided in managed languages.
  - holowoodman 1y ago
    Then pray tell, how come that the most parallel and most demanding computations like weather simulations, fluid dynamics and stuff like that avoid superior Java like the plague? Shouldn't it have been a blessing with its easier parallelizable code? The reality is that it's quite the opposite. Java boxed types, lack of control over memory layouts leading to page flapping and false sharing, lack of fast synchronisation primitives, lack of a compiler capable of hinted or automatic loop parallelization lead to Java being totally unsuitable here. The crown goes to FORTRAN in that regard, with C and C++ being second and third places. Of course theoretically a magic fairy-tale Java compiler could look at the code, recognize all the aforementioned problems and fix them. Of course the language would allow for this to happen totally without changing semantics. But no Java compiler even comes close...
  - carlmr 1y ago
    >I will very easily write a faster parallelizable program in Java, before I get the C one even remotely correct and then we haven't even taken into account every future maintenance cost. Even better in Rust. You get great memory safety guarantees from the borrow checker helping guide your parallelization, while still being fast and GCless. It's the best of both worlds. >Also, the way C devs often hide the cost is simply.. less efficient code like copying stuff right and left, etc, which can actually be more "bravely" avoided in managed languages. I'd say Rust is again the easiest way to avoid unnecessary copies without sacrificing safety.
    - 1y ago
mrkeen 1y ago
Look at your sibling comments. Some people are still saying it now.
CalChris 1y ago
I was there in the 90s and people at Sun were saying that Java would be faster than C++. This kind of talk even begat Jikes, a Java-in-Java JVM from IBM.

pegasus 1y ago

Yes, 20 years later, the JVM is considered a marvel of engineering, and, surprisingly, some of those marketing claims have in fact come true. Or at least, more than would be expected after doing the hype-correction always called for in such situations. Yes, Java can be faster in certain contexts: the kind of contexts Java is usually employed in addressing these days. Stuff like enterprise backend systems and big data processing, where startup time or precise memory control are not important. Then there's GraalVM which allows for AOT compilation, etc.

holowoodman 1y ago
I'd like to see those numbers please. While there have been improvements, Java performance work seems to have stopped after 2011 or so. Mobile CPUs became fast enough for Android, so no movement there. And commercial software got stuck on numerous proprietary Java VMs that didn't improve after the Oracle takeover of SUN. Alterative VMs improved, but didn't get adopted, fragemented and in the end didn't really raise the bar a lot. To this day, Java applications are the slowest and most memory hungry long-running server applications by far. Only some scripting languages are worse, but only by performance, almost never by memory.
- pegasus 1y ago
  Seriously? Since 2011, so since Java 7, stagnation in performance? That's a startling claim. I'd like to see some numbers as well. I'll start the first round with this article: https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html Note: this is comparing to Java 17 to Java 8 (released in 2014), and we are now at Java 24!
  - holowoodman 1y ago
    That is garbage collection performance, something that only GC languages even have to consider as additional overhead. It also doesn't even try to compare against anything non-Java. There are no serious Java performance comparisons on stuff like transaction throughput, which would be what the "long running server application" usecase should aim for. You yourself claimed that enterprise data processing is what you are talking about. There are benchmarks that even with long warmup times make Java come up far worse than all the compiled languages (even Golang nowadays). https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javavm-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Imho, people have stopped benchmarking Java ages ago, since it is known to be hopeless.

yccs27 1y ago

TFA only talks about having strong or weak static guarantees. There's more that typically comes with a "high-level" language like Java: Nonzero-cost abstractions like boxed objects, automatic memory management and more.