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: Lew on 28 Dec 2009 21:25 Tom Anderson wrote: > 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. As the Nazi of Grammar, whose naughty Naziness triggered that troll, I did not see that Nazi-Nazi Nazi grammar Nazi knot scene coming. -- Lew
From: Lew on 28 Dec 2009 21:36
Tom Anderson wrote: > 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. Probability based on what factors, and asserted with what evidence? > With compressed OOPs, *will probably not* run noticeably slower. As M. Pornin posted, there are large categories of Java programs that run appreciably faster with a 64-bit JVM. The probability of any given program running faster or slower is directly related to the probability that one will write a program whose profile fits the "faster" or "slower" category. Thomas Pornin also asserted that for the "overwhelming majority" of programs, "little to no performance difference is to be observed between a 32-bit and a 64-bit JVM." I don't know what his evidence is, either, but his claim contradicts yours somewhat. The only claim I trust here is the one made by every writer on the subject of software performance engineering, that it takes measurement to know. The OP should concentrate on good algorithms and clean, maintainable code. The performance will likely take care of itself then. As Peter Duniho remarked, in response to the OP's statement that, "[In the e]nvironment 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. -- Lew |