JTK - Care to comment on this?

java-programmer, JTK - Care to comment on this? Java vs C and C++
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

l8r, Mike N. Christoff

java-programmer >> JTK - Care to comment on this? Michael N. Christoff wrote:
> Java vs C and C++
> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
>
>
>
> l8r, Mike N. Christoff

No Mike, I don't. I've been seeing "benchmarks" claiming to show that
Java is "almost as fast as C++", "fast enough", "in some cases maybe
even slightly faster than C++", blah blahblah blah blah since the very
inception of Java. It was not true then, it isn't true now, and it will
never be true. Furthermore, you and the rest of the Java "Community
Process" know that, or you wouldn't have to keep pushing these "benchmarks".

And you'd be using 100% Pure Java apps. Which of course you don't. Why
is that Mike? Care to comment on that?

l8r, JTK

java-programmer >> JTK - Care to comment on this?
"JTK" <email***@***.com> wrote in message
news:VIRvc.2208$email***@***.com...
> Michael N. Christoff wrote:
> > Java vs C and C++
> > http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
> >
> >
> >
> > l8r, Mike N. Christoff
>
> No Mike, I don't. I've been seeing "benchmarks" claiming to show that
> Java is "almost as fast as C++", "fast enough", "in some cases maybe
> even slightly faster than C++", blah blahblah blah blah since the very
> inception of Java. It was not true then, it isn't true now, and it
will
> never be true. Furthermore, you and the rest of the Java "Community
> Process" know that, or you wouldn't have to keep pushing these
"benchmarks".

Like you keep pushing your java's-dead(-again) kind of FUD?

> And you'd be using 100% Pure Java apps. Which of course you don't.

I do.

> Why
> is that Mike? Care to comment on that?
>
> l8r, JTK

java-programmer >> JTK - Care to comment on this?
"JTK" <email***@***.com> wrote in message
news:VIRvc.2208$email***@***.com...
> Michael N. Christoff wrote:
> > Java vs C and C++
> > http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
> >
> >
> >
> > l8r, Mike N. Christoff
>
> No Mike, I don't. I've been seeing "benchmarks" claiming to show that
> Java is "almost as fast as C++", "fast enough", "in some cases maybe
> even slightly faster than C++", blah blahblah blah blah since the very
> inception of Java. It was not true then, it isn't true now, and it will
> never be true. Furthermore, you and the rest of the Java "Community
> Process" know that, or you wouldn't have to keep pushing these
"benchmarks".
>
> And you'd be using 100% Pure Java apps. Which of course you don't. Why
> is that Mike? Care to comment on that?
>

I use LimeWire which is a Java app. I also used Maestro, the Mars Rover app
developed by the Jet Propulsion Labs. In the past I also used Java-ICQ.

l8r, Mike N. Christoff

java-programmer >> JTK - Care to comment on this? >Java vs C and C++
>http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
>

At the page: "Java program startup is slow... But while it might explain user's
impressions, it does not explain why many programmers... share our belief."

When you base something on the users being wrong, your whole point is usually
wrong. For servers or canned tests, Java may be almost as fast as C. But, when
it comes to client apps and applets, Java will always be slower than a
well-written C program because it uses more memory and takes longer to start
up.

The bit about the startup times should have been placed at the top of the page,
instead of being relegated to the bottom.

-- The Lonewacko Blog
http://lonewacko.com/blog

java-programmer >> JTK - Care to comment on this?
"Lonewackodotcom" <email***@***.com> wrote in message
news:email***@***.com...
> >Java vs C and C++
> >http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
> >
>
> At the page: "Java program startup is slow... But while it might explain
user's
> impressions, it does not explain why many programmers... share our
belief."
>
> When you base something on the users being wrong, your whole point is
usually
> wrong. For servers or canned tests, Java may be almost as fast as C. But,
when
> it comes to client apps and applets, Java will always be slower than a
> well-written C program because it uses more memory and takes longer to
start
> up.
>

