4 ms·

In the end it seems like CLR is superior to the JVM based on these assertions.

by ryanlm 10y ago

Mikeb85 10y ago
Except for the fact the JVM has far superior performance...
- sremani 10y ago
  I understand JVM is battle tested on Linux, *BSD, where CLR would have to catch up, but are there any technical reasons say JVM perfs better than CLR on windows.
  - richard_todd 10y ago
    JVM optimizes and reoptimizes as your code runs, so that "hot spots" run very quickly. Last I heard, CLR still doesn't do this... it JITs once only.
    - MikeHolman 10y ago
      This multitiered approach does not necessarily make the end result faster. It is in vogue to do this, and for startup performance having a baseline JIT can be beneficial, but for workload throughput adding another tier isn't going to do much unless you have some concrete optimizations you are going to run that you decided against due to cost of compile time.
      - jdmichal 10y ago
        > ... for workload throughput adding another tier isn't going to do much unless you have some concrete optimizations you are going to run that you decided against due to cost of compile time. Isn't this statement pretty much the entirety of the reason to implement multi-tiered JITs? Do a fast JIT with few optimizations to get out of interpreted mode. Then do a slow JIT after you've collected enough statistics to make good optimization decisions.
      - richard_todd 10y ago
        To me that's like saying compression algorithms don't necessarily make data smaller. It's true enough, but you can still make general comparisons between approaches. If your work has an "inner-loop" situation, then the JVM can optimize the heck out of it using statistics specific to this particular execution. That's huge.. it opens up all kinds of concrete optimizations that aren't possible with static analysis alone (precomputing call targets, knowing what to inline, etc.). I'd wager this is a major factor in cases when the JVM occasionally outperforms C. But no, it doesn't necessarily help.
      - sievebrain 10y ago
        Actual gathered statistics say you're wrong. Profile guided optimisations can easily add 20% performance or more. And for that to work, the easiest path for the developer is a tiered JIT. More concretely, you can disable the tiered JIT on the JVM and find out what it buys you (and there are people who have done this).
        iconhacker 10y ago
        The fact is that before the JVM has a chance to optimize the code, the app already restarted by the user unless it is some long running server process. On the server side, JVM is so heavy, normally there is only 1-2 heavy JVM running for web server and database driver on the entire machine. On the client side, Java is a joke. Though users now have more choices: Swing, AWT, JavaFx. Every one of these is hard to use comparing with C# or Qt. Most native platform developers hate Java, including OSX developers.
  - Mikeb85 10y ago
    > but are there any technical reasons say JVM perfs better than CLR on windows Considering the amount of man-hours that have gone into both, the exact reasons are probably hidden under a whole bunch of implementation details. That being said, I've run benchmarks where the JVM (version 1.8) outperforms C++ and Fortran... The JVM seemingly optimizes everything, and the amount of fine tuning you can do is amazing. I've never heard of the CLR coming close to Java performance on large-ish apps or tasks, all else being equal.
    - iconhacker 10y ago
      Why every Java app is so slow and memory hungry?!!
      - Mikeb85 10y ago
        There's plenty of slow, memory hungry C++ apps too. Just enterprise software things...
        iconhacker 10y ago
        Plenty != every. And comparing IntelliJ and Visual studio 201*, there is no chance Java is winning.
        sievebrain 10y ago
        There are fast, optimised Java apps as well. IntelliJ is actually a good example - on my laptop it starts in a few seconds, the UI is snappy and responsive, it looks native. Back when I used Eclipse I thought the same as you; Java apps must just inherently suck. The difference in performance between IntelliJ and Eclipse put that idea to bed for good. The real reason Java apps are often associated with being big and heavy is less to do with the technology and more to do with the fact that it's so often used for bespoke enterprise apps where there's no competition and so little incentive to optimise (vs add new features).
        10y ago

In the end it seems like CLR is superior to the JVM based on these assertions.

by ryanlm 10y ago

In the end it seems like CLR is superior to the JVM based on these assertions.

Mikeb85 10y ago

Except for the fact the JVM has far superior performance...

sremani 10y ago
I understand JVM is battle tested on Linux, *BSD, where CLR would have to catch up, but are there any technical reasons say JVM perfs better than CLR on windows.
- richard_todd 10y ago
  JVM optimizes and reoptimizes as your code runs, so that "hot spots" run very quickly. Last I heard, CLR still doesn't do this... it JITs once only.
  - MikeHolman 10y ago
    This multitiered approach does not necessarily make the end result faster. It is in vogue to do this, and for startup performance having a baseline JIT can be beneficial, but for workload throughput adding another tier isn't going to do much unless you have some concrete optimizations you are going to run that you decided against due to cost of compile time.
    - jdmichal 10y ago
      > ... for workload throughput adding another tier isn't going to do much unless you have some concrete optimizations you are going to run that you decided against due to cost of compile time. Isn't this statement pretty much the entirety of the reason to implement multi-tiered JITs? Do a fast JIT with few optimizations to get out of interpreted mode. Then do a slow JIT after you've collected enough statistics to make good optimization decisions.
    - richard_todd 10y ago
      To me that's like saying compression algorithms don't necessarily make data smaller. It's true enough, but you can still make general comparisons between approaches. If your work has an "inner-loop" situation, then the JVM can optimize the heck out of it using statistics specific to this particular execution. That's huge.. it opens up all kinds of concrete optimizations that aren't possible with static analysis alone (precomputing call targets, knowing what to inline, etc.). I'd wager this is a major factor in cases when the JVM occasionally outperforms C. But no, it doesn't necessarily help.
    - sievebrain 10y ago
      Actual gathered statistics say you're wrong. Profile guided optimisations can easily add 20% performance or more. And for that to work, the easiest path for the developer is a tiered JIT. More concretely, you can disable the tiered JIT on the JVM and find out what it buys you (and there are people who have done this).
      - iconhacker 10y ago
        The fact is that before the JVM has a chance to optimize the code, the app already restarted by the user unless it is some long running server process. On the server side, JVM is so heavy, normally there is only 1-2 heavy JVM running for web server and database driver on the entire machine. On the client side, Java is a joke. Though users now have more choices: Swing, AWT, JavaFx. Every one of these is hard to use comparing with C# or Qt. Most native platform developers hate Java, including OSX developers.
- Mikeb85 10y ago
  > but are there any technical reasons say JVM perfs better than CLR on windows Considering the amount of man-hours that have gone into both, the exact reasons are probably hidden under a whole bunch of implementation details. That being said, I've run benchmarks where the JVM (version 1.8) outperforms C++ and Fortran... The JVM seemingly optimizes everything, and the amount of fine tuning you can do is amazing. I've never heard of the CLR coming close to Java performance on large-ish apps or tasks, all else being equal.
  - iconhacker 10y ago
    Why every Java app is so slow and memory hungry?!!
    - Mikeb85 10y ago
      There's plenty of slow, memory hungry C++ apps too. Just enterprise software things...
      - iconhacker 10y ago
        Plenty != every. And comparing IntelliJ and Visual studio 201*, there is no chance Java is winning.
        sievebrain 10y ago
        There are fast, optimised Java apps as well. IntelliJ is actually a good example - on my laptop it starts in a few seconds, the UI is snappy and responsive, it looks native. Back when I used Eclipse I thought the same as you; Java apps must just inherently suck. The difference in performance between IntelliJ and Eclipse put that idea to bed for good. The real reason Java apps are often associated with being big and heavy is less to do with the technology and more to do with the fact that it's so often used for bespoke enterprise apps where there's no competition and so little incentive to optimise (vs add new features).
        10y ago