I have now updated the PDL version, which now shows speed comparable to C, and 
indeed with the pthreading it’s even faster (which isn’t fun to do in pure C, 
but incredibly trivial in PDL): 
https://github.com/Fourmilab/floating_point_benchmarks/pull/1


From: Ed .<mailto:ej...@hotmail.com>
Sent: 01 October 2021 12:30
To: Boyd Duffee<mailto:boyd.duf...@gmail.com>
Cc: perldl<mailto:pdl-devel@lists.sourceforge.net>; 
perldl<mailto:pdl-gene...@lists.sourceforge.net>
Subject: Re: [Pdl-devel] benchmarks

Hi Boyd,

The problem as stated is difficult to do vectorised because it features such 
small data. It occurred to me today that the way to make PDL shine is simply to 
replace the for-loop with iterations (which isn’t really the PDL way in any 
case) by taking my @input and multiplying all the inputs by adding a dummy 
dimension of the right size (say 1000) so the calculations are done that many 
times in a threaded way, then slicing the output back down. I will do this 
probably tomorrow.

The repo is the one I showed with the pull request on. No-one is particularly 
criticising Perl on this, John simply published accurate numbers. Perl is slow 
with trig functions because as I said in my message, it’s doing pure-Perl which 
means it’s going in and out of Perl-space. To make that fast you’d need to port 
Math::Trig to XS, which is not at all a terrible idea, but I won’t be doing it.

Best regards,
Ed

From: Boyd Duffee<mailto:boyd.duf...@gmail.com>
Sent: 01 October 2021 07:27
To: Ed .<mailto:ej...@hotmail.com>
Cc: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
perldl<mailto:pdl-devel@lists.sourceforge.net>
Subject: Re: [Pdl-devel] benchmarks

I was thinking that the problem was better suited to using a vector approach, 
but I haven't been able to find the original article or reference to the 
technique and I haven't sat down and worked it out from Wyld's loops.  I also 
haven't seen any output from Walker's benchmark scripts.  I ended up dropping 
the iterations down to 1 and let it run for 5 minutes but still nothing, so I 
don't know what I'm doing wrong.

On the wider question of benchmarks, I feel that it's something we as a group 
should get behind to counter the tired criticism of perl is old and slow.  Does 
someone have a repo I can clone to get in on that?

cheers,
Boyd

On Thu, 30 Sept 2021 at 18:52, Ed . 
<ej...@hotmail.com<mailto:ej...@hotmail.com>> wrote:
The pull request now also shows my attempt with a PP function. It’s about twice 
as slow as pure-Perl (rather than 70 times with the naïve version). The way 
this would benefit performance-wise would be to trace rays through many more 
surfaces than 4, or (as mentioned below) with a large number of different ray 
heights. That could then benefit from pthreading.

Comments very welcome on the design of the PP function and its use of threading!

Best regards,
Ed

From: Ed .<mailto:ej...@hotmail.com>
Sent: 30 September 2021 16:38
To: Luis Mochan<mailto:moc...@icf.unam.mx>; 
perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
perldl<mailto:pdl-devel@lists.sourceforge.net>
Subject: RE: [Pdl-devel] benchmarks

Hi Luis,

That was very interesting in the part about Raku, and I think I agree with the 
author’s comments about that language.

I have made a (so-far very naïve) PDL version, visible at 
https://github.com/Fourmilab/floating_point_benchmarks/pull/1/files?diff=unified&w=1.
 This caused some difficulties, exacerbated by John’s technique of functions’ 
inputs and outputs being via globals(!), and the copying of those needing (in 
PDL-land) to be a “->copy” not the normal PDL reference-copy.

As a result of an initially-mistaken analysis of the differences actually 
caused by the copying semantics, I have learned that Perl’s Math::Trig does not 
use a C library function, but calculates the value in pure Perl. This is almost 
certainly why Perl gets correct but slow answers in John’s benchmark (20+ times 
slower than C).

The current naïve PDL version is much slower than the pure-Perl (about 70 
times), because it is using the PDL machinery to calculate single values, which 
PDL isn’t for. For completeness, I will now make the PDL version have a PP 
function will carry out the algorithm in C-land but in a PP-idiomatic way. This 
would then be usable with PDL-threading (including pthreading) to 
simultaneously calculate a large number of ray paths, perhaps for use in making 
a graphical representation of light travelling through refraction paths.

By the way, the Python number of 2.6 times the time for C isn’t scipy, but 
PyPy, a JIT compiler for Python. I won’t be investigating, but I’d assume that 
NumPy/scipy would have the same performance difficulties in this benchmark as 
PDL, and for similar reasons.

Best regards,
Ed

From: Luis Mochan<mailto:moc...@icf.unam.mx>
Sent: 28 September 2021 00:47
To: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
perldl<mailto:pdl-devel@lists.sourceforge.net>
Subject: [Pdl-devel] benchmarks

Hi all,

I read today in a Raku newsletter about a floating point
benchmark of several languages.
    
https://www.fourmilab.ch/scanalyzer/archives/2021/09/floating-point-benchmark-raku-perl-6-language-added.html

Taking C=1 as a reference, Julia=1.5, Python=2.6-30, Perl=23,
Raku=205-735, Mathematica=391.

I guess Perl with PDL would be much faster, as Python with scipy.

Are there any benchmarks that compare PDL's speed to others?

Regards,
Luis





--

                                                                  o
W. Luis Mochán,                      | tel:(52)(777)329-1734     /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388     `>/   /\
Av. Universidad s/n CP 62210         |                           (*)/\/  \
Cuernavaca, Morelos, México          | 
moc...@fis.unam.mx<mailto:moc...@fis.unam.mx>   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/pdl-devel


_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/pdl-devel


--
Boyd Duffee
   Bring on a brand-new renaissance - The Tragically Hip


_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel

Reply via email to