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.
