[ Quoting Denis Tonn to Scott Little ]
 DT> Sure. SUN is developing one such. This does NOT mean that Java is CPU
 DT> specific, as you claimed.
To be of any real use it has to be compiled for specific CPUs. JITs and
interpreters just can't cut it.
 DT> concept that Java was tightly tied to a specific CPU, a RISC CPU to be
 DT> specific.
The bytecode is more easily translated into RISC CPU code. CISC JITs &
interpreters have a lot more work to do to do the same job.
 DT> Where do you get your "numbers" that support the contention that
 DT> SUN's CPU is faster than JIT code?
From the APC magazine, December 1996. The benchmarks were performed by Sun,
not APC Labs.
                               Javac Tests     RayTracer Tests
Pentium with Java interpreter: 20.4 seconds    174.3 seconds
   "     "   JIT compiler       9.3             64.5
picoJava                        1.8             13.0
 DT> code, but this is because it is already "JIT compiled" by nature.
JIT still compile on the fly. However they cache already compiled code and
precompile code to be used and cache that too.
 DT> Every "number" I have ever seen shows that a good JIT compiler will 
 DT> equal the results of running the same app on SUN's CPU.
That is not possible (not on CPUs of equal speed). You are saying that a
computer with a JIT compiler can translate and run a program in the same 
amount
of time that it takes the Java CPU to simply execute it immediatly.
 
 DT> But this leads me to ask why you are running Win95. Wouldn't you be 
 DT> better off running straight DOS and only assembler programs that run 
 DT> native to the metal?
Which I would prefer, however DOS doesn't multitask, and OS2 does not run
DOS programs nativly (ie. without addon support).
 DT> Even most games are being written in high level languages today. Are 
 DT> you satisfied playing only the games written totally in assembler?
If there was a choice, I'd wait for and use the assembler one. But since 
here
isn't, I will use the one that is released.
Programmers today are just plain lazy. They rely heavily on high-end 
processing
power rather than their own efficient code to produce a fast program.
 DT> compilers should be able to approach the same performance as anything
 DT> coded in "C", and the same performance as SUN's "Java bytecode" CPU.
If the Java code was compiled into CPU specific versions there would be no
problem. JITs cannot match CPU specific, precompiled executables.
 
 SL> every time it's executed. It would make much more sense to kill JITs and
 DT> But this is EXACTLY the step that a JIT compiler is intended to
 DT> correct. A JIT compiler "pretranslates" the Java bytecodes to native 
 DT> opcodes.
Yes, but it does it EVERY TIME it is executed. I'm talking about converting
the program to native code and storing that on disk so it can be executed
later.
 DT> Question: What did you think a JIT compiler actually does?
"Just-in-time compilers translate Java bytecode into native code like
interpreters do, but they don't have to translate the same code over and over
again because they cache the native code. This can result in significant
performance improvements, but sometimes a JIT compiler takes an unacceptable
amount of time and memory to do its job."
 
 DT> This already happens. The JIT compiler will leave the results of it's
 DT> compile around for the next use.
Since when? And where does it leave these results? What if I have a 300 meg
graphics suite written in Java. Does it save 300 meg of native code as well,
making the total size 600meg?
A straight out, permanent conversion is the best method. That way, the entire
program is native code, and there is no JIT taking up valuable memory and
CPU time, and no Java bytecode taking up space.
 DT> is when it first runs, or when it is changed. It doesn't "precompile" 
 DT> every time it runs, this would be inefficient. Give the JIT compiler 
 DT> writers some credit. You are not the first to have this "objection".
These must be the latest wave of JIT compilers. They don't really fit into
the definition of JIT if they save native code.
Regards,
 - Scott
[ admin@cyberia.asstdc.com.au | www.asstdc.com.au/~cyberia ]
--- FMailX 1.22
3:712/848)
---------------