Maybe a noob observation, but can anyone explain why the Lock Coarsening example is valid? Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B... Unless the programmer made a cognitive error the cases seem incomparable, unlike the other examples.
JVM JIT optimization techniques
21–30 of 62 posts
Re: JVM JIT optimization techniques
#22Maybe a noob observation, but can anyone explain why the Lock Coarsening example is valid? Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B... Unless the programmer made a cognitive error the cases seem incomparable, unlike the other examples.
"Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B"
You're looking at:
public void canNotBeMerged()
Re: JVM JIT optimization techniques
#23Re: JVM JIT optimization techniques
#24for most of the time, many performance considerations are invisible from the higher abstraction levels, so you can concentrate writing simple, elegant and maintainable applications in Java, Scala, Kotlin or anything that runs on the JVM. Funny statement, at least for Java. I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, a…
> I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, and whose codebases are just as unoptimised for the perspective of the humans who have to work with them. I would, and I've been developing in Java for over ten years now, after ten years of C/C++. I think that your complaints have nothing to do with Java, and much to do w…
That paper says the actual benchmark was only 2.2% faster. What does the 3x speedup actually mean then?
Re: JVM JIT optimization techniques
#25It's interesting how most of the optimizations are only really available if you essentially write your programs in a functional style. That is, they all depend on the compiler being able to analyse the local scope to decide whether the state changes are confined enough that it can perform an optimization without changing behavior. If a reference escapes, even into a private, instance variable, the compiler will (admi…
Escape analysis is pretty damn capable if you can give it enough time to run.
Re: JVM JIT optimization techniques
#26for most of the time, many performance considerations are invisible from the higher abstraction levels, so you can concentrate writing simple, elegant and maintainable applications in Java, Scala, Kotlin or anything that runs on the JVM. Funny statement, at least for Java. I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, a…
> I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, and whose codebases are just as unoptimised for the perspective of the humans who have to work with them. I would, and I've been developing in Java for over ten years now, after ten years of C/C++. I think that your complaints have nothing to do with Java, and much to do w…
Is Graal not only faster than the Client JVM, but slower than the server VM?
Re: JVM JIT optimization techniques
#27It's interesting how most of the optimizations are only really available if you essentially write your programs in a functional style. That is, they all depend on the compiler being able to analyse the local scope to decide whether the state changes are confined enough that it can perform an optimization without changing behavior. If a reference escapes, even into a private, instance variable, the compiler will (admi…
That's not a functional style, but an observation of how most (non-pathological) code behaves. If you're talking about escape analysis and stack allocation, the functional style doesn't help, because references escape all the time. That they're pointing to immutable objects doesn't matter. In any case, whether functional or not, the observation is that many objects have limited scopes, that correspond to structural s…
Actually In all analysis seen so far it mostly is way slower to do the Java EE style (biomorphic, megamorphic) and instead use normal classes, static class functions instead of polymophism. So actually a flat level is way faster than any sane stuff which is mostly done in a lot of Enterprise software.
Re: JVM JIT optimization techniques
#28Earlier quoted context omitted.
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...
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…
> 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...) 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)
Re: JVM JIT optimization techniques
#29Earlier quoted context omitted.
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...
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 12…
"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.
Re: JVM JIT optimization techniques
#30There is something about this site that absolutely destroys Firefox when scrolling. Expensive work in a scroll handler isn't good guys :(
I would not be too quick to blame the authors of the website. It seems likely to be the same Firefox bug as all the other cases of HN comments complaining about bad scrolling performance in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1250947
Bad link, I'm afraid... It's about a box-shadow glitch.