compilation of java for 64 bit
in [Java Help]
|
Prev: sha256sum and (new BigInteger(1, MD.digest())).toString(16) not listing exactly the same ...
Next: JPA+hibernate merge vs find fetching lazy collection
From: alexandre_paterson on 28 Dec 2009 16:55 On Dec 27, 6:12 pm, Lew <no...(a)lewscanon.com> wrote: > zigzagdna wrote: > > I am reading some literature on 64bit java [sic]. It says 64 bit jvm could > > be slower than 32 jvm because all paths are larger (pointers etc). So > > if application java [sic] code is not taking advantage of 64 bit > > architecture, things could be slower. > > -XX:+UseCompressedOops OP's concern as I read his post was about speed, not memory usage. I think we are conflating two very different issues here Lew aren't we!? - memory bloat without compressed pointers for applications that keep lots of references in memory - speed: which may or may not be faster by using 64 bits pointers on 64 bits CPUs And altough the two are related the answer is *much* more complicated than your usual "one-line-I-know-it-all" answers. In that case one could even say you're misleading, if not downright off the mark and simply, well... wrong. I recently read a fascinating article written by dudes much smarter than me who were surprised to see that the 64 bit version of their algo, despite a higher memory usage, was faster (even tough they needn't 64 bit). It wasn't Java but still: that was *without* any encoding/decoding and the 64 bit version was already faster. Using UseCompressedOops there's pointer encoding/decoding going on (it's document, Google is your friend Lew) and it is documented that, albeit low, there's still a cost to it. So in addition to the fact that 64 bit with 32 bit waste may already be faster in itself on 64 bit cpu, your adding compressed pointer encoding/decoding to the issue. Just slightly missing OP's concern about speed I think... It's people who have memory issue, not speed issue (the two being not always related), who want to look into compressed pointers. This is a subject much more complex than: "-XX:+UseCompressedOops" especially if the concern is about speed, not memory. lol ? But as usual your one liner was enlightening right? Grammar naziness and JLS-worshipping can be sent to /dev/null. ;)
From: Thomas Pornin on 28 Dec 2009 17:15 According to Kevin McMurtrie <mcmurtrie(a)pixelmemory.us>: > I've generally seen the x86-64 JVM run faster than the x86 JVM. Computations with 'long' values are faster in 64-bit mode. In particular, BigInteger.modPow() is three times faster than in 32-bit mode. For CPU intensive tasks which use only 32-bit values, the 64-bit mode can still offer some gains, due to the additional registers, which help the JIT compiler; a +30% gain is typical. However, the overwhelming majority of applications is not CPU-bound and little to no performance difference is to be observed between a 32-bit and a 64-bit JVM. Theoretically, the larger registers could make the 64-bit JVM slower, because pointer-heavy structures would not fit as well in cache, but I have yet to encounter such an application. I find it plausible that a specially contrived micro-benchmark could demonstrate that effect, but this is quite a long shot from an actually useful application. --Thomas Pornin
From: Peter Duniho on 28 Dec 2009 17:49 alexandre_paterson(a)yahoo.fr wrote: > On Dec 27, 6:12 pm, Lew <no...(a)lewscanon.com> wrote: >> zigzagdna wrote: >>> I am reading some literature on 64bit java [sic]. It says 64 bit jvm could >>> be slower than 32 jvm because all paths are larger (pointers etc). So >>> if application java [sic] code is not taking advantage of 64 bit >>> architecture, things could be slower. >> -XX:+UseCompressedOops > > OP's concern as I read his post was about > speed, not memory usage. > > I think we are conflating two very different issues > here Lew aren't we!? It doesn't appear to me that he is. > - memory bloat without compressed pointers > for applications that keep lots of references > in memory > > - speed: which may or may not be faster by using 64 bits > pointers on 64 bits CPUs The OP has specifically stated a concern that speed will be reduced by the larger pointer size. While that's not a valid concern, it's not possible to discuss that concern without bringing up the potential, and providing a suggestion that can reduce pointer sizes allows the OP a way to make some real evaluation of whether the pointer size really is affecting his code negatively or not. > And altough the two are related the answer is *much* > more complicated than your usual "one-line-I-know-it-all" > answers. Frankly, that sort of ad hominem attack is uncalled for. Lew has not in any way implied that the answer is less complicated than it really is, and your blatant mischaracterization is simply insulting. > In that case one could even say you're misleading, if not > downright off the mark and simply, well... wrong. "One" _can_ say whatever "one" wants to. But you, er...I mean "one", would be wrong "oneself" in doing so. > I recently read a fascinating article written by dudes > much smarter than me who were surprised to see that the > 64 bit version of their algo, despite a higher memory > usage, was faster (even tough they needn't 64 bit). That potential has in fact been pointed out several times to the OP already. I doubt Lew saw any reason to belabor the point. > [...] > Just slightly missing OP's concern about speed I think... Seems to me it's you who is missing the context in which the OP is stating a concern about speed. Pete
From: John B. Matthews on 28 Dec 2009 18:01 In article <35de15c0-d9da-4845-9e91-5b211fc542d2(a)a32g2000yqm.googlegroups.com>, alexandre_paterson(a)yahoo.fr wrote: > Grammar naziness As a nazi nazi, I feel compelled to criticize your inappropriate comparison to the Nazis by mentioning Godwin's Law: <http://en.wikipedia.org/wiki/Godwin%27s_law> but I am too late: <http://groups.google.com/group/comp.lang.java.programmer/msg/92ebfa54cf35f3cb> I probably need to consult a nazi nazi nazi for some kind of ruling. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Tom Anderson on 28 Dec 2009 18:43
On Sun, 27 Dec 2009, Mike Schilling wrote: > zigzagdna wrote: >> Looks like safest way is to use 64bit jvm when on 64 bit OS, however it >> runs slightly slower > > Read it more carefully: *may* run slightly slower. Without compressed OOPs, *will probably* run moderately slower. With compressed OOPs, *will probably not* run noticeably slower. tom -- I content myself with the Speculative part [...], I care not for the Practick. I seldom bring any thing to use, 'tis not my way. Knowledge is my ultimate end. -- Sir Nicholas Gimcrack |