7 ms·

The JVM has had billions of dollars of engineering effort poured into it. At the same time, it is still out-performed by low-budget small-team efforts (e.g. Lua

by twp 11y ago

The JVM has had billions of dollars of engineering effort poured into it. At the same time, it is still out-performed by low-budget small-team efforts (e.g. LuaJIT, Inferno). The article disassociates itself from Java the language. Java was a better C++ in 1994. It has long since been eclipsed by both improved old languages that have evolved (e.g. C++11/C++14) and new languages (e.g. Go and Rust) that are unencumbered by the JVM. This is despite recent incremental efforts to renew Java the language. Instead, the article tries to claim some success for Java by switching focus to the JVM. The JVM is still slow and - by its design (a clunky stack-based architecture) - simple to implement but very hard to run fast. Java will still be around for a long time to come. It's the COBOL of our generation: it's better than what it replaced, but far away from what we are capable of.

coldtea 11y ago
>The JVM is still slow What are you talking about? It's the fastest widely deployed VM out there...
- twp 11y ago
  If you want to talk about "widely deployed VMs" then Dalvik is faster. If you want to talk about VMs in general then there are many that are faster, e.g. LuaJIT.
  - coldtea 11y ago
    Actually no, Dalvik is slower than the JVM and with worse GC. And LuaJIT faster than the JVM? Where you got that? You wont fine many benchmarks or people agreeing with you. LuaJIT is faster (much) than most scripting languages, but not faster than Java. Are you comparing startup time?
  - danieldk 11y ago
    Dalvik is ~3x slower than JVM for compiled (JITed) code (on an ARM Cortex A8): https://dl.acm.org/citation.cfm?id=2388956 https://dl.acm.org/citation.cfm?id=2388956
- sanderjd 11y ago
  It's always fun to see how different people throw around the seemingly-absolute terms "slow" and "fast" when there is always some other platform they're implicitly comparing to. I had a chuckle about this the other day as I was evaluating BEAM for potentially running a re-write of a Rails app; I was thinking how pleasant it was to use a platform so fast when I came across people ridiculing how slow Erlang is (presumably relative to C++ or even the JVM).
  - tormeh 11y ago
    Those people don't get the point of Erlang. You'd have to be completely oblivious to complain about performance on the Erlang VM. The Erlang developers will always sacrifice performance and everything else in favor of reliability and response time. Consider that every actor has its own heap and GC. That's slightly absurd, honestly, but it makes sense when you think about Erlang's goals. I just get so frustrated when people say things like that.
    - codesushi42 11y ago
      Indeed, these claims always lack context of what is being attempted. If you are using Erlang to perform matrix multiplications on large datasets or some kind of CPU intensive work, you're probably barking up the wrong tree. But if you want to parallelize and distribute less CPU intensive tasks and have fault tolerance, then it's a good choice.
- fleitz 11y ago
  Being the fastest VM doesn't make a VM fast. It's just faster than other slow things.
  - tormeh 11y ago
    True, but thankfully the JVM is faster than most compiled languages as well.
    - fleitz 11y ago
      Yes, that's why modern triple A titles are written on the JVM. The JVM can generate faster numeric code than C++ in limited instances and when writing in C/C++ style. And then when you want to be faster than java you drop down to ASM and use a few SIMD instructions. In the general case when you write real applications it's much slower. Not to mention that no one wants to drop 12 frames waiting for GC.
      - danieldk 11y ago
        Why does someone bring up game performance when the discussion is about JVM versus native code? Languages with a GC compiled to native code have the same problems, even C/ASM calls can be relatively expensive in languages compiled to native code (e.g. see Go). There are many other classes of applications outside games where a few milliseconds of garbage collection are acceptable. It is no surprise that many server applications are written in JVM languages - the 2x C/C++ performance is acceptable when people get a lot of instrumentation, more safety, etc.
        fleitz 11y ago
        Java is rarely 2x faster than C/C++. I would say the primary reasons server apps are written in Java is the enterprise support and giant ecosystem as well as number of developers who can write java. The performance on the server is decent, and great compared to ruby/python. People bring up video games because they are the most demanding apps most people run. Similarly you'll see apps like Photoshop, Office, etc written in C++. Languages with a GC blah blah blah don't matter because no one writing C++ for performance uses a GC with it. I'm comparing C++ to Java for real world apps not language benchmarks, etc. C++ would not be my first choice for a web app because the task is trivially parallelizable and you get little improvement in string copying between C++ / Java / etc which is the primary thing web apps do, copy strings.
chrisseaton 11y ago
You say the JVM is hard to run fast because it has a stack-based architecture. That argument doesn't make any sense to me - by the time you are in your dynamic compiler, and you have an IR in something like sea of nodes, what difference does it make in what format the program was represented on disk? The stack part of it has long gone by then.
- mkramlich 11y ago
  wait til they hear that Linux has a stack-based architecture. that all C-based software has a stack based architecture. threads with stacks everywhere: surprisingly fast. it's usually things like higher-level architectural patterns and algorithm choices which make a MUCH bigger impact on latency and throughput, than whether you have stacks or not.
  - pcwalton 11y ago
    The thread is talking more about stack versus register-based VMs than call stacks. The great stack vs. register-based debate is, in my mind, somewhat like the CISC vs. RISC debate—a fun water cooler conversation, but not too relevant in practice. All performance-focused language VMs lower into a (usually SSA-based) IR soon anyway, so the difference only ends up mattering for VMs that are deliberately kept simple for code size, simplicity, or legacy reasons (like Lua, or CPython).
    - mkramlich 11y ago
      fair points
  - mikeash 11y ago
    That's not what that means. In the context of bytecode, a stack-based architecture is one where instructions directly manipulate stack entries. For example, the Java bytecode instruction iadd takes the top two entries from the stack, adds them together, and pushes the result onto the stack. This is in contrast to a register architecture, where you might have an instruction of the form `add x, y, z`, which takes the values in two registers, adds them, and stores the result in another register. To say that Linux or C is stack-based is nonsensical, as it applies to an instruction set architecture. Virtually all hardware ISAs you're likely to encounter are register-based these days.
ised 11y ago
"The JVM has billions of dollars of engineering effort poured into it. At the same time, it is stil out-performed by low-budget small-team efforts (e.g., LuaJIT, Inferno)." This seems a truism with respect to many "high value" software products/projects across the computing world. The ones that attract large investment. The only time I ever use Java is when I use something made by someone else who uses Java. And when their software slows to a crawl or crashes, what can I do? It was not my decision to use Java. It is so pervasive, there's Java on a SIM card, what can a user do? Impossible to avoid. But as for computers where I can open them up and install my choice of kernel and utilities, I have no need for Java. There is not a single file of Java anywhere in my source tree. I can find code written in terse languages that does everything I need to do with the computer. Code that out-performs Java, easily. Maybe something written by a small team or even one person. :) I think that is what makes the ITC field so entertaining. No matter how much cash and how many engineers a company can accumulate, a small team of dedicated people with little to no money, sometimes just one incredible mind sitting at a keyboard, can still create something that wins on performance. Is that not "success" of some sort? As for Java, I guess it depends on how one defines success. I like brevity, conciseness, performance and reliablity. Not sure I would label Java as a success under those criteria, but that is just my personal opinion as a user. In terms of mindshare, Java is a tremendous success. You mentioned Go. Rob Pikes' OSCON 2010 talk introducing Go had some criticisms of Java with examples. I think he said Java was a symbol of bureaucracy or something to that effect. Let us celebrate the success of bureaucracy. Congratulations Java.
cp9 11y ago
What year is it where you are? Java is no longer slow. JVM languages in general are very, very fast. HotSpot is, frankly, incredible. There are legitimate gripes to be had about Java as a language, but Java as an ecosystem and a runtime are incredible.
- tapirl 11y ago
  All java software installed on my computer are still slow as shitting. All my java projects need minutes to compile fully and to startup. All my java programs uses hundreds Mb memory. On the contrary, Golang programs run much faster, compile much faster, use much less memory.
  - jacquesm 11y ago
    Apples, Oranges. The Golang compiler is made for a language designed for speed of compilation. If you'd write a golang compiler in java (why you'd ever do that is not a relevant question here) then it would most likely be quite fast too. If you're complaining about java programs that are slow or memory hogs you can only compare languages when you build the exact same application using different languages.
    - tapirl 11y ago
      Yes, for the exact same application using golang and java, golang one startups faster, much faster, and uses less memory, much less.

