6 ms·

Do you have appropriate benchmarks? I would appreciate seeing the comparison.

DannyB2 7y ago
Yes, benchmarks. But it's not just benchmarks. It's capabilities. He should please provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities.
- igouy 7y ago
  > provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities How many weeks work do you imagine that would be?
  - DannyB2 7y ago
    My point: if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well. While no language / platform / os / etc is perfect, JVM as a managed runtime platform is hard to beat. More than two decades of research in its JIT compilers, and multiple GC implementations with various knobs and dials for tuning and monitoring. Battle tested. Someone mentioned SBCL. While I am a fan of Common Lisp, and generally all Lisps, I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload -- and see how well it holds up. Just an example: You can Google for this, but in 2012 Twitter switched from Ruby on Rails to Java. They have YouTube videos explaining their change over. Basic reasons: performance and scalability. They have to handle BILLIONS of tweets per day and route each one to multiple places with notifications in near real time.
    - lispm 7y ago
      > I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload That's nothing SBCL can do, but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. Generally there is a lot of stuff in the JVM which makes it less attractive as runtime for Lisp: more complex code loading via 'class loaders', lack of support for memory representation of Lisp's data types (like CLOS objects, which are more dynamic than Java classes), lack of TCO, lack of easy AOT compilation, lack of easy image dumps, lack of resumeable exceptions, ... And in 2019 something like Eclipse still is a bit clunky to run on my 8 core Xeon - part of the reason could be a less than great GUI implementation. In IntelliJ I need to restart my IDE for every simple plugin... probably features like live-updating haven't made it yet into popular apps.
      - pron 7y ago
        > but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. A few tens of magabytes maybe and the JVM runs a complete Hello World in about 60ms, but yeah, Clojure does a lot of work on startup. It's more of a Clojure issue than a JVM issue, though. It's true that HotSpot is mostly designed for long-running applications. Other JVMs -- like Substrate VM (AKA Graal native image, which isn't quite a JVM yet) and Excelsior JET give you AOT compilation (no warmup). > makes it less attractive as runtime for Lisp I think Clojurists (which probably outnumber all other professional Lispers combined several times over) would disagree. I'm sure there are use cases where you'd like to use Lisp and HotSpot is not the right choice, but it seems like those cases are vastly outnumbered by the cases where it is. Domains where HotSpot is certainly not the right choice are usually either client-side web or domains where C/C++ dominate. > lack of TCO, lack of resumeable exceptions Delimited continuations and eventually tail calls are coming as part of Project Loom (https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/). > lack of easy image dumps HotSpot's monitoring, management and observability are almost unmatched (maybe Smalltalk is somewhat better in some regards, and BEAM in some others). Whatever you may be lacking on that front is probably offset by something probably even more valuable (these capabilities have been designed over the past decades to suit the needs of millions of developers running huge backbones). I'm not saying that HotSpot is always the best tool for the job, but it's the best tool for the job for a huge portion of the software industry. > And in 2019 something like Eclipse still is a bit clunky to run on my 8 core Xeon - part of the reason could be a less than great GUI implementation. In IntelliJ I need to restart my IDE for every simple plugin... probably features like live-updating haven't made it yet into popular apps. You don't need to use a Java IDE if you want to write Clojure, although the Java IDEs are also pretty unmatched -- a matter of getting used to.
        lispm 7y ago
        > Other JVMs So I need to switch to exotic JVMs to get better performance? > I think Clojurists (which probably outnumber all other professional Lispers combined several times over) would disagree Does the number matter, since most of them have a) never used Lisp nor b) do they know anything about Lisp implementation? Things like 'no TCO' in the JVM are no question of the number of people using it, it's simply a fact. If the JVM would be a better match, then Lisp implementations on it would have a better start-up time - like most Lisp runtimes have. There are many reasons to use the JVM, but good support in the JVM for Lisp implementations is not one of the strong points. > Delimited continuations and eventually tail calls are coming as part of Project Loom Which means, after reading the linked doc, that neither resumeable exceptions nor TCO are in JVM, neither currently nor in the near future. Now the usual arguments about TCO are: a) one does not need TCO b) it makes tracing difficult c) it's a security problem d) we can do recursive self-calls e) a future version of the JVM will provide annotatations for tail calls f) using TCO would provide interop problems with JVM code... etc etc. The fact remains: TCO is not supported by the JVM, while this capability is a part of many other runtimes. > probably even more valuable (these capabilities have been designed over the past decades to suit the needs of millions of developers running huge backbones). That's all great, but I don't develop huge backbones all the time. > I'm not saying that HotSpot is always the best tool for the job Your original claim was this: 'if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well.' We are now talking about capabilities like full TCO and the JVM simply does not provide it. It currently provides no TCO at all. > You don't need to use a Java IDE It's not about what I need, it's that capabilities like extending the IDE on the fly are still not available in an IDE like IntelliJ - why? After downloading a plugin, it wants to restart the IDE. Something which a typical Lisp system on a Lisp runtime brings for free, because of its capabilities.
