Help me!! Why java is so popular

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

And don't forget about the very fact that with JVM,
you have to load the entire JVM to run a 2+2 program
and that magnifies the size of a 1 meg program by the
factors of magnitude. Before your main() is hit,
it already swallowed at least 10 megs, and for what?

If you are not willing to spend MB's running in a JVM, then
look for a KVM.

Vast majority of systems out there are windows based.

One of the main design goals of Java is platform independence.

BTW, Windows is 95% of system when counting computers - it
is much much less when counting dollar value.

Third, java has too many layers of abstraction, which,
in turn, translates into pointer pointing to pointers,
pointing to yet more pointers, which can not possibly
translate into the equivalent performance.

Emperical evidence seems to indicate otherwise.

All these layers are also a load on the developer
as you can not possibly do the simpliest things
in a most direct way.

The experience learning people OOP via Java is
relative good I believe.

But it is intended for computer professionals.

The average guy in Walmart will consider PHP
or similar easier.

Another issue is this obscession with obsoleting things.
When you get the next version, you are pretty much
guaranteed that some things in your old code would
have to be rewritten to use the never version of the
same thing. I never heard of such issues with C/C++
code.

That is true.

Which is why they still have a gets that does not
give a warning.

As to graphical aspects of GUI design, to see people
telling you that about the best way to do it, is to
write a GUI code by hand is simply insane!
WHAT?
By HAND is the BEST way of writing a GUI code?
In Java?

You can use a GUI builder if you want. Practically
all Java IDE's comes with one.

A lot of Java programmers prefer to hand code.

But that is their choice.

You are free to choose the GUI builder.

Another lil thing: can anyone imagine that standard
C/C++ code will become OBSOLETE with a new version
of compiler?

Never heard of such a thing.
File is a file and gui is just gui, knob is a knob
and text field is a text field.

Why should I abandon AWT?

There are a better solution. The compiler tells you that. You
can disable the warning if you prefer to stay with the old
way. It will work.

The whole issue JVM needs to be looked at.
The fact that you need to load the whole thing
every time you run ANY app, is a monster size
overkill. It is like loading an operating system
just to output "hello" string on your terminal.

Not a problem for real world applications.

The market for hello world apps is insignificant.

This is the way of the future.

NS .NET is the same thing.

I predict that in 2-3 years, Microsoft will obliterate
the whole java philosophy and mechanisms,

They copied it in .NET !

and people
would not even see the word Java in documentation.

And there will be 4 mondays in a week ...

When I read some articles regading the performance
issues and Java freaks even going as far as to claim
that java could be even MORE efficient that the native
mode programs, I could not believe my eyes.

What happened to their brains?
Have they all gone mad?

How this could POSSIBLY be, even in theory?

If you actually read some of the stuff you would know why.

As I said before, and repeat it again, unless java
is wired into your hardware, which is probably
a generation in the future, I just don't see it becoming
that brick out of which any building is built.

All indications say that it will be Java 1/3, .NET 1/3
and LAMP 1/3.

Arne

 

[blmblm]

Some belated "just curious" questions here .... :




String or StringBuffer?

String. Before I get flamed, keep in mind I knew NOTHING about Java.
I picked up a Java Unleashed or some rot that was laying around,
perused it, figured String was the same as "char string[BUFSIZE];" and
so I used it. The language accepted it, no warnings, and thus I
figured it was all good.

Well, *I*'m not going to be doing any flaming here, though maybe
someone else will explain snidely to both of us ....

I don't understand how a StringBuffer would be useful in this context
even if you knew about it. I guess I say that because I can't think of
any easy way (meaning, using one of the standard library classes) to
get the next line of text from a file into a StringBuffer. Getting a
String is easy, with a BufferedReader, but I couldn't find anything
that would return text line by line into anything *but* a string.
I admit I didn't search too hard.

I'm starting to get curious now. Knowing what you know now, what
would you do instead? read into an array of characters and do your
own splitting into lines? something else?

I know now about immutability and such, I know now about garbage
collection, etc. It's not enough to understand syntax and semantics,
there's meta knowledge about how objects behave that's bigger than any
data structure in C, and more impactful than most (but not all) of
those in C++.

