std.math performance (SSE vs. real)

[Iain Buclaw via Digitalmars-d]

On 5 July 2014 15:20, via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> 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.
>

This is a library problem, not a language problem.  In this case
std.math uses real everywhere when perhaps it shouldn't.


>> 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.
>

http://pyd.dsource.org


> 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).

You mean, MiniD?  Someone has already done that, years ago....

http://jfbillingsley.com/croc/wiki/Lang/GettingStarted