DIP80: phobos additions

[Manu via Digitalmars-d]

On 10 June 2015 at 02:32, John Colvin via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Tuesday, 9 June 2015 at 16:18:06 UTC, Manu wrote:
>>
>> On 10 June 2015 at 01:26, Ilya Yaroshenko via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>>
>>>> I believe that Phobos must support some common methods of linear algebra
>>>> and general mathematics. I have no desire to join D with Fortran libraries
>>>> :)
>>>
>>>
>>>
>>> D definitely needs BLAS API support for matrix multiplication. Best BLAS
>>> libraries are written in assembler like openBLAS. Otherwise D will have last
>>> position in corresponding math benchmarks.
>>
>>
>> A complication for linear algebra (or other mathsy things in general)
>> is the inability to detect and implement compound operations.
>> We don't declare mathematical operators to be algebraic operations,
>> which I think is a lost opportunity.
>> If we defined the properties along with their properties
>> (commutativity, transitivity, invertibility, etc), then the compiler
>> could potentially do an algebraic simplification on expressions before
>> performing codegen and optimisation.
>> There are a lot of situations where the optimiser can't simplify
>> expressions because it runs into an arbitrary function call, and I've
>> never seen an optimiser that understands exp/log/roots, etc, to the
>> point where it can reduce those expressions properly. To compete with
>> maths benchmarks, we need some means to simplify expressions properly.
>
>
> Optimising floating point is a massive pain because of precision concerns
> and IEEE-754 conformance. Just because something is analytically the same
> doesn't mean you want the optimiser to go ahead and make the switch for you.

We have flags to control this sort of thing (fast-math, strict ieee, etc).
I will worry about my precision, I just want the optimiser to do its
job and do the very best it possibly can. In the case of linear
algebra, the optimiser generally fails and I must manually simplify
expressions as much as possible.
In the event the expressions emerge as a result of a series of
inlines, or generic code (the sort that appears frequently as a result
of stream/range based programming), then there's nothing you can do
except to flatten and unroll your work loops yourself.

> Of the things that can be done, lazy operations should make it
> easier/possible for the optimiser to spot.

My experience is that they possibly make it harder, although I don't
know why. I find the compiler becomes very unpredictable optimising
deep lazy expressions. The backend inline heuristics may not be tuned
for typical D expressions of this type?

I often wish I could address common compound operations myself, by
implementing something like a compound operator which I can special
case with an optimised path for particular expressions. But I can't
think of any reasonable ways to approach that.