4 ms·

(I only read the pdf outline) As someone who is neither a Common Lisp nor a JVM programmer, I’m genuinely curious to hear from experts whether the old trope of

by nsm 3y ago

(I only read the pdf outline) As someone who is neither a Common Lisp nor a JVM programmer, I’m genuinely curious to hear from experts whether the old trope of “JVM is slow and bloated” is even remotely true any more. Based on hearsay, the JVM often competes in language performance closer to C++, and has probably the best garbage collectors in the world as well as the best developer and operational tooling. How much do other platform developers leave on the table by ignoring the JVM these days? As an aside, even the trope about us running out of energy, or energy usage directly corresponding to planetary destruction is becoming less and less true. With solar PVs and the sun, we truly do have a shot at a future with limitless energy and resources.

brabel 3y ago
> Based on hearsay, the JVM often competes in language performance closer to C++, and has probably the best garbage collectors in the world as well as the best developer and operational tooling. How much do other platform developers leave on the table by ignoring the JVM these days? I am mostly a Java developer, but have had the opportunity to play with Common Lisp and many other languages. While it's true the JVM is very performant, its performance actually comes at a cost: it has a JIT, Garbage Collector, a whole lot of machinery for Threads/VirtualThreads, JMX etc. all of which comes at a cost... thanks to multicore processors and lots and lots of RAM being available, this translates in really fast performance for Java applications... so that cost may be advantageous to you. Common Lisp applications are much lighter than Java applications from what I've actually measured given its simpler model... it basically compiles Lisp code to machine code directly and then runs that (Java runs bytecode, and then at runtime the JIT selects which code to optimise, which continues to happen for the lifetime of the application). I would bet money on any application written in Common Lisp being significantly lighter, and hence "greener", than the equivalent Java application, while still running at nearly the same speed, or even faster. For short running programs, Common Lisp is incredibly fast at starting up and getting stuff done - it competes with C and Rust in that regard, not with Java. > How much do other platform developers leave on the table by ignoring the JVM these days? Common Lisp tooling is integrated into the language itself. You can inspect the machine code it generates, ask it to instrument every function so you can profile, and so on without even needing any external tools - it's all built-in... but of course, using it from SLIME or SLY (in emacs) makes it a lot more pleasant. If you think Java tools are better, I believe you may not know Common Lisp very well.
- andsoitis 3y ago
  > While it's true the JVM is very performant, its performance actually comes at a cost: it has a JIT, Garbage Collector, a whole lot of machinery for Threads/VirtualThreads, JMX etc. all of which comes at a cost... thanks to multicore processors and lots and lots of RAM being available, this translates in really fast performance for Java applications... so that cost may be advantageous to you. Here you say “it comes at a cost” twice, but you don’t say what the cost is! Or am I missing something?
  - brabel 3y ago
    The cost is on the things mentioned themselves: JIT is not free at all, it may take more CPU power than your actual application during some period! You can actually tell the JVM to not JIT... try that and see just how slow your code runs... it may give you an idea of how much it costs in terms of energy as well if you're able to measure that (I don't know how much that cost would look like, to be honest, I can only imagine it's a significant proportion of the total).
    - pjmlp 3y ago
      Or maybe AOT compile, there are two free beer options now, or make use of JIT caches, there are also a couple of implementationst that do it. That is the beauty of languages with multiple implementations.
- pjmlp 3y ago
  That "cost" ignores the ecosystem of Java implementations, including AOT ones, embedded deployments, and real time implementations. Also lets not forget the influence of Lisp/Scheme people like Guy Steele on how Java turned out. "We were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." Full Lisp would have been better, but apparently Lisps in desguise like Dylan and Julia, are the best mainstream is willing to take on.
tmtvl 3y ago
As someone who has done a bit of both Java and CL (and Perl, and C, and Free Pascal, and Guile Scheme, and Raku, and... oh my, where does the time go?) Java is entirely fine. A bit heavy on the ol' RAM, and if you really want to get it fast you need to know which knobs to push and which settings to turn various dials to, but it's fine. I haven't tried that new Graal VM thing, hearsay is that it makes Java run real good, but with plain old OpenJDK it's fine.
bsdpufferfish 3y ago
> the JVM often competes in language performance closer to C++ I don't think it's even close. Benchmark game is one (biased) reference. And it's even worse because optimized Java is not canonical Java. Canonical C++ is pretty fast.
- lelanthran 3y ago
  > I don't think it's even close. Benchmark game is one (biased) reference. I agree. 1. Benchmarks tend to do one thing, then repeat that one thing 25000 times. Non-server programs don't do that[1] so you don't get to amortise the time spent on JITting a code snippet across 25000 executions. 2. The runtime basically requires exclusive use of a core for short periods (GC, JIT). If you're running on a system that costs per core, you're using (worst case scenario) an extra core for each Java program. The benchmarks happily give multiple cores even to sequential (non-parallel) benchmarks. [1] Even many server programs don't do that.
  - igouy 3y ago
    1. The benchmarks game doesn't "repeat that one thing 25000 times" as warmup and the benchmarks game measurements include 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/... 2. The benchmarks game happily gives multiple cores and shows that "cpu secs" measurement: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- igouy 3y ago
  1) Their comment was "Based on hearsay" and made no reference to the benchmarks game. 2) "one (biased) reference" is simply name calling. 3) What specifically are you saying is "biased" about these measurements? https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - deleted 3y ago

