Am 27.02.2015 um 00:05 schrieb deadalnix:
>
> Note that in D, you have union and all kind of crap like that, so what
> is writing a pointer is non obvious and so the tradeof is very different
> than it is in other languages.

To have any chance of implementing a better GC in D I would simly start of with assuming all code is @safe. For code that is not @safe the user would have to make sure it plays nice with the GC. This would also apply to unions which contain pointer types. If you wan't to write a good GC that does support non @safe features without user input you don't even have to start in my opinion.

On 2015-02-26 20:58, Walter Bright wrote:

> It was a generational gc, I described earlier how it used page faults
> instead of write barriers. I eventually removed the page fault system
> because it was faster without it.

Instead you used?

-- 
/Jacob Carlborg

On 2015-02-26 21:45, Walter Bright wrote:

> If you want some fun, take any system and fill up the disk drive to just
> short of capacity. Now go about your work using the system.
>
> You'll experience all kinds of delightful, erratic behavior, because
> real world C code tends to ignore write failures and just carries on.

It has happened to me quite often. It's usually no problem. Just (re)move some data an continue.

-- 
/Jacob Carlborg

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.


>> So you can't re-enter that mutex as you asked, so I will grant you a scopedLock, but it is in an errored state so you'd better check that it is valid!
>
> A file can always enter an errored state. So can OpenGL. That doesn't mean you have to react immediately in all cases.
>

This is counter to my experience.
It does't make much sense to go on after an error, in any software that want some reliability.

On Friday, 27 February 2015 at 07:09:20 UTC, Benjamin Thaut wrote:
> Am 27.02.2015 um 00:05 schrieb deadalnix:
>>
>> Note that in D, you have union and all kind of crap like that, so what
>> is writing a pointer is non obvious and so the tradeof is very different
>> than it is in other languages.
>
> To have any chance of implementing a better GC in D I would simly start of with assuming all code is @safe. For code that is not @safe the user would have to make sure it plays nice with the GC. This would also apply to unions which contain pointer types. If you wan't to write a good GC that does support non @safe features without user input you don't even have to start in my opinion.

That is a reasonable approach (and indeed, I would assume that @system code have to ensure that it does not do something that will confuse the GC).

Still, what you can do when compiling AOT is different than what you can do when you JIT. For instance, when you JIT, you can add write barrier and remove them on the fly when you need to. When doing AOT, they must be always on or always of.

On 02/22/2015 03:23 AM, Walter Bright wrote:
> - RC is slower overall

This claim isn't true for almost all applications when using a conservative GC, except for programs that produce a lot of garbage and have very few long-lived objects. The memory bandwidth consumed to mark long-lived objects during every collection dominates the GC cost even for small heaps (say 100MB).

On 02/22/2015 01:43 AM, Manu via Digitalmars-d wrote:
> D's GC is terrible, and after 6 years hanging out in this place, I have seen precisely zero development on the GC front. Nobody can even imagine, let alone successfully implement a GC that covers realtime use requirements.

We have achieved quite some speedup on the GC front (up to 50% faster
allocations) and we work on a few more improvements for the next
release (good for at least another 20% speedup).

There is even a useful idea how to implement an incremental GC.

I might give a talk about the current state at DConf.

On 02/24/2015 10:53 AM, Walter Bright wrote:
> 
> Even 10% makes it a no-go. Even 1%.

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 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.

On 02/26/2015 09:29 PM, deadalnix wrote:
> Page fault ARE write barrier.

If done at kernel mode, it's too expensive anyhow.