System programming in D (Was: The God Language)

Manu turkeyman at gmail.com
Thu Jan 5 12:36:22 PST 2012


On 5 January 2012 21:41, Sean Kelly <sean at invisibleduck.org> wrote:

> On Jan 5, 2012, at 10:02 AM, Manu wrote:
> >
> > That said, this is just one of numerous issues myself and the OP raised.
> I don't know why this one became the most popular for discussion... my
> suspicion is that is because this is the easiest of my complaints to
> dismiss and shut down ;)
>
> It's also about the only language change among the issues you mentioned.
>  Most of the others are QOI issues for compiler vendors.  What I've been
> curious about is if you really have a need for the performance that would
> be granted by these features, or if this is more of an idealistic issue.
>

I think they are *all* language requests. They could be implemented by 3rd
party compilers, but these things are certainly nice to standardise in the
language, or you end up with C, which is a mess I'm trying to escape.

Of the topics been discussed:
  * vector type - I can't be expected to write a game without using the
vector hardware... I'd rather use a portable standardised type than a GDC
extension. Why the resistance? I haven't heard any good arguments against,
other than some murmurings about float[4] as the official syntax, which I
gave detailed arguments against.

  * inline asm supporting pseudo regs - As an extension of using the vector
hardware, I'll need inline asm, and inline assembly without pseudo regs is
pretty useless... it's mandatory that the compiler shedule the register
allocation otherwise inline asm will most likely be an un-optimisation. If
D had pseudo regs in its inline assembler, it would make it REALLY
attractive for embedded systems programmers.
    In lieu of that, I need to use opcode intrinsics instead, which I
believe GDC exposes, but again, I'm done with C and versioning (#ifdef-ing)
every compiler I intend to use. Why not standardise these things? At least
put the intrinsics in the standard lib...

  * __restrict - Not a deal breaker, but console game dev industry uses
this all the time. There are countless articles on the topic (many are
private or on console vendor forums). If this is not standardised in the
language, GDC will still expose it I'm sure, fragmenting the language.

  * __forceinline - I'd rather have a proper keyword than using tricks like
mixins and stuff as have been discussed. The reason for this is debugging.
Code is not-inlined in debug builds, looks&feels like normal code, can
still evaluate, and step like regular code... and guarantee that it inlines
properly when optimised. This just saves time; no frills debugging.

  * multiple return values - This is a purely idealistic feature request,
but would lead to some really nice optimisations while retaining very tidy
code if implemented properly. Other languages support this, it's a nice
modern feature... why not have it in D?

I couldn't release the games I do without efficient use of vector hardware
and __restrict used in appropriate places. I use them every day, and I
wouldn't begin a project in D without knowing that these features are
supported, or are definitely coming to the language.
On fixed hardware systems, the bar is high and it's very competitive... you
can't waste processor time.
Trust me when I say that using __restrict appropriately might lead to twice
as many particles on screen, or allowing more physics bodies, or more
accurate simulation. SIMD hardware is mandatory, and will usually increase
performance 2-5 times in my experience. The type of code that usually
benefits the most ranges from particle simulation, collision/physics,
procedural geometry/texturing, and funnily enough, memcopy ;) .. stock
memcopy doesn't take advantage of 16byte simd registers for copying memory,
Ill bet D doesn't either.
A little while back I rewrote a bitplane compositor (raw binary munging,
not a typical vector hardware job) in VMX. Very tricky, but it was around
10 times faster... which is good, because our game had to hold rock solid
60fps, and it saved the build and even allowed us to add some more nice
features ;)

If D can't compete with, or beat C, it won't be used in this market on high
end products, though perhaps still viable on smaller/not-cutting-edge
projects if productivity is considered more important.
Engine programmers are thoroughly aware of code generation, and in C,
tricks/techniques to coerce the compiler to generate the code you want to
see are common place... and often very, very ugly. I think the industry
would be very impressed and enthusiastic if D were able to generate the
best possible code with conventional and elegant language semantics,
without annoying tricks or proprietary compiler extensions to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120105/fc97f3e7/attachment-0003.html>


More information about the Digitalmars-d mailing list