Well, I would claim that this matters in C++ too -- though you're
more apt to have to think about not introducing memory leaks than
about garbage collection.

Well, I'm no Java expert, just someone with intermediate-level
experience with the language, but -- I don't spot anything about
your pseudocode that's obviously bad. ?

What's bad is the String class is immutable -- rereading into the same
buffer forced instantiation of a new String object every time.

A fair change in the C program would have been instead of doing "char
buffer[sizebuf];" type of thingy, to do :

char* buffer = malloc(buffer);
read(buffer);
search(buffer);
free(buffer);

That was inherent in the way String was used, but not blatantly
obvious to this programmer when coding the application at that time.

StringBuffer in place of String would have been closer to "char
buffer[sizebuf];"

"char buffer[sizebuf]" would be closer still, and it seems to me that
the significant thing is what "plays nice" with the language's standard
I/O mechanism. StringBuffer -- does it? I'd have said no.

I'm going to do some benchmarking this week (time permitting) because
this thread has really sparked an interest in me.

That happens. Please post results if you do this and have time --
I too am getting kind of curious about your original code and what you
do to make it faster (if it can be made faster).

The StringBuffer would not be reinstantiated each time causing the
garbage collector to run like a squirrell on crack. The original app
innocently violated good Java programming best practices.

I wonder whether it's at all possible that GC in this situation isn't
as big a performance hit as one might think. As I understand it,
GC works by marking objects that are reachable and then freeing all
other space, and *maybe*, just *maybe*, if there aren't many reachable
objects it's not that big a performance drain????

And while it seems like this can't avoid being a performance hit and
therefore bad in a "this is most of the computation" loop, hm, it
seems to me that Java actually encourages programmers to use this
kind of throw-away object, so is this really a "violates best practice"
thing? I wonder whether there's anything going on under the hood that
makes throw-away objects not as much of a performance problem as one
might think. ??

But forcing a "new" each time. A StringBuffer outside of the loop
instantiated once would circumvent some of the problems I experienced.

Or a character array. But point taken.

The difference between using a Vector and an ArrayList, for instance,
is that Vector has an inherent lock. You won't tend to find that in
char, char* to buffer, struct&, struct* in C, or object&, object*, etc
in C++.

Sure. But what you seem to be saying here is that with Java you have
to also know something about its admittedly vast standard library, in
a way that isn't needed with C++ (which has its STL, but that's not
as huge)?

A COBOL PIC X(1000) or COBOL PIC X OCCURS 1000 TIMES wouldn't
get you either. Some objects in Java are orders of magnitude more
efficient and you need to be aware of that when you use them.

Replace "objects" with "library classes" and I guess I'd agree.

[ snip ]

I think it's about understanding effects.

For instance, in some native assemblers you can peruse the instruction
set and find that choice of instruction can effect performance. A DIV
by a factor of 2 is far less efficient than a SHR. IBM's 360/370
instruction sets contain some peculiar instructions that were built to
enhance COBOL. The EDTMK (I might have that mneumonic wrong -- been a
LONNNNNGGG time) can take packed data and make it into a character
string with dollar signs, commas and decimal points in one statement.

"EDMK" is what I remember (and I think the language is usually called
BAL, rather than BASM as you said in an earlier post?). Huh, intended
for COBOL .... That didn't occur to me back in the long-ago days when
I was using that rather peculiar instruction, but yeah, plausible.

But your data has to be packed decimal to use it. Packed decimal is
not as good for math operations as binary. So you'd need to know that
so you could either convert to packed just before your EDMKs or leave
it packed all the time.

The avg person would only care if it "worked" or not -- realtime
system programmers go nutz when they see inefficiencies at this level.

Yeah, this is all an argument for understanding some of what's going
on under the hood. Sometimes it matters a lot, sometimes not so much,
or that would be my claim.

Over in comp.lang.fortran there was a discussion recently of how to
parallelize some O(N*N) algorithm that would run for -- hours at
least, maybe days -- and finally someone suggested first trying a
different algorithm that I think was O(N log N). The OP just reported
back on using the better algorithm, and -- *huge* difference, such
that parallelization no longer seems like the only hope of getting
acceptable performance.

