[music-dsp] JIT Compilers

[Christopher Weare]

I agree that JIT'ing has great potential.  I would argue, however, that
we are still a bit away from seeing JIT'ers outperform native code on
real-world applications.

-chris

-----Original Message-----
From: music-dsp-bounces at shoko.calarts.edu
[mailto:music-dsp-bounces at shoko.calarts.edu] On Behalf Of Jeff
McClintock
Sent: Monday, February 02, 2004 6:18 PM
To: music-dsp at shoko.calarts.edu
Subject: [music-dsp] JIT Compilers

> > Are there particular mechanisms that have been claimed to
> > allow  JITseed>Native speed?

> However, I don't think that any Java machines really compete with
compiled
code.  Likewise although MS is pushing it hard I don't  expect c# to be
faster than Native.

I read some very interesting info from Transmeta, they manufacture a CPU
that converts X86 code to VLIW on the fly (with the help of software).
They
claim a JIT (just in time) compiler can create faster code than a
compiler.
Some of the reasons:
-A JIT compiler can optimise code for your exact CPU (AMD or Intel, P1
or
P4), a standard compiler usually creates a 'blended' optimisation (a
compromise between all CPU types).
-Branch mis-predictions are very expensive on a pipelined processor. A
JIT
compiler can analyse branch instructions depending on your actual code
usage
( a standard compiler can only predict branches based on an informed
guess).
-A JIT compiler can watch the actual calling sequence of the program,
and
re-arrange your routines in memory, so the most-used path is a continous
section of memory (kind of like defragging your code).  This saves a lot
of
cache misses, a big advantage with todays CPUs.

All this extra run-time information allows the JIT compiler to tailor
the
code to your exact system, and even to your particular usage pattern
(what
features of the software you use most).

A fascinating subject.

more...
http://slashdot.org/features/00/01/26/197211.shtml

Best Regards,
Jeff






> Message: 1
> Date: Sat, 31 Jan 2004 20:48:33 -0000
> From: "Ed Wildgoose" <lists at wildgooses.com>
> Subject: Re: [music-dsp] C# Interpolation Code
> To: "a list for musical digital signal processing"
> <music-dsp at shoko.calarts.edu>
> Message-ID: <053201c3e83b$99e51eb0$0369a8c0 at BigMotha>
> Content-Type: text/plain; charset="iso-8859-1"
>
> > Are there particular mechanisms that have been claimed to
> > allow  JITseed>Native speed?
>
> The Java jit folks always claimed that memory allocation was actually
faster in the jit than native.  I forget the exact logic now,
> but it was actually plausible and appeared to be accurate.
>
> However, I don't think that any Java machines really compete with
compiled
code.  Likewise although MS is pushing it hard I don't
> expect c# to be faster than Native.
>
> However, I have written a huge amount of stuff (non DSP) in VB (partly
interpretted, certainly not native speed) over the last 8+
> years, and the speed has not usually been an issue for me.  Depends on
your problem I should think.  C# looks like a nice tool to
> me.


dupswapdrop -- the music-dsp mailing list and website: 
subscription info, FAQ, source code archive, list archive, book reviews,
dsp links 
http://shoko.calarts.edu/musicdsp 
http://ceait.calarts.edu/mailman/listinfo/music-dsp