Slow performance compared to C++, ideas?

Manu turkeyman at gmail.com
Sat Jun 8 23:03:02 PDT 2013


On 8 June 2013 21:27, Flamaros <flamaros.xavier at gmail.com> wrote:

> On Saturday, 8 June 2013 at 03:59:25 UTC, Manu wrote:
>
>> On 8 June 2013 13:25, Walter Bright <newshound2 at digitalmars.com> wrote:
>>
>>  On 6/7/2013 5:15 PM, Manu wrote:
>>>
>>>  I can tell you that in my case, we export a lot(/most) things. Renderer
>>>> api,
>>>> sound api, etc are often all in their own libraries. So none of them are
>>>> ever
>>>> eligible for optimisation.
>>>>
>>>>
>>> I'm curious why these exports all must be classes, and cannot be structs?
>>>
>>>
>> Because they embody functionality, not just data. That's just how many
>> many
>> programmers write code.
>> Go to university for a couple of years, see what they tell you... ;)
>> Some of these systems can effectively be considered plugins. Consider
>> OpenGL/DirectX? DirectSound/XAudio? Linux has a million back-end API's to
>> choose from.
>> I can see why many people feel it's natural to design their API's/systems
>> that way, right or wrong.
>>
>> I don't agree with it personally, I would write it differently, but I'll
>> never win that argument. Tech/systems programmers are vastly outnumbered
>> in
>> most studios. And of course, most programmers are junior-mid experience,
>> that's just commercial reality.
>>
>
> Personally, I never understood why portability must pass by a plugin
> architecture. In our game engine we use macro to build the right
> implementation depending on the target platform and pure interfaces to be
> sure that API are respected.
> It's not an issue, because the user don't have to be able to choose the
> sound backend, and developer can do it for testing but it requires a full
> rebuild (a real issue due to the C++ slow compilation).
>

But you are aware that people write code that way?
I'm trying to represent the interests of an industry, not just myself.
Anyone who rejects D because they perceive it doesn't meet their needs is a
lost opportunity.

Here's some example game-dev type API's.
http://www.ogre3d.org/docs/api/html/namespaceOgre.html
http://www.continuousphysics.com/Bullet/BulletFull/annotated.html
These aren't particularly aggressive libs, but they are public, so you can
see the sort of API that's typical as an example. Count the occurrences of
'virtual'...
Note, the accessors almost never declare virtual, unless they are
low-frequency classes, like 'Compositor', which is mostly virtual (gets hit
once per frame).

The ones I'm most familiar with are naturally closed-source or proprietary.
For instance, Havok, FMod, Morpheme, Unreal, etc... All C++, with careful
application of 'virtual'.

Microsoft API's (DirectX, etc) are COM, which implies classes.

People use classes. Classes are not optional. I'm not looking for
workarounds or alternative solutions.
If we can't supply classes that people can use in more-or-less the same way
they have been doing so for decades, they probably won't choose D.

If D does offer some superior alternative paradigms, given time, they might
experiment and become comfortable with them eventually (prove to themselves
it's solid and satisfies all their requirements). But they won't just take
your word for it, and certainly not without a wealth of other successful
examples in the industry.
Programmers that make the switch to D have already taken on enough risk in
that first step alone. If they have to risk changing a decade of coding
habits and conventions too (which involves retraining all the staff), how
can any business ever realistically make the change?

I'm here, and interested in D due mainly to it's immediate familiarity, as
opposed to others like Rust for instance. I can actually envision a
migration. It seems like it's possible... one step at a time.
...it's also compiled and binary compatible, which is obviously critical ;)
.. (this is where C# fails, or everyone would already be on that wagon
without question)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130609/57cd0ac7/attachment.html>


More information about the Digitalmars-d mailing list