Poor memory allocation performance with a lot of threads on 36 core machine

[Chris Wright via Digitalmars-d]

On Fri, 19 Feb 2016 21:45:31 +0000, Yuxuan Shui wrote:

> On Friday, 19 February 2016 at 08:29:00 UTC, Jonathan M Davis wrote:
>> On Thursday, 18 February 2016 at 17:27:13 UTC, Chris Wright wrote:
>>> [...]
>>
>> Unfortunately, given how easy it is to cast between mutable, const,
>> immutable, shared (and it's quite common to construct something as
>> mutable and then cast it to immutable or shared) and how it's pretty
>> easy to pass objects across threads, it becomes _very_ problematic to
>> have a per-thread memory pool in D, even if theoretically it's a great
>> idea.
> 
> Can't we keep track of when this thing happens? We can have the compiler
> insert call to move data in/out of the per-thread pool when this kind of
> things happen.

Yes. Some casts already invoke runtime functions. I believe array casts 
do this, as do class casts. I thought I'd made that point somewhere, but 
apparently I didn't hit the post button.

It's always safe (albeit inefficient) to treat all data as shared, so you 
can promote things to the shared pool liberally and never return them to 
the local pool (until that memory got collected, at least).