What's the classic remark (Knuth?) about premature optimization being
the root of all evil?

There's lots of collections that will work in the same algorithm, but
which one you chose and how you apply it can really make a big
difference. From the languages I know, this kind of data structure
choice is more prevalent by far with the Java runtime than with
anything else I've used.

Certainly the scope of the Java standard library is a mixed blessing --
I like to tell people that for pretty much anything you might want to
do in a program there's probably a Java library class that would make
it easier, but the trick is to find it -- or maybe I should say "to
find *them*, and decide which is more suitable".

 

[Oliver Wong]

I'm assuming it takes longer to translate a thing and run it, than
it does to skip translation and just run it. I think that's a fair
assumption.

I think this is the assumption that Arne is complaining about. You make
this assumption, and therefore conclude Java is slower than C/C++. However,
there are reasons to believe that that assumption is false, and thus your
conclusion is invalid.

Consider, for example, a typical modern Pentium class processor: when
you present it with a stream of instructions, it will translate it into a
different set of instructions (e.g. see
http://en.wikipedia.org/wiki/Out-of-order_execution). These processors are
designed this way specifically because the "translate-then-run" is faster
than "just run as-is".

Consider virtualization software such as Apple's Rosetta: when presented
with a set of instructions, rather than fetching each one, and interpreting
it, it will dynamically recompile the set of instructions to a different set
which takes greater advantage of the capabilities of the processor that all
of this software is being run on.

I think part of the misunderstanding stems from an oversimplification of
what is going on between writing the source code for a program, and running
that program. Both Java and C/C++ programs undergo a "transformation"
process -- the difference is when this translation occurs.

With C/C++, the translation process typically occurs once, by the
developer of the program, *before* it's distributed to the end user. If the
developer wishes to reach a large audience, the developer will typically
compile to a lowest common denominator processor (e.g. the 386).

With Java, a translation process occurs twice, once by the developer
before distribution to the end user, and a second time by the end user's
JVM, just in time for running the program itself. The first translation
typically makes very few assumptions about the processor on which the
program will eventually run on. The second translation doesn't need to make
assumptions: it knows exactly which processor the program will run on, and
thus can tailor the code specifically to that processor.

Furthermore, not only does the JVM know the exact processor (and note, I
mean the *exact* processor, not merely the exact make and model of the
processor -- though on multi-processor systems, I suppose the JVM would
"merely" know the exact set of processors) on which the code will run, but
additionally, it also knows the exact behaviour of the user using the
program. Because it's performing the translation while the user is using it!

For example, let's say the program has a menu structure, with a "File"
menu which has options "New Message", "Send Message", "Send Later", "Save",
"Save As", etc., and I, as a user, have never once bothered to click on the
"Send Later" option. The JVM can actually notice this, and take that into
account when performing optimizations in the code. Specifically, it could
avoid loading any classes associated with the "Send Later" functionality,
which will mean certain methods will never be overridden by subclasses
(which never get loaded), which means more methods could be inlined than
with a statically compiled program.

If at a later date, I do choose to use the "Send Later", the JVM can
un-inline the method, make it virtual, and load the relevant subclasses to
allow for the correct semantic behaviour to occur when I click on that menu
item.

You could, of course, replicate the same functionality in C++: You'd
have to add code which monitors which features the user typically uses, and
then dynamically modify its own code in memory to optimize itself. But you'd
essentially be reimplementing the JVM.

- Oliver

 

[Lew]

That's really not so bad. In fact, immutability is more often than not a Good
Thing for an object, especially in multi-threaded applications.

I wonder whether it's at all possible that GC in this situation isn't
as big a performance hit as one might think. As I understand it,
GC works by marking objects that are reachable and then freeing all
other space, and *maybe*, just *maybe*, if there aren't many reachable
objects it's not that big a performance drain????

In the young generation GC doesn't mark the reachable objects, it copies them.

And while it seems like this can't avoid being a performance hit and
therefore bad in a "this is most of the computation" loop, hm, it

Not so bad, really. Object creation is cheap, and the JIT in a tight loop
might even optimize it away altogether.

If the programmer tries to "manage" the memory manually they could defeat both
the GC and the JIT compiler, and end up costing performance.

seems to me that Java actually encourages programmers to use this
kind of throw-away object, so is this really a "violates best practice"
thing? I wonder whether there's anything going on under the hood that
makes throw-away objects not as much of a performance problem as one
might think. ??

Absolutely correct. Java's GC is optimized for the use of throwaway objects.
Keeping objects around can actually make memory problems worse, and even slow
GC down.

Object creation is on the order of ten machine instructions. Young object
destruction takes no time at all. Old object destruction takes considerably
more time, and is much more likely to cause "burps" in program flow when it
occurs.

Best practice in Java is to create new objects for short-lived scenarios, and
to make every object immutable unless there's an affirmative reason to make it
mutable.

- Lew

 

[Oliver Wong]

[post re-ordered to group similar-topic paragraphs together]

[Mark wrote:]

Using Unicode whether encoded as UTF-16 or UTF-8 eliminates a whole
world of pain the moment you see a character outside your current
character set. If you never see anything outside traditional ASCII then
you may not appreciate this. [...]
Even writing in English, I want a generous range
of mathematical symbols available (I am a mathematician).

That's completely valid....

...if you need it. It's not valuable if you don't.

I pay a lot of money for cable and HBO television which would be a
waste if I didn't own a TV.
[...]

Your mileage may vary, and that's where having an option suits both
needs.

Not being able to input non-ASCII unicode characters in the textfield of
an application seems as archaic to me as not being able to enter "0" in a
numeric field, because early (e.g. bronze age) arithmetic systems did not
know about the concept of zero as a number.

It's hard to believe that today, there are still mp3 players that are
unable to handle ID3 tags for songs with non-English characters in them.

Also, while it is a pain to convert when you have to, it's just as
much of a pain to convert when you don't feel you need to --
getChars() is a pain because I don't need anything by chars 99% of the
time in the particular code I'm writing.

I don't understand your complaint: If you don't need getChars(), then
don't invoke it. What's the problem?

- Oliver

 

[Oliver Wong]

I think Arne may have taken my language as
negative towards Java. That's not true at all -- I love pretty much
every language I've learned, from RPG II to Java and all points in
between.

The issue for me is that EVERY language has strengths and weaknesses.
This portion of the thread kinda got ignited when I said I didn't
write Java for my home PC. I don't because I don't want to incur
loading the JVM so that I can turn around and do a recursive tree
search through my directories to find the largest, or oldest, or a
particular file with a certain string. I can quickly write that in
Perl, C or C++, call the OS APIs in the case of C and C++, and I'm
done. A Java app doing the same thing will not run faster, the
overall algorithm will not be simplified, and worse the JVM will
negatively impact my overall system's performance because it requires
a lot of space to load.

I don't think anyone will argue with you that writing command line apps
that locate files with particular properties would be better written in
C/C++/Perl/Whatever else instead of Java. If the C/C++/Perl/Whatever program
executes for less than 1 second, then the equivalent Java program will be
significantly slower, as it takes around 1 second just to load up the JVM.

Where some people (myself included) are taking issues are with some of
the errors of logic or false assumptions you have been making. E.g. "I'm
assuming it takes longer to translate a thing and run it, than it does to
skip translation and just run it."

I don't think anyone is saying Java is always faster than
C/C++/Perl/Whatever. Instead, we're saying that C/C++/Perl/Whatever isn't
always faster than Java. In other words, it's the keyword "always" which is
being protested against.

- Oliver

 

[Chris Uppal]

Consider, for example, a typical modern Pentium class processor: when
you present it with a stream of instructions, it will translate it into a
different set of instructions (e.g. see
http://en.wikipedia.org/wiki/Out-of-order_execution). These processors are
designed this way specifically because the "translate-then-run" is faster
than "just run as-is".

I think that's a false analogy. The comparison that "raddog58c" is making is
between generating the instructions (at some level of abstraction) in advance,
and opposed to generating instructions at a higher level in advance and only
converting them to the lower level in a phase which counts towards overall
runtime.

To make the comparison correct, you'd have to compare
"translate-IA32-instruction-into-uops-then-run" with "just run uops" (uops ==
the micro-instructions of the "real" underlying RISC processor). Also the uop
stream in the second case would have been optimised in advance rather than at
runtime by the processor.

Since the VLIW architecture that Intel attempted to persuade the world to
switch to (unsuccessfully, thank god) is essentially the "just run uops"
approach, that probably /would/ be quicker overall than
"translate-IA32-instruction-into-uops-then-run".

As it stands the decision that Intel (etc) have made is to choose
"translate-IA32-instruction-into-uops-then-run" over "just run IA32
instructions" -- which in JVM terms would be preferring a JITing implementation
with a classic bytecode interpreter. It's true that JITing is faster than
instruction-by-instruction interpretation, but not very illuminating.

-- chris

 

[raddog58c]

I don't understand your complaint: If you don't need getChars(), then

don't invoke it. What's the problem?

- Oliver

The data is stored in UNICODE whether you require it or not. I'm not
writing multinational code at this juncture. In 25+ years of
programming the number of times I've needed multinational character
sets can be counted on one had with fingers to spare.

You might find it archaic, but I find it wasteful. It's a waste
converting into and out of a format you never use.

Why don't you convert your data into Russian characterset. Since
you're never communicating in Russian, when you need English, swap
back. What's the big deal?

The big deal is why do that? Nobody would do that if there wasn't a
reason.

That's what I'm saying. It's conversion to a format that I'm not
personally using. Some people need it; some don't; yet we all pay for
it.

 

[raddog58c]

I don't think anyone will argue with you that writing command line apps

that locate files with particular properties would be better written in
C/C++/Perl/Whatever else instead of Java. If the C/C++/Perl/Whatever program
executes for less than 1 second, then the equivalent Java program will be
significantly slower, as it takes around 1 second just to load up the JVM.

Where some people (myself included) are taking issues are with some of
the errors of logic or false assumptions you have been making. E.g. "I'm
assuming it takes longer to translate a thing and run it, than it does to
skip translation and just run it."

I don't think anyone is saying Java is always faster than
C/C++/Perl/Whatever. Instead, we're saying that C/C++/Perl/Whatever isn't
always faster than Java. In other words, it's the keyword "always" which is
being protested against.

- Oliver

Right, that's true. But it does take longer to go from A to B than to
be at B already. So in those cases where translation results in
something equivalent, you've lost ground translating.

In cases where translation results in something faster, you might make
up ground.

If the lifetime of the app is short, or the difference in improvement
is small, not so good.

When the runtime is long, like a webserver, or where the difference is
huge, bingo. This does occur frequently in some environments. That's
where techniques like those used by the JVM can shine.

 

[raddog58c]

I think that's a false analogy. The comparison that "raddog58c" is making is
between generating the instructions (at some level of abstraction) in advance,
and opposed to generating instructions at a higher level in advance and only
converting them to the lower level in a phase which counts towards overall
runtime.

To make the comparison correct, you'd have to compare
"translate-IA32-instruction-into-uops-then-run" with "just run uops" (uops ==
the micro-instructions of the "real" underlying RISC processor). Also the uop
stream in the second case would have been optimised in advance rather than at
runtime by the processor.

Since the VLIW architecture that Intel attempted to persuade the world to
switch to (unsuccessfully, thank god) is essentially the "just run uops"
approach, that probably /would/ be quicker overall than
"translate-IA32-instruction-into-uops-then-run".

As it stands the decision that Intel (etc) have made is to choose
"translate-IA32-instruction-into-uops-then-run" over "just run IA32
instructions" -- which in JVM terms would be preferring a JITing implementation
with a classic bytecode interpreter. It's true that JITing is faster than
instruction-by-instruction interpretation, but not very illuminating.

-- chris

If the compiler and runtime converter (eg, JVM) generate the same
opcodes to be fed into the processor, the precompiled program will run
faster because it's "cooked" -- the converter must take "raw" data and
"cook" it.

If the compiled code is not formatted to run directly, but the
converter can convert its pseudo code (eg, byte code) directly, then
all things being equal it would depend on which conversion was faster.

This presumes that in the end you have approximately the same set of
instruction data being executed. When that's false, all bets are off.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

No, I'm assuming it takes longer to translate a thing and run it, than
it does to skip translation and just run it. I think that's a fair
assumption.

Yes.

But I was not arguing that.

I was arguing that you assumed the very specific system
optimization could only help close the gap.

FWIW, some of the late-binding advantage can be simulated with
reasonably simple code in any language. For instance an installation
script could check installed hardware and deploy the best from several
versions, or I could build a run-time hardware checker/loader to pull
code from a different DLL based on environments. I have created code
to do these kinds of things. It's not out of the box functionality,
but it's not very difficult either.

It is way behind what the JVM can do.

> Also, a JVM can pay attention to usage, provide caching, adapt at run
> time, etc., but such a service requires space and processing cycles to
> supply. That means *potentially* it could make a single processing
> unit it serves run faster or maybe not, but the service's computations
> come at the expense of the operating environment as a whole. Most
> comparisons focus on a single program's execution, but the resources
> consumed by the JVM to look for runtime optimizations are resources
> unavailable to other processes in the operating environment. How much
> I don't know, but computational knowledge requires memory to store and
> processor cycles to access. I do know large Java apps running on my
> workstation will "blackout" (eg become unresponsive to mouse clicks),
> and I don't experience the same from my C, C++ or Perl scripts -- I
> presumed garbage collection was running, but maybe it's the JVM
> looking for ways to run its apps and classes faster.

The JVM may decide to reoptimize in the middle of the
execution if the usage pattern tells it that the first optimization
was not optimal.

It is a standard example by the JVM experts - I do not know
much it actually does this in practice.

One other thing that I believe hurts Java's runtime environment is the
built-in unicode support. I have no use for unicode in my
applications, but Java stores everything as unicode, right? So that
means twice as much memory, and the need to convert from ASCII or
EBCDIC into and out of unicode, over and over again, and for nothing.
Is there are really good reason for mandatory unicode support? This
hurts Java's runtime model, IMO, and it's pointless if you don't need
it.

I think so.

Single byte only character sets is going the way of punched cards.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

If the lifetime of the app is short, or the difference in improvement
is small, not so good.

When the runtime is long, like a webserver, or where the difference is
huge, bingo. This does occur frequently in some environments. That's
where techniques like those used by the JVM can shine.

All modern JVM's has built in the ability to spend less
time JIT compiling or even do old fashioned interpreting,
if it consider it optimal usage.

But yes - a Java program does not start as quickly as
a native executable.

I am not sure though that the JIT process is the
only cause for that.

Arne

 

[Mark Thornton]

Why don't you convert your data into Russian characterset. Since
you're never communicating in Russian, when you need English, swap
back. What's the big deal?

Some of my data consists of European place names, each in the relevant
language. That means I need all the characters in every European
language in the same data set.

I often holiday in a part of Italy where many of the place names are
given in two languages.

Some years ago I was at a party in Brussels where at least 6 languages
were being spoken, sometimes two languages in a single sentence.

The idea that you can Balkanize the data into nice separate compartments
with their own character set just doesn't work (not least in the Balkans
hee hee).

Mark Thornton

 

[raddog58c]

Yes.

-Xms<size> Set initial Java heap size
-Xmx<size> Set maximum Java heap size

But if the machine is dedicated to only run WAS they may
likely have set both to about 3/4 of the total memory.

Arne

Thank you for the parms, and yes, I'm certain you're correct as
running WAS is the reason for those servers' existence.

 

[raddog58c]

Some of my data consists of European place names, each in the relevant
language. That means I need all the characters in every European
language in the same data set.

I often holiday in a part of Italy where many of the place names are
given in two languages.

Some years ago I was at a party in Brussels where at least 6 languages
were being spoken, sometimes two languages in a single sentence.

The idea that you can Balkanize the data into nice separate compartments
with their own character set just doesn't work (not least in the Balkans
hee hee).

