D for Game Development

[Walter Bright via Digitalmars-d]

On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:
> On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d
>> But waiting for someone else to discover the same thing on some other piece
>> of code means you'll be waiting a long time.
> I understand, but that's not sustainable.
> We can't be in a situation where I'm at work with a deadline, and I
> need to invoke the community to address a codegen issue that's
> blocking a release. Unexpected surprises like that with unknown/long
> turn-around times aren't a practical commitment.

It will NEVER get fixed if you don't file bug reports, and you'll continue to be 
frustrated (and me too, because there's NOTHING I can do to improve things based 
on what you post here).


> Last time I was concerned with this, x87 was destroying DMD
> performance. Floats were x87, moved to XMM (according to x64 ABI) when
> passed to functions, then moved back into x87 on the other side when
> they're operated on.
> Float code was overwhelmed with shuffling values between registers.
> Basically all hot code is float code in my line of work.

All I really need is a bugzilla issue with just ONE example of needlessly using 
the x87 where a SIMD instruction would be better.


> I think Ethan was in discussions with you about this some time back?
> It was a problem at the time I left Remedy.

As I recall, I heard from Ethan just once since you left. In contrast, I hear 
regularly from Sociomantic when they've got an issue, and I'm able to 
consequently help them be successful with D.


> Also, I think one of the big issues is the optimiser in general. The
> inliner's just not fantastic, and D depends on it perhaps even more
> than C++, especially when using the modern lazy code style.
> I'm sure I can hand-assist DMD to produce the assembly I expect for
> some hot function with some work, but traditional hand-assisted code
> generation all falls apart when you start stacking lazy-ranges and
> generally using the modern D style.
> DMD's backend has almost no development, it's advancing at near-zero
> velocity compared to LLVM. We need to get out of the situation where
> LDC and GDC are perpetually 1-2 versions behind.
>
> Incidentally, In my recent (dead-end) experience with LDC, I get
> endless ICE's whenever I try to do anything mildly complex. When you
> have your Debug and Release build straddling language versions and
> compilers with different ICE characteristics, it's just not a
> practical workflow. Only green-fields projects or the simplest of
> simple apps can hope not to trigger bugs constantly in that
> environment.

I can't help you with LDC ICE's, but are you filing bug reports for them? Again, 
if you don't file bug reports, NOTHING WILL GET FIXED. You will be frustrated 
and everyone else will be, too.


>>> 2. DMD generates x87 code, and uses real everywhere.
>> Less so now than it used to. For float and double, it uses SIMD.
> Okay, is this fairly recent? My last set of comprehensive tests are
> probably out of date.

No, it's been that way for a while.


> Massive register swapping was the issue. I'd like to think register
> swapping should never be implicitly generated unless I *explicitly*
> type the real keyword, I don't want to see x87 opcodes.

It'll still use the x87 for things like FCOS and FSIN. But if it's doing an x87, 
say, multiply when it should be using SIMD, you need to file a bug report. Vague 
statements are not actionable.


>>> 2. LDC has a lot more bugs than DMD (which still has quite a few
>>> bugs), and the Windows build is new and even more immature still.
>>> 3. LDC has no debuginfo. **biggest practical issue by far!**
>>> 4. LDC/GDC are always a few versions behind DMD. This creates an
>>> awkward/almost-impossible situation when you rely on DMD to build
>>> debug code, and LDC to build releasable code. Depending on 2 flaky
>>> compilers is even less fun than one.
>>> 5. DLL's were really flakey at the time, I'm not sure how they are
>>> now, but I'm concerned they may not be much better.
>>> 6. Shared druntime; we were loading D code from DLL's, lots of them.
>>> It's not really reasonable for each DLL to have it's own druntime
>>> instance, they need to share one provided by the host app.
>>
>>
>> I agree, and now we ship a Phobos DLL, resolving that issue.
>
> Really? Where is it? (I can't see it in the distribution).

Should be in the bin directory.


> At the time I was actually heckled by people here telling me I was
> stupid to try and use vibe.d commercially.
> I was fairly surprised, it seems like one of the D community's biggest
> success stories, and people were (almost violently) telling me I'm
> stupid to attempt to use it in production.

I didn't see such comments, but there'll always be naysayers.


> Might I suggest - and I'm sure you won't like this, but I think it
> would do worlds of good; your experience implementing MS debuginfo in
> DMD is invaluable and fairly unique. If you could contribute that
> debuginfo support to LLVM, it would make a world of difference.

All I know is actually in the DMD source code.


>> Bindings aren't too hard to update.
> Qt is not a small library. Binding Qt appears to be a much, much
> bigger task than my task. I'd need to take it as an ongoing hobby
> project, but I'm overrun with those already >_<

You wouldn't need to do the whole thing, just an update to the existing one, and 
just enough to get your project moving. Does your project use every Qt 
declaration? :-)


> You're probably right to an extent, I was really pushing for it and I
> had the latitude to do so at the time, but interest was actually very
> high. Most commercial dev's I've worked with tend not to engage in the
> open-source space though, so maybe it just wasn't part of their habit
> to involve in communities like this one. I really do appreciate the
> effort you made. I hope it was valuable development regardless, I
> think a lot of important things came form it.

The Win64 port came out of it, at least!


> LDC bugs, I reported them all.

That's great. Do they remain open?


> The question I have
> to ask though is, would that enable me to do my work, or would I just
> run into the next problem?

I have no idea.


> Note, x^^y is still in that list. That's blocking std.color ;)

It has trivial workarounds.


> I'm obviously doing something wrong
> repeatedly, but you can't say I haven't given it a jolly good effort!

I do appreciate that, and your efforts.


> I'm pretty consistent at logging bugs, except those that I can't
> justify burning a few hundred dollars of work time to produce a
> reduction that I could log are often lost (and often quite important).
> I'm often inhibited by the fact that I attempt to use D at work, and
> offices are stupid proprietary places so I can't share code >_<

If your bug reports require an NDA, I'd be happy to sign one and we can handle 
the bug report privately. In any case, by the time a bug report is reduced to 
one suitable for filing, I've never seen one that had any information in it that 
was of proprietary value.

At least for targets that DMD supports, I recommend sticking with DMD if you are 
blocked by LDC. At least get the project working and stable before worrying with 
LDC specific problems.