Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] FP's and HyperThreading Processors
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David McClain <dmcclain1@m...>
Subject: Re: [Caml-list] FP's and HyperThreading Processors
> If it was optimized for the P2 it will by definition not be optimized for
> the P4,

Yes, you are correct about this, but I have the Intel numerical libs for the
P4 linked into the program. On the old P2 system, this code spend roughly
60% of its time inside that vendor code for FFT's. This is no longer true,
as other tests show very high performance of just those vendor routines.

Whereas, on the P2 at 350 MHz, I have been able to process audio through 5
stereo pairs of heavy duty (1-4 K) FFT's per data block at rates of around
200 MSamples/sec, this new computer is even faster by a huge amount. I
haven't any numerical rates to give on this just yet, but I can certainly
produce these. The new processor is fast enough to do serious DSP coding on
the P4 directly from compiled OCaml.

What is different about the audio processing code versus my optical phase
retreival code, is that I took care to reuse audo memory buffers. I know
this violates the spirit of FP to some extent, but it was needed to gain
this kind of speedy throughput in OCaml. I did no such optimizations in the
optical analysis code. So clearly, data locality is an important performance
parameter.

By the way, I did not mean to indict any of the high level languages, OCaml,
Lisp, SML, etc. I love these to death! But I also have some experience in
designing memory subsystems aimed at making OO code more efficient.
Specifically, we developed a hardware assist to garbage reclamation. What
I'm really asking is that hardware now become more aware of higher level
language needs. They have shown that they can do a superb job of running
hand crafted efficient low-level code. But they turned their backs on our
more forward looking needs.

Cheers,

- DM


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners