5 ms·

It looks like JavaScript is almost at performance parity with Java now: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html http

It looks like JavaScript is almost at performance parity with Java now: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... That begs the immediate question: Why would anybody continue to hire Java developers? I was thinking about that recently and two things came to mind: * The JavaScript ecosystem is incredibly immature. You can deliver some amazingly supreme trash in this language and it will likely execute, most of the time. Nearly everybody is deathly afraid of the platform (the DOM) and requires the worlds largest frameworks merely to put text on a webpage, even though familiarity with the DOM is understanding just a few methods. * Most Java developers are trained by schools. After thinking through those two points I have to realize employers would rather burn money than train developers or pray and hope that with enough open source tools dependencies will compensate for the maturity gap.

bitcharmer 5y ago
I had a look at a couple of the Java benchmarks you've linked to and they are horribly written, completely disregarding stuff like OSR, forgetting about the warm up and ridden with absolutely unnecessary allocations. Either someone did this on purpose or they have no idea how to write efficient Java code and benchmark it.
- sgift 5y ago
  The benchmark game is always full of these things. Some people are very motivated to make their language shine on it, so it has good[1] implementations, almost everything else is bad. Really, really bad. It's best to just ignore it. [1] With good defined as fast. Many of the implementations there are so contorted that no one in their right mind would use anything like it in production. But they are fast.
  - johnisgood 5y ago
    Yep. There were two implementations of whatever in Ada, but one of them failed to print the right output, so was disregarded in favor of the slower, but correct one. I fixed the implementation and now Ada is way, way faster. If I remember correctly I actually had the conversation with whoever is responsible for that website here on HN, and I posted the correct code here (via a link).
    - igouy 5y ago
      So — programs have to show the correct output — program source code is shown — programs can be contributed What was the problem?
      - deleted 5y ago
        [deleted]
      - johnisgood 5y ago
        Are you asking specifically about what I had to do to fix the faster, but previously incorrect implementation? It is on HN somewhere. Other than that, there is no problem. Perhaps people who took the site too seriously may have gotten the wrong idea about the language's performance.
        igouy 5y ago
        You answered "Yep" to someone's comment that the benchmarks game was "Really, really bad." and that didn't really seem to be the experience you described?
        johnisgood 5y ago
        > Some people are very motivated to make their language shine on it, so it has good[1] implementations, I said "Yep" as in "Yep, some people do contribute", and it has good implementations for some, while shitty ones for others, and it should not be taken way too seriously because of what he just said.
        igouy 5y ago
        Just seriously enough :-)
        johnisgood 5y ago
        Yup, enough just to give me a little nudge towards the direction I was already leaning! If my favorite language is slow, I will not take it seriously at all. :)
  - igouy 5y ago
    Here are 2 of the programs austincheney referenced. What in particular is wrong about comparing measurements of these programs? n-body Node js #6 https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-node-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... n-body Java #4 https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-java-4.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- peterashford 5y ago
  Not warming up hotspot seems to be a constant in benchmarks for people comparing languages with Java. I mean, it's probably valid if your use case is a CLI tool (although, in that case an AOT compiler is clearly a better option)
  - igouy 5y ago
    fyi "Wtf kind of benchmark counts the jvm startup time?" https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - peterashford 5y ago
      Thanks for that. Jvm startup time used to be an issue which doesn't appear to exist anymore given those numbers - although as that reference said, it would still matter for something that is finished very quickly. TIL
- viktorcode 5y ago
  If I'm not mistaken the hallmark of benchmark game is to use same looking source code and see how fast it runs written in different languages. Basically, it presumes that all languages follow the same programming paradigms.
  - igouy 5y ago
    Mistaken-ish. "So we accept something intermediate between chaos and rigidity — enough flex & slop & play to allow for Haskell programs that are not just mechanically translated from Fortran; enough similarity in the basic workloads & tested results." https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#starting-point https://benchmarksgame-team.pages.debian.net/benchmarksgame/... What you describe is more like the "Are We Fast Yet?" project — https://benchmarksgame-team.pages.debian.net/benchmarksgame/why-measure-toy-benchmark-programs.html#cross-language-compiler-benchmarking https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- igouy 5y ago
  - bitcharmer 5y ago
    I love how you insist on using the "vastly superior" phrase to mock something's you haven't even seen but have strong opinions about right off the bat. Not taking the bait, anyone who can read and comprehend Java code will tell you the same. What I refer to is a standard way of approaching Java code benchmarking. https://shipilev.net/talks/jvmls-July2013-benchmarking.pdf https://shipilev.net/talks/jvmls-July2013-benchmarking.pdf
    - igouy 5y ago
      > … horribly written … ridden with absolutely unnecessary allocations … no idea how to write efficient Java code… If those claims are true then how could your alternatives not be vastly superior? > … a standard way… What are your JMH measurements? https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- igouy 5y ago
  Please show your improved programs, along with the measurements which show the improvement, so we can confirm your claims. The benchmarks game does show measurements which take OSR and warm up into account — https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