by twp 11y ago

coldtea 11y ago

>The JVM is still slow What are you talking about? It's the fastest widely deployed VM out there...

twp 11y ago
If you want to talk about "widely deployed VMs" then Dalvik is faster. If you want to talk about VMs in general then there are many that are faster, e.g. LuaJIT.
- coldtea 11y ago
  Actually no, Dalvik is slower than the JVM and with worse GC. And LuaJIT faster than the JVM? Where you got that? You wont fine many benchmarks or people agreeing with you. LuaJIT is faster (much) than most scripting languages, but not faster than Java. Are you comparing startup time?
- danieldk 11y ago
  Dalvik is ~3x slower than JVM for compiled (JITed) code (on an ARM Cortex A8): https://dl.acm.org/citation.cfm?id=2388956 https://dl.acm.org/citation.cfm?id=2388956
sanderjd 11y ago
It's always fun to see how different people throw around the seemingly-absolute terms "slow" and "fast" when there is always some other platform they're implicitly comparing to. I had a chuckle about this the other day as I was evaluating BEAM for potentially running a re-write of a Rails app; I was thinking how pleasant it was to use a platform so fast when I came across people ridiculing how slow Erlang is (presumably relative to C++ or even the JVM).
- tormeh 11y ago
  Those people don't get the point of Erlang. You'd have to be completely oblivious to complain about performance on the Erlang VM. The Erlang developers will always sacrifice performance and everything else in favor of reliability and response time. Consider that every actor has its own heap and GC. That's slightly absurd, honestly, but it makes sense when you think about Erlang's goals. I just get so frustrated when people say things like that.
  - codesushi42 11y ago
    Indeed, these claims always lack context of what is being attempted. If you are using Erlang to perform matrix multiplications on large datasets or some kind of CPU intensive work, you're probably barking up the wrong tree. But if you want to parallelize and distribute less CPU intensive tasks and have fault tolerance, then it's a good choice.
