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: Tom Anderson on 28 Dec 2009 18:47 On Mon, 28 Dec 2009, John B. Matthews wrote: > 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. Actually, that would be a nazi-nazi nazi. Sorry to be such a nazi-nazi nazi grammar nazi about this. 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
From: Arved Sandstrom on 28 Dec 2009 19:36 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!? > [ SNIP ] > But as usual your one liner was enlightening right? > > Grammar naziness and JLS-worshipping can be sent > to /dev/null. > > ;) I'm surprised you didn't notice, and comment on, Lew's narrow-minded obsession with RDBMS-driven semi-OOP. AHS
From: zigzagdna on 28 Dec 2009 19:48 On Dec 28, 7:36 pm, Arved Sandstrom <dces...(a)hotmail.com> wrote: > alexandre_pater...(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!? > > [ SNIP ] > > > But as usual your one liner was enlightening right? > > > Grammar naziness and JLS-worshipping can be sent > > to /dev/null. > > > ;) > > I'm surprised you didn't notice, and comment on, Lew's narrow-minded > obsession with RDBMS-driven semi-OOP. > > AHS Thanks a lot to all the feedback which I received. Good to know 64 bit jvm should not cause performance problem for most applications. -XX: +UseCompressedOops, I tried this option but not available on the JDK update which I have. I need to update my JDK to latest update. I have a third party production application used by many users which currently runs on Windows 2003 32 bit. I am looking into using Windows 2003 64 bit OS with 64 bit jvm. Environment I work in, there is not any time to do any performance comparison. I just have to make an informed decision and go with it. Really appreciate all the feedback provided in this thread.
From: Peter Duniho on 28 Dec 2009 20:06 zigzagdna wrote: > [...] > I have a third party production application used by many users which > currently runs on Windows 2003 32 bit. Then you definitely cannot afford to risk using /LARGEADDRESSAWARE > I am looking into using Windows > 2003 64 bit OS with 64 bit jvm. Environment I work in, there is not > any time to do any performance comparison. [...] Then by definition, performance doesn't matter. Don't worry about it. Pete
From: Lew on 28 Dec 2009 21:22
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!? Not at all. The speed issue with 64-bit pointers, if there is one, is due to their size and concomitant reduction in number of pointers that can fit in cache. Using compressed object pointers where available obviates that pressure, allowing caches to hold more pointers and thus speeding up the program. When that issue applies. > In that case one could even say you're misleading, if not > downright off the mark and simply, well... wrong. Don't let your irrational personal animosity toward me blind you to the facts. > 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's consistent with the points I've been making in this thread, that 64-bit pointers do not perforce slow a program down, contrary to what the OP had heard. > 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. Still, the option can be useful in those situations where the pointer size becomes an issue, which, as many have said here, is far from a certainty. > Just slightly missing OP's concern about speed I think... You are mistaken. My comments directly addressed the OP's concern, in that the only issue of speed from 64-bit pointers, about which the OP posted, is due to cache capacity. Good try finding fault with me, though. It's not that I never make mistakes; I make them all the time and folks here are quick to correct them. I just didn't make a mistake this time. Your claims, that pointer en/decoding affects speed, is also unsupported. It requires evidence, and descriptions of the scenarios in which that affect is notable. I swan they are few, vanishingly so. But then, I don't know without measurement either. > 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? Sure it was, if you read and understood it. > Grammar naziness and JLS-worshipping can be sent > to /dev/null. What are you on about? Are you saying that the Java Language Specification is not useful? Or that it isn't the definitive reference for Java? Or that there's something wrong with recommending that a professional Java programmer be familiar with it? If that's your point, why not support it with logic, evidence and reasoning, instead of your usual trollish nonsense? You will note that I consistently argue against religiosity in engineering discussions, so your amateurish attempt to insult me by calling my statements "JLS-worshipping" really missed the mark. Oh, and "Naziness" should be spelled with a capital letter "N", since "Nazi" is a proper noun/adjective. As long as you're going to stoop to such ridiculous and harmless name-calling. -- Lew |