* Robin Szemeti <[EMAIL PROTECTED]> [010428 15:50]:
> On Fri, 27 Apr 2001, you wrote:
> > On Fri, 27 Apr 2001, Robin Szemeti wrote:
> > > On Fri, 27 Apr 2001, someone who Robin's attrib to fscked up wrote:
> > >
> > > > [side note: I did just see a bizarre thread in macosx-dev where
> > > > one guy claimed his FFT code was executing faster in Java than C
> > > > because its interpreter used runtime info to optimize it. Search on
> > > > 'informal benchmarks']
> > >
> > > uh huh .. but he's a Java programmer .. his C could be *REALLY* bad ;) ..
> > > favourite Java quote 'If javas garbage collector is damn good, how come
> > > the whole thing doesn't delete itself upon execution?'
> >
> > Don't see why this isn't possible. The idea is that you factor out *all*
> > really unlikely cases (how you know this is based on past performance) and
> > catch them all with some simple test. Then you (more expensively, but who
> > cares since this happens only once in a blue moon) deal with it and work
> > out exactly what was the problem.
>
> my basic point was: that given that the FFT code uses similar technicques
> in both its C and Java variants the C variant will win hands down. if
> you're going to throw in completley new techniques then sure you could
> skew it the other way around .. but in the end (assuming that both
> codesets use similar basic principles) you will not beat the speed of C
> with anything other than hand optimised assembler. Now that is a fact.
I think FFTW does a lot of runtime optimising and even stores it
across runs (called 'wisdom', like the name). But then I think they're using
Ocaml to write the C code, scary. Also uses whatever extra instructions
are there for a each processor.
http://www.fftw.org/
- FFTW is written in ANSI C. Most of the code, however, was
automatically generated by a program called genfft, written in the
Objective Caml dialect of ML.
- FFTW uses an internal interpreter to adapt itself to a machine.
- FFTW uses a code generator to produce highly-optimized routines
for computing small transforms.
--
Brad Bowman