pron 7y ago
FWIW, there's the language shootout game (which is downright awful, but maybe better than nothing, especially if we just want a ballpark): https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/lisp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Java outperforms SBCL by a very wide margin -- 1.25-4x faster -- except in the short-running benchmarks (and except the spectral-norm test, where SBCL is 5% faster), as the game does not perform warmup, and includes Java's compilation time (you can see that no Java result is under 2 seconds).
- igouy 7y ago
  "which is downright awful" just because you say so, and yet apparently better than anything else you know-of. > you can see that no Java result is under 2 seconds That's because the workloads were chosen to push Java results above a couple of seconds. > as the game does not perform warmup, and includes Java's compilation time How many 1/10ths of a second do you imagine that takes? https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - deleted 7y ago
    [deleted]
  - pron 7y ago
    I don't know of any other SBCL benchmarks, so, as I said, it's probably better than nothing. I have looked at some example programs in the shootout game where different implementations use completely different low-level algorithms, including code that's very unidiomatic, so those benchmarks are of low quality. And yes, Java does have a disadvantage here (I work on OpenJDK, BTW, so I don't need to imagine). Anyway, I’m not sure which side you’re arguing, because the benchmark game did show a rather drastic win to Java (TBH, I would have been surprised if that were not the case). I simply qualified that win because the shootout game is not a high quality benchmark.
    - igouy 7y ago

Yes, benchmarks. But it's not just benchmarks. It's capabilities. He should please provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities.

