Re: [Patch] libstdc++/28277 valarray bits

[Paolo Carlini <pcarlini at suse dot de>]

Hi Gaby and thanks for your quick feedback,

> I think you have tried hard to find lot of reasons to justify the
> current shape of the codes; thanks for the credit :-)
>
> I don't think I've tried to make valarray exception safe.  This stuff
> is for number crunching, and as recognized in the standard wording it
> is not the kind of thing that is supposed to handle exceptions correctly.
> However, it is expected to do its job pretty fast.  Consequently, were
> temporary storage is needed for local computation, I've tried to use
> the stack -- worries about unbounded alloca is NOT an issue here.
> High performance number crunchers are willing to adjust the stack --
> that has been existing practice since FORTRANS ages.  So, I don't
> think you should spend effort to remove alloca from the valarray
> implementation for the sake of removing alloca -- using the stack also
> gives the compiler a hint about the containment of the storage and
> when it gets smart apply appropriate optimization.o
> This stuff was written when we did not have the NRVO, and the other
> way of doing it on average was faster.
>  
Ok. Only a note from my experiments, missing from my previos messages: 
outside valarray, in more mundane areas, when an unbounded alloca can be 
an issue (e.g., forcing the user to unduly increase  the stack only to 
output a char array or pad to width a number), I'm seeing very good 
performance for new []. I mean, unless you are doing a *tiny* amount of 
real work, the time spared allocating on the stack seems relatively very 
small. That surprised me, I was under the impression that we had a nasty 
trade-off, but apparently that is not the case, experimentally. At least 
not now, with the current underlying mallocs. I have yet to analyze the 
real reasons of that, hopefully I'll be able to provide more details in 
due course, in any case, rest assured that I'm always performance 
testing my proposed changes.

> However I do agree with you that where the work can be done
> efficiently in place, that should happen.
>  
Indeed, this case seems particularly easy (assuming the exception safety 
non requirements).

> OK.
>  
Thanks a lot!

Paolo.