Mark Thornton

Now for you it's an entirely different story, yes? If I had these
requirements my feelings about UNICODE would be more in line with
yours. Since I don't the conversion is a wasted expense.

 

[raddog58c]

All modern JVM's has built in the ability to spend less
time JIT compiling or even do old fashioned interpreting,
if it consider it optimal usage.

But yes - a Java program does not start as quickly as
a native executable.

I am not sure though that the JIT process is the
only cause for that.

Arne

The slower startup and size (although I'm thinking size could be
controlled with some of the parms you provided) which swaps other
processes out of main storage are two primary reasons I'm not
(currently) writing much in Java for my personal consumption. Add to
that the fact the tools I slap together are small, lightweight
instruments that get used intermittently and often (very often) make
direct calls to the native (in this case Windows) OS APIs. I can
slap together a C/C++ program quickly in notepad, commandline compile
it and drop it into the bin directory I have pathed for tools. It
works well for me.

When I need to automate some batch process, it's Perl, baby! I know
peeps at work who think we should write EVERYTHING in Perl -- "Perl
can do GUI, object oriented, yadda yadda"... Love is so blind -- we
accept faults as that which makes our "sweetheart" unique. (guffaw,
chuckle, snort snort)...

In any event, we're fiddling around with JMS at work, and I'm
considering setting up a JMS listener on my work station. I have some
ideas for mobilizing (in a good way) workstations into a unified grid
processing unit. There's also regular stuff that could benefit by
shoving diagnostic messages out to some listener. I wouldn't run these
all the time, but they'd definitely pull their weight when needed.
This/these will be written entirely in Java. Writing in C++ or
(heaven forbid) C or Assembler makes no sense and would be a lot
harder to do.