I don't think the fact that a Java app may use more memory would have a huge
effect on performance once its loaded. The best Java app I have used so
far, up there with Eclipse, is BEA Weblogic Workshop 8.1. While it uses a
LOT of memory (however it admittedly does a lot of things), it matches
window's look and feel exactly and the GUI is extremely fast. At first I
thought they had written the GUI natively, but later found out it was
vanilla Swing.

Also note that BEA Workshop uses its own optimized proprietary vm. In other
words, it often does not make sense to describe 'Java' as being slow as
opposed to 'Java apps are slow when run on this particular vm'. All vms
have their plusses and minuses, each one makes its own unique trade offs.
There is no monolithic hierarchy of performance for any set of language
implementations. There will always be overlaps in performance and general
messiness.

> The bit about the startup times should have been placed at the top of the
page,
> instead of being relegated to the bottom.
>

It depends on how the application is typically used (assuming that the
startup time is not outrageously slow). For example, a program to trade
stocks would typically be turned on in the morning and left on until the
market closes. In this case a slower startup time, although annoying, is
not that big a deal. As for memory/cpu, 512MB/~2Ghz is currently standard
for new pcs. This is adequate to run java client apps. This time next year
soccer moms will probably be buying 3GHz+ pcs from Dell with 1GB of ram
standard.

If interested, check out workshop in this devx rticle.

Stop Speculating, Start Building: A Step-by-step Guide to Building Web
Services with WebLogic Workshop 8.1 and MySQL
http://www.devx.com/getHelpOn/Article/15944/0/page/1

l8r, Mike N. Christoff

java-programmer >> JTK - Care to comment on this? On 14 Jun 2004 21:37:03 GMT, email***@***.com
(Lonewackodotcom) wrote or quoted :

> Java will always be slower than a
>well-written C program because it uses more memory and takes longer to start
>up.

Not so any more. The reason java is slow to start is it has to load
classes. If you statically compile so all classes are already loaded
you start up just as smartly as C. You can further use DLLs to keep
the standard classes loaded most of the time further speeding startup.

See http://mindprod.com/jgloss/nativecompiler.html
http://mindprod.com/jgloss/jet.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

java-programmer >> JTK - Care to comment on this? >I don't think the fact that a Java app may use more memory would have a huge
>effect on performance once its loaded.

Well, let's see. How many RAM-hungry apps can I have running? How many
non-RAM-hungry apps can I have running? Does starting and running a RAM-hungry
app have an affect on the OS, such as creating a demand for swap space, taking
resources that other apps could use, etc. etc. etc. Of course, if you have 2
gigs of RAM and your machine is dedicated to running that one app, it doesn't
matter. But, in the real world of real users, it does matter.

>As for memory/cpu, 512MB/~2Ghz is currently standard
>for new pcs. This is adequate to run java client apps.

I don't know how long you've been around here, but I've been hearing "just wait
'til next year!" for some years now.

> This time next year
>soccer moms

Mmmm... soccer moms.

-- The Lonewacko Blog
http://lonewacko.com/blog

java-programmer >> JTK - Care to comment on this? >Not so any more. The reason java is slow to start is it has to load
>classes. If you statically compile so all classes are already loaded
>you start up just as smartly as C. You can further use DLLs to keep
>the standard classes loaded most of the time further speeding startup.

Of the eight choices at the first link, only the first involves compiling to a
native executable. The other seven involve interpreted Java code. In any case,
let me refine my original statement: both interpreted Java and Java compiled
into a native executable will always be slower than a well-written C program
because it uses more memory and takes longer to start up and also because the C
programmer has (almost) complete control over the program. Of course, the
compiler inserts standard code into the executable, but that can be eliminated.

For instance, compare how long one of your MASM programs (for instance
BootSave/BootRest) take to startup and execute. Then write the same program in
Java and compile it with a native compiler. The MASM version will always be
faster and use less memory.

-- The Lonewacko Blog
http://lonewacko.com/blog

java-programmer >> JTK - Care to comment on this? On 15 Jun 2004 04:26:43 GMT, email***@***.com
(Lonewackodotcom) wrote or quoted :