igouy 7y ago
> provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities How many weeks work do you imagine that would be?
- DannyB2 7y ago
  My point: if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well. While no language / platform / os / etc is perfect, JVM as a managed runtime platform is hard to beat. More than two decades of research in its JIT compilers, and multiple GC implementations with various knobs and dials for tuning and monitoring. Battle tested. Someone mentioned SBCL. While I am a fan of Common Lisp, and generally all Lisps, I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload -- and see how well it holds up. Just an example: You can Google for this, but in 2012 Twitter switched from Ruby on Rails to Java. They have YouTube videos explaining their change over. Basic reasons: performance and scalability. They have to handle BILLIONS of tweets per day and route each one to multiple places with notifications in near real time.
  - lispm 7y ago
    > I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload That's nothing SBCL can do, but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. Generally there is a lot of stuff in the JVM which makes it less attractive as runtime for Lisp: more complex code loading via 'class loaders', lack of support for memory representation of Lisp's data types (like CLOS objects, which are more dynamic than Java classes), lack of TCO, lack of easy AOT compilation, lack of easy image dumps, lack of resumeable exceptions, ... And in 2019 something like Eclipse still is a bit clunky to run on my 8 core Xeon - part of the reason could be a less than great GUI implementation. In IntelliJ I need to restart my IDE for every simple plugin... probably features like live-updating haven't made it yet into popular apps.
    - pron 7y ago
      > but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. A few tens of magabytes maybe and the JVM runs a complete Hello World in about 60ms, but yeah, Clojure does a lot of work on startup. It's more of a Clojure issue than a JVM issue, though. It's true that HotSpot is mostly designed for long-running applications. Other JVMs -- like Substrate VM (AKA Graal native image, which isn't quite a JVM yet) and Excelsior JET give you AOT compilation (no warmup). > makes it less attractive as runtime for Lisp I think Clojurists (which probably outnumber all other professional Lispers combined several times over) would disagree. I'm sure there are use cases where you'd like to use Lisp and HotSpot is not the right choice, but it seems like those cases are vastly outnumbered by the cases where it is. Domains where HotSpot is certainly not the right choice are usually either client-side web or domains where C/C++ dominate. > lack of TCO, lack of resumeable exceptions Delimited continuations and eventually tail calls are coming as part of Project Loom (https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/). > lack of easy image dumps HotSpot's monitoring, management and observability are almost unmatched (maybe Smalltalk is somewhat better in some regards, and BEAM in some others). Whatever you may be lacking on that front is probably offset by something probably even more valuable (these capabilities have been designed over the past decades to suit the needs of millions of developers running huge backbones). I'm not saying that HotSpot is always the best tool for the job, but it's the best tool for the job for a huge portion of the software industry. > And in 2019 something like Eclipse still is a bit clunky to run on my 8 core Xeon - part of the reason could be a less than great GUI implementation. In IntelliJ I need to restart my IDE for every simple plugin... probably features like live-updating haven't made it yet into popular apps. You don't need to use a Java IDE if you want to write Clojure, although the Java IDEs are also pretty unmatched -- a matter of getting used to.
      - lispm 7y ago
        > Other JVMs So I need to switch to exotic JVMs to get better performance? > I think Clojurists (which probably outnumber all other professional Lispers combined several times over) would disagree Does the number matter, since most of them have a) never used Lisp nor b) do they know anything about Lisp implementation? Things like 'no TCO' in the JVM are no question of the number of people using it, it's simply a fact. If the JVM would be a better match, then Lisp implementations on it would have a better start-up time - like most Lisp runtimes have. There are many reasons to use the JVM, but good support in the JVM for Lisp implementations is not one of the strong points. > Delimited continuations and eventually tail calls are coming as part of Project Loom Which means, after reading the linked doc, that neither resumeable exceptions nor TCO are in JVM, neither currently nor in the near future. Now the usual arguments about TCO are: a) one does not need TCO b) it makes tracing difficult c) it's a security problem d) we can do recursive self-calls e) a future version of the JVM will provide annotatations for tail calls f) using TCO would provide interop problems with JVM code... etc etc. The fact remains: TCO is not supported by the JVM, while this capability is a part of many other runtimes. > probably even more valuable (these capabilities have been designed over the past decades to suit the needs of millions of developers running huge backbones). That's all great, but I don't develop huge backbones all the time. > I'm not saying that HotSpot is always the best tool for the job Your original claim was this: 'if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well.' We are now talking about capabilities like full TCO and the JVM simply does not provide it. It currently provides no TCO at all. > You don't need to use a Java IDE It's not about what I need, it's that capabilities like extending the IDE on the fly are still not available in an IDE like IntelliJ - why? After downloading a plugin, it wants to restart the IDE. Something which a typical Lisp system on a Lisp runtime brings for free, because of its capabilities.

pron 7y ago

FWIW, there's the language shootout game (which is downright awful, but maybe better than nothing, especially if we just want a ballpark): https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/lisp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Java outperforms SBCL by a very wide margin -- 1.25-4x faster -- except in the short-running benchmarks (and except the spectral-norm test, where SBCL is 5% faster), as the game does not perform warmup, and includes Java's compilation time (you can see that no Java result is under 2 seconds).

igouy 7y ago
"which is downright awful" just because you say so, and yet apparently better than anything else you know-of. > you can see that no Java result is under 2 seconds That's because the workloads were chosen to push Java results above a couple of seconds. > as the game does not perform warmup, and includes Java's compilation time How many 1/10ths of a second do you imagine that takes? https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- deleted 7y ago
  [deleted]
- pron 7y ago
  I don't know of any other SBCL benchmarks, so, as I said, it's probably better than nothing. I have looked at some example programs in the shootout game where different implementations use completely different low-level algorithms, including code that's very unidiomatic, so those benchmarks are of low quality. And yes, Java does have a disadvantage here (I work on OpenJDK, BTW, so I don't need to imagine). Anyway, I’m not sure which side you’re arguing, because the benchmark game did show a rather drastic win to Java (TBH, I would have been surprised if that were not the case). I simply qualified that win because the shootout game is not a high quality benchmark.
  - igouy 7y ago