Java will make the task trivial. It's perfectly suited and since this
is I/O bound processing I'll bet I won't even realize it's running.

 

[raddog58c]

Yes.

But I was not arguing that.

I was arguing that you assumed the very specific system
optimization could only help close the gap.

Well, I can tell you this, this discussion thread has elucidated
things in the JVM about which I knew little. I admit that -- I can
write Java code and presumably "good" code. But what occurs within
the domicile of the JVM only the JVM, its architects, evidently some
people here, and the JVM's hairdresser know for sure.

So this discussion has been extremely beneficial to me. I can now see
some of how the JVM goes about adding value with late binding, and
this will help me to use Java better in future endeavors.

Thanks to everyone who's provided this illumination (d'waug curtseys
to the group).

Anyways, I think these boosts in some cases where there's no low-
hanging fruit will hurt; in some they'll help; in some they'll
exceed. The third case (X-eeding) is a new understanding for me, as
prior to this thread I'd have said "that's impossible." Now I know
better.

It is way behind what the JVM can do.

No doubt, it's the quick-n-dirty, base-case boosting. But it's
inexpensive, non invasive to the system, and depending on the problem
space can be all you need.

The JVM may decide to reoptimize in the middle of the
execution if the usage pattern tells it that the first optimization
was not optimal.

