Reduce has dreadful performance? (page 2)

On Thursday, 18 June 2015 at 18:55:25 UTC, Russel Winder wrote: > On Thu, 2015-06-18 at 10:46 +0000, Ilya Yaroshenko via Digitalmars-d wrote: >> > […] >> Looks like you forgot optimisation troika "-O -inline -release" >> > > Don't I feel stupid :-) > > Thanks to all for quick answers, most helpful. > > Now I get > > Loop: 3.14s > Reduce 1: 4.76s > Reduce 2: 5.12s > > This is DMD 2.067 > > Anyone know how to get PyD to use LDC rather than DMD in the setuptools build spec? > > (I can't use GDC just now as it is not packaged for Fedora.) python setup.py pydexe --compiler=ldc

On Thursday, 18 June 2015 at 20:18:31 UTC, Laeeth Isharc wrote: > On Thursday, 18 June 2015 at 18:55:25 UTC, Russel Winder wrote: >> On Thu, 2015-06-18 at 10:46 +0000, Ilya Yaroshenko via Digitalmars-d wrote: >>> >> […] >>> Looks like you forgot optimisation troika "-O -inline -release" >>> >> >> Don't I feel stupid :-) >> >> Thanks to all for quick answers, most helpful. >> >> Now I get >> >> Loop: 3.14s >> Reduce 1: 4.76s >> Reduce 2: 5.12s >> >> This is DMD 2.067 >> >> Anyone know how to get PyD to use LDC rather than DMD in the setuptools build spec? >> >> (I can't use GDC just now as it is not packaged for Fedora.) > > python setup.py pydexe --compiler=ldc GDC doesn't work anyway, I think, because of the shared library problem. would be great to have a dub setup so one can build in a standard way without using python.

On 6/18/2015 7:04 AM, Russel Winder via Digitalmars-d wrote: > Now I get > > Loop: 3.14s > Reduce 1: 4.76s > Reduce 2: 5.12s I expect that at the moment, range+algorithms code will likely be somewhat slower than old fashioned loops. This is because code generators have been tuned for decades to do a great job with loops. There's no intrinsic reason why ranges must do worse, so I expect they'll achieve parity. Ranges can move ahead because they can reduce the algorithmic complexity, whereas user written loops tend to be suboptimal.

On Thursday, 18 June 2015 at 20:53:20 UTC, Walter Bright wrote: > On 6/18/2015 7:04 AM, Russel Winder via Digitalmars-d wrote: >> Now I get >> >> Loop: 3.14s >> Reduce 1: 4.76s >> Reduce 2: 5.12s > > > I expect that at the moment, range+algorithms code will likely be somewhat slower than old fashioned loops. This is because code generators have been tuned for decades to do a great job with loops. > > There's no intrinsic reason why ranges must do worse, so I expect they'll achieve parity. > > Ranges can move ahead because they can reduce the algorithmic complexity, whereas user written loops tend to be suboptimal. ldc and gdc have no issue optimizing the range code(range code is actually faster with ldc)

June 18, 2015

Re: Reduce has dreadful performance?

Posted by Andrei Alexandrescu
in reply to weaselcat

Permalink

Andrei Alexandrescu

Posted in reply to weaselcat

Permalink

On 6/18/15 2:04 PM, weaselcat wrote:
> On Thursday, 18 June 2015 at 20:53:20 UTC, Walter Bright wrote:
>> On 6/18/2015 7:04 AM, Russel Winder via Digitalmars-d wrote:
>>> Now I get
>>>
>>> Loop: 3.14s
>>> Reduce 1: 4.76s
>>> Reduce 2: 5.12s
>>
>>
>> I expect that at the moment, range+algorithms code will likely be
>> somewhat slower than old fashioned loops. This is because code
>> generators have been tuned for decades to do a great job with loops.
>>
>> There's no intrinsic reason why ranges must do worse, so I expect
>> they'll achieve parity.
>>
>> Ranges can move ahead because they can reduce the algorithmic
>> complexity, whereas user written loops tend to be suboptimal.
>
> ldc and gdc have no issue optimizing the range code(range code is
> actually faster with ldc)

Russel, do you have numbers for ldc by any chance? Thx! -- Andrei

On Thursday, 18 June 2015 at 20:18:31 UTC, Laeeth Isharc wrote: > On Thursday, 18 June 2015 at 18:55:25 UTC, Russel Winder wrote: >> On Thu, 2015-06-18 at 10:46 +0000, Ilya Yaroshenko via Digitalmars-d wrote: >>> >> […] >>> Looks like you forgot optimisation troika "-O -inline -release" >>> >> >> Don't I feel stupid :-) >> >> Thanks to all for quick answers, most helpful. >> >> Now I get >> >> Loop: 3.14s >> Reduce 1: 4.76s >> Reduce 2: 5.12s >> >> This is DMD 2.067 >> >> Anyone know how to get PyD to use LDC rather than DMD in the setuptools build spec? >> >> (I can't use GDC just now as it is not packaged for Fedora.) > > python setup.py pydexe --compiler=ldc Just a note: if you're using PydMagic you can pass --compiler=ldc to %%pyd

On Thu, 2015-06-18 at 15:54 -0700, Andrei Alexandrescu via Digitalmars-d wrote: > […] > > Russel, do you have numbers for ldc by any chance? Thx! -- Andrei Single data point only, and I need to check this, but: Loop: 1.44s Reduce 1: 1.43s Reduce 2: 1.42s LDC seems to beat DMD into the ground. But then I think we all know this ;-) The PyD setuptools support appears to not properly ser RPATH which is a bit annoying. Actually it is a lot annoying. -- Russel. ============================================================================= Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.winder@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder

On Thu, 2015-06-18 at 20:18 +0000, Laeeth Isharc via Digitalmars-d wrote: > […] > > python setup.py pydexe --compiler=ldc I now have this working and reduce is no longer an embarrassment. Also we have reaffirmed that LDC is the tool of choice and DMD unusable. But this surprises no-one involved with CPU-bound activity I suspect. -- Russel. ============================================================================= Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.winder@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder

On Thu, 2015-06-18 at 13:53 -0700, Walter Bright via Digitalmars-d wrote: > […] > > There's no intrinsic reason why ranges must do worse, so I expect they'll achieve parity. > reduce already has achieved parity using LDC – once you install it properly, unlike what I had been doing. Explicit loops are just so last millenium. :-) PyData London 2015 here we come. -- Russel. ============================================================================= Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.winder@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder

On Saturday, 20 June 2015 at 05:55:07 UTC, Russel Winder wrote: > On Thu, 2015-06-18 at 15:54 -0700, Andrei Alexandrescu via Digitalmars-d wrote: >> […] >> >> Russel, do you have numbers for ldc by any chance? Thx! -- Andrei > > Single data point only, and I need to check this, but: > > Loop: 1.44s > Reduce 1: 1.43s > Reduce 2: 1.42s > > LDC seems to beat DMD into the ground. > > But then I think we all know this ;-) > > The PyD setuptools support appears to not properly ser RPATH which is a bit annoying. Actually it is a lot annoying. Interesting, I saw a bigger speedup from the ranges. Do you use windows? What LLVM/LDC version? flags?

Forums