I made my own version of the ray-tracing program (as I tried to
understand it). I didn't use pp_def, only Perl and ordinary PDL. I used
ndarrays indexed by the three wavelengths and the entrance height,
$size of them (I tested $size=10000 and 100000), so the calculations
could have been significant, although I threw them all away except for
the last one, being the one that is compared to the reference. I
made a Perl loop to reach the desired number of iterations. The
program inherits part of the style of the original one, but I did made
some changes here and there.
With a million total iterations the results are
$ time perl fbench.pl 1000000 # The original code
Ready to begin John Walker's floating point accuracy
...
Press return to begin benchmark:
Stop the timer:
No errors in results.
real 0m39.521s
user 0m35.693s
sys 0m0.013s
$ perl fbench2.pl 1000000 # My version
Ready to begin John Walker's floating point accuracy
...
No errors in results.
Iterations: 1000000, Elapsed time: 4.27540707588196
The results don't change more if I change $size. I tried using more
cores with
$ PDL_AUTOPTHREAD_SIZE=0 PDL_AUTOPTHREAD_TARG=4 perl fbench2.pl 1000000
Ready to begin John Walker's floating point accuracy
...
No errors in results.
Iterations: 1000000, Elapsed time: 4.50635004043579
I checked that all the cores of my laptop became active, but the time
didn't change much. It is slightly faster with only 2 cores. I haven't
tested the C version in my laptop, and the tests above relatively
short, so I don't know what grade it would get in the benchmark, but
the speed seems to be about ten times faster than pure perl, so if it
was at 23 times slower than C, now it is only 2.3 times slower. I
haven't compared with Ed's program yet.
I put my code in
https://github.com/wlmb/floating_point_benchmarks/blob/altperl/src/perl/fbench2.pl
Regards,
Luis
On Sat, Oct 02, 2021 at 01:55:51PM +0000, Ed . wrote:
> 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
--
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 /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel
