6 ms·

Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years. As for applications that are huge, memory h

Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years. As for applications that are huge, memory hogs, complex and non elegant, well, congratulations you just described the majority of enterprise applications.

NotRustAgain 10y ago
https://benchmarksgame.alioth.debian.org/u64q/java.html https://benchmarksgame.alioth.debian.org/u64q/java.html Consistently twice as slow, with memory usage between 2 and 400(!) times larger. Java is slow and bloated compared to native. Your next argument will be something about how micro-benchmarks don't reflect reality for larger programs...
- bitmapbrother 10y ago
  Ah, synthetic benchmarks. Are you really sure they're consistently twice as slow? Your link shows otherwise. mandelbrot 17% slower fannkuch-redux 34% slower fasta 38% slower fasta-redux 39% slower pidigits 44% slower So much for predicting my next argument.
  - CherryPickMuch 10y ago
    How come you left out these ones? spectral-norm 115% slower reverse-compliment 121% slower n-body 136% slower regex-dna 235% slower k-nucleotide 253% slower Cherry picking your data shows you're either dishonest or really lost in your denial.
    - bitmapbrother 10y ago
      Perhaps you should read his reply more carefully next time. He said the benchmarks were "consistently 2x" as slow. He was wrong and the rest of the synthetic benchmarks you posted just corroborated my point. As for being dishonest, well, you're commenting from a newly minted temp account so it would seem you didn't have the courage/backbone to use your real one.
- userbinator 10y ago
  It's interesting that the "gz" column, which reflects the amount of source code required, shows a very slight trend towards C being smaller, although there are big exceptions like regex-dna and reverse-complement. I'm not seeing the 400x more memory - there is a 40x though. But if you add up the columns for the programs that have both C and Java versions, you get this rough summary... secs KB gz Java 76.33 2004048 12775 C gcc 37.32 793652 11651 ...that Java is on average half as fast as C and uses 2.5x more memory, while requiring slightly more source code.
  - pvg 10y ago
    "half as fast as C and 2.5x the memory on average" is a stupendously good result for any managed runtime. Most don't get anywhere near it while providing more than acceptable performance in practice.
    - MrBuddyCasino 10y ago
      Yes, and 2.5x is something that can be dealt with by deploying beefier hardware. The productivity gain is what makes that tradeoff a no-brainer.
  - igouy 10y ago
    >> more memory http://programmers.stackexchange.com/a/189552/4334 http://programmers.stackexchange.com/a/189552/4334
