Java speed vs Tcl speed
Kristoffer Lawson
applications with Tcl as the scripting interface. However, I have my doubts
about this claim. After testing a few Tcl/Tk-based applications and a
couple Java ones in recent days, I must say I have yet to see a single
Java application that was faster than a Tk one. In general they tend to
be much much slower.
Reminds me of the time when we did some simple iteration tests in
different languages. Again, Java was by far the slowest of all languages
we tried (we tested it both on Linux and SGI). So is the above phrase
only a myth? We all know that with iTcl, XOTcl etc the large application
problem can be solved in much the same way as Java tries to do it...
--
- ---------- = = ---------//--+
| / Kristoffer Lawson | www.fishpool.fi|.com
+-> | se...@fishpool.com | - - --+------
|-- Fishpool Creations Ltd - / |
+-------- = - - - = --------- /~setok/
Cameron Laird
Kristoffer Lawson <se...@fishpool.com> wrote:
>A common phrase is that Java is used for larger more performance-critical
>applications with Tcl as the scripting interface. However, I have my doubts
>about this claim. After testing a few Tcl/Tk-based applications and a
>couple Java ones in recent days, I must say I have yet to see a single
>Java application that was faster than a Tk one. In general they tend to
>be much much slower.
>
>Reminds me of the time when we did some simple iteration tests in
>different languages. Again, Java was by far the slowest of all languages
>we tried (we tested it both on Linux and SGI). So is the above phrase
>only a myth? We all know that with iTcl, XOTcl etc the large application
>problem can be solved in much the same way as Java tries to do it...
.
.
It's a myth that the culture believes, so it becomes real.
Are you comparing GUI applications? Oh, yes; Tk just *em-
barrasses* Swing and even AWT. Comparisons of "back-end"
work is more ambiguous.
Incidentally, your tests were of particular implementations
rather than of the languages. Linux-based Java facilities
are becoming faster. I'm less optimistic than I used to be
that Java'll ever catch up.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Chang LI
Kristoffer Lawson wrote in message <8lmko6$2bd7$1...@news.bbnetworks.net>...
>A common phrase is that Java is used for larger more performance-critical
>applications with Tcl as the scripting interface. However, I have my doubts
>about this claim. After testing a few Tcl/Tk-based applications and a
>couple Java ones in recent days, I must say I have yet to see a single
>Java application that was faster than a Tk one. In general they tend to
>be much much slower.
>
Do you have benchmark program? There are posts about benchmark program
of Tcl/Tk, where is the available package? If you try to convenice people
Tcl
is faster you need to present data. Now there is TclBlend so we can compare
Tcl code and Java class code under a TclBlend program.
>Reminds me of the time when we did some simple iteration tests in
>different languages. Again, Java was by far the slowest of all languages
>we tried (we tested it both on Linux and SGI). So is the above phrase
>only a myth? We all know that with iTcl, XOTcl etc the large application
>problem can be solved in much the same way as Java tries to do it...
>
Absolutely. JPS and ASP are also no better than Tcl for servers. But I have
to say that both Sun and Microsoft are successfully in marketing Java and
VB. A better technique is not always winner.
Chang LI
Neatware
Darel Finkbeiner
Cameron Laird wrote:
> In article <8lmko6$2bd7$1...@news.bbnetworks.net>,
> Kristoffer Lawson <se...@fishpool.com> wrote:
> >A common phrase is that Java is used for larger more performance-critical
> >applications with Tcl as the scripting interface. However, I have my doubts
> >about this claim. After testing a few Tcl/Tk-based applications and a
> >couple Java ones in recent days, I must say I have yet to see a single
> >Java application that was faster than a Tk one. In general they tend to
> >be much much slower.
> >
> >Reminds me of the time when we did some simple iteration tests in
> >different languages. Again, Java was by far the slowest of all languages
> >we tried (we tested it both on Linux and SGI). So is the above phrase
> >only a myth? We all know that with iTcl, XOTcl etc the large application
> >problem can be solved in much the same way as Java tries to do it...
> .
> .
> .
> It's a myth that the culture believes, so it becomes real.
>
> Are you comparing GUI applications? Oh, yes; Tk just *em-
> barrasses* Swing and even AWT. Comparisons of "back-end"
> work is more ambiguous.
>
> Incidentally, your tests were of particular implementations
> rather than of the languages. Linux-based Java facilities
> are becoming faster. I'm less optimistic than I used to be
> that Java'll ever catch up.
> --
>
I used Java + Swing for a couple of major projects. After doing that, I tried
out Tcl/Tk because I wanted to see if it could do some simple stuff.
Oh.... My..... God!!!!
Unless Java goes through a complete rewrite I am never going back.
(btw, this was Java 1.3 on NT/95/and 1.2 on Linux, ... maybe one year ago)
Bryan Oakley
news:8lmko6$2bd7$1...@news.bbnetworks.net...
> A common phrase is that Java is used for larger more performance-critical
> applications with Tcl as the scripting interface.
Really? I've never heard anyone suggest using java for performance-critical
applications. Interesting.
> However, I have my doubts
> about this claim. After testing a few Tcl/Tk-based applications and a
> couple Java ones in recent days, I must say I have yet to see a single
> Java application that was faster than a Tk one. In general they tend to
> be much much slower.
My experience mirrors yours.
>
> Reminds me of the time when we did some simple iteration tests in
> different languages. Again, Java was by far the slowest of all languages
> we tried (we tested it both on Linux and SGI). So is the above phrase
> only a myth?
I suspect so. I've never heard it, personally. In fact, outside of
comp.lang.tcl, I've *never* heard tcl and java mentioned in the same
sentence. Shoot, not even in the same paragraph/article/book. But I'll have
to admit -- I don't travel in Java circles much these days. I'm still in
recovery from the year I had to do full time java development...
Darel Finkbeiner
Bryan Oakley wrote:
I sympathize with you. There should an alt.recovery.java NG.
The shellshock can leave a programmer stunned and listless for quite a while.
;-)
Kristoffer Lawson
: Are you comparing GUI applications? Oh, yes; Tk just *em-
: barrasses* Swing and even AWT. Comparisons of "back-end"
: work is more ambiguous.
Yes, they were GUI applications... But as mentioned even simple
iterative tests were sloooow.
: Incidentally, your tests were of particular implementations
: rather than of the languages.
Well I did test them on both the SGI and Linux. The difference between
Java and Tcl was so huge that some pretty major improvements would have
to be made to make much of a difference.
Kristoffer Lawson
: Do you have benchmark program? There are posts about benchmark program
: of Tcl/Tk, where is the available package? If you try to convenice people
: Tcl
: is faster you need to present data. Now there is TclBlend so we can compare
: Tcl code and Java class code under a TclBlend program.
Oh it wasn't what I'd call a real benchmark. I mean it was just simple
for loops and things anyone could do ;-) Of course could compile them
again at some point and post the results, but I doubt anyone would
consider them serious benchmarks. It's just a bit concerning that
Java was so far behind for such straightforward stuff.
: Absolutely. JPS and ASP are also no better than Tcl for servers. But I have
: to say that both Sun and Microsoft are successfully in marketing Java and
: VB. A better technique is not always winner.
Well the bizarre thing is that Tcl was a Sun product at one point...
Kristoffer Lawson
: Really? I've never heard anyone suggest using java for performance-critical
: applications. Interesting.
Oh I've seen it mentioned in a couple of places. Probably most recently
on the Jacl/Tcl Blend pages where it says something like "parts of
the Tcl programs can then be replaced with equivalent Java code for
higher performance".
Right now I'm having a hard time convincing myself that Java is better
for anything. Especially after testing some Tclets...
Cameron Laird
Kristoffer Lawson <se...@fishpool.com> wrote:
>Cameron Laird <cla...@starbase.neosoft.com> wrote:
>
>: Are you comparing GUI applications? Oh, yes; Tk just *em-
>: barrasses* Swing and even AWT. Comparisons of "back-end"
>: work is more ambiguous.
>
>Yes, they were GUI applications... But as mentioned even simple
>iterative tests were sloooow.
>
>: Incidentally, your tests were of particular implementations
>: rather than of the languages.
>
>Well I did test them on both the SGI and Linux. The difference between
>Java and Tcl was so huge that some pretty major improvements would have
>to be made to make much of a difference.
.
.
Mo likely will chime in here. It's a fact that sometimes
Jikes (for example) can be a couple *orders of magnitude*
zippier in some aspects, as compared to JavaSoft's javac.
Everything you've reported about your own experience sounds
entirely sensible. I just think you should know that sur-
prising variations can still be found out in the field.
Cameron Laird
Kristoffer Lawson <se...@fishpool.com> wrote:
.
.
.
>: Absolutely. JPS and ASP are also no better than Tcl for servers. But I have
>: to say that both Sun and Microsoft are successfully in marketing Java and
>: VB. A better technique is not always winner.
>
>Well the bizarre thing is that Tcl was a Sun product at one point...
.
.
Big corporations are just inherently "bizarre things" to
carbon-based lifeforms like us. You're right that that
fact--Sun's temporary ownership of Tcl--involves several
interesting stories.
Mo
>
> "Kristoffer Lawson" <se...@fishpool.com> wrote in message
> news:8lmko6$2bd7$1...@news.bbnetworks.net...
> > A common phrase is that Java is used for larger more performance-critical
> > applications with Tcl as the scripting interface.
>
> applications. Interesting.
Really? You have got to check out the GCJ project, it is a Java
front end to the gcc compiler. With it, you can compile Java to
native code. There is no JVM, so it takes up a small amount of
memory and runs real fast.
http://sources.redhat.com/java/
> > However, I have my doubts
> > about this claim. After testing a few Tcl/Tk-based applications and a
> > couple Java ones in recent days, I must say I have yet to see a single
> > Java application that was faster than a Tk one. In general they tend to
> > be much much slower.
>
> My experience mirrors yours.
Yes, Java GUIs suck. There is no doubt about that. Java without the
AWT is really nice though.
> > Reminds me of the time when we did some simple iteration tests in
> > different languages. Again, Java was by far the slowest of all languages
> > we tried (we tested it both on Linux and SGI). So is the above phrase
> > only a myth?
>
> I suspect so. I've never heard it, personally. In fact, outside of
> comp.lang.tcl, I've *never* heard tcl and java mentioned in the same
> sentence. Shoot, not even in the same paragraph/article/book. But I'll have
> to admit -- I don't travel in Java circles much these days. I'm still in
> recovery from the year I had to do full time java development...
Well, I do what I can, but I am only one man. There was a nice article
about Tcl/Java in sunworld, you can find the link on scriptics.com/java.
Mo DeJong
Red Hat Inc
Mo
>
> Bryan Oakley <boa...@vignette.com> wrote:
> : Really? I've never heard anyone suggest using java for performance-critical
> : applications. Interesting.
>
> on the Jacl/Tcl Blend pages where it says something like "parts of
> the Tcl programs can then be replaced with equivalent Java code for
> higher performance".
>
> Right now I'm having a hard time convincing myself that Java is better
> for anything. Especially after testing some Tclets...
Well, I would counter that Java is better for writing a Tcl extension
than C. You can write a Tcl extension in Java and ship a .jar file with
the .class file and .tcl files for your extension. That is much easier
than trying to get people to compile your native C code.
Cameron Laird
.
.
.
>Well, I do what I can, but I am only one man. There was a nice article
>about Tcl/Java in sunworld, you can find the link on scriptics.com/java.
.
.
Also through
<URL:http://starbase.neosoft.com/~claird/comp.lang.java/jacl.html>.
Joe English
>
>Well, I would counter that Java is better for writing a Tcl extension
>than C. You can write a Tcl extension in Java and ship a .jar file with
>the .class file and .tcl files for your extension. That is much easier
>than trying to get people to compile your native C code.
Am I the only one here who has a hard time
installing Java code?
It seems that everytime I download a new nifty
Java package off the net I end up spending a quarter of
an hour diddling with my CLASSPATH, clicking through
pages and pages of mostly-worthless JavaDoc'ed HTML
to find out which class defines 'main' and adding
Yet Another Alias to my .bashrc to call
'java com.NiftyCo.apps.frobnicator.NiftyMain $*'.
And I've *never* successfully compiled a Java program from
source, but that's probably just 'cause I haven't
bothered to figure out how to do it yet...
With Tcl packages, the magic incantation './configure;make;
make install;' and 'package require NiftyPackage'
works for me at least *half* the time...
--Joe English
Mo
You should download and install Jacl (Tcl implemented in Java)
ftp://ftp.scriptics.com/pub/tcl/java/jacl1.2.6.tar.gz
The install process is as follows:
tar -xzvf jacl1.2.6.tar.gz
cd jacl1.2.6
./configure
make install
jaclsh
There is a money back guarantee if you don't love it :)
Kristoffer Lawson
: Well, I would counter that Java is better for writing a Tcl extension
: than C. You can write a Tcl extension in Java and ship a .jar file with
: the .class file and .tcl files for your extension. That is much easier
: than trying to get people to compile your native C code.
True.. but I might be tempted to just simply directly access the Java
libraries from Tcl and build extensions that way. I think that is possible
with Tcl Blend.
Kristoffer Lawson
: Really? You have got to check out the GCJ project, it is a Java
: front end to the gcc compiler. With it, you can compile Java to
: native code. There is no JVM, so it takes up a small amount of
: memory and runs real fast.
Ah yes, naturally that would be much faster. What I really should've said
is that I'm not convinced that Java applications running in the JVM
are ever faster than equivalent Tcl ones. Naturally compiling things
changes that completely, but then you miss half of the point in Java.
Steve Offutt
Mo <m...@nospam.com> wrote:
>
> Well, I would counter that Java is better for writing a Tcl extension
> than C. You can write a Tcl extension in Java and ship a .jar file
with
> the .class file and .tcl files for your extension. That is much easier
> than trying to get people to compile your native C code.
>
Mo,
Could you please post a simple example, or a link to one?
Thanks
Steve
--
Steve Offutt
*Learning* to program is my hobby
Sent via Deja.com http://www.deja.com/
Before you buy.
lvi...@cas.org
According to Joe English <jeng...@flightlab.com>:
:Am I the only one here who has a hard time
:installing Java code?
<hand_held_high>
No, I'm with you Joe. The few Java apps that I ever DID get to run
required me to write (or at least use) a /bin/sh command to set all
the various appropriate environment variables so that the correct version
of JVM, with the correct CLASSPATHs, were all set so that the application
would a) run and b) not cause any other Java enabled app to fail.
If I am not mistaken, I even had that experiencing trying to use the
TclBlend package...
:With Tcl packages, the magic incantation './configure;make;
:make install;' and 'package require NiftyPackage'
:works for me at least *half* the time...
Works for me far greater than half the time...
--
<URL: https://secure.paypal.com/refer/pal=lvirden%40yahoo.com>
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Mo
>
> In article <397F4D1C...@nospam.com>,
> Mo <m...@nospam.com> wrote:
>
> >
> > Well, I would counter that Java is better for writing a Tcl extension
> > than C. You can write a Tcl extension in Java and ship a .jar file
> with
> > the .class file and .tcl files for your extension. That is much easier
> > than trying to get people to compile your native C code.
> >
> Mo,
>
> Could you please post a simple example, or a link to one?
Well, I don't have one on me, but if you would be willing to
write one up, I am sure we could get it posted on the
tcljava web page. The key to the whole thing would be the
way to can use the source command with the resource: sting
at the front of a file name, like so:
source resource:mypkg/foo/myfile.tcl
That will use the JVM's "resource loader" to grab the file
out of a .jar file on the CLASSPATH.
Download Jacl and jive it a quick test run to see what I
mean.
Mo
>
> Mo <m...@nospam.com> wrote:
> : Really? You have got to check out the GCJ project, it is a Java
> : front end to the gcc compiler. With it, you can compile Java to
> : native code. There is no JVM, so it takes up a small amount of
> : memory and runs real fast.
>
> Ah yes, naturally that would be much faster. What I really should've said
> is that I'm not convinced that Java applications running in the JVM
> are ever faster than equivalent Tcl ones. Naturally compiling things
> changes that completely, but then you miss half of the point in Java.
I don't agree. You can always compile from .class files to native
code using gcj. That means you can use all your Java tools and
deal with nice cross platform .class files. When you want to actually
install the system on a server or embeded box, you can just
recompile the .class files to native code. That skipps the need for
a JVM and a JIT, so you save lots of memory and it all runs a lot
faster.
I have actually been thinking that it would be really cool to
take Tcl byte codes and write them out a JVM bytecodes using
that cool Tcl Bytecode->C converter that was posted a little
while back. You could then compile the byte codes into native
code, kind of a hack but real neat no the less.
Donal K. Fellows
Darel Finkbeiner <myt...@mailandnews.com> wrote:
> I used Java + Swing for a couple of major projects. After doing
> that, I tried out Tcl/Tk because I wanted to see if it could do some
> simple stuff. Oh.... My..... God!!!! Unless Java goes through a
> complete rewrite I am never going back.
The thing about Swing is that it is built on an extremely general
graphics architecture that allows some *seriously* funky stuff
(spinning semi-transparent windows, for example.) The problem with
this is that it is also very computationally expensive, and makes the
whole GUI treacliform.
Tk, by comparison, doesn't even attempt to do this, and so can go much
faster. The fact that it is also implemented pretty close to the
metal (as far as GUI toolkits go) helps as well, as does the sheer
quantity of cacheing and the quality of the hash table code.
By comparison, non-GUI Java code is (with a few tricks, admittedly)
within a factor of about 2 of heavily optimised C or FORTRAN. Not bad
for an interpretable language less than 10 years old...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- I may seem more arrogant, but I think that's just because you didn't
realize how arrogant I was before. :^)
-- Jeffrey Hobbs <jeffre...@ajubasolutions.com>
Kristoffer Lawson
: :With Tcl packages, the magic incantation './configure;make;
: :make install;' and 'package require NiftyPackage'
: :works for me at least *half* the time...
: Works for me far greater than half the time...
Depends what you're doing it on. If you happen to run the same machine
as the guy who created the software (usually Linux) then it'll probably
work fine. Then try it on another machine and chances are it'll fail.
./configure is supposed to take care of all that, but I'm not 100%
convinced ;-)
Kristoffer Lawson
: I don't agree. You can always compile from .class files to native
: code using gcj. That means you can use all your Java tools and
: deal with nice cross platform .class files. When you want to actually
: install the system on a server or embeded box, you can just
: recompile the .class files to native code. That skipps the need for
: a JVM and a JIT, so you save lots of memory and it all runs a lot
: faster.
Yes, but nothing's really stopping you from doing that with C source.
I admit, though, that a .class -> binary compiler is pretty neat although
I'm not quite sure why it's better than a .java -> binary compiler?
Dan Kuchler
>
> Yes, but nothing's really stopping you from doing that with C source.
> I admit, though, that a .class -> binary compiler is pretty neat although
> I'm not quite sure why it's better than a .java -> binary compiler?
The point is that you don't need to ship "source" around at all. You
are
shipping around a compiled .class file, which is still platform
independent.
This way, if you are working on something that isn't open-source, you
can
distribute the java class files, without the source.
If the person who wants to run them, doesn't want to have to use a jvm
or
jit, they can just compile them into binaries.
--Dan
Kristoffer Lawson
: The thing about Swing is that it is built on an extremely general
: graphics architecture that allows some *seriously* funky stuff
: (spinning semi-transparent windows, for example.)
I wonder why anyone would want spinning or semi-transparent windows
(transparent menus/dialogs can be useful)? OTOH would make sense on an
SGI ;-)
: By comparison, non-GUI Java code is (with a few tricks, admittedly)
: within a factor of about 2 of heavily optimised C or FORTRAN. Not bad
: for an interpretable language less than 10 years old...
Not the last time I tested it.. (admittedly the tests were simple).
Any clues as to why simple IO and loops and things like that would
be so much slower than anything else we tried? Have the JVMs improved much
lately?
Cameron Laird
.
.
>The thing about Swing is that it is built on an extremely general
>graphics architecture that allows some *seriously* funky stuff
>this is that it is also very computationally expensive, and makes the
>whole GUI treacliform.
>
>Tk, by comparison, doesn't even attempt to do this, and so can go much
>faster. The fact that it is also implemented pretty close to the
>metal (as far as GUI toolkits go) helps as well, as does the sheer
>quantity of cacheing and the quality of the hash table code.
>
>within a factor of about 2 of heavily optimised C or FORTRAN. Not bad
>for an interpretable language less than 10 years old...
.
.
All true, to the point that it bears repeating.
My favorite Swing generality-perhaps-to-excess is all the
stuff built on top of TextPane that provides for callbacks
which distinguish whether you're backspacing leftwards or
rightwards within a block of rightways or leftways (Arabic,
Hebrew, ...) text.
Cameron Laird
>: within a factor of about 2 of heavily optimised C or FORTRAN. Not bad
>: for an interpretable language less than 10 years old...
>
>Any clues as to why simple IO and loops and things like that would
>be so much slower than anything else we tried? Have the JVMs improved much
>lately?
.
.
Yes, and different ones differ a great deal. A GREAT deal.
Donal K. Fellows
> : within a factor of about 2 of heavily optimised C or FORTRAN. Not bad
> : for an interpretable language less than 10 years old...
>
> Not the last time I tested it.. (admittedly the tests were simple).
Well, my experiments (with 1.1.7 on Solaris using the Sun JDK) when
running a full application ported from C gave that sort of performance
figure (the software is also much easier to maintain and understand;
all that crufty memory management code is just gone!) and I've heard
similar results from people doing advanced matrix ops, though they
found it difficult to actually get this close (the C/FORTRAN
optimisers are very good indeed...)
> Any clues as to why simple IO and loops and things like that would
> be so much slower than anything else we tried?
There are lies, damned lies and benchmarks. It is with good reason
that processor speed is measured in MIPS, known in the industry as
Meaningless Indications of Processor Speed. The only way to conduct a
fair test is to code a full app up in the two languages and compare
their actual measured performance (e.g. how many minutes to perform a
certain very expensive operation, how many million-element matrices
can have their gaussians eliminated per hour, etc.)
> Have the JVMs improved much lately?
Yes. Try searching for Hotspot...
Donal K. Fellows
> The few Java apps that I ever DID get to run required me to write
> (or at least use) a /bin/sh command to set all the various
> appropriate environment variables so that the correct version of
> JVM, with the correct CLASSPATHs, were all set so that the
> application would a) run and b) not cause any other Java enabled app
> to fail.
Much easier to do with 1.2.* though using a shell-script wrapper is
still the easiest technique.
> According to Joe English <jeng...@flightlab.com>:
>> With Tcl packages, the magic incantation './configure;make;
>> make install;' and 'package require NiftyPackage'
>> works for me at least *half* the time...
>
> Works for me far greater than half the time...
However, writing a good configure script is non-trivial, even with
autoconf. Particularly if you are using features that are somewhat
unusual...
Donal K. Fellows
> I don't agree. You can always compile from .class files to native
> code using gcj. That means you can use all your Java tools and
> deal with nice cross platform .class files. When you want to actually
> install the system on a server or embeded box, you can just
> recompile the .class files to native code. That skipps the need for
> a JVM and a JIT, so you save lots of memory and it all runs a lot
> faster.
How does this work with dynamic loading of classes? Some of the most
interesting servers are those that take active code from their clients
and do something with it...
lvi...@cas.org
According to Kristoffer Lawson <se...@fishpool.com>:
:lvi...@cas.org wrote:
:: :With Tcl packages, the magic incantation './configure;make;
:: :make install;' and 'package require NiftyPackage'
:: :works for me at least *half* the time...
:: Works for me far greater than half the time...
:Depends what you're doing it on. If you happen to run the same machine
:as the guy who created the software (usually Linux) then it'll probably
:work fine. Then try it on another machine and chances are it'll fail.
I've never used a Linux box - I use SPARC Solaris. But perhaps it is
similar enough to Linux for things to work fine.
<Shrug>I just don't know</Shrug>.
Kristoffer Lawson
: There are lies, damned lies and benchmarks. It is with good reason
: that processor speed is measured in MIPS, known in the industry as
: Meaningless Indications of Processor Speed. The only way to conduct a
: fair test is to code a full app up in the two languages and compare
: their actual measured performance (e.g. how many minutes to perform a
: certain very expensive operation, how many million-element matrices
: can have their gaussians eliminated per hour, etc.)
Yes, naturally. I know the story. But still.. if one were to optimize
performance for an environment I'd imagine that simple IO, iterations
and method calling would be the first place to start...
Kristoffer Lawson
: I've never used a Linux box - I use SPARC Solaris. But perhaps it is
: similar enough to Linux for things to work fine.
: <Shrug>I just don't know</Shrug>.
It's probably partly because Solaris would be the second platform people
test on. Then when I try to do the same on IRIX (SGI) something doesn't
work, and it's almost always just careless coding or incomplete configuration.
Or then it requires that I use gcc because it want to use "some nice
trick" :P
Donal K. Fellows
Kristoffer Lawson <se...@fishpool.com> wrote:
> Yes, naturally. I know the story. But still.. if one were to optimize
> performance for an environment I'd imagine that simple IO, iterations
> and method calling would be the first place to start...
They've actually focussed on array accesses and casts, IIRC. (The
former because it is what the HPC people want, and the latter because
Java is still annoyingly cast-heavy, and they are much more expensive
than in C...)
Anthony Green
Donal wrote:
> How does this work with dynamic loading of classes? Some of the most
> interesting servers are those that take active code from their clients
> and do something with it...
It works pretty well. GCJ compiled code can fish natively compiled
classes out of dynamic shared libraries, as well as load and interpret
classes from .class files. You just ask for a class and the class
loader will look for something appropriate and use it. It's pretty
spiffy.
AG
--
Anthony Green Red Hat
Sunnyvale, California
Donal K. Fellows
Anthony Green <gr...@cygnus.com> wrote:
> It works pretty well. GCJ compiled code can fish natively compiled
> classes out of dynamic shared libraries, as well as load and interpret
> classes from .class files. You just ask for a class and the class
> loader will look for something appropriate and use it. It's pretty
> spiffy.
Lets see if I understood that correctly. It uses the compiled version
if its got it (for appropriatly security/domain-aware definitions of
"got it") and falls back to interpreting/JIT otherwise?
Sounds reasonable to me...