On 5 May 2010, at 09:25, Craig DeForest wrote:
> Jarle,
>
> Neat stuff.
>
> The PDL/IDL split has been known anecdotally for a long time -- the
> PP engine really does well at generating vector code, and RSI have
> long touted the efficiency of IDL vector code. Both languages are
> probably RAM bound and not significantly different in speed when
> they are inside large(r than cache) vector operations.
Yes, indeed. Some parts of IDL (the HISTOGRAM function most
notoriously) is extremely fast - I can't beat the HISTOGRAM routine
with a pure C routine so it is clearly well written.
But interestingly I the two languages do offer different modes of
operation - for IDL I had to do a spread in dimensions to use the
vectorisation routines (memory hit & some speed), while in PDL I could
use the threading engine to save in RAM. I think that is where the
speed gain came in. Threading in PDL is really one of its most
beautiful aspects.
> IDL's interpreter, on the other hand, really blows chunks compared
> to Perl's. It's not legally possible to know what IDL is doing, but
> I suspect it merely tokenizes, rather than JIT-compiling, the
> interpreted code, so the interpreter has to do a lot more work at
> run-time (work that Perl caches up-front).
>
> The python curve is (as Daniel pointed out) surprising - folks in my
> office keep advocating switching to Python, largely because it is
> alleged to be screamingly fast. I'm not enough of a python guy to
> know if there are simple optimizations that are being ignored...
I think Tim cleared this up, but it is still weird that a pure IDL
loop implementation (which as you say is very slow) is faster than
Python with a tiny bit of numpy.
Cheers,
Jarle.
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
