compilattion of java for 64 bit

[Tom Anderson]

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's_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

 

[Arved Sandstrom]

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

 

[zigzagdna]

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.

 

[Lew]

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]

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]

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":