On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> 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.
>>
>> dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower.
>>
>
> I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's "not made here" syndrome strikes again!
>
> Also I really wish we had 1 main editor that was "THE" D editor. Something that was officially maintained and packaged with the rest of D. VisualD is cool, but not cross platform. monoD is nice, but no windows debugging support. DDT is also nice, it says it can do debugging in windows, but I was never been able to get it to work. They all have problems. If I had to vote, I would vote for monoD or DDT as they are both the closest to being complete solutions. But one really needs to be the focus and packaged with D, make it complete and let the others die.
>
>
(Neo)Vim?  :o)



> D debugging is in a laughable state. It really sucks and it seems to not be a concern at all by the core D people. That alone is a huge problem. If only we could get a cross platform D debugger that just worked and was officially maintained.
>
>
Not sure which environment you refer to, but most times I've been pinged
into discussion, the problem was less the debugger (GDB) and more the
compiler (DMD) which does not produce enough (or wrong) information to even
allow some basics to work properly.

So your idea of a debugger tool to fix all problems is a non-starter project because from DMD there is not much information present to begin with.  You can't magically build a debug environment that represents a program state in its entirety from nothing!

Iain.

On Sunday, 9 August 2015 at 06:59:15 UTC, Iain Buclaw wrote:
> On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>>[...]
> (Neo)Vim?  :o)
>
>
>
>>[...]
> Not sure which environment you refer to, but most times I've been pinged
> into discussion, the problem was less the debugger (GDB) and more the
> compiler (DMD) which does not produce enough (or wrong) information to even
> allow some basics to work properly.
>
> So your idea of a debugger tool to fix all problems is a non-starter project because from DMD there is not much information present to begin with.  You can't magically build a debug environment that represents a program state in its entirety from nothing!
>
> Iain.

+1, gdb works just fine with both gdc and ldc(gdc moreso.) Another area that dmd falls flat on its face in.

The only real problem I have with GDC is that it's slow.

On 9 August 2015 at 09:03, rsw0x via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Sunday, 9 August 2015 at 06:59:15 UTC, Iain Buclaw wrote:
>
>> On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>
>> [...]
>>>
>> (Neo)Vim?  :o)
>>
>>
>>
>> [...]
>>>
>> Not sure which environment you refer to, but most times I've been pinged
>> into discussion, the problem was less the debugger (GDB) and more the
>> compiler (DMD) which does not produce enough (or wrong) information to
>> even
>> allow some basics to work properly.
>>
>> So your idea of a debugger tool to fix all problems is a non-starter project because from DMD there is not much information present to begin with.  You can't magically build a debug environment that represents a program state in its entirety from nothing!
>>
>> Iain.
>>
>
> +1, gdb works just fine with both gdc and ldc(gdc moreso.) Another area that dmd falls flat on its face in.
>
> The only real problem I have with GDC is that it's slow.
>

Well I have no control over the sheer number of optimization passes in GCC backend, nor the sheer number of functions the D frontend wants to send to compile.  :o)

If the libraries were shared, this would reduce linking time, which in various benchmarks I've done is where most small projects spend the majority of their time doing.  But no one has as of yet come up with a feasibly implementable idea to do that.

Iain.

On 8/8/2015 11:38 PM, Iain Buclaw via Digitalmars-d wrote:
> I know that at least for the benefit of std.math, we should allow any precision
> without expensive casting to and from real, which has been found to be a
> performance problem on various benchmarks (GDC, LDC, DMD, doesn't matter).

I thought that had largely been done.

On 8/8/2015 11:36 PM, Tofu Ninja wrote:
> On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
>> dmd not being deprecated continues the cycle of gdc/ldc lagging versions
>> behind and being understaffed in manpower.
>
> I think another point to look at is how far gdc and ldc have come while still
> having so few people working on them. Clearly they are able to get more done
> faster because they can leverage the work of the llvm and gcc devs. Seems silly
> that the majority of our talent is focused on dmd when it is the slowest of the
> bunch. D's "not made here" syndrome strikes again!

There's pretty much no talent focused on the dmd back end. I do most of the (very) occasional bug fixes, and sometimes Martin or Daniel correct something, and that's about it.

The idea that it is sucking up resources is incorrect.

On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:
> If the libraries were shared, this would reduce linking time, which in various
> benchmarks I've done is where most small projects spend the majority of their
> time doing.  But no one has as of yet come up with a feasibly implementable idea
> to do that.

We ship Phobos as a shared library on Linux, OSX and FreeBSD.

On 9 August 2015 at 09:28, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 8/8/2015 11:38 PM, Iain Buclaw via Digitalmars-d wrote:
>
>> I know that at least for the benefit of std.math, we should allow any
>> precision
>> without expensive casting to and from real, which has been found to be a
>> performance problem on various benchmarks (GDC, LDC, DMD, doesn't matter).
>>
>
> I thought that had largely been done.
>
>
What about intrinsics?

https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630

On 9 August 2015 at 09:33, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:
>
>> If the libraries were shared, this would reduce linking time, which in
>> various
>> benchmarks I've done is where most small projects spend the majority of
>> their
>> time doing.  But no one has as of yet come up with a feasibly
>> implementable idea
>> to do that.
>>
>
> We ship Phobos as a shared library on Linux, OSX and FreeBSD.
>
>
... By inventing your own storage section?  This doesn't work where TLS is not natively supported.  (Though, no one has really told me how it works after years repeatedly asking, but this is what I assume is being done).

On 8/9/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
> What about intrinsics?
>
> https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630

There isn't a simd cosine instruction, so making cos(double) builtin accomplishes nothing. However, the casting in those functions go away when code is generated.

For example:

  import std.math;
  double foo(double d) {
    return cos(d);
  }

generates:

  _D3foo3fooFdZd:
                fld     qword ptr 4[ESP]
                fcos
                ret     8

On 8/9/2015 12:51 AM, Iain Buclaw via Digitalmars-d wrote:
> On 9 August 2015 at 09:33, Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
>     On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:
>
>         If the libraries were shared, this would reduce linking time, which in
>         various
>         benchmarks I've done is where most small projects spend the majority of
>         their
>         time doing.  But no one has as of yet come up with a feasibly
>         implementable idea
>         to do that.
>
>
>     We ship Phobos as a shared library on Linux, OSX and FreeBSD.
>
> ... By inventing your own storage section?  This doesn't work where TLS is not
> natively supported.  (Though, no one has really told me how it works after years
> repeatedly asking, but this is what I assume is being done).

I don't understand your question. On Linux, TLS data is inserted into the same section that gcc puts it. On OSX, where gcc didn't support TLS, dmd did create it into a data segment. Every time a new thread was created, druntime would malloc a chunk of data, and copy that data segment into it to initialize it. Then it would save a pointer to the malloced data in the thread data structure.

Accessing the OSX TLS involved finding the thread data structure for the current thread, and getting the pointer to the TLS malloced data, and adding the offset of the symbol to it.

The only reason a new data section was required was so that all the TLS data from all the object modules would be adjacent. It's the only way to do it.