Comments on "Sun's Java Compiler Falters" article?
Scott Raney
This week's InformationWeek has an article (buried way in the back, pg
136 of the Sept 16 issue) that basically states that Sun's Java
compiler is not usable because it's too slow, and that it's too slow
because it's written in Java. Now the basic test of any system-level
programming language compiler is that you can write the compiler in
the language and compile it with the compiler.
Does this mean that Java is too slow to do system-level programming
in? If so, doesn't this put the kibosh on the whole idea of using
Java as a language for development components with?
Are the other vendor's compilers written in C or C++?
--
***************************************************************
Scott Raney ra...@metacard.com http://www.metacard.com
Tcl and ksh: syntactic gymnastics
MetaCard: it does what you think
Lewis Stiller
No. Slow compiler speed is not really a problem in a Java environment,
or at least not a serious one, in contradistinction to the case for C
and C++, in which environments a slow compiler is very annoying.
The reason slow compilation is not a problem in a Java environment is
that Java does not have lots of static code depencies, such as nested
header files. When one makes a change to a source file in Java,
typically only that one file needs to be recompiled. There are none of
the long "compile-link" waits that you have to put up with when you
change some prototype in a C header file. (By the way, in many systems
much of the wait for "compile-time" in C environments is really a wait
for linking, particularly in NFS, but I digress).
For example, I personally place all code for each class in its own file.
Then when I want to change one class, only one file needs to be
recompiled. A small file.
I am not defending Java or the JDK here. I could certainly ramble on for
hours about ways in which I would improve the JDK if I had some free
time. However, complaints about slow compilation speed are mostly an
artifact of the way C/C++ coders are used to using compilers. In
addition, it is true that there are certain applications that do benefit
from very fast compilation but, nonetheless, I believe speeding up
compilation times should be a low-priority task for Sun and has minimal
effect on most programmers.
--
Lewis Stiller sti...@symmetry.cs.berkeley.edu
Alexander Anderson
In article <3242DE0C...@metacard.com>, Scott Raney
<ra...@metacard.com> writes
>This week's InformationWeek has an article (buried way in the back, pg
>136 of the Sept 16 issue) that basically states that Sun's Java
>compiler is not usable because it's too slow, and that it's too slow
>because it's written in Java. Now the basic test of any system-level
>programming language compiler is that you can write the compiler in
>the language and compile it with the compiler.
>
>Does this mean that Java is too slow to do system-level programming
>in? If so, doesn't this put the kibosh on the whole idea of using
>Java as a language for development components with?
>
>Are the other vendor's compilers written in C or C++?
No. No. And some are.
Sun's compiler is a proof of concept as far as I see it. Just like
the original HotJava was a vehicule to show possibilities, and show
people what Java could do.
Sun's "Java" is nothing to do with their particular java compiler.
Their JDK 1.0.2 is a bit like the first Prolog interpreter:
"We have the technology."
Sandy
--
// Alexander Anderson Computer Systems Student //
// sa...@almide.demon.co.uk Middlesex University //
// Home Fone: +44 (0) 171-794-4543 Bounds Green //
// http://www.mdx.ac.uk/~alexander9 London U.K. //
Franklin Schmidt
Scott Raney wrote:
>
> This week's InformationWeek has an article (buried way in the back, pg
> 136 of the Sept 16 issue) that basically states that Sun's Java
> compiler is not usable because it's too slow, and that it's too slow
> because it's written in Java. Now the basic test of any system-level
> programming language compiler is that you can write the compiler in
> the language and compile it with the compiler.
Sun's compiler just compiles to intermediate code for the Java Virtual
Machine. This, then, is either interpreted or compiled to native code
by a JIT (Just In Time) compiler. The problem is that Sun has no JIT
compiler. Therefor it's regular compiler is interpreted, and therefor
it is slow. I think Sun's Java compiler would perform just fine if run
with a JIT compiler.
Jonathan Locke
Scott Raney wrote:
>
> This week's InformationWeek has an article (buried way in the back, pg
> 136 of the Sept 16 issue) that basically states that Sun's Java
> compiler is not usable because it's too slow, and that it's too slow
> because it's written in Java. Now the basic test of any system-level
> programming language compiler is that you can write the compiler in
> the language and compile it with the compiler.
>
> in? If so, doesn't this put the kibosh on the whole idea of using
> Java as a language for development components with?
>
> Are the other vendor's compilers written in C or C++?
>
> ***************************************************************
> Scott Raney ra...@metacard.com http://www.metacard.com
> Tcl and ksh: syntactic gymnastics
> MetaCard: it does what you think
There are many good reasons to expect equal or, in some cases, *better*
performance from Java programs than from C/C++ programs. Some of the
better JITs and Asymetrix' Supercede are the first baby steps in this
direction, but they are a *LONG* way from the limits of what can be
done. Just be patient... we'll get there.
J
/**
* Contract Java programmer at large (Jo...@SealevelSoftware.com)
* @param codeSpecifications Your project requirements.
* @return High quality, well documented Java code.
* @see SealevelSoftware at http://www.sealevelsoftware.com/sealevel/
*/
public JavaCode Jonathan_Locke(String codeSpecifications) { /*
Undocumented algorithm... ;-) */ }
Franklin Schmidt
Reposting article removed by rogue canceller.
Scott Raney wrote:
>
> This week's InformationWeek has an article (buried way in the back, pg
> 136 of the Sept 16 issue) that basically states that Sun's Java
> compiler is not usable because it's too slow, and that it's too slow
> because it's written in Java. Now the basic test of any system-level
> programming language compiler is that you can write the compiler in
> the language and compile it with the compiler.
Sun's compiler just compiles to intermediate code for the Java Virtual
Hank Shiffman
You would be wrong. According to figures I've heard, javac spends just
55% of its time executing interpreted code. The rest is in the Java
runtime, which is already native. So the best JIT compiler in the
world will reduce compilation time by 50%. That's not bad but it isn't
the Holy Grail either.
It will take a serious rewrite of the runtime libraries to get much of
an improvement in the compiler. One problem that probably won't get
fixed is that the runtimes are all thread-safe. That's necessary for
multithreaded Java applets and applications but unnecessary overhead
for single threaded programs like compilers. The only way to eliminate
that overhead is to have separate versions of the runtime for single
and multithreaded codes to use. I suspect that's a complication that
JavaSoft won't want to tackle.
--
Hank Shiffman shif...@sgi.com
Developer Evangelist phone: 415-933-2330
Silicon Graphics Computer Systems fax: 415-969-6327
SGI internal: http://slappy.engr
External: http://reality.sgi.com/shiffman
Hank Shiffman
In article <324368...@sealevelsoftware.com>, Jonathan Locke <jo...@sealevelsoftware.com> writes:
>
> There are many good reasons to expect equal or, in some cases, *better*
> performance from Java programs than from C/C++ programs.
And many reasons to believe that this will never be achieved for the
vast majority of applications. I have a writeup on some of these at
http://reality.sgi.com/shiffman/Java-QA.html
Of course, that doesn't mean that Java's performance won't get close
*enough* for most tasks for which it's appropriate. But equal to or
faster than C++? I don't think so.
Jonathan Locke
I hope you will read my counter-arguments with an open mind, because I
think you (and many others) have missed some very important and
interesting points by focusing too narrowly on low-level language
mechanics. The biggest performance benefits will come from from higher
ground.
Here are the titles of the core arguments from your web page and my
response-to/view-of each:
Reliance on pointers for objects:
In a pure sense you are absolutely right about this one. It's difficult
or impossible to argue that heaps will beat stacks for speed. However,
I think some smart tuning can make this a bit better than it is now.
Also, application of some simple theorem proving at class load time (or
even after that) might enable the class verifier to substitute
instructions for more stack-like behaviour of heap allocations which can
be shown to be properly scoped. Still, I'll give you a small, but
presently significant advantage here.
Garbage collection:
Again, you win this one, but I think the margin of victory is less than
you think. Optimization via special purpose heaps is definitely
possible within VMs for common-sized objects (which is the main reason
that people write special purpose memory allocators). And there's
nothing to prevent you from doing something smart with your own Java
object management. Yes, I agree, there are more interesting collection
algorithms that might be applied someday. Overall, this is probably
Java's weakest spot - especially for performance hungry apps. However,
there may be more to this story in the not-too-distant future. It seems
more than likely that memory allocation and garbage collection will end
up in hardware.
Run time method selection:
Yes, there is a small price to pay here too. But the price is quite
small indeed, and rather reminds me of the arguments we all got into
about the value of vtables when C++ was new and being compared to C.
Insistence on object orientation:
I think there are definitely some good counter-arguments here.
Dynamic-inlining (perhaps even based on run-time profiling information!)
might actually land Java *significantly* ahead of C++ here and in much
better standing in terms of code logic/structure. But more importantly,
better object oriented design often results in better code. Fewer
repetitions of the same idioms will result in less code bloat (something
that C++ suffers from enormously, especially on RISC systems). This,
in combination with Java's more space efficient bytecoding, will mean
less disk thrashing (BTW, if you've forgotten about the problems with
C++ code bloat, go start up Microsoft Word and then come back ;-)).
Since the disk is the SLOWEST thing on your system, even a small win in
the area of swap tuning could be a *very* significant win for Java over
C++. I think your mistake here is that you are extrapolating the
performance of small systems linearly to the performance of large
systems! It usually doesn't work that way, and I think Java will
ultimately come out ahead here.
A secondary, but INCREDIBLY important consideration that you have
overlooked is that Java's strength in object orientation will promote
more code reuse than has been practical or possible in C++. The upshot
of this is that some of the goals of the O-O revolution will finally be
realized -- the *smart* people will write more of the stuff that gets
reused, allowing those of us who are... uhh... less inclined... to take
advantage of the experience of other, better code writers! Having
worked on a couple dozen products by now and having seen some of the
most god-awful code you'd ever imagine, I can tell you that any
improvement in code reuse will definitely have tremendous performance
benefits!
Thread-safety:
Yup. Your base argument is good. But the ease of threading and
thread-safety may give Java significant practical advantages that will
make Java applications more responsive and often faster (due to more use
of pre-computation during idle times), simply because it's so easy to
multithread them. Also, we aren't absolutely stuck with any particular
set of class libraries in Java. I don't see any reason why
non-threadsafe versions of these libraries couldn't be made available
for certain special purposes. In fact, I don't see why you couldn't
just rebuild the class libraries with fewer synchronized keywords right
now!
JIT translation has to be fast:
I understand what you are saying here, but you have made a very
important assumption here that I feel is just flat out wrong. You
assume that compilation/optimization has to end at class-load time. I
don't agree. Dynamic-optimization techniques will be applied here to
spread out the impact of code optimization/compilation over the lifetime
of the application. The longer you run the app (especially in any kind
of UI idle), the faster it will get. In fact, who says that
compilation/optimization has to be a one shot deal that is discarded
when you shut down the app? That code can be cached. The
compiler/optimizer can then pick up where it left off the next time you
run the app! Or along a different tack, the *VAST* majority of your
computer's CPU time is COMPLETELY WASTED! If you leave your computer on
at lunch or while you sleep, why can't that CPU spend all it's time
doing dramatic global optimizations on your code instead of just sitting
there like a log!? There are probably a variety of
aggressive/experimental code-optimizations that can't be used for
practical reasons (they take too long because they look too many
"search-plies" ahead) right now. But with Java bytecoding, we can apply
those radical transformations during what used to be "idle time"! No, I
think you are way off the mark here. Simply by being what amounts to a
compiler intermediate representation, Java bytecode opens up a whole
host of TREMENDOUS opportunities for optimization. An arbitrarily
complex compiler back-end can sit on your machine and work all sorts of
miracles that we've only just begun to dream up. In short, the static,
hardwired compilation of C++ to native machine code is, ironically, a
tremendous practical DISADVANTAGE to optimization!
I essentially agree with your conclusions about market driving forces.
One more real-world practical advantage is at work here... The
existence of Java bytecodes permits more mindpower to be focused on
optimization technologies than is possible with C++. ie., because C++
targets such a wide variety of native platforms, the effort to optimize
(building compiler "backends") is fragmented. By simplifiying and
focusing the optimization problem I think we will come up with more
interesting and better solutions.
I hope that I have at least partly changed your mind about this!
Scott Raney
Alexander Anderson wrote:
>
> In article <3242DE0C...@metacard.com>, Scott Raney
> <ra...@metacard.com> writes
>
> >136 of the Sept 16 issue) that basically states that Sun's Java
> >compiler is not usable because it's too slow, and that it's too slow
> >because it's written in Java. Now the basic test of any system-level
> >programming language compiler is that you can write the compiler in
> >the language and compile it with the compiler.
> >
> >in? If so, doesn't this put the kibosh on the whole idea of using
> >Java as a language for development components with?
> >
> >Are the other vendor's compilers written in C or C++?
>
All are, near as I can tell.
> Sun's compiler is a proof of concept as far as I see it. Just like
> the original HotJava was a vehicule to show possibilities, and show
> people what Java could do.
>
> Sun's "Java" is nothing to do with their particular java compiler.
That was my point: the language *itself* is what is not appropriate
for system software development. No amount of rearchitecting the
compiler will overcome this limitation.
> Their JDK 1.0.2 is a bit like the first Prolog interpreter:
Wow, talk about damning with faint praise!
> "We have the technology."
>
> Sandy
> --
> // Alexander Anderson Computer Systems Student //
> // sa...@almide.demon.co.uk Middlesex University //
> // Home Fone: +44 (0) 171-794-4543 Bounds Green //
> // http://www.mdx.ac.uk/~alexander9 London U.K. //
--
Scott Raney
Lewis Stiller wrote:
>
> No. Slow compiler speed is not really a problem in a Java environment,
> or at least not a serious one, in contradistinction to the case for C
> and C++, in which environments a slow compiler is very annoying.
>
> The reason slow compilation is not a problem in a Java environment is
> that Java does not have lots of static code depencies, such as nested
> header files. When one makes a change to a source file in Java,
> typically only that one file needs to be recompiled. There are none of
> the long "compile-link" waits that you have to put up with when you
> change some prototype in a C header file. (By the way, in many systems
> much of the wait for "compile-time" in C environments is really a wait
> for linking, particularly in NFS, but I digress).
>
> For example, I personally place all code for each class in its own file.
> Then when I want to change one class, only one file needs to be
> recompiled. A small file.
>
> I am not defending Java or the JDK here. I could certainly ramble on for
> hours about ways in which I would improve the JDK if I had some free
> time. However, complaints about slow compilation speed are mostly an
> artifact of the way C/C++ coders are used to using compilers. In
> addition, it is true that there are certain applications that do benefit
> from very fast compilation but, nonetheless, I believe speeding up
> compilation times should be a low-priority task for Sun and has minimal
> effect on most programmers.
I agree with your assessment, but it certainly begs the question:
If compiler performance isn't important, why did Sun pull their
Java-based Java compiler and start looking for one written in C or
C++? Maybe the problem is worse than you think...
> --
> Lewis Stiller sti...@symmetry.cs.berkeley.edu
Scott Raney
Franklin Schmidt wrote:
>
> Scott Raney wrote:
> >
> > This week's InformationWeek has an article (buried way in the back, pg
> > 136 of the Sept 16 issue) that basically states that Sun's Java
> > compiler is not usable because it's too slow, and that it's too slow
> > because it's written in Java. Now the basic test of any system-level
> > programming language compiler is that you can write the compiler in
> > the language and compile it with the compiler.
>
> Machine. This, then, is either interpreted or compiled to native code
> by a JIT (Just In Time) compiler. The problem is that Sun has no JIT
> compiler. Therefor it's regular compiler is interpreted, and therefor
> it is slow. I think Sun's Java compiler would perform just fine if run
> with a JIT compiler.
No, you missed the point of the article, which was *about* a JIT
compiler. Even with a JIT compiler, the JIT compiler was too slow
to be usable. So, your faith in JIT technology is apparently
misplaced...
Scott
Scott Raney
Jonathan Locke wrote:
>
> Scott Raney wrote:
> >
> > This week's InformationWeek has an article (buried way in the back, pg
> > 136 of the Sept 16 issue) that basically states that Sun's Java
> > compiler is not usable because it's too slow, and that it's too slow
> > because it's written in Java. Now the basic test of any system-level
> > programming language compiler is that you can write the compiler in
> > the language and compile it with the compiler.
> >
> > in? If so, doesn't this put the kibosh on the whole idea of using
> > Java as a language for development components with?
> >
> >
> > --
> > ***************************************************************
> > Scott Raney ra...@metacard.com http://www.metacard.com
> > Tcl and ksh: syntactic gymnastics
> > MetaCard: it does what you think
>
> performance from Java programs than from C/C++ programs.
Really? Name one.
Garbage collection? Bzzzt, thanks for playing...
Array bounds checking? Guess again...
Stack based p-code? Not in a register-based world...
No pointers or raw memory allocation? Not a chance...
> Some of the
> better JITs and Asymetrix' Supercede are the first baby steps in this
> direction, but they are a *LONG* way from the limits of what can be
> done. Just be patient... we'll get there.
Spoken like a true zealot: Damn the facts! We shall overcome!
Note that I have nothing against the technologies used in Java,
just in the uncritical acceptance of the language as a replacement
for C or C++. Java seems to combine the worst of both worlds:
the low level, low productivity develoment of C and C++, with the
relatively poor performance of scripting languages (Perl, Tcl).
If developing in Java were anywhere near as productive as
developing in these high-level languages it would be worth paying
the performance penalty. Unfortunately, it isn't.
Scott
> J
>
> /**
> * Contract Java programmer at large (Jo...@SealevelSoftware.com)
> * @param codeSpecifications Your project requirements.
> * @return High quality, well documented Java code.
> * @see SealevelSoftware at http://www.sealevelsoftware.com/sealevel/
> */
> public JavaCode Jonathan_Locke(String codeSpecifications) { /*
> Undocumented algorithm... ;-) */ }
--
Jonathan Locke
See my response from earlier today for the long-winded version of my
argument. Basically though, I think you too are making the mistake of
focusing in on low level mechanics at the expense of ignoring a rather
large set of high level issues that are equally, if not more important.
Yes, at the micro level, in simple test cases, C/C++ has and will
probably always have Java beat. And low-level device drivers in C/C++
will always make more sense. But I have to disagree with you if you
think that this performance advantage in low-level mechanics will scale
linearly in the real world. I think a lot of *applications* written in
Java will eventually outperform those written in C/C++ for all the
reasons I listed in that other posting (I can repost that if you can't
find it).
> > Some of the
> > better JITs and Asymetrix' Supercede are the first baby steps in this
> > direction, but they are a *LONG* way from the limits of what can be
> > done. Just be patient... we'll get there.
>
> Spoken like a true zealot: Damn the facts! We shall overcome!
Perhaps so, but I have reasons for thinking these things having spent a
lot of time thinking about them, and if I may say so, you speak like
someone who is entrenched in the past and cannot think beyond
yesterday's problems and minutae.
>
> Note that I have nothing against the technologies used in Java,
> just in the uncritical acceptance of the language as a replacement
> for C or C++. Java seems to combine the worst of both worlds:
Right. I agree. For example, there aren't a lot of good reasons to
write low-level device drivers in Java. That should rightfully stay the
territory of C/C++/Assembly.
> the low level, low productivity develoment of C and C++, with the
Oh please... you haven't actually done any Java development have you?
Java is easily an order of magnitude more productive that C/C++. I have
(quite literally) spent zero time in the last N months debugging out of
control programs. A few *logic* problems here and there, but I
seriously doubt you could say the same for C/C++. Every time I talk to
one of my friends who is still doing C/C++ they are always complaining
endlessly about memory smashes, stack corruption, COM reference counting
problems, portability problems, endlessly repeated code idioms, disk
thrashing and swap tuning etc. No, I think you're *way* off the mark
here.
> relatively poor performance of scripting languages (Perl, Tcl).
That's crap too. Especially the comparison with Tcl.
> If developing in Java were anywhere near as productive as
> developing in these high-level languages it would be worth paying
> the performance penalty. Unfortunately, it isn't.
Personally, I think you still haven't unzipped your JDK. ;-)
Scott Raney
Reposting article removed by rogue canceller.
Franklin Schmidt wrote:
>
> Scott Raney wrote:
> >
> > This week's InformationWeek has an article (buried way in the back, pg
> > 136 of the Sept 16 issue) that basically states that Sun's Java
> > compiler is not usable because it's too slow, and that it's too slow
> > because it's written in Java. Now the basic test of any system-level
> > programming language compiler is that you can write the compiler in
> > the language and compile it with the compiler.
>
> Sun's compiler just compiles to intermediate code for the Java Virtual
> Machine. This, then, is either interpreted or compiled to native code
> by a JIT (Just In Time) compiler. The problem is that Sun has no JIT
> compiler. Therefor it's regular compiler is interpreted, and therefor
> it is slow. I think Sun's Java compiler would perform just fine if run
> with a JIT compiler.
No, you missed the point of the article, which was *about* a JIT
compiler. Even with a JIT compiler, the JIT compiler was too slow
to be usable. So, your faith in JIT technology is apparently
misplaced...
Scott
--
Hank Shiffman
Reposting article removed by rogue canceller.
In article <324368...@sealevelsoftware.com>, Jonathan Locke <jo...@sealevelsoftware.com> writes:
>
> There are many good reasons to expect equal or, in some cases, *better*
> performance from Java programs than from C/C++ programs.
And many reasons to believe that this will never be achieved for the
Jonathan Locke
Reposting article removed by rogue canceller.
Scott Raney wrote:
>
> Jonathan Locke wrote:
> >
> > Scott Raney wrote:
> > >
> > > This week's InformationWeek has an article (buried way in the back, pg
> > > 136 of the Sept 16 issue) that basically states that Sun's Java
> > > compiler is not usable because it's too slow, and that it's too slow
> > > because it's written in Java. Now the basic test of any system-level
> > > programming language compiler is that you can write the compiler in
> > > the language and compile it with the compiler.
> > >
> > > Does this mean that Java is too slow to do system-level programming
> > > in? If so, doesn't this put the kibosh on the whole idea of using
> > > Java as a language for development components with?
> > >
> > > Are the other vendor's compilers written in C or C++?
> > >
> > > --
> > > ***************************************************************
> > > Scott Raney ra...@metacard.com http://www.metacard.com
> > > Tcl and ksh: syntactic gymnastics
> > > MetaCard: it does what you think
> >
> > There are many good reasons to expect equal or, in some cases, *better*
> > performance from Java programs than from C/C++ programs.
>
> --
> ***************************************************************
> Scott Raney ra...@metacard.com http://www.metacard.com
> Tcl and ksh: syntactic gymnastics
> MetaCard: it does what you think
Jonathan Locke
Reposting article removed by rogue canceller.
Hank Shiffman wrote:
>
> In article <324368...@sealevelsoftware.com>, Jonathan Locke <jo...@sealevelsoftware.com> writes:
> >
> > There are many good reasons to expect equal or, in some cases, *better*
> > performance from Java programs than from C/C++ programs.
>
> And many reasons to believe that this will never be achieved for the
> vast majority of applications. I have a writeup on some of these at
>
> http://reality.sgi.com/shiffman/Java-QA.html
>
> Of course, that doesn't mean that Java's performance won't get close
> *enough* for most tasks for which it's appropriate. But equal to or
> faster than C++? I don't think so.
>
> --
> Hank Shiffman shif...@sgi.com
> Developer Evangelist phone: 415-933-2330
> Silicon Graphics Computer Systems fax: 415-969-6327
>
> SGI internal: http://slappy.engr
> External: http://reality.sgi.com/shiffman
I hope you will read my counter-arguments with an open mind, because I
Garbage collection:
Run time method selection:
Insistence on object orientation:
Thread-safety:
J
Hank Shiffman
Reposting article removed by rogue canceller.
In article <32432E...@gustos.com>, Franklin Schmidt <f...@gustos.com> writes:
> Scott Raney wrote:
> >
> > This week's InformationWeek has an article (buried way in the back, pg
> > 136 of the Sept 16 issue) that basically states that Sun's Java
> > compiler is not usable because it's too slow, and that it's too slow
> > because it's written in Java. Now the basic test of any system-level
> > programming language compiler is that you can write the compiler in
> > the language and compile it with the compiler.
>
> Sun's compiler just compiles to intermediate code for the Java Virtual
> Machine. This, then, is either interpreted or compiled to native code
> by a JIT (Just In Time) compiler. The problem is that Sun has no JIT
> compiler. Therefor it's regular compiler is interpreted, and therefor
> it is slow. I think Sun's Java compiler would perform just fine if run
> with a JIT compiler.
You would be wrong. According to figures I've heard, javac spends just
55% of its time executing interpreted code. The rest is in the Java
runtime, which is already native. So the best JIT compiler in the
world will reduce compilation time by 50%. That's not bad but it isn't
the Holy Grail either.
It will take a serious rewrite of the runtime libraries to get much of
an improvement in the compiler. One problem that probably won't get
fixed is that the runtimes are all thread-safe. That's necessary for
multithreaded Java applets and applications but unnecessary overhead
for single threaded programs like compilers. The only way to eliminate
that overhead is to have separate versions of the runtime for single
and multithreaded codes to use. I suspect that's a complication that
JavaSoft won't want to tackle.
--
Scott Raney
Reposting article removed by rogue canceller.
Alexander Anderson wrote:
>
> In article <3242DE0C...@metacard.com>, Scott Raney
> <ra...@metacard.com> writes
>
> >This week's InformationWeek has an article (buried way in the back, pg
> >136 of the Sept 16 issue) that basically states that Sun's Java
> >compiler is not usable because it's too slow, and that it's too slow
> >because it's written in Java. Now the basic test of any system-level
> >programming language compiler is that you can write the compiler in
> >the language and compile it with the compiler.
> >
> >Does this mean that Java is too slow to do system-level programming
> >in? If so, doesn't this put the kibosh on the whole idea of using
> >Java as a language for development components with?
> >
> >Are the other vendor's compilers written in C or C++?
>
> No. No. And some are.
All are, near as I can tell.
> Sun's compiler is a proof of concept as far as I see it. Just like
> the original HotJava was a vehicule to show possibilities, and show
> people what Java could do.
>
> Sun's "Java" is nothing to do with their particular java compiler.
That was my point: the language *itself* is what is not appropriate
for system software development. No amount of rearchitecting the
compiler will overcome this limitation.
> Their JDK 1.0.2 is a bit like the first Prolog interpreter:
Wow, talk about damning with faint praise!
> "We have the technology."
>
> Sandy
> --
> // Alexander Anderson Computer Systems Student //
> // sa...@almide.demon.co.uk Middlesex University //
> // Home Fone: +44 (0) 171-794-4543 Bounds Green //
> // http://www.mdx.ac.uk/~alexander9 London U.K. //
--
Scott Raney
Reposting article removed by rogue canceller.
Lewis Stiller wrote:
> --
> Lewis Stiller sti...@symmetry.cs.berkeley.edu
--
Alexander Anderson
In article <324472C5...@metacard.com>, Scott Raney
<ra...@metacard.com> writes
>That was my point: the language *itself* is what is not appropriate
>for system software development. No amount of rearchitecting the
>compiler will overcome this limitation.
>
>> Their JDK 1.0.2 is a bit like the first Prolog interpreter:
>
>Wow, talk about damning with faint praise!
I think your point is wrong.
I do not understand what you mean by damning with faint praise.
Today, declarative programming with Prolog on parallel architectures
is staggeringly powerful.
An extract from the Foreword to "The Art of Prolog" is
instructional:
------------------------------------------------------------------snip--
I shall never forget my first Prolog program. The time was early
1974. I had learned about the abstract idea of logic programming from
Bob Kowalski at Edinburgh, although the name "logic programming" had not
yet been coined. The main idea was that deduction could be viewed as a
form of computation, and that a declarative statement of the form
P if Q and R and S.
could be interpreted procedurally as
To solve P, solve Q and R and S.
Now I had been invited to Marseilles. Here, Alain Colmerauer and his
collegues had devised the language Prolog based on the logic programming
concept. Somehow, this realization of the concept seemed to me, at
first sight, too simpleminded. However, Gerard Battani and Henri Meloni
had implemented a Prolog interpreter in Fortran (their first major
exercise in programming, incidentally). Why not give Prolog a try?
I sat at a clattering teletype connected down an ordinary telephone
line to an IBM machine far away in Grenoble. I typed in some rules
defining how plans could be constructed as sequences of actions. There
was one important rule, modeled on the SRI planner Strips, which
described how a plan could be elaborated by adding an action at the end.
Another rule, necessary for completeness, described how to elaborate a
plan by inserting an action in the middle of the plan. As an example
for the planner to work on, I typed in facts about some simple actions
in a "blocks world" and an initial state of this world. I entered a
description of a goal state to be achieved. Prolog spat back at me:
?
meaning it couldn't find a solution. Could it be that a solution was
not deducible from the axioms I had supplied? Ah, yes, I had forgotten
to enter some crucial facts. I tried again. Prolog was quiet for a
long time and then responded:
DEBORDEMENT DE PILE
Stack overflow! I had run into a loop. Now a loop was conceivable
since the space of potential plans to be considered was infinite.
However, I had taken advantage of Prolog's procedural semantics to
organize the axioms so that the shorter plans ought to be generated
first. Could something else be wrong? After a lot of head scratching,
I finally realized that I had mistyped the names of some variables. I
corrected the mistakes, and tried again.
Lo and behold, Prolog responded almost instantly with a correct plan
to achieve the goal state. Magic! Declaratively correct axioms had
assured a correct result. Deduction was being harnessed before my very
eyes to produce effective computation. Declarative programming was
truly programming on a higher plane! I had dimly seen the advantages in
theory. Now Prolog had made them vividly real in practice. Never had I
experienced such ease in getting a complex program coded and running.
Of course, I had taken care to formulate the axioms and organize
them in such a way that Prolog could use them effectively. I had a
general idea of how the axioms would be used. Nevertheless it was a
surprise to see how the axioms got used in practice on particular
examples. It was a delightful experience over the next few days to
explore how Prolog actually created these plans, to correct one or two
more bugs in my facts and rules, and to further refine the program.
Since that time, Prolog systems have improved significantly in terms
of debugging environments, speed, and general robustness. The
techniques of using Prolog have been more fully explored and are now
better understood. And logic programming has blossomed, not least
because of its adoption by the Japanese as the central focus of the
Fifth Generation project.
------------------------------------------------------------------snip--
Scott Raney
Alexander Anderson wrote:
>
> In article <324472C5...@metacard.com>, Scott Raney
> <ra...@metacard.com> writes
>
> >That was my point: the language *itself* is what is not appropriate
> >for system software development. No amount of rearchitecting the
> >compiler will overcome this limitation.
> >
> >> Their JDK 1.0.2 is a bit like the first Prolog interpreter:
> >
> >Wow, talk about damning with faint praise!
>
> I think your point is wrong.
Perhaps it was just too subtle.
> I do not understand what you mean by damning with faint praise.
Bartlett's says it's from Alexander Pope. It means to criticize
something indirectly, as in "your girlfriend is definitely better
looking than my dog".
> Today, declarative programming with Prolog on parallel architectures
> is staggeringly powerful.
Possibly, but it's also completely useless for nearly all real-world
programming needs. Java may have the same fate as its *design* is
such that it will never be able to achieve the performance necessary
to displace C or C++ for system programming projects (including
development of components for desktop applications). As was the
case with Prolog, no amout of improvement in the tools will change
this.
Scott
> An extract from the Foreword to "The Art of Prolog" is
> instructional:
(snip)
------------------------------------------------------------------snip--
>
> Sandy
> --
> // Alexander Anderson Computer Systems Student //
> // sa...@almide.demon.co.uk Middlesex University //
> // Home Fone: +44 (0) 171-794-4543 Bounds Green //
> // http://www.mdx.ac.uk/~alexander9 London U.K. //
--
Randy Chapman
Scott Raney (ra...@metacard.com) wrote:
: programming needs. Java may have the same fate as its *design* is
: such that it will never be able to achieve the performance necessary
: to displace C or C++ for system programming projects (including
: development of components for desktop applications). As was the
Really? Java as it stands *NOW* is somewhat faster than Visual Basic
(talk about daming with faint praise...). Thats not with a JIT system,
thats Sun's interpreter.
People definitely consider VB to be fast enough for developing components
of applications and in fact whole applications. Not servers, perhaps,
but certainly user-interface code.
Furhter, I fail to see how Java is, by design, slower. Being interpreted
is not by design, Java code can certainly be compiled to native code.
(Assymetrix and, I believe, Natural Intelligence have tools to do exactly
this). Null pointer checking is a zero-cost operation, so that is not an
issue (memory protection). Methods can be final, so they don't have to
suffer a virtual table lookup. And, even if they did, its faster than
the message-passing architecture MS-Windows programs have. Ditto for
how Xt-based programs work. Methods can also be inlined, so that is
also not an issue.
Garbage collection? Research says thats about a wash; tests can be made
to show either how slow it is or how fast it is relative to "manual"
memory allocation.... but in any case, it certainly *is* easier to
program with.
Really, I fail to see how Java is *not* a superb language to choose
for application development. For doing OS level work (such as device
drivers, say), some "extensions" might be needed. Most likely,just
simple things like outp, inp and an mmap-like call that returns a
byte-array that matches real memory.
--randy
Alexander Anderson
In article <3245BBF6...@metacard.com>, Scott Raney
<ra...@metacard.com> writes
>Possibly, but it's also completely useless for nearly all real-world
>programming needs
Possibly? Perhaps? "nearly"?
It's an impossible job to argue around snideness, but entire Air
Traffic Control system kernels, written in Prolog, are in use today.
The bottle is half full.
jim frost
Lewis Stiller <sti...@symmetry.CS.Berkeley.EDU> writes:
>Slow compiler speed is not really a problem in a Java environment,
>or at least not a serious one, in contradistinction to the case for C
>and C++, in which environments a slow compiler is very annoying.
>The reason slow compilation is not a problem in a Java environment is
>that Java does not have lots of static code depencies, such as nested
>header files. When one makes a change to a source file in Java,
>typically only that one file needs to be recompiled. There are none of
>the long "compile-link" waits that you have to put up with when you
>change some prototype in a C header file.
I concur. While native compilers are quite obviously faster, this
primarily affects only complete rebuilds, and I still find performance
to be within acceptable bounds -- certainly faster than most C++
environments I've used. My turnaround time is usually within five to
ten seconds per change, and is dominated by other tools (dependency
analyzer, GNU emacs compile interface). Considering that similar
sized C++ projects usually had turnaround times in the minutes for
even the smallest change, and even with incremental linkers it was in
the tens of seconds, I really have no complaints.
Faster is better, but the turnaround time is just fine. If you want
to complain about missing features, I'd look at debuggers. I haven't
seen one yet that I thought was worth anything.
jim frost
ji...@world.std.com
Harley Davis
Lewis Stiller <sti...@symmetry.CS.Berkeley.EDU> writes:
> No. Slow compiler speed is not really a problem in a Java environment,
> or at least not a serious one, in contradistinction to the case for C
> and C++, in which environments a slow compiler is very annoying.
>
> The reason slow compilation is not a problem in a Java environment is
> that Java does not have lots of static code depencies, such as nested
> header files. When one makes a change to a source file in Java,
> typically only that one file needs to be recompiled. There are none of
> the long "compile-link" waits that you have to put up with when you
> change some prototype in a C header file. (By the way, in many systems
> much of the wait for "compile-time" in C environments is really a wait
> for linking, particularly in NFS, but I digress).
I have to disagree. Java compilation speed is quite important - in
some ways *more* than in C/C++. Java has about the same amount of
static dependencies as C/C++ - unfortunately, the only way to have the
Java compiler detect them is to pass the -depend flag to javac, and
that turns an already-slow compiler into an unbearable dog. If you
don't pass the -depend flag, and you make incompatible changes in base
classes, requiring recompilation of subclasses, then you will quickly
start getting weird runtime errors and be obliged to recompile entire
class hierarchies.
The only thing the (Sun) Java compiler really has going for it is the
ability to compile several Java files at once without restarting the
compiler. This avoids reading interface descriptions multiple times,
which can be critical in those networked file environments you rightly
complain about.
I hope Sun has looked into this compilation speed issue for JDK 1.1.
-- Harley
-------------------------------------------------------------------
Harley Davis net: da...@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
James V. Reagan
Franklin Schmidt wrote:
> Sun's compiler just compiles to intermediate code for the Java Virtual
> Machine. This, then, is either interpreted or compiled to native code
> by a JIT (Just In Time) compiler. The problem is that Sun has no JIT
> compiler. Therefor it's regular compiler is interpreted, and therefor
> it is slow. I think Sun's Java compiler would perform just fine if run
> with a JIT compiler.
By the way, does anyone know the status of Sun's JIT? Will it
be out with JDK 1.1?
--
James V. Reagan 1515 E. Woodfield #860
Consulting Engineer Schaumburg, IL 60173
Object Design, Inc. 847.413.9700 ext. 15
mailto:jre...@odi.com http://www.odi.com
Scott Raney
Jonathan Locke wrote:
>
(snip)
> > > There are many good reasons to expect equal or, in some cases, *better*
> > > performance from Java programs than from C/C++ programs.
> >
> > Really? Name one.
> >
> > Garbage collection? Bzzzt, thanks for playing...
> > Array bounds checking? Guess again...
> > Stack based p-code? Not in a register-based world...
> > No pointers or raw memory allocation? Not a chance...
>
> See my response from earlier today for the long-winded version of my
> argument. Basically though, I think you too are making the mistake of
> focusing in on low level mechanics at the expense of ignoring a rather
> large set of high level issues that are equally, if not more important.
> Yes, at the micro level, in simple test cases, C/C++ has and will
> probably always have Java beat. And low-level device drivers in C/C++
> will always make more sense. But I have to disagree with you if you
> think that this performance advantage in low-level mechanics will scale
> linearly in the real world. I think a lot of *applications* written in
> Java will eventually outperform those written in C/C++ for all the
> reasons I listed in that other posting (I can repost that if you can't
> find it).
I don't doubt that, since there are lots of programs developed with MetaCard and
Tcl/Tk that are faster than C programs that use Xt/Motif. But my original
post was restricted to the idea of using Java for system software, which I
define to be UI controls, heavy-duty data manipulation, and OS-level things
like drivers and daemons. Maybe I'm missing something, but a lot of what
I hear people talking about using "applets" for fall into the first two
categories. If Java fails as a language for developing components, it doesn't
have a future because it certainly can't compete with high-level languages for
the rest of application development.
> > > Some of the
> > > better JITs and Asymetrix' Supercede are the first baby steps in this
> > > direction, but they are a *LONG* way from the limits of what can be
> > > done. Just be patient... we'll get there.
> >
> > Spoken like a true zealot: Damn the facts! We shall overcome!
>
> Perhaps so, but I have reasons for thinking these things having spent a
> lot of time thinking about them, and if I may say so, you speak like
> someone who is entrenched in the past and cannot think beyond
> yesterday's problems and minutae.
On the contrary, I look forward to the day when we won't be using a language
with a syntax that was designed 25 years ago, and we won't have to exit an
application, wait for a recompile, and then restart the application just to
make a simple change.
> > the low level, low productivity develoment of C and C++, with the
>
> Oh please... you haven't actually done any Java development have you?
> Java is easily an order of magnitude more productive that C/C++.
I would have to disagree with you there. You haven't actually done any
development with Perl, Tcl, or MetaCard have you? They can make that
"order of magnitude" claim, but there's no way Java can (unless of course
you were willing to grant these high-level languages *two* orders of
magnitude ;-)
> I have
> (quite literally) spent zero time in the last N months debugging out of
> control programs. A few *logic* problems here and there, but I
> seriously doubt you could say the same for C/C++. Every time I talk to
> one of my friends who is still doing C/C++ they are always complaining
> endlessly about memory smashes, stack corruption, COM reference counting
> problems, portability problems, endlessly repeated code idioms, disk
> thrashing and swap tuning etc. No, I think you're *way* off the mark
> here.
I think maybe those C++ developers could use a little discipline. I do
*a lot* of C++ development and have few problems with any of these things.
Of course, we use a highly-polished class library and a malloc debugger,
but between the two of these Java development really isn't all that different
than what I do now.
> > relatively poor performance of scripting languages (Perl, Tcl).
>
> That's crap too. Especially the comparison with Tcl.
I guess I'd have to agree with you about Tcl (it *is* dog slow). But the
benchmarking we've done against Perl and MetaTalk show that byte-code Java
has similar performance characteristics. It's a *lot* more resource intensive
though, especially when doing lots of graphical work.
> > If developing in Java were anywhere near as productive as
> > developing in these high-level languages it would be worth paying
> > the performance penalty. Unfortunately, it isn't.
>
> Personally, I think you still haven't unzipped your JDK. ;-)
No, I played with it some. I found it very easy to adapt to, which is
undoubtedly one of the reason's it's becoming popular so quickly: C and
C++ developers can pick it up extremely quickly. But I quickly became
disgusted by the long waits to compile and restart the application after
making changes (neither of which are necessary when using a true high-level
development tool), the very primitive GUI tools, the minutiae of
dealing with string-to-number to conversion, primitive text manipulation
capabilities (no regex?) and so on.
Peter van der Linden
This is what he means by "damned with faint praise":
> And logic programming has blossomed, not least because of its adoption
> by the Japanese as the central focus of the Fifth Generation project.
If you recall, we don't hear so much about the Japanese Fifth Generation project
any more. I well remember picking up the current CACM some time in the early
eighties, and the cover picture was a cartoon of a group of American
computer scientists trying all sorts of ludicrous things to catch up with the
Japanese Fifth Generation project. Some of them were standing on each others'
backs, one of them had spring-heeled shoes etc, but they were plainly doomed
to failure.
Well it turned out that the Japanese Fifth Generation project was the
initiative doomed to failure. It utterly failed to meet even one of its
stated goals. The Japanese computer industry and government thoroughly paniced
a number of people over here (many of whom should have known better) and
spent a king's ransom to come up with ... nothing. Prolog was a core
part of that initiative.
I don't have a moral or anything, just wanted to connect the dots.
Peter
--
Peter van der Linden lin...@Eng.sun.com Java -> http://www.best.com/~pvdl
Recent Java ad: "Build advanced systems in nascent genres."
-#-#-#-#-#- free() the malloc'd 512 -#-#-#-#-#-
Alexander Anderson
In article <527hei$n...@engnews2.Eng.Sun.COM>, Peter van der Linden
<lin...@positive.eng.sun.com> writes
>Well it turned out that the Japanese Fifth Generation project was the
>initiative doomed to failure. It utterly failed to meet even one of its
>stated goals. The Japanese computer industry and government thoroughly paniced
>a number of people over here (many of whom should have known better) and
>spent a king's ransom to come up with ... nothing. Prolog was a core
>part of that initiative.
Agreed, or maybe agleed.
However I was thinking we're all at the same stage as David Warren
(the guy writing the Foreword) when he says
I tried again. Prolog was quiet for a long time and then
-----------------------------------------
responded:
---------
DEBORDEMENT DE PILE
Stack overflow!
My underlining.
-----------
That the 5th Gen centred around Prolog is like saying Microsoft have
a J++.
(Ooouuchhh!... I can see this thread going on forever!)
Randy Chapman
Scott Raney (ra...@metacard.com) wrote:
: I don't doubt that, since there are lots of programs developed with MetaCard and
: Tcl/Tk that are faster than C programs that use Xt/Motif. But my original
Thats not saying a lot, really. Xt/Motif is *DOG SLOW*. An entire GUI
widget set written in Java (using Xlib) seriously outperforms Xt/Motif.
Thats not with a JIT compiler.
: I would have to disagree with you there. You haven't actually done any
: development with Perl, Tcl, or MetaCard have you? They can make that
: "order of magnitude" claim, but there's no way Java can (unless of course
: you were willing to grant these high-level languages *two* orders of
: magnitude ;-)
Well, I certainly have. And I would most definitely NOT choose tcl/tk over
Java as a development language. Sure, tcl/tk looks easier at first. Then
try a larger project with it. The reasons it looks easier will soon be
the reasons you are tearing your hair out. Likewise with Perl. And VB.
They all encourage you to develop more with silly things like global variables
and the like.. stuff that will come back and bite you hard later.
Java, OTOH, encourages you to program in a way that is much less likely
to be a problem in thbig scale. It encourages you to program in
components that inherently can stand alone. And its much easier to
do this than in C or C++. Hence why it *is* an order of magnitude
easier!
: I think maybe those C++ developers could use a little discipline. I do
: *a lot* of C++ development and have few problems with any of these things.
: Of course, we use a highly-polished class library and a malloc debugger,
: but between the two of these Java development really isn't all that different
: than what I do now.
So why are you using a malloc debugger if you are so good? If you are
claiming comparison, you don't need it; it will never get tripped.
If it does, you then have to debug something that you wouldn't have
had to in Java! Yes, a good malloc debugger will definitely save you
in the long run, but not as much as a system where it just *can't* be an issue.
: I guess I'd have to agree with you about Tcl (it *is* dog slow). But the
: benchmarking we've done against Perl and MetaTalk show that byte-code Java
: has similar performance characteristics. It's a *lot* more resource intensive
: though, especially when doing lots of graphical work.
Byte-code java has similar characteristics. Yet JIT compiled java tends
to have 5-10 times the raw speed (if not more, actually). That would be
a lot faster. Whether that matters for app-development work, I don't know.
But it certainly *does* matter for what you say Java is too slow for.
: No, I played with it some. I found it very easy to adapt to, which is
: undoubtedly one of the reason's it's becoming popular so quickly: C and
: C++ developers can pick it up extremely quickly. But I quickly became
: disgusted by the long waits to compile and restart the application after
: making changes
If its taking longer to compile your java stuff than your C++, something
is *very* strange about your java setup. And I've yet to meet a tool
that doesn't at least require a restart at least most of the time for
a code change... always if you want reproducible circumstances.
: dealing with string-to-number to conversion, primitive text manipulation
: capabilities (no regex?) and so on.
Its libraries are certainly lacking, no-one doubts that. But it is also
quite extendible. Not as much as tcl, yes. At least as much as perl, however.
--randy
Timothy Murphy
Scott Raney <ra...@metacard.com> writes:
>That was my point: the language *itself* is what is not appropriate
>for system software development. No amount of rearchitecting the
>compiler will overcome this limitation.
Why?
You have given no reason that I can see for your opinion.
It seems to me therefore of very little or no value.
--
Timothy Murphy
e-mail: t...@maths.tcd.ie
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Brian Pane
In article <R.51vbrg$v...@murrow.corp.sgi.com>, shif...@slappy.engr.sgi.com (Hank Shiffman) writes:
> It will take a serious rewrite of the runtime libraries to get much of
> an improvement in the compiler. One problem that probably won't get
> fixed is that the runtimes are all thread-safe. That's necessary for
> multithreaded Java applets and applications but unnecessary overhead
> for single threaded programs like compilers. The only way to eliminate
> that overhead is to have separate versions of the runtime for single
> and multithreaded codes to use. I suspect that's a complication that
> JavaSoft won't want to tackle.
Better yet, it would be nice to see a compiler take advantage of the
thread-safe runtime libraries. Compiling multiple classes simultaneously
would offer some opportunities to overlap computation and I/O for reduced
execution time.
brian pane
bri...@cnet.com
Chuck McManis
It can be very amusing watching someone who feels threatened by
a technology try desparately to slam it. It would be more amusing
if there was a coherent argument in here somewhere but when you
are dealing with exchanges like:
Scott Raney saying:
... my original post was restricted to the idea of using
Java for system software, which I define to be UI
controls, heavy-duty data manipulation, and OS-level
things like drivers and daemons.
Java works as well as a systems language as any other. You can
express any 'OS' concept you care to, in Java. There actually is
an implementation of this from Sun called Kona.
Java running on a hosted VM (that is the VM is running on top of
some OS, which is running on top of some hardware) is generally
the slowest implementation. Speed increases by a factor of 3 to 6
when you host it directly on the hardware (native VM) (still the
same virtual machine, but now you have no interface delays going
into and out of the "kernel" or thread switching delays). If you
use a second stage compiler (aka a JIT compiler) then execution
is increased again by 5 to 10 times. Finally if you go to either
a staging compiler (which produces pre-compiled classes into the
class cache) or a hardware implementation of the JVM itself you
get another jump in speed. (Sun's not posting numbers on the picoJava
stuff that I can find, at the Embedded Systems Conference there
were mumblings of "order of magnitude" but who knows what the
baseline was.)
So, there is absolutely no reason not to consider Java as a systems
language, and in fact if my sources are correct, you may be able to
purchase a computer which is completely programmed in Java (caveat
the BIOS rom) in a relatively short time frame.
Then Scott continues with:
Maybe I'm missing something, but a lot of what
I hear people talking about using "applets" for
fall into the first two categories.
And this is the amusing part. "Maybe I'm missing something" is
sort of like saying "Maybe there is something to this notion that
the planet is round." :-)
Seriously, seen through the eyes of heart and soul behind "MetaCard"
Java is a HORRIBLE language. Hell, it would take at least a hundred
hours to implement MetaCard in Java and reap the benefits of getting
cross platform support for "free" without any additional investment.
It all depends on how you look at things. Here is a simple, objective
test using the Scientific Method:
Hypothesis:
"Java is a better language for building Web servers
in than MetaCard."
Contrary Proof :
1. Metacard is the best programming language in the world.
2. Web Server writers try to use the best programming
languages.
3. There is a web server written in MetaCard.
Well, 3 doesn't seem to hold up. Let's try a positive proof.
Proponent(?) Proof :
1. Java is the best programming language in the world.
2. Web Server writers try to use the best programming
languages.
3. There is a web server written in Java
Well it seems like there are actually two web servers written in Java,
one by Sun and one by a neutral third party (W3C). I think the second
proof is more compelling. How about it Scott?
Now if your yelling and screaming "But MetaCard isn't for writing
Web servers in stupid, its for doing cool GUI tools." then the second
point is made as well. Java isn't your competitor, and it could be
your ally if you pick the winning strategy.
If we're going to have a language bashing session lets at least
define the rules for judging the language.
--
cmcm...@netcom.com http://www.professionals.com/~cmcmanis
All opinions in the non-included text above are the sole opinions of
the author.
jim frost
Chuck McManis <cmcm...@netcom.com> writes:
>Well it seems like there are actually two web servers written in Java,
>one by Sun and one by a neutral third party (W3C). I think the second
>proof is more compelling. How about it Scott?
There are more than two (by which I mean "there are at least three"
:-). It's trivial to write a web server in Java, even one with pretty
good performance.
jim frost
This is effectively managed by using something like a parallel "make"
("something like" because make works poorly with java). You don't
gain a lot by putting the parallelism within the compiler, and you
increase the compiler's complexity a lot.
Scott Raney
Timothy Murphy wrote:
>
> Scott Raney <ra...@metacard.com> writes:
>
> >That was my point: the language *itself* is what is not appropriate
> >for system software development. No amount of rearchitecting the
> >compiler will overcome this limitation.
>
> Why?
> You have given no reason that I can see for your opinion.
> It seems to me therefore of very little or no value.
Perhaps you missed the original post. It was about an article
in Information Week (Sept 16, 1996 p. 136) that Sun was abandoning
plans for a Java JIT compiler written in Java *because it was
too slow*. It went on to say that this slowness was inherent
in the design of the language. All I'm doing is reporting
Sun's own conclusion.
Scott
> --
> Timothy Murphy
> e-mail: t...@maths.tcd.ie
> tel: +353-1-2842366
> s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
--
Dean Schulze
Hank Shiffman wrote:
> > There are many good reasons to expect equal or, in some cases, *better*
> > performance from Java programs than from C/C++ programs.
>
> And many reasons to believe that this will never be achieved for the
> vast majority of applications. I have a writeup on some of these at
>
> http://reality.sgi.com/shiffman/Java-QA.html
>
> Of course, that doesn't mean that Java's performance won't get close
> *enough* for most tasks for which it's appropriate. But equal to or
> faster than C++? I don't think so.
Hank, your write up needs updating in a couple of areas.
First when you say "... we won't know until someone actually
tries it [writing a large application in Java]" you're a little
behind. People have written large, "real world" applications in Java.
Here's a reference to one:
Patricia Seybold, Computer World, Aug. 5, 1996, Pg. 33
This application is called Via World Network. It is a multi-airline
scheduling and reconciliation program that was written for Anderson
Consulting. It consists of 200,000 lines of Java, and it was written
and deployed in 9 months. The leader of the project lauded the
quality control aspects of Java compared to other languages.
Second, the world of C++ has changed dramatically. There was
a thread of discussion on comp.lang.c++.moderated a few weeks ago
about C++ vs. Fortran. It turns out that it is theoretically
possible for C++ to outperform Fortran for numeric computing
(vector and matrix manipulation). I believe the optimization
theories rely on iterators, but this may be for parallel machines.
Right now this is just vapor, but you might want to qualify your
comment that "C++ won't be as fast as Fortran".
There is now a C++ compiler that gives object oriented programs
nearly the run time performance of C (http://www.kai.com). If
C++ is giving C a run for it's money it won't be long before it
equals Fortran too.
So while this means that the gap between Java and C++ is probably
larger than many people think, it also shows how unexpected performance
gains can happen. Five years ago no one claimed that C++ would be
as fast as Fortran. Now it appears ready to overtake Fortran.
I wouldn't speculate that one language will always be faster than
another.
Dean Schulze
======================================================================
"You plot the growth of the NEA [National Education Association] and
the dropping of SAT scores, and they're inversely proportional.
The problems are unions in the schools. The problem is bureaucracy.
I'm one of these people who believes the best thing we could ever do
is go to the full voucher system."
Steve Jobs
Wired Magazine, Feb. 96
http://www.hotwired.com/wired/4.02/features/jobs.html
=====================================================================
Hank Shiffman
In article <3249B7...@cassini.lpl.arizona.edu>, Dean Schulze <sch...@cassini.lpl.arizona.edu> writes:
> Hank, your write up needs updating in a couple of areas.
>
> First when you say "... we won't know until someone actually
> tries it [writing a large application in Java]" you're a little
> behind. People have written large, "real world" applications in Java.
> Here's a reference to one:
I'll stand by my statement a little longer. One application doesn't
really make a complete case. And I'm more than a little skeptical
about this one. The claims that are made for the application are
interesting. But I've read a lot of claims that didn't bear closer
scrutiny. And questions about how maintainable the application really
is won't be answered until it's gone through a few years of maintenance.
>
> Second, the world of C++ has changed dramatically. There was
> a thread of discussion on comp.lang.c++.moderated a few weeks ago
> about C++ vs. Fortran. It turns out that it is theoretically
> possible for C++ to outperform Fortran for numeric computing
> (vector and matrix manipulation). I believe the optimization
> theories rely on iterators, but this may be for parallel machines.
> Right now this is just vapor, but you might want to qualify your
> comment that "C++ won't be as fast as Fortran".
Keep in mind that Fortran is a moving target as well. Fortran
enhancements are designed to make the language higher performance as
well as easier to program. One of the ways this happens is to steal
ideas from other languages. (There's an old joke that says that we
don't know what the language of the future will be. The only thing
we can be sure of is that it will be called Fortran.) And there are
several variants of Fortran already that address different classes
of problem.
> So while this means that the gap between Java and C++ is probably
> larger than many people think, it also shows how unexpected performance
> gains can happen. Five years ago no one claimed that C++ would be
> as fast as Fortran. Now it appears ready to overtake Fortran.
Well, I wouldn't say that no one made that claim. Tom Keffer of Rogue
Wave wrote an article for Dr. Dobbs that suggested C++ with class
libraries for Fortran kinds of problems.
In any event, the point I wanted to make about languages is a little
different than the one you addressed. Different languages permit
different degrees of compiler optimization. That's what makes Fortran
a better choice for computational codes than C++. It's true that you
may be able to write a smarter algorithm using C++ that will give you
better performance than Fortran. But all things being equal (and when
is that ever true?), Fortran lets the compiler do a better job of
efficient code generation than C++. And C++ permits better code
generation than C (although most compilers don't take advantage of it)
or Java.
Chuck McManis
Scott Raney wrote:
> Perhaps you missed the original post. It was about an article
> in Information Week (Sept 16, 1996 p. 136) that Sun was abandoning
> plans for a Java JIT compiler written in Java *because it was
> too slow*. It went on to say that this slowness was inherent
> in the design of the language. All I'm doing is reporting
> Sun's own conclusion.
No, you're reporting your flawed interpretation of a flawed article.
Sun never, ever, planned to write a "JIT" (as in Just in Time)
compiler in Java as a product. The did write a Java source code
compiler in Java (its part of the JDK) and this has both advantages
and disadvantages. On the plus side, as soon as the basic virtual
machine is ported to a platform, you've got a compiler, on the minus
side it is slower than a compiler which is running on the native
hardware.
The article may have gone on to say that the slowness was "inherent
in the design of the language" however no one at Sun has ever said
that. Further, Bill Joy has stated on the record that he believed
that programs written in the Java language and compiled into native
machine code would be inherently *faster* than code written
in C++ because of the cleaner semantics of the language.
So Infoworld reported some bogus information, and you propagated it.
Like any good messenger on the net you get held responsible for what
you forward ;-)
--
--Chuck McManis http://www.professionals.com/~cmcmanis/index.html
All opinions in this message are those of the author. No warranty as to
the suitability or accuracy is stated or implied. Use at your own risk.
cmcm...@netcom.com +1.408.524.4805
Eugene O'Neil
In article <52ckk4$h...@murrow.corp.sgi.com>, shif...@slappy.engr.sgi.com
>In any event, the point I wanted to make about languages is a little
>different than the one you addressed. Different languages permit
>different degrees of compiler optimization. That's what makes Fortran
>a better choice for computational codes than C++. It's true that you
>may be able to write a smarter algorithm using C++ that will give you
>better performance than Fortran. But all things being equal (and when
>is that ever true?), Fortran lets the compiler do a better job of
>efficient code generation than C++. And C++ permits better code
>generation than C (although most compilers don't take advantage of it)
>or Java.
C++ is more optimizable than C? How can that be true, when C++ is a superset
of C? As for Java, it is at least as optimizable as C++, though it hasn't had
nearly as much work put into it yet.
In any case, I think that most languages can be optimized far more than most
people would think. Even a language like lisp, which at first glance appears
chained to it's interpereter, can be compiled into fast machine language given
the right tools. All it takes is effort, inginuity, and the understanding that
it can be done.
-Eugene
Hank Shiffman
In article <DyCHz...@world.std.com>, eug...@cs.umb.edu writes:
> In article <52ckk4$h...@murrow.corp.sgi.com>, shif...@slappy.engr.sgi.com
> (Hank Shiffman) wrote:
> >In any event, the point I wanted to make about languages is a little
> >different than the one you addressed. Different languages permit
> >different degrees of compiler optimization. That's what makes Fortran
> >a better choice for computational codes than C++. It's true that you
> >may be able to write a smarter algorithm using C++ that will give you
> >better performance than Fortran. But all things being equal (and when
> >is that ever true?), Fortran lets the compiler do a better job of
> >efficient code generation than C++. And C++ permits better code
> >generation than C (although most compilers don't take advantage of it)
> >or Java.
>
> C++ is more optimizable than C? How can that be true, when C++ is a superset
> of C? As for Java, it is at least as optimizable as C++, though it hasn't had
> nearly as much work put into it yet.
Is the superset aspect that makes greater optimization possible. Pointers
are hard to optimize away, since a compiler can't generally tell if the
pointer's target has changed since the last time it was stored. References
(present in C++ but absent in C) don't have this problem. So a C++ compiler
*could* produce a faster reference-using program than the equivalent C with
pointers alone. There are probably other examples, but that one should
suffice to make my point.
> In any case, I think that most languages can be optimized far more than most
> people would think. Even a language like lisp, which at first glance appears
> chained to it's interpereter, can be compiled into fast machine language given
> the right tools. All it takes is effort, inginuity, and the understanding that
> it can be done.
I agree that most languages can be optimized beyond what is done today.
There are constraints both in terms of compile time and the expense of
developing the technology that delay or prevent such optimization from
being done. Economics plays its part even in the software business.
(Insert smiley here.)
Jonathan Locke
> The article may have gone on to say that the slowness was "inherent
> in the design of the language" however no one at Sun has ever said
> that. Further, Bill Joy has stated on the record that he believed
> that programs written in the Java language and compiled into native
> machine code would be inherently *faster* than code written
> in C++ because of the cleaner semantics of the language.
Well said... and exactly right. I like this Bill Joy guy.
I'd like to one-up him on the wild prediction front, though. Most
significant Java programs will eventually be faster than native C++ code
on Java VMs. This will take a number of years to work out, but I think
it makes complete sense. My root argument is that by doing on-the-fly
profiling and code inlining/optimization, you can produce self-tuning
systems which automatically balance the traditional time versus space
tradeoff. C++ wins (and should continue to win) in terms of raw
execution speed in small systems, but it will lose against Java in a big
way as systems scale.
Jeremy L. Rosenberger
Eugene O'Neil wrote:
> C++ is more optimizable than C? How can that be true, when C++ is a
> superset of C? As for Java, it is at least as optimizable as C++,
> though it hasn't had nearly as much work put into it yet.
I'm by no means an expert, but it would seem that higher-level
constructs would be more open to optimization than lower-level ones,
since the compiler would have more freedom to do as it wishes with
these constructs without breaking the program flow.
Regards,
Jeremy
--
Jeremy L. Rosenberger
mus...@henge.com
jim frost
Dean Schulze <sch...@cassini.lpl.arizona.edu> writes:
> First when you say "... we won't know until someone actually
>tries it [writing a large application in Java]" you're a little
>behind. People have written large, "real world" applications in Java.
>Here's a reference to one:
> Patricia Seybold, Computer World, Aug. 5, 1996, Pg. 33
>This application is called Via World Network. It is a multi-airline
>scheduling and reconciliation program that was written for Anderson
>Consulting. It consists of 200,000 lines of Java, and it was written
>and deployed in 9 months. The leader of the project lauded the
>quality control aspects of Java compared to other languages.
This exactly mirrors what I say about the language. In the past five
months I've written some thirty thousand lines of Java code. That is
a productivity level more than double that I have in C++, and the code
is considerably more robust on the first try.
Java is a godsend for large applications.
Jonathan Locke
I *totally* blew myself away the other day. I finished working all day
long on a class for my class library. At the end of the day I was ready
to start debugging and testing it... but to my complete and utter
surprise the whole darn thing (around 800 lines) SIMPLY WORKED, with the
exception of a couple of rather trivial bugs. Both the turnaround and
the robustness of java are on a completely different order of magnitude
from C++.
Yesterday, I wrote an extensible, scrollable, variable node-height
treeview control and filled it with the thread-hierarchy from my java
vm. Last week I ported my old regular expression engine from C to
java. It works fine and half the code disappeared because of better
java semantics and exception handling. This weekend I plan to add
editing, filtering and drag-drop to my treeview. I wonder what my
friends have got done in C/C++ in the same time period...
Jim Balter
In article <3245BBF6...@metacard.com>,
Scott Raney <ra...@metacard.com> wrote:
>such that it will never be able to achieve the performance necessary
>to displace C or C++ for system programming projects (including
>development of components for desktop applications). As was the
>this.
I gather from this that you are either an expert on Prolog, or a pompous
ignoramus. Are you an expert on Prolog?
--
<J Q B>
Jonathan Locke
> I would have to disagree with you there. You haven't actually done any
> development with Perl, Tcl, or MetaCard have you? They can make that
> "order of magnitude" claim, but there's no way Java can (unless of course
> you were willing to grant these high-level languages *two* orders of
> magnitude ;-)
You don't know me very well. I am a major language enthusiast. I have
been doing Perl for more than six years now (just for fun i went and
counted the lines (using a Perl script of course)... i currently have
written... or at least kept... 12,866 lines of Perl code). I've done
Tcl as well, not to mention a wide variety of other languages you may
not have heard of... as a matter of fact, I have a Dylan manual sitting
next to my desk right now. And while we're at it, I have also
implemented several languages, including one with a full IDE and a
debugger.
> I guess I'd have to agree with you about Tcl (it *is* dog slow). But the
> benchmarking we've done against Perl and MetaTalk show that byte-code Java
> has similar performance characteristics. It's a *lot* more resource intensive
> though, especially when doing lots of graphical work.
That really depends on what you are doing. Perl is blazing fast (in
fact, I think it would be hard in some cases to write more efficent C
code!) if you're doing certain kinds of text manipulation. But it falls
down SERIOUSLY if you move outside that realm. I wrote a Perl lexer for
Java yesterday that works quite nicely but suffers serious performance
problems because Perl just isn't even suited for certain kinds of text
parsing (although that particular fault could be easily remedied).
> No, I played with it some. I found it very easy to adapt to, which is
> undoubtedly one of the reason's it's becoming popular so quickly: C and
> C++ developers can pick it up extremely quickly. But I quickly became
> disgusted by the long waits to compile and restart the application after
> making changes (neither of which are necessary when using a true high-level
> development tool), the very primitive GUI tools, the minutiae of
> dealing with string-to-number to conversion, primitive text manipulation
> capabilities (no regex?) and so on.
You might want to check out my SealevelSoftware.RE package. It is a
compiler / interpreter pair that supports a superset of Perl 4.0 regular
expressions (it passes the full test battery that comes with Perl 4.0).
The compiler is recurse descent. The interpreter is a tight loop that
runs a bytecode program created by the compiler. The package also
supports "pre-compiling" regular expressions so that you don't have to
load the compiler (the interpreter is about 5K).
In addition, you may want to check out my "JaM" package (short for "Java
Munger") which implements a few of the most interesting Perl text
munging features (split, join, push, pop, grep etc.)
There are interactive on-line demonstrations of both packages so you can
check them out fully before you download. Each package comes with
on-line JavaDoc documentation (with a searchable JaDIx index).
http://www.sealevelsoftware/sealevel/java.html
Enjoy!
Phil Austin
>>>>> "HS" == Hank Shiffman <shif...@slappy.engr.sgi.com> writes:
>>
>> C++ is more optimizable than C? How can that be true, when C++
>> is a superset of C? As for Java, it is at least as optimizable
>> as C++, though it hasn't had nearly as much work put into it
>> yet.
HS> Is the superset aspect that makes greater optimization
HS> possible. Pointers are hard to optimize away, since a
HS> compiler can't generally tell if the pointer's target has
HS> changed since the last time it was stored. References
HS> (present in C++ but absent in C) don't have this problem. So
HS> a C++ compiler *could* produce a faster reference-using
HS> program than the equivalent C with pointers alone. There are
HS> probably other examples, but that one should suffice to make
HS> my point.
I'm apending a post by Paul Dubois in comp.lang.eiffel that makes this
point. It also underscores how important parameterized types can
be for performance (see Computers in Physics
http://www.aip.org/cip/preview/preview.htm for a blurb about this).
Hopefully Java will one day have the equivalent of expression templates.
>>>>> "PD" == Paul F Dubois <dub...@llnl.gov> writes:
PD> This thread has contained an implicit assumption that C++ is a
PD> known reference point. It surely is not. In the Scientific
PD> Programming Department of the journal Computers in Physics we
PD> are in the process of publishing a series of articles on the
PD> speed of C++ for scientific programs. Between compiler
PD> improvements and new coding techniques there has been a very
PD> significant increase in performance on some simple benchmarks
PD> in just a year or so. Some of the compiler improvements have
PD> been driven in part by the creation of some small benchmarks
PD> (by Scott Haney) and their publication.
PD> Publication of benchmarks, and cooperation between the vendors
PD> and the benchmark authors, can result in real improvements in
PD> compilers. I have followed this thread with increasing
PD> frustration in that I could not see the Eiffel coding being
PD> tested, so that I had no idea what was being measured. I have
PD> no idea if the benchmark author is doing something clever or
PD> something stupid. My view is that a benchmark only contributes
PD> if it doesn't do something a reasonable practictioner of the
PD> language would know is a performance problem, and if its mix
PD> of operations is typical of a significant application area.
PD> The benchmarks that Haney wrote for scientific C++ were very
PD> simple. It is easy to see that a very simple benchmark can be
PD> misleading, but on the other hand it can isolate a certain
PD> area of concern in the compiler. One must combine simple
PD> benchmarks with an understanding of their limitations. I also
PD> take it as given that we all understand that execution speed
PD> is just one of many factors one must consider.
PD> If you wish to have a speed reference it is safer to use
PD> Fortran, although even with Fortran a certain amount of care
PD> must be taken in writing the benchmark. Of course, some of the
PD> interesting object-oriented operations are hard to express in
PD> Fortran. It should be F77, by the way, not F90, which is
PD> significantly slower I understand.
PD> By the way, the result of the C++ adventures has been that the
PD> abstraction penalty for using a nice real or complex array
PD> class can be nearly eliminated. Statements such as
PD> z = x + y / sqrt (w*w + 1.0);
PD> where x, y, z, and w are arrays, can result in the generation
PD> of virtually the same one loop that a C or Fortran programmer
PD> would write. This is possible because the C++ template
PD> facility differs from the Eiffel generic facility in a
PD> interesting way. Whether it is possible to do this trick in
PD> Eiffel is an interesting question.
Phil Austin INTERNET: ph...@geog.ubc.ca
(604) 822-2175 FAX: (604) 822-6150
http://www.geog.ubc.ca/~phil
Associate Professor
Atmospheric Sciences Programme
Geography #217
University of British Columbia
1984 W Mall
Vancouver, BC V6T 1Z2
CANADA