On 09-Aug-2015 15:27, Manu via Digitalmars-d wrote:
> On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote:
>>>
>>> On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:
>>>>>
>>>>>
>> [snip]
>>>>
>>>> Even though it is hard for you to still be here, I hope you do continue
>>>> to
>>>> help D grow. This is a good community, we just need time before real
>>>> adoption. E.g. we are only just now starting to unify projects.
>>>
>>>
>>> Cheers, but don't get me wrong; I've barely contributed anything of
>>> value other than advocacy and little bits and pieces here and there. I
>>> don't deserve any credit, I just complain about things that make it
>>> impossible for me to get on with my work.
>>
>>
>> std.simd though would be awesome to have ;)
>
> Yeah, I keep coming back to it, and getting myself stuck with various
> troubles making it work good. I'm perpetually unhappy with my code,
> and I just need a really good block of time to get through it.
> If people want to review std.color and help get that off my
> short-list, I promise I'll make std.simd my top priority :P

Well, let us march towards std.experimental.color then :)
I'll see what I need about it or maybe it's plenty good enough for me already.

One thing I've hit with color in the past is painfully slow bulk array at once color conversions. In 2013 my CV app for an embbeded linux device had spent ~50% of time gray-scaling input image(!) that is until I coded a bit of NEON to fix that to ~11%. And note I'm no SIMD guru so I had spent an evening worth of time to test a few versions but the result was well worth it.

> I also haven't had need for it in my recent work, so it's not being
> motivated by necessity since I haven't been game-dev-ing much.
>


-- 
Dmitry Olshansky

On 8/9/15 5:15 AM, Walter Bright wrote:
> On 8/9/2015 2:04 AM, Johannes Pfau wrote:
>> That statement is too broad to be true ;-) GCC's emulated TLS doesn't
>> have adjacent memory for TLS variables and it works fine with D
>> (and the GC). It is a little bit slower than if we had adjacent memory.
>> OTOH this approach works with all kinds of shared libraries and
>> requires very little system specific code (only need some pthread tls
>> mechanism). And it is compatible with GCCs emulated TLS, so you can
>> even have extern TLS variables shared between C and D with emutls.
>
> The reason I did the special support for TLS on OSX is because gcc at
> the time did not support TLS in any way shape or form. Now that it does,
> dmd should change to do it the same way.

"Where is the bugzilla issue" etc :o). -- Andrei

On 9 August 2015 at 23:52, Dmitry Olshansky via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 09-Aug-2015 15:27, Manu via Digitalmars-d wrote:
>>
>> On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote:
>>>>
>>>>
>>>> On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>>>
>>>>>
>>>>> On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:
>>>>>>
>>>>>>
>>>>>>
>>> [snip]
>>>>>
>>>>>
>>>>> Even though it is hard for you to still be here, I hope you do continue
>>>>> to
>>>>> help D grow. This is a good community, we just need time before real
>>>>> adoption. E.g. we are only just now starting to unify projects.
>>>>
>>>>
>>>>
>>>> Cheers, but don't get me wrong; I've barely contributed anything of value other than advocacy and little bits and pieces here and there. I don't deserve any credit, I just complain about things that make it impossible for me to get on with my work.
>>>
>>>
>>>
>>> std.simd though would be awesome to have ;)
>>
>>
>> Yeah, I keep coming back to it, and getting myself stuck with various
>> troubles making it work good. I'm perpetually unhappy with my code,
>> and I just need a really good block of time to get through it.
>> If people want to review std.color and help get that off my
>> short-list, I promise I'll make std.simd my top priority :P
>
>
> Well, let us march towards std.experimental.color then :)
> I'll see what I need about it or maybe it's plenty good enough for me
> already.
>
> One thing I've hit with color in the past is painfully slow bulk array at once color conversions. In 2013 my CV app for an embbeded linux device had spent ~50% of time gray-scaling input image(!) that is until I coded a bit of NEON to fix that to ~11%. And note I'm no SIMD guru so I had spent an evening worth of time to test a few versions but the result was well worth it.

I'm happy to do optimisation passes, and have plenty of experience to
do so, but the API and general feature set needs to be agreed before I
do that sort of thing.
Optimisation can come via future PR's.

Incidentally, std.color would be a great customer for std.simd ;)

On Sunday, 9 August 2015 at 12:27:26 UTC, Manu wrote:
>
> Yeah, I keep coming back to it, and getting myself stuck with various
> troubles making it work good. I'm perpetually unhappy with my code,
> and I just need a really good block of time to get through it.
> If people want to review std.color and help get that off my
> short-list, I promise I'll make std.simd my top priority :P
>
> I also haven't had need for it in my recent work, so it's not being motivated by necessity since I haven't been game-dev-ing much.

Cool.

On 09/08/15 15:53, Andrei Alexandrescu wrote:

> "Where is the bugzilla issue" etc :o). -- Andrei

It's been there for a while [1] ;)

[1] https://issues.dlang.org/show_bug.cgi?id=9476

-- 
/Jacob Carlborg

On 09/08/15 13:38, Manu via Digitalmars-d wrote:

> In fact, we've been discussing for a few months that we'd have have
> another very promising opportunity to use D at work in a really
> appropriate context if I could rely on Android and iOS appearing
> within 6-12 months or so.

There's been quite a lot of activities lately in improving the Andriod and iOS support by Joakim and Dan.

-- 
/Jacob Carlborg

On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
> On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:
>> ...
>
> This pretty much hit the nail on the head on why dmd needs deprecated.
>
> I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care if it works on windows, it produces code slower than interpreted lua. Exactly what use is that? It may as well not work on windows at all as far as release builds are concerned.

Well, for Win64 the codegen is simply wrong. I don't even care if the codegen is fast or not, but correct should be a given. Biggest problem for me so far.

Aggravated by the time it takes to isolate such bugs.

On 8/9/2015 12:59 PM, ponce wrote:
> Well, for Win64 the codegen is simply wrong. I don't even care if the codegen is
> fast or not, but correct should be a given. Biggest problem for me so far.

There's nothing I nor anyone else can do with comments like this.

It passes the executable part of the test suite on Win64. If there are bugs in the Win64 code generation, I don't see any on Bugzilla.

Please post incorrect codegen bugs to bugzilla. If they are already on bugzilla, please post the bug numbers.

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.

On Sunday, 9 August 2015 at 20:24:47 UTC, Walter Bright wrote:
> On 8/9/2015 12:59 PM, ponce wrote:
>> Well, for Win64 the codegen is simply wrong. I don't even care if the codegen is
>> fast or not, but correct should be a given. Biggest problem for me so far.
>
> There's nothing I nor anyone else can do with comments like this.
>
> It passes the executable part of the test suite on Win64. If there are bugs in the Win64 code generation, I don't see any on Bugzilla.
>
> Please post incorrect codegen bugs to bugzilla. If they are already on bugzilla, please post the bug numbers.

Once I get back to Windows I will post the report.
The problem is that from a selfish point of view I can better optimize for my time and just disable optimizations in the faulty code, moving on to the next task. A Tragedy of the commons situation.