std.math performance (SSE vs. real)

Paolo Invernizzi via Digitalmars-d digitalmars-d at puremagic.com
Sat Jul 5 06:16:27 PDT 2014


On Saturday, 5 July 2014 at 11:14:40 UTC, Ola Fosheim Grøstad
wrote:
> On Saturday, 5 July 2014 at 09:39:10 UTC, Paolo Invernizzi 
> wrote:
>> Again, outside, in the real business world, reality is a little
>> different: take this monster, look, no C++!
>>
>> http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/
>> http://www.pcgamer.com/2013/06/15/eve-online/
>
> I don't play Eve, but in general the challenge in virtual worlds
> is that you need to do full veracity checking on the server to
> reduce cheating. You should also hide parts of the model so that
> only the server knows it. Basically, you have to run the entire
> sim on the server and only run parts of it on the client for
> display purposes if you want to reduce cheating without
> introducing draconian measures that basically takes over the
> machine (which cannot work if the client runs in the browser).
>
> Anyway, at the end of the day, for a freemium game you need to
> cut server costs because you cannot estimate correctly how much
> money you make per online user. With a subscription model you 
> are
> better off and can spend more on hardware.
>
> What you can or cannot do, depends on the business model, the
> market and the game design…

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.
And this is true also in the programming language field, as the
IT universe is not a static thing.

I liked the Lang.NEXT panel, especially when Bjarne talked about
the real world pressure over C++...

>> What I loved about D, from the real beginning, was this:
>> pragmatism, pragmatism!
>
> I am pragmatic about this. I have stuff planned that can run on
> Python on top of Google Datastore on the server and use
> Dart+WebGL on the client. But if you want a physics based model,
> user building and fast travelling you have to consider the worst
> case scenario and you cannot do it in Python or using a disk
> based database.  You need a in-memory database and hit the
> hardware so that you can take the peaks without ending up with
> molasses of latency.

If you read carefully, EVE was not designed for the actual number
of concurrent users: they was forced to keep changing, to survive
the challenges. The worst case scenario is the today worst case
scenario.

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.

>> And after the love, what moved us as a company to adopt it was
>> Walter: He is a deeply pragmatic guy!
>> Pragmatism is an invaluable asset in business (btw, THAT should
>> be stressed in the logo/identity/redesign looooooong thread)
>
> The most valuable factor in business is predictability,
> opportunities and being better at cutting costs than the
> competition.

Thinks are a little more complicated than that, but well, at the
end, business is all about satisfying the needs of someone else
who is free to choose among alternatives.

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?

Take the road that satisfy better the most demanded need asked
nowadays by D user base, so speed by default.
Satisfy the precision demand with real, but keep this need in an
explicit language domain corner: there's no silver bullet.

> Pragmatism in the context of D is community building. Sure, 
> being
> pragmatic about the logo is important, you should encourage
> people using it in different ways because it is a community
> building tool (among many). Like the penguin in Linux being used
> in games etc. Community building means encouraging participation
> and setting direction. If you don't set direction, people will
> sit on the fence waiting for something to happen. Communities
> don't build skeletons, they add meat to the bones.

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

---
Paolo


More information about the Digitalmars-d mailing list