On Saturday, 9 July 2016 at 17:41:59 UTC, Andrei Alexandrescu wrote:
> I wish we could amass the experts able to make similar things happen for us.

I humbly believe it is not just about amassing experts, but also making it easy to do experiments. Phobos/druntime should provide set of APIs for literally everything so people can do their own implementations of ANY standard library module(s). I wish D offered module interfaces the same way Modula-3 did...

To work on new GC in D one needs to remove the old one, and replace it with his/her new implementation, while with competition it is more/less implementation of few interfaces, and instructing compiler to use the new GC...

On 07/09/2016 03:42 PM, Martin Nowak wrote:
> We sort of have an agreement that we don't want to pay 5% for write
> barriers, so the common algorithmic GC improvements aren't available for
> us.

Yah, I was thinking in a more general sense. Plenty of improvements of all kinds are within reach. -- Andrei

On Saturday, 9 July 2016 at 21:25:34 UTC, Dejan Lekic wrote:
> On Saturday, 9 July 2016 at 17:41:59 UTC, Andrei Alexandrescu wrote:
>> I wish we could amass the experts able to make similar things happen for us.
>
> I humbly believe it is not just about amassing experts, but also making it easy to do experiments. Phobos/druntime should provide set of APIs for literally everything so people can do their own implementations of ANY standard library module(s). I wish D offered module interfaces the same way Modula-3 did...
>
> To work on new GC in D one needs to remove the old one, and replace it with his/her new implementation, while with competition it is more/less implementation of few interfaces, and instructing compiler to use the new GC...

https://github.com/dlang/druntime/blob/master/src/gc/gcinterface.d
https://github.com/dlang/druntime/blob/master/src/gc/impl/manual/gc.d

What else do you need to start working on a new GC implementation?

On Saturday, 9 July 2016 at 13:48:41 UTC, Dicebot wrote:
> On 07/09/2016 02:48 AM, ikod wrote:
>> If I made a wrong guess and
>> ask for too small stack then programm may crash. If I ask for too large
>> stack then I probably waste resources.
>
> Nope, this is exactly the point. You can demand crazy 10 MB of stack for each fiber and only the actually used part will be allocated by kernel.

Remember that virtual address space is limited on 32-bit platforms. Thus spawning 2000 threads 1 MB stack each will occupy all available VA space and you'll get an allocation failure (even if the real memory usage is low).

On Saturday, 9 July 2016 at 23:12:10 UTC, Andrei Alexandrescu wrote:
> Yah, I was thinking in a more general sense. Plenty of improvements of all kinds are within reach. -- Andrei

Yes, but hardly anything that would allow us to do partial collections.
And without that you always have to scan the full live heap, this can't scale to bigger heaps, there is no way to scan a GB sized heap fast. So either we facilitate to get by with a small GC heap, i.e. more deterministic MM, or we spent a lot of time to make some partial collection algorithm work. Ideally we do both but the former is a simpler goal.

The connectivity based GC would be a realistic goal as well, only somewhat more complex than the precise GC. But it's unclear how well it will work for typical applications.

On Sunday, 10 July 2016 at 19:49:11 UTC, Sergey Podobry wrote:
> On Saturday, 9 July 2016 at 13:48:41 UTC, Dicebot wrote:
>> Nope, this is exactly the point. You can demand crazy 10 MB of stack for each fiber and only the actually used part will be allocated by kernel.
>
> Remember that virtual address space is limited on 32-bit platforms. Thus spawning 2000 threads 1 MB stack each will occupy all available VA space and you'll get an allocation failure (even if the real memory usage is low).

Sorry, but someone who tries to run highly concurrent server software with thousands of fibers on 32-bit platform is quite unwise and there is no point in taking such use case into account. 32-bit has its own niche with different kinds of concerns.

On Monday, 11 July 2016 at 11:23:26 UTC, Dicebot wrote:
> On Sunday, 10 July 2016 at 19:49:11 UTC, Sergey Podobry wrote:
>>
>> Remember that virtual address space is limited on 32-bit platforms. Thus spawning 2000 threads 1 MB stack each will occupy all available VA space and you'll get an allocation failure (even if the real memory usage is low).
>
> Sorry, but someone who tries to run highly concurrent server software with thousands of fibers on 32-bit platform is quite unwise and there is no point in taking such use case into account. 32-bit has its own niche with different kinds of concerns.

Agreed. I don't know why golang guys bother about it.

On Mon, 2016-07-11 at 12:21 +0000, Sergey Podobry via Digitalmars-d wrote:
> On Monday, 11 July 2016 at 11:23:26 UTC, Dicebot wrote:
> > On Sunday, 10 July 2016 at 19:49:11 UTC, Sergey Podobry wrote:
> > > 
> > > Remember that virtual address space is limited on 32-bit platforms. Thus spawning 2000 threads 1 MB stack each will occupy all available VA space and you'll get an allocation failure (even if the real memory usage is low).
> > 
> > Sorry, but someone who tries to run highly concurrent server software with thousands of fibers on 32-bit platform is quite unwise and there is no point in taking such use case into account. 32-bit has its own niche with different kinds of concerns.
> 
> Agreed. I don't know why golang guys bother about it.

Maybe because they are developing a language for the 1980s?

;-)

-- 

Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 11 July 2016 at 12:21:04 UTC, Sergey Podobry wrote:
> On Monday, 11 July 2016 at 11:23:26 UTC, Dicebot wrote:
>> On Sunday, 10 July 2016 at 19:49:11 UTC, Sergey Podobry wrote:
>>>
>>> Remember that virtual address space is limited on 32-bit platforms. Thus spawning 2000 threads 1 MB stack each will occupy all available VA space and you'll get an allocation failure (even if the real memory usage is low).
>>
>> Sorry, but someone who tries to run highly concurrent server software with thousands of fibers on 32-bit platform is quite unwise and there is no point in taking such use case into account. 32-bit has its own niche with different kinds of concerns.
>
> Agreed. I don't know why golang guys bother about it.

Because of attitudes like shown in that thread
https://forum.dlang.org/post/ilbmfvywzktilhskpeoh@forum.dlang.org
people who do not really understand why 32 bit systems are a really problematic even if the apps don't use more than 2 GiB of memory.

Here's Linus Torvalds classic rant about 64 bit
https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/  (it's more about PAE but the reasons why 64 bits is a good thing in general are the same: address space!)

On Monday, 11 July 2016 at 13:05:09 UTC, Russel Winder wrote:
> Maybe because they are developing a language for the 1980s?
>
> ;-)

It is quite common for web services to run with less than 1GB. 64bit would be very wasteful.