fleitz 11y ago
Being the fastest VM doesn't make a VM fast. It's just faster than other slow things.
- tormeh 11y ago
  True, but thankfully the JVM is faster than most compiled languages as well.
  - fleitz 11y ago
    Yes, that's why modern triple A titles are written on the JVM. The JVM can generate faster numeric code than C++ in limited instances and when writing in C/C++ style. And then when you want to be faster than java you drop down to ASM and use a few SIMD instructions. In the general case when you write real applications it's much slower. Not to mention that no one wants to drop 12 frames waiting for GC.
    - danieldk 11y ago
      Why does someone bring up game performance when the discussion is about JVM versus native code? Languages with a GC compiled to native code have the same problems, even C/ASM calls can be relatively expensive in languages compiled to native code (e.g. see Go). There are many other classes of applications outside games where a few milliseconds of garbage collection are acceptable. It is no surprise that many server applications are written in JVM languages - the 2x C/C++ performance is acceptable when people get a lot of instrumentation, more safety, etc.
      - fleitz 11y ago
        Java is rarely 2x faster than C/C++. I would say the primary reasons server apps are written in Java is the enterprise support and giant ecosystem as well as number of developers who can write java. The performance on the server is decent, and great compared to ruby/python. People bring up video games because they are the most demanding apps most people run. Similarly you'll see apps like Photoshop, Office, etc written in C++. Languages with a GC blah blah blah don't matter because no one writing C++ for performance uses a GC with it. I'm comparing C++ to Java for real world apps not language benchmarks, etc. C++ would not be my first choice for a web app because the task is trivially parallelizable and you get little improvement in string copying between C++ / Java / etc which is the primary thing web apps do, copy strings.