- pron 10y ago
  > Java is slow and bloated compared to native. What do you mean by "native"? C/C++? Yes, given enough effort you can write C code that outperforms Java code, sometimes handily, especially in single threaded or low-contention cases. Yet we did write applications in C/C++ before we switched to Java, we had excellent reasons to make the switch, and there have been precious few companies making the switch back. That shows you that the microbenchmarks don't tell the whole story. Right now, the JVM's biggest performance issue is the lack of value types. Once they arrive -- and work is well underway -- beating Java would be harder and harder, especially given new compilers like Graal. But in any event, I just don't see large developers switch back to C++ (or Rust) en masse. Memory usage is hardly an issue, as RAM is very cheap and underutilized in server environments anyway. Spending effort to conserve RAM just doesn't make any sense, unless you're targeting RAM constrained environments.
  - geodel 10y ago
    I feel with companies moving to cloud environment defending Java memory bloat will be harder and harder. Java's limited value types may be out by 2020-21 or so and it will be many more years libraries ecosystem start utilizing it. So we are still at least 10 years away from some form of Java value type available for general users.
    - pron 10y ago
      1. Memory "bloat" is always a better use of resources than increased development time, regardless of how you have to pay for it. 2. How are Java's value types limited? 3. I find your calculation extremely pessimistic. Lambda expression are widespread a couple of years after their release, and I see no reason why value types will be different. I think that 5 years are a better estimate for wide use of value types.
      - geodel 10y ago
        Here is what I read from JEP 169 > Except for pointer equality checks, forbidden operations will throw some sort of exception. How to control pointer equality checks is an open question with several possible answers. And more: Rules for permanently locked objects: - restrictions on classes of locked objects - all non-static fields must be final - there must be no finalizer method (no override to `Object.finalize`) - these restrictions apply to any superclasses as well - an array can be marked locked, but then (of course) its elements cannot be stored to - if not an array, the object's class must implement the marker type `PermanentlyLockable` (is this a good idea?) - restricted operations on locked objects (could be enforced, or else documented as producing undefined results) - do not use any astore or putfield instructions, nor their reflective equivalents, to change any field - do not lock (you may get a hang or a LockedObjectException) - do not test for pointer equality; use Object.equals instead (there may be a test for this) - do not ask for an identity hash code; use Object.hashCode instead (there may be a test for this) - do not call wait, notify, or notifyAll methods in Object - at the time it is marked locked, an object's monitor must not be locked (in fact, should never have been?) - side effects - elements of locked arrays are stably available to readers just like final object fields (i.e., there is a memory fence) - a locked object can be locked again, with no additional effect - any attempt to mutate a permanently locked object raises java.lang.LockedObjectException - any attempt to synchronize on a permanently locked object raises java.lang.LockedObjectException - object lifecycle - all objects are initially created in a normal (unlocked) state - an object marked locked cannot be "unlocked" (reverted to a normal state) - an object marked locked must be unreferenced by any other thread (can we enforce this?) - the reference returned from the (unsafe) marking primitive must be used for all future accesses - any previous references (including the one passed to the marking primitive) must be unused - in practice, this means you must mark an object locked immediately after constructing it - API - the method `lockPermanently` is used to lock an object permanently - there is a predicate `isLockedPermanently` which can test whether an object is locked or not - for initial experiments, these methods are in `sun.misc.Unsafe`; perhaps they belong on `Object` (cf. `clone`)` With all this above I feel it is not exactly same as understood in languages which natively support value type.
- FreezerburnV 10y ago
  I mean, micro-benchmarks are just generally not something to put a huge amount of stock into in general, regardless of language. Software that scales out to hundreds of thousands if not millions of users is generally written in "slow", "bloated" languages, and seems to be doing ok. It really all depends on the use case, and who is creating the software. Most enterprise software is slow and bloated, but a lot of other stuff exists that is quite the contrary. Two easy examples: - Cyberduck is written in Java, yet nobody seems to be complaining about how slow and bloated it is. - There exists a version of Quake 2 written in Java: http://bytonic.de/html/benchmarks.html http://bytonic.de/html/benchmarks.html It seems to be able to push out more frames than native, actually. Both of those are real software that actually run well on Java, regardless of penalty paid for running in a VM, JIT, and GC. Also when looking at the amount of memory and time taken when comparing C to Java in the microbenchmarks, always be sure to mentally factor in the base overhead of starting up the JVM both in time and memory. It's pretty easy to see that when a C version takes up something like 100KB of memory and the Java one takes up 30MB, Java consistently takes up at least ~30MB regardless of how much memory is required for that microbenchmark. When the C version takes up 300MB and the Java one takes up 700MB, that's a bit better of a comparison. (though still not perfect, because the Java GC will reserve a lot of memory for itself, even if it isn't using the full 700MB, if it feels it needs that much, etc.)
  - Alphasite_ 10y ago
    Does their exist a JVM with an OS level shared heap, to reduce GC overhead? Obviously each can be collected independently of one another so pausing shouldn't be a significant issue and IPC becomes a Normal heap reference which may aid in performance.
  - merb 10y ago
    > Cyberduck is written in Java, yet nobody seems to be complaining about how slow and bloated it is. Lol I just double checked that after you said it, it never felt "Javaish" even the interface is really sane. Actually they are using JNA for a lot of stuff and they written foundation bindings... (https://g.iterate.ch/projects/ITERATE/repos/cyberduck/browse/binding/src/main/java/ch/cyberduck/binding https://g.iterate.ch/projects/ITERATE/repos/cyberduck/browse...) cool stuff I keep that for reference. However he should put the bindings stuff under something like LGPL since most stuff will fall under fair use anyway (simple class Names which you would use anyway even without looking at the Source when making a JNA binding to Cocoa)
- igouy 10y ago
  >> memory usage http://programmers.stackexchange.com/a/189552/4334 http://programmers.stackexchange.com/a/189552/4334
userbinator 10y ago
Not pre-HotSpot; I saw the release of HotSpot, and while it did improve performance considerably compared to before, it was still pretty bad compared to native. I see the proliferation of "Java is not slow" articles as a sign that it is --- if it wasn't, why would there be a need for such strong propaganda and carefully constructed microbenchmarks? Sun/Oracle have a deep interest in hiding their "naked emperor". Where are all the "C is not slow" articles, for example? I'm sure anyone who has used a non-trivial Java application, not even an "Enterprise" one, is immediately aware that it seems slower, even those who might not know at all what Java is.
- sievebrain 10y ago
  I guess you see a lot of such articles because of comments like yours - lots of people still think Java is generically slow or Java code is always bloated, despite not having used it for 10 years or more. Whilst such views persist, there will be articles arguing they're false based on newer data. Nobody writes "C is not slow" articles any more, but I remember a time when there were people who believed C++ was inherently slower than C. Maybe some such people still exist! I don't see much talk like that anymore though. With respect to bloated code, the 1990's and early 2000's also saw things like DCOM and other C++ bloat-zones. It's not really to do with the language. The presence of bloat in enterprise apps is more to do with the lack of competition (bespoke apps are by definition monopolies), the frequent lack of deadline pressure (deadlines are invariably artificial) and the inflexible team sizes (over-engineering is incentivised by the need to retain a nice safe corporate job). The fact that enterprise software and Java go hand in hand speaks more to the lack of competition in the space Java plays in, than anything about the language itself.
  - pjmlp 10y ago
    So many memories... Yeah, I remember the days when junior Assembly coders could easily write better code than any C compiler for home computers. Or the days when the arguments that are now used against Java, Go, Swift and many others where used against Turbo Pascal, C, C++, Modula-2, Basic compilers. The more things change, the more they stay the same, I guess.
  - 10y ago

NotRustAgain 10y ago

https://benchmarksgame.alioth.debian.org/u64q/java.html https://benchmarksgame.alioth.debian.org/u64q/java.html Consistently twice as slow, with memory usage between 2 and 400(!) times larger. Java is slow and bloated compared to native. Your next argument will be something about how micro-benchmarks don't reflect reality for larger programs...

bitmapbrother 10y ago
Ah, synthetic benchmarks. Are you really sure they're consistently twice as slow? Your link shows otherwise. mandelbrot 17% slower fannkuch-redux 34% slower fasta 38% slower fasta-redux 39% slower pidigits 44% slower So much for predicting my next argument.
- CherryPickMuch 10y ago
  How come you left out these ones? spectral-norm 115% slower reverse-compliment 121% slower n-body 136% slower regex-dna 235% slower k-nucleotide 253% slower Cherry picking your data shows you're either dishonest or really lost in your denial.
  - bitmapbrother 10y ago
    Perhaps you should read his reply more carefully next time. He said the benchmarks were "consistently 2x" as slow. He was wrong and the rest of the synthetic benchmarks you posted just corroborated my point. As for being dishonest, well, you're commenting from a newly minted temp account so it would seem you didn't have the courage/backbone to use your real one.
userbinator 10y ago
It's interesting that the "gz" column, which reflects the amount of source code required, shows a very slight trend towards C being smaller, although there are big exceptions like regex-dna and reverse-complement. I'm not seeing the 400x more memory - there is a 40x though. But if you add up the columns for the programs that have both C and Java versions, you get this rough summary... secs KB gz Java 76.33 2004048 12775 C gcc 37.32 793652 11651 ...that Java is on average half as fast as C and uses 2.5x more memory, while requiring slightly more source code.
- pvg 10y ago
  "half as fast as C and 2.5x the memory on average" is a stupendously good result for any managed runtime. Most don't get anywhere near it while providing more than acceptable performance in practice.
  - MrBuddyCasino 10y ago
    Yes, and 2.5x is something that can be dealt with by deploying beefier hardware. The productivity gain is what makes that tradeoff a no-brainer.
- igouy 10y ago
  >> more memory http://programmers.stackexchange.com/a/189552/4334 http://programmers.stackexchange.com/a/189552/4334
pron 10y ago
> Java is slow and bloated compared to native. What do you mean by "native"? C/C++? Yes, given enough effort you can write C code that outperforms Java code, sometimes handily, especially in single threaded or low-contention cases. Yet we did write applications in C/C++ before we switched to Java, we had excellent reasons to make the switch, and there have been precious few companies making the switch back. That shows you that the microbenchmarks don't tell the whole story. Right now, the JVM's biggest performance issue is the lack of value types. Once they arrive -- and work is well underway -- beating Java would be harder and harder, especially given new compilers like Graal. But in any event, I just don't see large developers switch back to C++ (or Rust) en masse. Memory usage is hardly an issue, as RAM is very cheap and underutilized in server environments anyway. Spending effort to conserve RAM just doesn't make any sense, unless you're targeting RAM constrained environments.
- geodel 10y ago
  I feel with companies moving to cloud environment defending Java memory bloat will be harder and harder. Java's limited value types may be out by 2020-21 or so and it will be many more years libraries ecosystem start utilizing it. So we are still at least 10 years away from some form of Java value type available for general users.
  - pron 10y ago
    1. Memory "bloat" is always a better use of resources than increased development time, regardless of how you have to pay for it. 2. How are Java's value types limited? 3. I find your calculation extremely pessimistic. Lambda expression are widespread a couple of years after their release, and I see no reason why value types will be different. I think that 5 years are a better estimate for wide use of value types.
    - geodel 10y ago
      Here is what I read from JEP 169 > Except for pointer equality checks, forbidden operations will throw some sort of exception. How to control pointer equality checks is an open question with several possible answers. And more: Rules for permanently locked objects: - restrictions on classes of locked objects - all non-static fields must be final - there must be no finalizer method (no override to `Object.finalize`) - these restrictions apply to any superclasses as well - an array can be marked locked, but then (of course) its elements cannot be stored to - if not an array, the object's class must implement the marker type `PermanentlyLockable` (is this a good idea?) - restricted operations on locked objects (could be enforced, or else documented as producing undefined results) - do not use any astore or putfield instructions, nor their reflective equivalents, to change any field - do not lock (you may get a hang or a LockedObjectException) - do not test for pointer equality; use Object.equals instead (there may be a test for this) - do not ask for an identity hash code; use Object.hashCode instead (there may be a test for this) - do not call wait, notify, or notifyAll methods in Object - at the time it is marked locked, an object's monitor must not be locked (in fact, should never have been?) - side effects - elements of locked arrays are stably available to readers just like final object fields (i.e., there is a memory fence) - a locked object can be locked again, with no additional effect - any attempt to mutate a permanently locked object raises java.lang.LockedObjectException - any attempt to synchronize on a permanently locked object raises java.lang.LockedObjectException - object lifecycle - all objects are initially created in a normal (unlocked) state - an object marked locked cannot be "unlocked" (reverted to a normal state) - an object marked locked must be unreferenced by any other thread (can we enforce this?) - the reference returned from the (unsafe) marking primitive must be used for all future accesses - any previous references (including the one passed to the marking primitive) must be unused - in practice, this means you must mark an object locked immediately after constructing it - API - the method `lockPermanently` is used to lock an object permanently - there is a predicate `isLockedPermanently` which can test whether an object is locked or not - for initial experiments, these methods are in `sun.misc.Unsafe`; perhaps they belong on `Object` (cf. `clone`)` With all this above I feel it is not exactly same as understood in languages which natively support value type.