the_duke 5y ago
Apart from the questionable code quality of the benchmarks: JavaScript can be impressively fast in very small benchmarks, but things change very quickly with real applications. Java has way more information, thanks to the type system, and can do a much better job with optimizations.
watwut 5y ago
> Why would anybody continue to hire Java developers? Usually, because they have projects written in Java and wants to continue developing those. Or, because they are starting new Java project and have no real reason to switch into Javascript ecosystem, really.

bitcharmer 5y ago

I had a look at a couple of the Java benchmarks you've linked to and they are horribly written, completely disregarding stuff like OSR, forgetting about the warm up and ridden with absolutely unnecessary allocations. Either someone did this on purpose or they have no idea how to write efficient Java code and benchmark it.

sgift 5y ago
The benchmark game is always full of these things. Some people are very motivated to make their language shine on it, so it has good[1] implementations, almost everything else is bad. Really, really bad. It's best to just ignore it. [1] With good defined as fast. Many of the implementations there are so contorted that no one in their right mind would use anything like it in production. But they are fast.
- johnisgood 5y ago
  Yep. There were two implementations of whatever in Ada, but one of them failed to print the right output, so was disregarded in favor of the slower, but correct one. I fixed the implementation and now Ada is way, way faster. If I remember correctly I actually had the conversation with whoever is responsible for that website here on HN, and I posted the correct code here (via a link).
  - igouy 5y ago
    So — programs have to show the correct output — program source code is shown — programs can be contributed What was the problem?
    - deleted 5y ago
      [deleted]
    - johnisgood 5y ago
      Are you asking specifically about what I had to do to fix the faster, but previously incorrect implementation? It is on HN somewhere. Other than that, there is no problem. Perhaps people who took the site too seriously may have gotten the wrong idea about the language's performance.
      - igouy 5y ago
        You answered "Yep" to someone's comment that the benchmarks game was "Really, really bad." and that didn't really seem to be the experience you described?
        johnisgood 5y ago
        > Some people are very motivated to make their language shine on it, so it has good[1] implementations, I said "Yep" as in "Yep, some people do contribute", and it has good implementations for some, while shitty ones for others, and it should not be taken way too seriously because of what he just said.
        igouy 5y ago
        Just seriously enough :-)
        johnisgood 5y ago
        Yup, enough just to give me a little nudge towards the direction I was already leaning! If my favorite language is slow, I will not take it seriously at all. :)
- igouy 5y ago
  Here are 2 of the programs austincheney referenced. What in particular is wrong about comparing measurements of these programs? n-body Node js #6 https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-node-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... n-body Java #4 https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-java-4.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
peterashford 5y ago
Not warming up hotspot seems to be a constant in benchmarks for people comparing languages with Java. I mean, it's probably valid if your use case is a CLI tool (although, in that case an AOT compiler is clearly a better option)
- igouy 5y ago
  fyi "Wtf kind of benchmark counts the jvm startup time?" https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - peterashford 5y ago
    Thanks for that. Jvm startup time used to be an issue which doesn't appear to exist anymore given those numbers - although as that reference said, it would still matter for something that is finished very quickly. TIL
viktorcode 5y ago
If I'm not mistaken the hallmark of benchmark game is to use same looking source code and see how fast it runs written in different languages. Basically, it presumes that all languages follow the same programming paradigms.
- igouy 5y ago
  Mistaken-ish. "So we accept something intermediate between chaos and rigidity — enough flex & slop & play to allow for Haskell programs that are not just mechanically translated from Fortran; enough similarity in the basic workloads & tested results." https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#starting-point https://benchmarksgame-team.pages.debian.net/benchmarksgame/... What you describe is more like the "Are We Fast Yet?" project — https://benchmarksgame-team.pages.debian.net/benchmarksgame/why-measure-toy-benchmark-programs.html#cross-language-compiler-benchmarking https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
igouy 5y ago
- bitcharmer 5y ago
  I love how you insist on using the "vastly superior" phrase to mock something's you haven't even seen but have strong opinions about right off the bat. Not taking the bait, anyone who can read and comprehend Java code will tell you the same. What I refer to is a standard way of approaching Java code benchmarking. https://shipilev.net/talks/jvmls-July2013-benchmarking.pdf https://shipilev.net/talks/jvmls-July2013-benchmarking.pdf
  - igouy 5y ago
    > … horribly written … ridden with absolutely unnecessary allocations … no idea how to write efficient Java code… If those claims are true then how could your alternatives not be vastly superior? > … a standard way… What are your JMH measurements? https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
igouy 5y ago
Please show your improved programs, along with the measurements which show the improvement, so we can confirm your claims. The benchmarks game does show measurements which take OSR and warm up into account — https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

the_duke 5y ago

Apart from the questionable code quality of the benchmarks: JavaScript can be impressively fast in very small benchmarks, but things change very quickly with real applications. Java has way more information, thanks to the type system, and can do a much better job with optimizations.

watwut 5y ago

> Why would anybody continue to hire Java developers? Usually, because they have projects written in Java and wants to continue developing those. Or, because they are starting new Java project and have no real reason to switch into Javascript ecosystem, really.