> Urgh. Product types masquerading as sum types. Give me a break will ya. -- Andrei

1. The product solution is more pleasant to work with, if you have no sugar for sum types like pattern matching.

2. It's the same as with exception specifications: Product types make ignoring the error path easier thus are more popular.

On 2/22/2015 3:25 AM, Jacob Carlborg wrote:
> * Most good GC implementations need some kind of barrier (read or write, don't
> remember which). If I recall there are several people against this in the community

Count me among those.

In Java, write barriers make sense because Java uses the GC for everything. Pretty much every indirection is a GC reference.

This is not at all true with D code. But since the compiler can't know that, it has to insert write barriers for all those dereferences regardless. I suspect it would be a terrible performance hit.

On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:
> This is going to sound really stupid... but do people actually use
> exceptions regularly?

I'd say exception are exceptional in most code. That being said, unless the compiler can PROVE that no exception is gonna be thrown, you are stuck with having to generate a code path for unwinding that decrement the refcount.

It means that you'll have code bloat (not that bad IMO, unless you are embeded) but more importantly, it means that most increment/decrement can't be optimized away in the regular path, as you must get the expected count in the unwinding path.

Moreover, as you get some work to do on the unwind path, it becomes impossible to do various optimizations like tail calls.

I think Walter is right when he says that switft dropped exception because of ARC.

> I've never used one. When I encounter code that does, I just find it
> really annoying to debug. I've never 'gotten' exceptions. I'm not sure
> why error codes are insufficient, other than the obvious fact that
> they hog the one sacred return value.

Return error code have usually been an usability disaster for the simple reason that the do nothing behavior is to ignore the error.

The second major problem is that you usually have no idea how where the error check is done, forcing the programmer to bubble up the error where it is meaningful to handle it.

> I'll agree though that this can't be changed at this point in the game.
> You say that's a terminal case? Generating code to properly implement
> a decrement chain during unwind impacts on the non-exceptional code
> path?
>

Yes as you can't remove increment/decrement pairs as there are 2 decrement path (so there is pair).

> I agree. I would suggest if ARC were proven possible, we would like, switch.
>

I'd like to see ARC support in D, but I do not think it makes sense as a default.

>
>> 3. Memory safety is a requirement for any ARC proposal for D. Swift ignores
>> memory safety concerns.
>
> What makes RC implicitly unsafe?

Without ownership, one can leak reference to RCed object that the RC system do not see.

On 2015-02-23 21:30, Walter Bright wrote:

> Count me among those.
>
> In Java, write barriers make sense because Java uses the GC for
> everything. Pretty much every indirection is a GC reference.
>
> This is not at all true with D code. But since the compiler can't know
> that, it has to insert write barriers for all those dereferences
> regardless.

The alternative would be to have two kind of pointers, one for GC allocated data and one for other kind of data. But I know you don't like that either.

We kind of already have this, class references and regular pointers. But that would tie classes to the GC.

> I suspect it would be a terrible performance hit.

It would be nice to have some numbers backing this up.

-- 
/Jacob Carlborg

On 2015-02-22 21:48, Walter Bright wrote:

> And I suspect that ARC is why they don't have exceptions.

Objective-C still has both ARC and exceptions. Although the documentation [1] says that ARC is not exception safe by default, but it does have a flag to enable it "-fobjc-arc-exceptions".

[1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions

-- 
/Jacob Carlborg

On Tuesday, 24 February 2015 at 07:53:52 UTC, Jacob Carlborg wrote:
> On 2015-02-23 21:30, Walter Bright wrote:
>
>> Count me among those.
>>
>> In Java, write barriers make sense because Java uses the GC for
>> everything. Pretty much every indirection is a GC reference.
>>
>> This is not at all true with D code. But since the compiler can't know
>> that, it has to insert write barriers for all those dereferences
>> regardless.
>
> The alternative would be to have two kind of pointers, one for GC allocated data and one for other kind of data. But I know you don't like that either.
>
> We kind of already have this, class references and regular pointers. But that would tie classes to the GC.
>
>> I suspect it would be a terrible performance hit.
>
> It would be nice to have some numbers backing this up.


This the approach taken by Active Oberon and Modula-3.

Pointers are GC by default, but can be declared as untraced pointers in code considered @system like in D.

--
Paulo

>>> I suspect it would be a terrible performance hit.
>>
>> It would be nice to have some numbers backing this up.
>
>
> This the approach taken by Active Oberon and Modula-3.
>
> Pointers are GC by default, but can be declared as untraced pointers in code considered @system like in D.
>

Do they have concurrent gc and emit barriers for each write to a
default pointer? Do they have precise scanning and don't scan the
untraced pointers? Are the meaningful performance comparisons
between the two pointer types that would enable us to estimate
how costly emitting those barriers in D would be?

On 2/23/2015 11:53 PM, Jacob Carlborg wrote:
> On 2015-02-23 21:30, Walter Bright wrote:
>
>> Count me among those.
>>
>> In Java, write barriers make sense because Java uses the GC for
>> everything. Pretty much every indirection is a GC reference.
>>
>> This is not at all true with D code. But since the compiler can't know
>> that, it has to insert write barriers for all those dereferences
>> regardless.
>
> The alternative would be to have two kind of pointers, one for GC allocated data
> and one for other kind of data. But I know you don't like that either.

That kinda defeats much of the point to having a GC.


>> I suspect it would be a terrible performance hit.
> It would be nice to have some numbers backing this up.

I've seen enough benchmarks that purport to show that Java is just as fast as C++, as long as only primitive types are being used and not pointers.

I've done enough benchmarks to know that inserting even one extra instruction in a tight loop has significant consequences. If you don't believe that, feel free to try it and see.

D is not going to have competitive performance with systems programming languages if write barriers are added.

On 2/24/2015 1:30 AM, Tobias Pankrath wrote:
> Are the meaningful performance comparisons
> between the two pointer types that would enable us to estimate
> how costly emitting those barriers in D would be?

Even 10% makes it a no-go. Even 1%.

D has to be competitive in the most demanding environments. If you've got a server farm, 1% speedup means 1% fewer servers, and that can add up to millions of dollars.

On 2/23/2015 11:57 PM, Jacob Carlborg wrote:
> On 2015-02-22 21:48, Walter Bright wrote:
>
>> And I suspect that ARC is why they don't have exceptions.
>
> Objective-C still has both ARC and exceptions. Although the documentation [1]
> says that ARC is not exception safe by default, but it does have a flag to
> enable it "-fobjc-arc-exceptions".
>
> [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions

From your reference:

"Making code exceptions-safe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions safety. Therefore, ARC-generated code leaks by default on exceptions, which is just fine if the process is going to be immediately terminated anyway. Programs which do care about recovering from exceptions should enable the option."

Note "severe runtime and code size penalties". Just what I said.