It is a standard example by the JVM experts - I do not know
much it actually does this in practice.

It's fascinating stuff to which I admit heavy ignorance. I will
profess that there's a lot about JVM boosts I don't know -- and it
could very well be misuse on my part has degraded throughput of some
of my Java apps. It's unquestionable in many cases where Java is
activated today on my desktop -- like Eclipse firing up its debugger
-- the CPU is pegged and all other apps become unresponsive. That
might be a one-time fee, but I do experience it.

I think so.

Single byte only character sets is going the way of punched cards.

Arne

In many domains, yes. But in many domains, no. And in legacy domains
the ASCII/EBCDIC byte will rule the kingdom for many years to come.

The key as far as I'm concerned is to minimize needless processing.
This isn't directed at Java but really anything that's built on the
notion of "hardware is cheap." That's a relative statement -- it's
not cheap unless you already have it installed. As SW Engineers I
(per realtime background) would much prefer we keep waste to a
minimum. It's annoying to see systems running at orders of magnitude
of systems 20 years ago being less responsive than the old monochrome
screen systems. Doing more? Sure, but also doing a LOT that doesn't
need to be done. Blatant inefficiency is a virus, worm, or adware in
my view, as it's taking away responsiveness I want dedicated to me and
my needs, or to the real needs of the system.