chrisseaton 11y ago

You say the JVM is hard to run fast because it has a stack-based architecture. That argument doesn't make any sense to me - by the time you are in your dynamic compiler, and you have an IR in something like sea of nodes, what difference does it make in what format the program was represented on disk? The stack part of it has long gone by then.

mkramlich 11y ago
wait til they hear that Linux has a stack-based architecture. that all C-based software has a stack based architecture. threads with stacks everywhere: surprisingly fast. it's usually things like higher-level architectural patterns and algorithm choices which make a MUCH bigger impact on latency and throughput, than whether you have stacks or not.
- pcwalton 11y ago
  The thread is talking more about stack versus register-based VMs than call stacks. The great stack vs. register-based debate is, in my mind, somewhat like the CISC vs. RISC debate—a fun water cooler conversation, but not too relevant in practice. All performance-focused language VMs lower into a (usually SSA-based) IR soon anyway, so the difference only ends up mattering for VMs that are deliberately kept simple for code size, simplicity, or legacy reasons (like Lua, or CPython).
  - mkramlich 11y ago
    fair points
- mikeash 11y ago
  That's not what that means. In the context of bytecode, a stack-based architecture is one where instructions directly manipulate stack entries. For example, the Java bytecode instruction iadd takes the top two entries from the stack, adds them together, and pushes the result onto the stack. This is in contrast to a register architecture, where you might have an instruction of the form `add x, y, z`, which takes the values in two registers, adds them, and stores the result in another register. To say that Linux or C is stack-based is nonsensical, as it applies to an instruction set architecture. Virtually all hardware ISAs you're likely to encounter are register-based these days.

ised 11y ago

"The JVM has billions of dollars of engineering effort poured into it. At the same time, it is stil out-performed by low-budget small-team efforts (e.g., LuaJIT, Inferno)." This seems a truism with respect to many "high value" software products/projects across the computing world. The ones that attract large investment. The only time I ever use Java is when I use something made by someone else who uses Java. And when their software slows to a crawl or crashes, what can I do? It was not my decision to use Java. It is so pervasive, there's Java on a SIM card, what can a user do? Impossible to avoid. But as for computers where I can open them up and install my choice of kernel and utilities, I have no need for Java. There is not a single file of Java anywhere in my source tree. I can find code written in terse languages that does everything I need to do with the computer. Code that out-performs Java, easily. Maybe something written by a small team or even one person. :) I think that is what makes the ITC field so entertaining. No matter how much cash and how many engineers a company can accumulate, a small team of dedicated people with little to no money, sometimes just one incredible mind sitting at a keyboard, can still create something that wins on performance. Is that not "success" of some sort? As for Java, I guess it depends on how one defines success. I like brevity, conciseness, performance and reliablity. Not sure I would label Java as a success under those criteria, but that is just my personal opinion as a user. In terms of mindshare, Java is a tremendous success. You mentioned Go. Rob Pikes' OSCON 2010 talk introducing Go had some criticisms of Java with examples. I think he said Java was a symbol of bureaucracy or something to that effect. Let us celebrate the success of bureaucracy. Congratulations Java.

cp9 11y ago

What year is it where you are? Java is no longer slow. JVM languages in general are very, very fast. HotSpot is, frankly, incredible. There are legitimate gripes to be had about Java as a language, but Java as an ecosystem and a runtime are incredible.

tapirl 11y ago
All java software installed on my computer are still slow as shitting. All my java projects need minutes to compile fully and to startup. All my java programs uses hundreds Mb memory. On the contrary, Golang programs run much faster, compile much faster, use much less memory.
- jacquesm 11y ago
  Apples, Oranges. The Golang compiler is made for a language designed for speed of compilation. If you'd write a golang compiler in java (why you'd ever do that is not a relevant question here) then it would most likely be quite fast too. If you're complaining about java programs that are slow or memory hogs you can only compare languages when you build the exact same application using different languages.
  - tapirl 11y ago
    Yes, for the exact same application using golang and java, golang one startups faster, much faster, and uses less memory, much less.