>
>Well, let's see. How many RAM-hungry apps can I have running? How many
>non-RAM-hungry apps can I have running? Does starting and running a RAM-hungry
>app have an affect on the OS, such as creating a demand for swap space, taking
>resources that other apps could use, etc. etc. etc. Of course, if you have 2
>gigs of RAM and your machine is dedicated to running that one app, it doesn't
>matter. But, in the real world of real users, it does matter.

Would you kindly stop changing your phony id. I am tired of listening
to you and I am getting pissed with you messing with my killfile.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

java-programmer >> JTK - Care to comment on this?
"Lonewackodotcom" <email***@***.com> wrote in message
news:email***@***.com...
> >Not so any more. The reason java is slow to start is it has to load
> >classes. If you statically compile so all classes are already loaded
> >you start up just as smartly as C. You can further use DLLs to keep
> >the standard classes loaded most of the time further speeding startup.
>
> Of the eight choices at the first link, only the first involves compiling
to a
> native executable. The other seven involve interpreted Java code. In any
case,
> let me refine my original statement: both interpreted Java and Java
compiled
> into a native executable will always be slower than a well-written C
program
> because it uses more memory and takes longer to start up and also because
the C
> programmer has (almost) complete control over the program. Of course, the
> compiler inserts standard code into the executable, but that can be
eliminated.
>

Unless you're talking about inline assembly language...

---
<previously written>
Martin Girard
In short: An automatic mechanism can never outperform an equivalent manual
one.

Mike N. Christoff
I don't know... It sounds intuitively correct, but empirical evidence is
empirical evidence. If you can find some flaw in the tests or testing
methodology I'd be more than happy to hear about it.

Martin Girard
It's more than just *intuitively* correct. It has a lot to do with the fact
that an automatic mechanism is foreign to the application itself and need to
rely on guesses and assumptions, whereas a programmer can eliminate them by
doing things manually.

Mike N. Christoff
Flexibility is good, but flexibility in terms of optimizing C++ code does
not always translate into what needs to be optimized on the machine code
level. Programmers may think what they are doing is optimizing but often do
not consider how that code will be translated into cpu instructions whose
performance depends on things like caches, number of cpu registers, fpu
performance, cpu extensions like mmx, sse1 and sse2 etc... As low level as
C++ is compared to Java it is still a high-level language. With regard to
assembly language, I totally agree with your flexibility argument.
</>
---

Java vs C and C++
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Again, as per usual, people making negative comments about this do not seem
to have read the whole article. If you can point out flaws in the
benchmarks, the ACM papers, or in the methodology then please do so. Also,
if you can find flaws in the arguments used (ie: like that memory locality
achieved by gc can be better for performance vs hand-coded memory management
because it is able to keep more data in hardware caches. (See from the
article: "perl was one of several programs that ran faster when converted to
use a garbage collector..."). How the 'freedom/control' allowed by pointer
arithmetic actually makes many machine code optimizations that are simple in
Java infeasible in C/C++, etc...).

Some papers...

K. Reinholtz
Java will be faster than C++
ACM Sigplan Notices, 35(2) 25-28 Feb 2000.

Benjamin Zorn
The Measured Cost of Conservative Garbage Collection Software
Practice and Experience 1992.

l8r, Mike N. Christoff

java-programmer >> JTK - Care to comment on this? Lonewackodotcom wrote:
>
> For instance, compare how long one of your MASM programs (for instance
> BootSave/BootRest) take to startup and execute. Then write the same program in
> Java and compile it with a native compiler. The MASM version will always be
> faster and use less memory.
>

Not necessarily. Some CPU are becoming too complicated to generate
optimal code by hand unless the task is trivial. This may well get worse
in future. Of course if you have unlimited time to write your assembler
code then go for it, but most of us have better things to do with our time.

Mark Thornton

java-programmer >> JTK - Care to comment on this? On Tue, 15 Jun 2004 19:44:07 +0100, Mark Thornton
<email***@***.com> wrote or quoted :

>Not necessarily. Some CPU are becoming too complicated to generate
>optimal code by hand unless the task is trivial. This may well get worse
>in future. Of course if you have unlimited time to write your assembler
>code then go for it, but most of us have better things to do with our time.

On the other hand, writing code in assembler invests X dollars. How
long does it take to recoup it when cpu cycles and RAM are so cheap?

It really only pays now for methods used very frequently and very
widely.

Not even OS's have that much assembler in them any more.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

java-programmer >> JTK - Care to comment on this? In comp.lang.java.advocacy, Roedy Green
<email***@***.com>
wrote
on Tue, 15 Jun 2004 00:47:01 GMT
<email***@***.com>:
> On 14 Jun 2004 21:37:03 GMT, email***@***.com
> (Lonewackodotcom) wrote or quoted :
>
>> Java will always be slower than a
>>well-written C program because it uses more memory and takes longer to start
>>up.
>
> Not so any more. The reason java is slow to start is it has to load
> classes. If you statically compile so all classes are already loaded
> you start up just as smartly as C. You can further use DLLs to keep
> the standard classes loaded most of the time further speeding startup.
>
> See http://mindprod.com/jgloss/nativecompiler.html
> http://mindprod.com/jgloss/jet.html
>

Erm...Pedant Point. Loading a DLL can be as bad as loading a class.
I'd have to benchmark it, though, to get a good comparison, but
a typical code load sequence is as follows:

- open file
- read header from file
- determine size of file
- call mmap()
- create process and run
- process faults in pages, loading the file

If DLLs are involved the sequence is similar; each DLL has a header
and the pages fault in as the program runs -- PC needs a page?
Fault it in if it's not already in.

Java's sequence may involve reading the entire file (I'm not sure
if Java calls mmap() during classload, or not) but the problem
appears extremely similar at this level. Whether it continues
to be similar is not clear; one issue for instance is address
fixup resolution.

