Andrei Alexandrescu, el  6 de October a las 10:40 me escribiste:
> On 10/6/14, 10:29 AM, Dicebot wrote:
> >On Monday, 6 October 2014 at 17:23:55 UTC, Andrei Alexandrescu wrote:
> >>On 10/6/14, 9:51 AM, Dicebot wrote:
> >>>https://github.com/D-Programming-Language/druntime/pull/985
> >>
> >>This is awesome. I recall Don had some solid performance numbers for it in his talk, do you have any in the context of D2? -- Andrei
> >
> >No, I didn't get to running any perf test so far. Did PR as soon as test suite passes and commits looked sane. Will do eventually. Any specific project you are interested in?
> >
> >I'd love to see the impact on vibe.d but it is subject to threading/malloc issue right now.
> 
> vibe.d would be great to test. Generally any realistic project would be relevant. -- Andrei

Probably projects needing low latency are the ones that will benefit the most. Although I was surprised by the results even with single-threaded applications when I did my performance tests back in the days, which got a considerable performance boost in multi-cores, as suddenly you application becomes automatically parallelized (now your program can run in parallel with the collector while before they were serialized).

Anyway, we'd love to hear about any numbers people can collect :-)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Did you see the frightened ones?
Did you hear the falling bombs?
Did you ever wonder why we had to run for shelter when the promise of a
brave new world unfurled beneath a clear blue sky?

On 10/7/2014 3:27 PM, Leandro Lucarella wrote:
> Walter Bright, el  7 de October a las 13:06 me escribiste:
>> On 10/6/2014 9:51 AM, Dicebot wrote:
>>> https://github.com/D-Programming-Language/druntime/pull/985
>>
>> Thank you. This is great progress!
>>
>> I understand the caveats, but can this be put into a shape where it
>> can be pulled despite being a work in progress? I.e. have the code
>> be disabled by default? That will help encourage the community to
>> help out with the gaps.
>
> Yes, I think that's the best approach too. Ideally this should be
> configurable at runtime as Marting suggested, so ANYONE can try it with
> their applications by just running it like this:
> D_GC=concurrent=1 ./myapp
>
> Then bugs can be filled more easily and people can work on fixing them
> more easily too. At some point I'd like to see the current GC and the
> concurrent GC merged, the concurrent GC already support disabling the
> concurrency. Both GCs diverged with time and both have (different)
> improvements over the common parent, and it will be a shame to lose any
> of them.
>

That's a good idea, but I hate environment variables affecting all D executables. They always wind up being inadvertently being left on, or off, or set for some unrelated purpose. It also would affect all D executables on the system, potentially making a big mess.

And there's always:

  user: "my program used to work, now it is too big / too slow / crashes"
  n.g.: "did you check that D_GC is not in your environment?"
  user: "yes I checked, it isn't set"
  n.g.: "check again"
  [lots of fruitless back and forth a few times]
  user: "oops, sorry!"

Sort of like:

  user: "need to fix this on the website"
  n.g.: "thanks! fixed now!"
  user: "no it isn't"
  n.g.: "looks good to me"
  [lots of fruitless back and forth]
  n.g.: "did you refresh your browser's cache?"
  user: "oops, sorry!"

On Wednesday, 8 October 2014 at 00:18:16 UTC, Walter Bright wrote:
> On 10/7/2014 3:27 PM, Leandro Lucarella wrote:
>> Walter Bright, el  7 de October a las 13:06 me escribiste:
>>> On 10/6/2014 9:51 AM, Dicebot wrote:

> That's a good idea, but I hate environment variables affecting all D executables. They always wind up being inadvertently

LD_LIBRARY_PATH ?

I like the on/off at runtime idea. Less scary to try on important code. We can just disable the concurrent gc if we notice dodgy things happening.

