On Friday, 27 February 2015 at 22:32:06 UTC, Martin Nowak wrote:
> On 02/26/2015 09:29 PM, deadalnix wrote:
>> Page fault ARE write barrier.
>
> If done at kernel mode, it's too expensive anyhow.

As mentioned, it is not for the immutable part of the heap, for obvious reasons.

On Fri, Feb 27, 2015 at 11:30:40PM +0100, Martin Nowak via Digitalmars-d wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/26/2015 01:50 AM, H. S. Teoh via Digitalmars-d wrote:
> > I don't know how typical this is, but in my own D code I tend to use arrays a lot, and they do tend to add significant GC load. A recent performance improvement attempt in one of my projects found that collection cycles take up to 40% of total running time (it's a CPU-bound process).
> 
> Is this project public? I'd like to benchmark it with the new GC growth strategy.
[...]

I haven't posted the code anywhere so far, though I probably will in the future. If you like, though, I could send you a tarball for you to play around with.


T

-- 
The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners... -- Slashdotter

On Friday, 27 February 2015 at 15:53:18 UTC, ponce wrote:
> On Thursday, 26 February 2015 at 14:22:01 UTC, Ola Fosheim Grøstad wrote:
>>> No. If I can't open a file I'd better not create a File object in an invalid state. Invalid states defeats RAII.
>>
>> This is the attitude I don't like, because it means that you have to use pointers when you could just embed the file-handle. That leads to more allocations and more cache misses.
>>
>
> I really don't understand how any of this is related to what we were previously discussing: error handling.

You wrote:

«No. If I can't open a file I'd better not create a File object in
an invalid state. Invalid states defeats RAII.»

If you embed the File object in other objects you also have to deal with the File object being in an invalid state. The alternative is to have discrete objects and nullable pointers to them. Makes sense for a high level programming language like  Java, makes no sense for a system programming language.

> It does't make much sense to go on after an error, in any software that want some reliability.

It does, when you do async buffering and want performance, e.g. OpenGL.

Often it also makes error-handling simpler. Often you don't care about when it failed, you often only care about the "transactional unit" as a whole.

It also makes programs more portable. There are big architectural differences when it comes to when errors can be reported. E.g. you don't want to wait for a networked drive to respond before going on. You only want to know if the "closing of the transaction" succeeded or not.

On 02/26/2015 05:08 AM, Walter Bright wrote:
> 
> A lot of benefit simply came from compacting all the remaining used allocations together, essentially defragging the memory.

Compacting is indeed easy once we have a precise GC, and can be done partially, i.e. objects pointed to by the stack/register are pinned.

On 02/25/2015 10:50 PM, deadalnix wrote:
> 
> I don't think it make sens to completely discard the idea of barriers, especially when it come to write barrier on the immutable heap. At least that should certainly pay off.

Before the argument gets lost. http://forum.dlang.org/post/mcqr3s$cmf$1@digitalmars.com

> Write barriers would cost a low single digit, e.g. 3-4%.
> While searching for ways to avoid the cost I found an interesting
alternative to generational GCs.

>
https://github.com/D-Programming-Language/druntime/pull/1081#issuecomment-69151660

On 3/2/2015 11:38 AM, Martin Nowak wrote:
> Compacting is indeed easy once we have a precise GC, and can be done
> partially, i.e. objects pointed to by the stack/register are pinned.

Also unions.

On Tuesday, 3 March 2015 at 02:05:08 UTC, Walter Bright wrote:
> On 3/2/2015 11:38 AM, Martin Nowak wrote:
>> Compacting is indeed easy once we have a precise GC, and can be done
>> partially, i.e. objects pointed to by the stack/register are pinned.
>
> Also unions.

Compacting doesn't solve the inherent performance problem of a conservative GC though. It's the capability to run small incremental collections that make modern GCs fast. With a conservative GC you always have to mark the complete heap to even free a single object. Shoveling a 1GB heap from main memory through your CPU already takes 250ms, and on top of that comes memory latency for non-sequential traversing and the actual marking.