shared array?

[Ola Fosheim Grostad via Digitalmars-d-learn]

On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis 
wrote:
> stop-the-world GC. For instance, this has come up in 
> discussions on games where a certain framerate needs to be 
> maintained. Even a 100 ms stop would be way too much for them. 
> In fact, it came up with the concurrent GC that was presented 
> at dconf 2013 that it would likely have to be guaranteed to 
> stop the world for less than 10 ms (or something in that range 
> anyway) to be acceptable for such environments. So, it _is_ a 
> problem for some folks.

In the renderloop you only have 15 ms, so it would be more like 
2ms (not realistic). The 10 ms target is for high performance 
servers and regular interactive applications.

> That being said, it is _not_ a problem for most folks, and the 
> folks who have those sorts of performance requirements 
> frequently can't even use malloc after the program has gotten 
> past its startup phase.

I don't agree with this. You can use your own allocators that 
don't syscall in critical areas.

> GC-allocated or malloced. For instance, as I understand it, 
> Warp used the GC, but it allocated everything up front and 
> didn't allocate once it got going, so the GC wasn't a 
> performance problem for it at all, and it's _very_ fast.

A c preprocessor is a simple program that has to allocate for 
macro defs, but the rest can just use static buffers... So it 
should not be a problem.

> Regardless, idiomatic D involves a lot more stack allocations 
> than you often get even in C++, so GC usage tends to be low in

Really? I use VLAs in my C++ (a C extension) and use very few 
mallocs after init. In C++ even exceptions can be put outside the 
heap. Just avoid STL after init and you're good.