Tomas Lindquist Olsen wrote:
> I do apologize if I made a lot of people download a broken DMD
> release, but ... Some people watch the changelog, so if you don't want
> to release to be public, don't update the site!

I suppose at this point we might as well make it official.

dsimcha wrote:
> Or is the automatic synchronization of shared variables part not supposed to be
> implemented yet?

The implementation of the synchronization of shared variables is not done yet. It's a big step to just make the default thread local, and to upgrade the static type system.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> dsimcha wrote:
> > Or is the automatic synchronization of shared variables part not supposed to be implemented yet?
> The implementation of the synchronization of shared variables is not done yet. It's a big step to just make the default thread local, and to upgrade the static type system.

Ok, certainly understandable.  In that case, congratulations on the release.

Walter Bright:
> I suppose at this point we might as well make it official.

I can see a large number of bugfixes. Lot of work.

DMD v1.042 compiles my dlibs fine. But if I try to compile them with v1.045 the compiler prints before stopping:

Assertion failure: '0' on line 136 in file 'statement.c'

So I'll keep using v1.042 for now.


I can't see the "vtls" switch when dmd v2.030 prints its usage switches, but it works.



>added .typeinfo to ClassInfo<

Can someone explain me a bit the purpose/usefulness of this?


>As D is a systems language, of course there's a way to do this. Use the storage class __gshared:<

