4 ms·
Nope, it has to do with the fundamental memory models of Java vs C/C++. In C++ you can arrange your access patterns so you don't cache miss, much harder to do
by vvanders 11y ago
Nope, it has to do with the fundamental memory models of Java vs C/C++.
In C++ you can arrange your access patterns so you don't cache miss, much harder to do that in Java.
- pjmlp 11y agoTrue, but it will hopefully change in Java 10.
- vvanders 11y agoGiven the ~3-5 year release cycle trend(plus the fact that android is still Java 7) I'm sure we can expect it by 2025 ;)
- pjmlp 11y agoMost likely Google will never update beyond Java 7, if their attitude at Google IO is anything to go by. For me what counts is the official Java, not forks.
- bitmapbrother 11y agoThey've already updated to Java 8 with the switch to the OpenJDK so whenever Java 9, 10, 11, etc come out they'll be in sync.
- pjmlp 11y agoI have news for you. Check the Android source code. They updated to selected parts of OpenJDK 7!
- kbenson 11y agoHarder to do manually, or harder to do even for the VM (given enough intelligence) because of the memory model?
- vvanders 11y agoYou can do it by treating everything as a ByteBuffer, but then you pay some conversion costs(Int -> Float is esp painful). It's fundamentally a data structure + execution flow problem so it's not something that a VM/compiler can help with. The fact that everything in Java is a ref(to be fixed some point in distant future) just means that every object fetch is a cache miss(really bad).
- kbenson 11y agoAh, that makes sense. So, we could conceivably claim that if that is fixed, Java might be able to JIT compile run code a bit faster than C++ in a wider application that currently, but then again by the time that happens, C++ might have a plethora of other tricks up it's sleeve to make execution a little faster.
- wtallis 11y agoYou're hypothesizing something that really wouldn't be Java anymore.
- yarou 11y agoIsn't this what Dalvik does? (And by extension, ART) IIRC, a register-based virtual machine would alleviate the cache-miss behavior the GP talks about. (Because larger, more complex instructions = fewer hits to cache) It's been a while since I've mucked around with this type of stuff, though.
- vvanders 11y agoNope, you're thinking a one level too low in the stack. The issue is that each object is a reference, and because it's a reference it's position in memory is by nature ambiguous(compacting GCs make this even worse by moving things around). Until you can guarantee memory location you don't know that the N+1 object you're going to access is in the same cache line(or prefetched) and any sort of cache optimization is shot to hell. Only by knowing your standard execution flow and data set size can you write code that's as efficient about cache misses as possible. Hotspot only tends to focus on tight inner loops where the stuff I'm talking about involves looking at the larger program(and the structures you choose to put data into). Think Structure of Arrays(SoA) rather than Arrays of Structures(AoS). Possible to do in Java, but very painful.