Unfortunately for Java jar files involve decompression.
I don't know which wins, the decompression size (which
means fewer pages are read from disk) or the decompression
CPU load (which means they need to be processed more
before actual use). There's also the issue that a jar
file may have to be read in its entirety to be properly
processed -- which is a bit of a benchmark-killer, AFAICT,
if it's not already in memory (e.g., Linux and (AFAIK)
NT keep pages from a file in memory if they're not more
urgently needed by running programs).

And then there's Java's VM/JIT system.

All in all, an interesting comparison.

--
#191, email***@***.com
It's still legal to go .sigless.

java-programmer >> JTK - Care to comment on this? >Of course, the
>> compiler inserts standard code into the executable, but that can be
>eliminated.
>>
>
>Unless you're talking about inline assembly language...

I was referring to the answer to this question:
http://groups.google.com/groups?selm=BNSA6.17706%24IJ1.1393239%40bgtnsc05-
news.ops.worldnet.att.net

as well as other boilerplate code the development system inserts behind your
back.

-- The Lonewacko Blog
http://lonewacko.com/blog

java-programmer >> JTK - Care to comment on this? >Lonewackodotcom wrote:
>>
>> For instance, compare how long one of your MASM programs (for instance
>> BootSave/BootRest) take to startup and execute. Then write the same program
>in
>> Java and compile it with a native compiler. The MASM version will always be
>> faster and use less memory.
>>
>
>Not necessarily. Some CPU are becoming too complicated to generate
>optimal code by hand unless the task is trivial. This may well get worse
>in future. Of course if you have unlimited time to write your assembler
>code then go for it, but most of us have better things to do with our time

Those MASM apps are about 30k. As in 30,000 bytes. How much RAM does any Java
app - whether interpreted or compiled to native code - take? On a Java CPU the
Java might be faster or similar, but loading all that stuff takes lots of time
under a regular CPU. Of course there are tradeoffs and I'd tend to prefer Java
to other things, however at the same time one has to be intellectually honest
about Java rather than saying it's always or almost always the best thing since
sliced bread.

-- The Lonewacko Blog
http://lonewacko.com/blog