It's a pet peeve of mine.... so I'll get off my soapbox now. (drops
to one knee and pumps fist)

 

[raddog58c]

I think that's a false analogy. The comparison that "raddog58c" is making is
between generating the instructions (at some level of abstraction) in advance,
and opposed to generating instructions at a higher level in advance and only
converting them to the lower level in a phase which counts towards overall
runtime.

To make the comparison correct, you'd have to compare
"translate-IA32-instruction-into-uops-then-run" with "just run uops" (uops ==
the micro-instructions of the "real" underlying RISC processor). Also the uop
stream in the second case would have been optimised in advance rather than at
runtime by the processor.

Since the VLIW architecture that Intel attempted to persuade the world to
switch to (unsuccessfully, thank god) is essentially the "just run uops"
approach, that probably /would/ be quicker overall than
"translate-IA32-instruction-into-uops-then-run".

As it stands the decision that Intel (etc) have made is to choose
"translate-IA32-instruction-into-uops-then-run" over "just run IA32
instructions" -- which in JVM terms would be preferring a JITing implementation
with a classic bytecode interpreter. It's true that JITing is faster than
instruction-by-instruction interpretation, but not very illuminating.

-- chris

Hey Chis, where can I find doc on the UOPS specification? I was
perusing the pentium data sheets (downloadable off the Intel site) and
didn't see this discussed -- what I saw were essentially the same
opcodes as they ever were.....