On Wed, Oct 8, 2014 at 8:09 AM, eles via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 8 October 2014 at 00:18:16 UTC, Walter Bright wrote:
>
>> On 10/7/2014 3:27 PM, Leandro Lucarella wrote:
>>
>>> Walter Bright, el  7 de October a las 13:06 me escribiste:
>>>
>>>> On 10/6/2014 9:51 AM, Dicebot wrote:
>>>>
>>>
>  That's a good idea, but I hate environment variables affecting all D
>> executables. They always wind up being inadvertently
>>
>
> LD_LIBRARY_PATH ?
>

On Monday, 6 October 2014 at 17:29:23 UTC, Dicebot wrote:
> No, I didn't get to running any perf test so far. Did PR as soon as test suite passes and commits looked sane. Will do eventually. Any specific project you are interested in?
>
> I'd love to see the impact on vibe.d but it is subject to threading/malloc issue right now.

SDC ?

On Tue, 07 Oct 2014 17:18:18 -0700
Walter Bright via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> That's a good idea, but I hate environment variables affecting all D executables. They always wind up being inadvertently being left on, or off, or set for some unrelated purpose. It also would affect all D executables on the system, potentially making a big mess.
maybe enable envvar-control in alphas/betas and disable in releases? this way people who want to try something new can experiment, but those who need stability will not be affected. after all, those who using alphas/betas knows what they're doing and are aware of possible problems.

i assume that not everyone are ready to build dmd from sources, yet many people are ready to try new features, so they can download and install separate alpha/beta to play with.

On Wednesday, 8 October 2014 at 06:58:36 UTC, ketmar via Digitalmars-d-announce wrote:
> On Tue, 07 Oct 2014 17:18:18 -0700
> Walter Bright via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com> wrote:
>
> i assume that not everyone are ready to build dmd from sources,

Digger? What can be easier?

--
/P

On Wed, 08 Oct 2014 07:14:29 +0000
Paolo Invernizzi via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> > i assume that not everyone are ready to build dmd from sources,
> Digger? What can be easier?
i've never used Digger, so i can't tell anything about it. ;-)

On Wed, 08 Oct 2014 07:14:29 +0000
Paolo Invernizzi via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> > i assume that not everyone are ready to build dmd from sources,
> Digger? What can be easier?
p.s. i mean that it will be good to have Digger mentioned somewhere at the front page, with some usage samples, so people will know that we have such good tool.

Walter Bright, el  7 de October a las 17:18 me escribiste:
> On 10/7/2014 3:27 PM, Leandro Lucarella wrote:
> >Walter Bright, el  7 de October a las 13:06 me escribiste:
> >>On 10/6/2014 9:51 AM, Dicebot wrote:
> >>>https://github.com/D-Programming-Language/druntime/pull/985
> >>
> >>Thank you. This is great progress!
> >>
> >>I understand the caveats, but can this be put into a shape where it can be pulled despite being a work in progress? I.e. have the code be disabled by default? That will help encourage the community to help out with the gaps.
> >
> >Yes, I think that's the best approach too. Ideally this should be
> >configurable at runtime as Marting suggested, so ANYONE can try it with
> >their applications by just running it like this:
> >D_GC=concurrent=1 ./myapp
> >
> >Then bugs can be filled more easily and people can work on fixing them more easily too. At some point I'd like to see the current GC and the concurrent GC merged, the concurrent GC already support disabling the concurrency. Both GCs diverged with time and both have (different) improvements over the common parent, and it will be a shame to lose any of them.
> >
> 
> That's a good idea, but I hate environment variables affecting all D executables. They always wind up being inadvertently being left on, or off, or set for some unrelated purpose. It also would affect all D executables on the system, potentially making a big mess.

I think this is an unjustified fear, there are already many environment variables that can affect your program. That's why they are called... environment variables :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
- Mire, don Inodoro! Una paloma con un anillo en la pata! Debe ser
  mensajera y cayó aquí!
- Y... si no es mensajera es coqueta... o casada.
	-- Mendieta e Inodoro Pereyra