FreezerburnV 10y ago
I mean, micro-benchmarks are just generally not something to put a huge amount of stock into in general, regardless of language. Software that scales out to hundreds of thousands if not millions of users is generally written in "slow", "bloated" languages, and seems to be doing ok. It really all depends on the use case, and who is creating the software. Most enterprise software is slow and bloated, but a lot of other stuff exists that is quite the contrary. Two easy examples: - Cyberduck is written in Java, yet nobody seems to be complaining about how slow and bloated it is. - There exists a version of Quake 2 written in Java: http://bytonic.de/html/benchmarks.html http://bytonic.de/html/benchmarks.html It seems to be able to push out more frames than native, actually. Both of those are real software that actually run well on Java, regardless of penalty paid for running in a VM, JIT, and GC. Also when looking at the amount of memory and time taken when comparing C to Java in the microbenchmarks, always be sure to mentally factor in the base overhead of starting up the JVM both in time and memory. It's pretty easy to see that when a C version takes up something like 100KB of memory and the Java one takes up 30MB, Java consistently takes up at least ~30MB regardless of how much memory is required for that microbenchmark. When the C version takes up 300MB and the Java one takes up 700MB, that's a bit better of a comparison. (though still not perfect, because the Java GC will reserve a lot of memory for itself, even if it isn't using the full 700MB, if it feels it needs that much, etc.)
- Alphasite_ 10y ago
  Does their exist a JVM with an OS level shared heap, to reduce GC overhead? Obviously each can be collected independently of one another so pausing shouldn't be a significant issue and IPC becomes a Normal heap reference which may aid in performance.