.....can you direct me to said documentation? Post here or to my email
of raddog_AT_kc_DOT_rr_DOT_com.

It's really interesting and apparently I've missed a significant
processor architectural change.

Thanks!

 

[blmblm]

raddog58c <[email protected]> wrote:

[ snip ]

In the young generation GC doesn't mark the reachable objects, it
copies them.

Ah. Yes, of course, that makes sense. Either way, though, time
needed would be proportional to the number of reachable objects rather
than to the number of discarded objects, which was the idea behind
my speculation that maybe GC might not be so bad.

("In the young generation"? Is that making a distinction, as you
say later is done, between objects that stay around a while versus
short-term ones?)

Not so bad, really. Object creation is cheap, and the JIT in a tight loop
might even optimize it away altogether.

It can do that even when the object being created is immutable? as
would be the case with readLine in BufferedReader, which seems to be
the "isn't this a problem?" in the OP's example?

[ snip ]

Object creation is on the order of ten machine instructions. Young object
destruction takes no time at all. Old object destruction takes considerably
more time, and is much more likely to cause "burps" in program flow when it
occurs.

Best practice in Java is to create new objects for short-lived scenarios, and
to make every object immutable unless there's an affirmative reason to make it
mutable.

Huh. I've heard some of this before but maybe not all. Maybe I need
to finally read Bloch's "Effective Java" rather than just housing it
on a bookshelf ....

 

[Mark Thornton]

Now for you it's an entirely different story, yes? If I had these
requirements my feelings about UNICODE would be more in line with
yours. Since I don't the conversion is a wasted expense.

Java's compulsory use of Unicode means that any third party tools I use
will also work with data like mine. In systems where use of unicode is
optional (or non-existent) it is common to find tools that would be nice
if only they mad provision for characters beyond ASCII. It also
simplifies internationalization even where the original developer didn't
pay too much attention to these requirements.

Character set conversion can only be avoided if you can be sure of
always working in a single specified character set. Once you have to do
a conversion of some sort, conversion to/from Unicode isn't much (if
any) more expensive than conversion between simple single byte character
sets. Even in the US I expect you are likely to see data in CP-437,
CP-850, CP-1252, and ISO-8859-1 as well as UTF-8, and UTF-16.

Finally just how much difference does the extra overhead of Unicode
actually make? In most substantial applications the overhead will be
negligible.

Mark Thornton