java-programmer >> JTK - Care to comment on this?
"Lonewackodotcom" <email***@***.com> wrote in message
news:email***@***.com...
> >Lonewackodotcom wrote:
> >>
> >> For instance, compare how long one of your MASM programs (for instance
> >> BootSave/BootRest) take to startup and execute. Then write the same
program
> >in
> >> Java and compile it with a native compiler. The MASM version will
always be
> >> faster and use less memory.
> >>
> >
> >Not necessarily. Some CPU are becoming too complicated to generate
> >optimal code by hand unless the task is trivial. This may well get worse
> >in future. Of course if you have unlimited time to write your assembler
> >code then go for it, but most of us have better things to do with our
time
>
> Those MASM apps are about 30k. As in 30,000 bytes. How much RAM does any
Java
> app - whether interpreted or compiled to native code - take? On a Java CPU
the
> Java might be faster or similar, but loading all that stuff takes lots of
time
> under a regular CPU. Of course there are tradeoffs and I'd tend to prefer
Java
> to other things, however at the same time one has to be intellectually
honest
> about Java rather than saying it's always or almost always the best thing
since
> sliced bread.
>

That's true, however even in the link I posted, Java does not win every
benchmark. C is faster in many of the tests, and in some by a signifigant
margin at that. However, my point about relative performance of A vs B not
always being a case of A > B for all conceivable tasks and inputs (or B > A)
applies.

l8r, Mike N. Christoff

java-programmer >> JTK - Care to comment on this?
"Lonewackodotcom" <email***@***.com> wrote in message
news:email***@***.com...
> >Lonewackodotcom wrote:
> >>
> >> For instance, compare how long one of your MASM programs (for instance
> >> BootSave/BootRest) take to startup and execute. Then write the same
program
> >in
> >> Java and compile it with a native compiler. The MASM version will
always be
> >> faster and use less memory.
> >>
> >
> >Not necessarily. Some CPU are becoming too complicated to generate
> >optimal code by hand unless the task is trivial. This may well get worse
> >in future. Of course if you have unlimited time to write your assembler
> >code then go for it, but most of us have better things to do with our
time
>
> Those MASM apps are about 30k. As in 30,000 bytes. How much RAM does any
Java
> app - whether interpreted or compiled to native code - take? On a Java CPU
the
> Java might be faster or similar, but loading all that stuff takes lots of
time
> under a regular CPU. Of course there are tradeoffs and I'd tend to prefer
Java
> to other things, however at the same time one has to be intellectually
honest
> about Java rather than saying it's always or almost always the best thing
since
> sliced bread.
>

btw - I can understand people being wary of memory usage (disk or ram
memory). I remember being shocked, after starting out in x86 assembler
language and using interrupts to print text to the screen, how my first C
program (which did nothing but print 'hello, world') compiled to over 1K on
disk. The equivalent asm program was under 100 _bytes_.

l8r, Mike N. Christoff

java-programmer >> JTK - Care to comment on this? >Would you kindly stop changing your phony id. I am tired of listening
>to you and I am getting pissed with you messing with my killfile.

Well, I never!

I certainly hope you think this is JTK, because otherwise I am deeply offended!

Here's a hint to my identity:
http://groups.google.com/groups?q=group%3Acomp.lang.java.advocacy+%22chris
+kelly%22&ie=UTF-8&hl=en

I use AOL because it's free. That means I can't use Agent and am thus forced to
use AOL's newsreader.

Now, let's turn this into a long discussion about Gary Sickle.

-- The Lonewacko Blog
http://lonewacko.com/blog

java-programmer >> JTK - Care to comment on this? On 14 Jun 2004 21:37:03 GMT, email***@***.com
(Lonewackodotcom) wrote or quoted :

>But, when
>it comes to client apps and applets, Java will always be slower than a
>well-written C program because it uses more memory and takes longer to start
>up.

There are two "its" starting up. -- the JVM and the Applet itself.

The first time you use an Applet in each session you have to load the
JVM, which takes a fair hunk of time. Then the Applet itself has to
start which is pretty quick since class files are so small and the
jars are compressed.

There are many things that Sun could do to start up the JVM faster.

See http://mindprod.com/projects/gespenster.html
and
http://mindprod.com/projects/suspendedanimation.html

However, Sun don't seem that interested. They are focusing on server
side where startup time is almost irrelevant.

Perhaps an Echidna approach could be used to share a single JVM
between browser and desktop for simple utilities and Applets.

http://mindprod.com/jgloss/echidna.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.