by nsm 3y ago

brabel 3y ago

> Based on hearsay, the JVM often competes in language performance closer to C++, and has probably the best garbage collectors in the world as well as the best developer and operational tooling. How much do other platform developers leave on the table by ignoring the JVM these days? I am mostly a Java developer, but have had the opportunity to play with Common Lisp and many other languages. While it's true the JVM is very performant, its performance actually comes at a cost: it has a JIT, Garbage Collector, a whole lot of machinery for Threads/VirtualThreads, JMX etc. all of which comes at a cost... thanks to multicore processors and lots and lots of RAM being available, this translates in really fast performance for Java applications... so that cost may be advantageous to you. Common Lisp applications are much lighter than Java applications from what I've actually measured given its simpler model... it basically compiles Lisp code to machine code directly and then runs that (Java runs bytecode, and then at runtime the JIT selects which code to optimise, which continues to happen for the lifetime of the application). I would bet money on any application written in Common Lisp being significantly lighter, and hence "greener", than the equivalent Java application, while still running at nearly the same speed, or even faster. For short running programs, Common Lisp is incredibly fast at starting up and getting stuff done - it competes with C and Rust in that regard, not with Java. > How much do other platform developers leave on the table by ignoring the JVM these days? Common Lisp tooling is integrated into the language itself. You can inspect the machine code it generates, ask it to instrument every function so you can profile, and so on without even needing any external tools - it's all built-in... but of course, using it from SLIME or SLY (in emacs) makes it a lot more pleasant. If you think Java tools are better, I believe you may not know Common Lisp very well.

andsoitis 3y ago
> While it's true the JVM is very performant, its performance actually comes at a cost: it has a JIT, Garbage Collector, a whole lot of machinery for Threads/VirtualThreads, JMX etc. all of which comes at a cost... thanks to multicore processors and lots and lots of RAM being available, this translates in really fast performance for Java applications... so that cost may be advantageous to you. Here you say “it comes at a cost” twice, but you don’t say what the cost is! Or am I missing something?
- brabel 3y ago
  The cost is on the things mentioned themselves: JIT is not free at all, it may take more CPU power than your actual application during some period! You can actually tell the JVM to not JIT... try that and see just how slow your code runs... it may give you an idea of how much it costs in terms of energy as well if you're able to measure that (I don't know how much that cost would look like, to be honest, I can only imagine it's a significant proportion of the total).
  - pjmlp 3y ago
    Or maybe AOT compile, there are two free beer options now, or make use of JIT caches, there are also a couple of implementationst that do it. That is the beauty of languages with multiple implementations.
pjmlp 3y ago
That "cost" ignores the ecosystem of Java implementations, including AOT ones, embedded deployments, and real time implementations. Also lets not forget the influence of Lisp/Scheme people like Guy Steele on how Java turned out. "We were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." Full Lisp would have been better, but apparently Lisps in desguise like Dylan and Julia, are the best mainstream is willing to take on.

tmtvl 3y ago

As someone who has done a bit of both Java and CL (and Perl, and C, and Free Pascal, and Guile Scheme, and Raku, and... oh my, where does the time go?) Java is entirely fine. A bit heavy on the ol' RAM, and if you really want to get it fast you need to know which knobs to push and which settings to turn various dials to, but it's fine. I haven't tried that new Graal VM thing, hearsay is that it makes Java run real good, but with plain old OpenJDK it's fine.

bsdpufferfish 3y ago

> the JVM often competes in language performance closer to C++ I don't think it's even close. Benchmark game is one (biased) reference. And it's even worse because optimized Java is not canonical Java. Canonical C++ is pretty fast.

lelanthran 3y ago
> I don't think it's even close. Benchmark game is one (biased) reference. I agree. 1. Benchmarks tend to do one thing, then repeat that one thing 25000 times. Non-server programs don't do that[1] so you don't get to amortise the time spent on JITting a code snippet across 25000 executions. 2. The runtime basically requires exclusive use of a core for short periods (GC, JIT). If you're running on a system that costs per core, you're using (worst case scenario) an extra core for each Java program. The benchmarks happily give multiple cores even to sequential (non-parallel) benchmarks. [1] Even many server programs don't do that.
- igouy 3y ago
  1. The benchmarks game doesn't "repeat that one thing 25000 times" as warmup and the benchmarks game measurements include 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/... 2. The benchmarks game happily gives multiple cores and shows that "cpu secs" measurement: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
igouy 3y ago
1) Their comment was "Based on hearsay" and made no reference to the benchmarks game. 2) "one (biased) reference" is simply name calling. 3) What specifically are you saying is "biased" about these measurements? https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- deleted 3y ago