- merb 10y ago
  > Cyberduck is written in Java, yet nobody seems to be complaining about how slow and bloated it is. Lol I just double checked that after you said it, it never felt "Javaish" even the interface is really sane. Actually they are using JNA for a lot of stuff and they written foundation bindings... (https://g.iterate.ch/projects/ITERATE/repos/cyberduck/browse/binding/src/main/java/ch/cyberduck/binding https://g.iterate.ch/projects/ITERATE/repos/cyberduck/browse...) cool stuff I keep that for reference. However he should put the bindings stuff under something like LGPL since most stuff will fall under fair use anyway (simple class Names which you would use anyway even without looking at the Source when making a JNA binding to Cocoa)
igouy 10y ago
>> memory usage http://programmers.stackexchange.com/a/189552/4334 http://programmers.stackexchange.com/a/189552/4334

userbinator 10y ago

Not pre-HotSpot; I saw the release of HotSpot, and while it did improve performance considerably compared to before, it was still pretty bad compared to native. I see the proliferation of "Java is not slow" articles as a sign that it is --- if it wasn't, why would there be a need for such strong propaganda and carefully constructed microbenchmarks? Sun/Oracle have a deep interest in hiding their "naked emperor". Where are all the "C is not slow" articles, for example? I'm sure anyone who has used a non-trivial Java application, not even an "Enterprise" one, is immediately aware that it seems slower, even those who might not know at all what Java is.

sievebrain 10y ago
I guess you see a lot of such articles because of comments like yours - lots of people still think Java is generically slow or Java code is always bloated, despite not having used it for 10 years or more. Whilst such views persist, there will be articles arguing they're false based on newer data. Nobody writes "C is not slow" articles any more, but I remember a time when there were people who believed C++ was inherently slower than C. Maybe some such people still exist! I don't see much talk like that anymore though. With respect to bloated code, the 1990's and early 2000's also saw things like DCOM and other C++ bloat-zones. It's not really to do with the language. The presence of bloat in enterprise apps is more to do with the lack of competition (bespoke apps are by definition monopolies), the frequent lack of deadline pressure (deadlines are invariably artificial) and the inflexible team sizes (over-engineering is incentivised by the need to retain a nice safe corporate job). The fact that enterprise software and Java go hand in hand speaks more to the lack of competition in the space Java plays in, than anything about the language itself.
- pjmlp 10y ago
  So many memories... Yeah, I remember the days when junior Assembly coders could easily write better code than any C compiler for home computers. Or the days when the arguments that are now used against Java, Go, Swift and many others where used against Turbo Pascal, C, C++, Modula-2, Basic compilers. The more things change, the more they stay the same, I guess.
- 10y ago