In future this may change, but at the moment a significant percentage of the little programs is single-thread. So if the decrease of performance is significant (and I don't know if it is, see below) then a compiler switch may be added that defaults all global variables to __gshared (and if possible optionally uses simple means to try to forbid multi-threaded code).

I have done a tiny benchmark:


import std.c.stdio: printf;

//int x; // global
__gshared int x;
//shared int x;

void main() {
    //int x; // local

    //for (int i; i < 1_000_000_000; i++)
    foreach (i; 0 .. 1_000_000_000)
        x++;
    printf("%d\n", x);
}


Timings, n=1_000_000_000, best of 6, seconds:
  DMD2:
    global for:        2.72
    global foreach:    2.62
    __gshared for:     3.03
    __gshared foreach: 3.09
    shared for:        3.07
    shared foreach:    3.08
    local for:         0.57
    local foreach:     0.57

  DMD1:
    global for:        3.08
    local for:         0.55

For this tiny code it seems that __gshared reduces the loop performance.

---------------------------

DMD2 __gshared for:

L0:     push    EAX
        xor EAX,EAX
L3:     inc dword ptr _D17thread_local_test1xi
        inc EAX
        cmp EAX,03B9ACA00h
        jb  L3
        push    dword ptr _D17thread_local_test1xi
        mov EAX,offset FLAT:_DATA
        push    EAX
        call    near ptr _printf
        [...]

---------------------------

DMD2 global for:

L0:     push    EAX
        xor ECX,ECX
        push    EBX
        push    ESI
L5:     mov EAX,FS:__tls_array
        mov EDX,[EAX]
        inc ECX
        inc dword ptr _D17thread_local_test1xi[EDX]
        cmp ECX,03B9ACA00h
        jb  L5
        mov ECX,FS:__tls_array
        mov EBX,[ECX]
        mov ESI,offset FLAT:_DATA
        push    dword ptr _D17thread_local_test1xi[EBX]
        push    ESI
        call    near ptr _printf
        [...]

Bye,
bearophile

bearophile wrote:
> Walter Bright:
>> I suppose at this point we might as well make it official.
> 
> I can see a large number of bugfixes. Lot of work.
> 
> DMD v1.042 compiles my dlibs fine. But if I try to compile them with
> v1.045 the compiler prints before stopping:
> 
> Assertion failure: '0' on line 136 in file 'statement.c'

I need a bugzilla post.


> Can someone explain me a bit the purpose/usefulness of this?

Frank needed it for dwt.


> In future this may change, but at the moment a significant percentage
> of the little programs is single-thread. So if the decrease of
> performance is significant (and I don't know if it is, see below)
> then a compiler switch may be added that defaults all global
> variables to __gshared (and if possible optionally uses simple means
> to try to forbid multi-threaded code).

Therein lies madness. Having compiler switches that alter binary interfaces makes life very hard for library developers.

With some minor work on the part of the user, there are ways to address all the performance issues. Using __gshared is the easiest.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> bearophile wrote:
> > Walter Bright:
> >> I suppose at this point we might as well make it official.
> >
> > I can see a large number of bugfixes. Lot of work.
> >
> > DMD v1.042 compiles my dlibs fine. But if I try to compile them with v1.045 the compiler prints before stopping:
> >
> > Assertion failure: '0' on line 136 in file 'statement.c'
> I need a bugzilla post.
> > Can someone explain me a bit the purpose/usefulness of this?
> Frank needed it for dwt.
> > In future this may change, but at the moment a significant percentage of the little programs is single-thread. So if the decrease of performance is significant (and I don't know if it is, see below) then a compiler switch may be added that defaults all global variables to __gshared (and if possible optionally uses simple means to try to forbid multi-threaded code).
> Therein lies madness. Having compiler switches that alter binary
> interfaces makes life very hard for library developers.
> With some minor work on the part of the user, there are ways to address
> all the performance issues. Using __gshared is the easiest.

So __gshared is expected to stick around as part of the spec long term?  It's not something that you just hacked in there for now so that, for example, druntime would compile?

Walter Bright, el 12 de mayo a las 09:40 me escribiste:
> Tomas Lindquist Olsen wrote:
> >Is there a reason for the missing announcement ?
> 
> Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.

I think a better way to do prereleases is to do a "full" release but mark it as a release candidate.

For example, make a DMD 1.045rc release. Wait a week, if nobody complains,
release DMD 1.045. If somebody complains, fix the bug, make a DMD
1.045rc2, etc (normally the final would be the same as the rc, and there
should be very rare cases where a rc2+ would be needed). Maybe it's
a little more work, but I'm sure the prerelease will get a lot more
testing than a hidden release and people won't get confused thinking that
something that is in the website ready for download and looks like a final
release, really is a "hidden prerelease".

Anyways, I think pre-releasing is great and it's better to have it this way than not having them at all.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------

dsimcha wrote:
> So __gshared is expected to stick around as part of the spec long term?

Yes.

> It's not
> something that you just hacked in there for now so that, for example, druntime
> would compile?

It's so users can "cowboy" quick and dirty changes to get their code to work. It isn't allowed in "safe" mode.

Leandro Lucarella wrote:
> Walter Bright, el 12 de mayo a las 09:40 me escribiste:
>> Tomas Lindquist Olsen wrote:
>>> Is there a reason for the missing announcement ?
>> Yes, I sent it to people who'd asked for a prerelease so they could
>> check their builds against it.
> 
> I think a better way to do prereleases is to do a "full" release but mark
> it as a release candidate.
> 
> For example, make a DMD 1.045rc release. Wait a week, if nobody complains,
> release DMD 1.045. If somebody complains, fix the bug, make a DMD
> 1.045rc2, etc (normally the final would be the same as the rc, and there
> should be very rare cases where a rc2+ would be needed). Maybe it's
> a little more work, but I'm sure the prerelease will get a lot more
> testing than a hidden release and people won't get confused thinking that
> something that is in the website ready for download and looks like a final
> release, really is a "hidden prerelease".
> 
> Anyways, I think pre-releasing is great and it's better to have it this
> way than not having them at all.

-rc is good when you have long release cycles. It isn't appropriate for dmd, which has very short release cycles.

If dmd had public source control, we could set up continuous integration for it that will, for instance, run dstress and attempt to compile the latest release of various common libraries. Then Walter can just check its results when he wants to do a release -- depending on how long that takes to run.

Tomas Lindquist Olsen wrote:
<snip>
> And what happened to the D1 stability stance ? 1.045 is a breaking
> release (both code and binary)! I don't mind, but I'm very surprised..

Which changes are you talking about here?

Stewart.