Divide & Conquer divides, but doesn't conquer

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon May 25 18:35:49 UTC 2020


On 5/25/20 12:46 PM, Timon Gehr wrote:
> On 25.05.20 18:04, Andrei Alexandrescu wrote:
>> On 5/25/20 3:15 AM, Max Samukha wrote:
>>> On Monday, 25 May 2020 at 06:18:13 UTC, FeepingCreature wrote:
>>>
>>>> static foreach and stringof were used so I didn't have to pull in 
>>>> `format` or `to!string`, which had issues in std.meta.
>>>>
>>>> I'm seeing some improvement over 2.086 at least; it should be about 
>>>> equivalent to the hand-unrolled version in master.
>>>
>>> How could you miss the state-of-the-art?) Preallocate the result 
>>> string and use the string counter hack!
>>> http://dpldocs.info/this-week-in-d/Blog.Posted_2020_05_11.html#dmd-and-static-foreach 
>>
>>
>>
>> static foreach is quadratic? Is this a matter of principle, or QoI?
>>
> 
> QoI. The original `static foreach` implementation in my compiler 
> frontend runs in linear time, even though it is implemented in a very 
> similar way. Note that even `iota(n).array` has superlinear running time 
> with DMD's CTFE.
> 
> The implementation of `static foreach` in DMD is based on lowering, and 
> the existing "tuple" foreach implementation. I suspect the culprit for 
> bad performance for very large `static foreach` is a slow expression 
> "tuple" implementation, but I am not sure.
> Therefore, maybe performance could be improved by modifying the foreach 
> expansion code such that it can accept a CTFE array instead of an 
> expression tuple. One could also add a special-case implementation for 
> range `static foreach` to work around inefficient CTFE.

Thank you! It would be great if you could contribute or shepherd a 
contribution to dmd. Anything quadratic fails at scale.


More information about the Digitalmars-d mailing list