std.math performance (SSE vs. real)

[via Digitalmars-d]

On Saturday, 5 July 2014 at 13:16:28 UTC, Paolo Invernizzi wrote:
> I agree, but keep this is mind: a business model is not carved 
> in stone, it keeps changing, as the market is not a static 
> thing.

Ok, but for the virtual world side I am more driven by (artistic) 
model needs than the business side. So I am looking for a 
solution that fits the requirements.

> And this is true also in the programming language field, as the
> IT universe is not a static thing.

No, but for contractual work I need to be able to add small 
enhancements 12 months after deployment without adding transition 
costs. So a static dev environment matters a lot. If a customer 
expect that an enhancement takes 10 hours to add, I cannot charge 
for 50 hours. So if the dev environment incurs a transition cost 
I have to accept the enhancement request at a loss.

(App Engine is pretty stable and has a 12 months guarantee, which 
is on the low side IMO. I think 24 months would be more 
appropriate.).

> If you read carefully, EVE was not designed for the actual 
> number of concurrent users:

I only glossed over it. I read external analyses of EVE 10 years 
ago when I studied online worlds. I believe they had some 
significant performance problems back. But the game model is not 
really low latency based.

> You can't design now for what you think will be the needs in a
> too much distance future, that's will put your product in the
> Longhorn cemetery. Things need to be done now, to get the 
> current business opportunity window.

I'm not interested in virtual worlds for the business, but for 
the art of it. So my basic ideas are 10-20 years old and 
basically just waiting for the technology to catch up. ;^)

If I have to nudge the tech to make the last mile, ok, then I 
might have to do so…

> So, turning back into the floating point issue of the thread,
> what's the most pragmatic move D can take about that floating
> point performance issue?

Provide the tools to specify the constraints, like you do for 
nogc/safe, but with version support.

But I think D should be specified, not by the implementation, but 
in a paper. And I think the language should be cleaned up a bit, 
on paper, without thinking about the implementation cost for a 
specific compiler. Because if the resulting language is a true 
beauty, then more hands will come to add meat to the bones.

I'm not complaining about requiring strict IEEE 754 compliance, I 
am complaining about requiring it and then saying that it does 
not matter what the compiler devs do. Because it is obvious that 
on many platforms you don't get full compliance for special cases 
without some kind of software emulation/handling.

> What I was meaning: "a pragmatic language" is a beautiful
> business claim, let's stress it: it worked very well for me!

Python is a very pragmatic language, I don't like the dynamic 
aspects, but it is one of the most pragmatic languages out there.

The way I see it now, the most pragmatic solution would be to 
fork D, clean up the syntax a bit and make it work well for the 
domain of game servers. I don't need the libraries. Only UDP/TCP. 
Whether that is cost efficient compared to just using C++, I 
dunno. But the more I follow the discussions on the D forums, the 
more I feel that forking will be more productive than spending 
effort on affecting the current direction (which most probably 
will not get me what I want).