I like Java and would like to use it in 2 different ways:
-
As a UI programming language. Here I value the portability
and running interpreted is no disadvantage.
-
As a general (non UI) programming language. Here I value
performance above all else, and portability is not as
important, hence, running interpreted is a disadvantage.
Usage (1) is currently covered pretty well. Usage (2) is AFAIK
not covered at all. It seems that the presence of gcj would
address usage (2), so my question is, does QSS have any plans
to officially support gcj as a compiler ?
It seems to me to suck greatly that I have to use C or C++ to
code one half of my app and Java to code the other half, when I
could use Java for probably 98% (maybe a few JNI/CNI things
in C). I realize the tools aren’t really there yet, but I’d
like to know if this is a direction that QSS will be pursuing ?
- As a general (non UI) programming language. Here I value
performance above all else, and portability is not as
important, hence, running interpreted is a disadvantage.
You might want to actually check some performance numbers for gcj…
http://www.shudo.net/jit/perf/
http://www.mail-archive.com/classpath@gnu.org/msg05994.html
http://www.spindazzle.org/benchmarks/
So it isn’t as if gcj is a clear winner and in many cases it is slower then
IBM’s and Sun’s JIT JVM. And since the most current j9’s have very good
JIT and AOT options, it’s not like your code is actually being executed
in interpreted mode.
All that being said, it would be nice to have support someday for gcj.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris McKillop wrote:
So it isn’t as if gcj is a clear winner and in many cases it is slower then
IBM’s and Sun’s JIT JVM. And since the most current j9’s have very good
JIT and AOT options, it’s not like your code is actually being executed
in interpreted mode.
Maybe I’m missing something ? How to get AOT ? I have tried “j9 -X” and
“j9 -help”.
All that being said, it would be nice to have support someday for gcj.
All I care about is exec performance. If it is sufficiently fast for
my intended use that’s all I care about. If j9 can do it, that’s cool,
I just haven’t seen j9 perform anywhere near that of native code yet
(QSSs’ stated requirements for eclipse are a 1Ggz processor or better).
I have a simple java class that lists the contents of a directory. The
time it takes to simply load, is longer than “ls” takes to print the
entire directory. I don’t care about load time (within reason of course),
but I do care about the irregular performance of jit. AOT might be the
answer (I presume that means all classes are translated from byte code
to native instructions prior to execution ?).
Thanks for the pointers to the benchmarks, and for responding.
Rennie Allen <rallen@csical.com> wrote:
Chris McKillop wrote:
So it isn’t as if gcj is a clear winner and in many cases it is slower then
IBM’s and Sun’s JIT JVM. And since the most current j9’s have very good
JIT and AOT options, it’s not like your code is actually being executed
in interpreted mode.
Maybe I’m missing something ? How to get AOT ? I have tried “j9 -X” and
“j9 -help”.
You are probably not running the lastest j9. We don’t ship with it yet.
If you have a support plan you can get a “newer then we use for Eclipse”
j9 from the WSDD packages on myQNX. Otherwise you will need to wait for
our next product release.
All I care about is exec performance. If it is sufficiently fast for
my intended use that’s all I care about. If j9 can do it, that’s cool,
I just haven’t seen j9 perform anywhere near that of native code yet
(QSSs’ stated requirements for eclipse are a 1Ggz processor or better).
I have a simple java class that lists the contents of a directory. The
time it takes to simply load, is longer than “ls” takes to print the
entire directory. I don’t care about load time (within reason of course),
but I do care about the irregular performance of jit. AOT might be the
answer (I presume that means all classes are translated from byte code
to native instructions prior to execution ?).
Thanks for the pointers to the benchmarks, and for responding.
Well, gcj won’t perform at native code levels either. Most of the startup
time is spent it setting up the environment - which gcj has to do just as
much j9 (all before the actual app is running).
chris
\
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
AOT is a development tooling issue. To obtain AOT, you need
IBM WebSphere Studio Device Developer tools.
The AOT technology is also used to enable JIT compilation in
the runtime.
My advice is to evaluate WSDD, then if you want to buy it,
order it directly from Handango. Since it’s cross-platform, it
will work with the Neutrino WSDD runtime ports available from
the account centre.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3F7C8878.6000407@csical.com…
Chris McKillop wrote:
So it isn’t as if gcj is a clear winner and in many cases it is slower
then
IBM’s and Sun’s JIT JVM. And since the most current j9’s have very good
JIT and AOT options, it’s not like your code is actually being executed
in interpreted mode.
Maybe I’m missing something ? How to get AOT ? I have tried “j9 -X” and
“j9 -help”.
All that being said, it would be nice to have support someday for gcj.
All I care about is exec performance. If it is sufficiently fast for
my intended use that’s all I care about. If j9 can do it, that’s cool,
I just haven’t seen j9 perform anywhere near that of native code yet
(QSSs’ stated requirements for eclipse are a 1Ggz processor or better).
I have a simple java class that lists the contents of a directory. The
time it takes to simply load, is longer than “ls” takes to print the
entire directory. I don’t care about load time (within reason of course),
but I do care about the irregular performance of jit. AOT might be the
answer (I presume that means all classes are translated from byte code
to native instructions prior to execution ?).
Thanks for the pointers to the benchmarks, and for responding.