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> 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 . <ej...@hotmail.com> > *Sent: *30 September 2021 16:38 > *To: *Luis Mochan <moc...@icf.unam.mx>; perldl > <pdl-gene...@lists.sourceforge.net>; perldl > <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 <moc...@icf.unam.mx> > *Sent: *28 September 2021 00:47 > *To: *perldl <pdl-gene...@lists.sourceforge.net>; perldl > <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 /\_/\__/ > 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 > > > > > _______________________________________________ > pdl-devel mailing list > 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