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-general@lists.sourceforge.net>; perldl<mailto:pdl-de...@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-general@lists.sourceforge.net>; perldl<mailto:pdl-de...@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 /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB _______________________________________________ pdl-devel mailing list pdl-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
_______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
