On 5 January 2012 21:41, Sean Kelly <sean@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.