std.math performance (SSE vs. real)

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Fri Jul 4 14:08:27 PDT 2014


On 7/4/2014 1:41 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Friday, 4 July 2014 at 20:28:36 UTC, Walter Bright wrote:
>> There's no such thing as done for a working language. C++, for example, is
>> constantly in flux. Every release by every vendor alters which parts of the
>> standard and draft standard it supports.
>
> And no sane devs rely on those experimental parts unless g++ or clang commits
> themselves to them. The C++ standard specs out things in advance at intervals
> specified in years, not weeks.

As I said, C++ vendors often implement things far in advance of spec approval, 
they do it piecemeal, and different vendors do things in different orders. C++ 
evangelists are constantly rewriting what C++ "best practices" are. To 
characterize all this churn as "stablility" is awfully charitable.


>> Furthermore, the C/C++ Standards don't have much to say about how floating
>> point works - how is that of any help in writing professional, stable fp code?
> You know that you are on your own and cannot make assumptions about conformance,
> and address it with code (like ifdefs).

Uh-huh. And how much professional code have you seen that had #ifdef's for Vax 
fp in it? IBM fp? Future CPUs that don't exist yet? How many developers have 
access to a Vax to test their #ifdef's on?

Next, consider how much C++ code breaks when ported from 32 to 64 bits. It's 
most of it, even mine, and I know what I'm doing. What you're implying is saying 
that when a spec says "implementation defined" then voila! the code is portable!


>> Do we want to make the spec better? Yes.
> Not make the spec better or bring it up to date with the implementation. Spec
> out the language so people know what the missing bits are.

Please contribute to those areas of the spec you feel need improvement. 
Non-specific statements like "bring it up to date" are not helpful.


>> Please, contribute to the things you care about, instead of suggesting in the
>> n.g. that others should do it. That would be far more helpful.
> That would imply a fork. And yes, I think that might be the most likely outcome
> that someone forks it.

A pull request does not imply a fork.


> I don't believe in language design by a comittee.

The only alternative is you believe I need to do all the work. This is not 
possible. I am not superman, nor am I expert at everything.

Sadly, this also implies that there are no computer languages you believe in. 
You set an impossible standard. How can you possibly say you prefer C++, a 
classic design by committee language?


> I think the language designers
> should spec out their vision. Let the community point out the flaws. Go back to
> the drawing board. Do some rounds. Then commit to it.
>
> I think that would attract more contribution to the core language development.

I'm asking you to contribute. These posts do not accomplish anything. Exhorting 
me to do more (I already work on D 24/7) cannot work.


> I am interested in contributing code to make a good spec come to life, not to
> add noise to an endless contractual metamorphosis that never will lead to
> anything consistent and coherent.

Nothing will improve if you and others remain on the sidelines. Get out in front 
and make what you want to happen, happen.



More information about the Digitalmars-d mailing list