DIP80: phobos additions

anonymous via Digitalmars-d digitalmars-d at puremagic.com
Mon Jun 15 01:12:16 PDT 2015


On Sunday, 14 June 2015 at 21:50:02 UTC, Ola Fosheim Grøstad 
wrote:
> On Sunday, 14 June 2015 at 21:31:53 UTC, anonymous wrote:
>>> 2. Then write similar code with hardware optimized BLAS and 
>>> benchmark where the overhead between pure C/LLVM and BLAS 
>>> calls balance out to even.
>> may there are more important / beneficial things to work on - 
>> assuming total time of contributors is fix and used for other 
>> D stuff:)
>
> Sure, but that is what I'd do if I had the time. Get a baseline 
> for what kind of NxN sizes D can reasonably be expected to deal 
> with in a "naive brute force" manner.
>
> Then consider pushing anything beyond that over to something 
> more specialized.
>
> *shrugs*

On Sunday, 14 June 2015 at 21:50:02 UTC, Ola Fosheim Grøstad 
wrote:
> On Sunday, 14 June 2015 at 21:31:53 UTC, anonymous wrote:
>>> 2. Then write similar code with hardware optimized BLAS and 
>>> benchmark where the overhead between pure C/LLVM and BLAS 
>>> calls balance out to even.
>> may there are more important / beneficial things to work on - 
>> assuming total time of contributors is fix and used for other 
>> D stuff:)
>
> Sure, but that is what I'd do if I had the time. Get a baseline 
> for what kind of NxN sizes D can reasonably be expected to deal 
> with in a "naive brute force" manner.
>
> Then consider pushing anything beyond that over to something 
> more specialized.
>
> *shrugs*

sorry, I should read more careful. I understand 'optimize default 
implementation to the speed of high quality BLAS for _any_/large 
matrix size'. Great if it is done but imo there is no real 
pressure to do it and probably needs lot of time of experts.

To benchmark when existing BLAS is actually faster is than 'naive 
brute force' sounds very good and reasonable.


More information about the Digitalmars-d mailing list