On 4/18/2014 8:34 AM, Andrei Alexandrescu wrote:
> Well there's been work on that. I mentioned this recent paper in this group:
> http://goo.gl/tavC1M, which claims RC backed by a cycle collector can reach
> parity with tracing. Worth a close read.

A couple crucial points:

1. It achieves near parity with tracing, i.e. with a regular GC. It says nothing about performance for regular pointer code, when those pointers are replaced with ref counts.

2. It's a Java VM implementation. You can bet that the VM internally isn't using ref counting - too slow.

3. I picked a GC for D because a GC coexists peacefully with pointers of all types. This is not remotely true with ref counting. It's not an issue with Java, which has no pointers, but this coexistence problem would be a huge one for D.

On 4/17/2014 10:53 PM, Walter Bright wrote:
> I recall our email discussion about implementing ARC in D

Rainer found it:

http://forum.dlang.org/thread/l34lei$255v$1@digitalmars.com

On Wednesday, 16 April 2014 at 22:11:23 UTC, froglegs wrote:
>
>> I am really looking forward to .NET Native becoming widespread.
>>
>> Then this type of comparisons (C# vs C++) will be quite different.
>
>
>  I don't think it will make a major difference. Taking a GC based language and giving it a native compiler doesn't automatically make it performance competitive with C++(see Haskel and D(without dumping GC) on anything besides micro bench marks).
>
> C# is still GC based, still makes heavy use of indirection(See Herb Sutters recent talk on arrays).


Also possible in C# with structs, interop annotations and unsafe blocks.

Don't forget that Herb Sutters also has a C++ agenda to sell.

>
> C++ exposes SSE/AVX intrinsics, C# does not.

That is not correct.

1 - Nowhere in the ANSI/ISO C++ are SSE/AVX intrinsics defined, those are compiler extensions. So equal foot with the C# EMCA standard;

2 - .NET Native makes use of Visual C++'s backend with all the automatic vectorization and other code generation optimizations Visual C++ developers enjoy;

3 - .NET Native and RyuJIT have official support for SIMD instructions, GPGPU support is also planned

--
Paulo

On 4/18/14, 10:12 AM, Walter Bright wrote:
> On 4/18/2014 8:34 AM, Andrei Alexandrescu wrote:
>> Well there's been work on that. I mentioned this recent paper in this
>> group:
>> http://goo.gl/tavC1M, which claims RC backed by a cycle collector can
>> reach
>> parity with tracing. Worth a close read.
>
> A couple crucial points:
>
> 1. It achieves near parity with tracing, i.e. with a regular GC. It says
> nothing about performance for regular pointer code, when those pointers
> are replaced with ref counts.

This is moving the goalposts. "Regular pointer code" is unsafe, and safety has been part of your past arguments. This is tracing GC compared to refcounting, cut and dried.

> 2. It's a Java VM implementation. You can bet that the VM internally
> isn't using ref counting - too slow.

Not sure what this means in context.

> 3. I picked a GC for D because a GC coexists peacefully with pointers of
> all types. This is not remotely true with ref counting. It's not an
> issue with Java, which has no pointers, but this coexistence problem
> would be a huge one for D.

Agreed.


Andrei

On Friday, 18 April 2014 at 17:12:11 UTC, Walter Bright wrote:
> 3. I picked a GC for D because a GC coexists peacefully with pointers of all types. This is not remotely true with ref counting. It's not an issue with Java, which has no pointers, but this coexistence problem would be a huge one for D.

My understanding is that a more sophisticated GC will also not coexist quite so peacefully with pointers of all types. Is it not the conservativeness* of the GC that enables this coexistence?

*not necessarily in the GC-jargon sense

On 2014-04-16 19:52, Adam D. Ruppe wrote:

> What I want is a __trait that scans for all call expressions in a
> particular function and returns all those functions.
>
> Then, we can check them for UDAs using the regular way and start to
> implement library defined things like @safe, @nogc, etc. (safe and gc
> are a bit different because they also are affected by built-in language
> features, not just functions, but the same idea of recursively scanning
> for an annotation in the function body).
>
> Of course, this wouldn't always be perfect, separate compilation could
> be used to lie about or hide annotations in a function prototype, but
> meh I don't really care about that, the main use for me would eb static
> asserts right under the function definition anyway.

Sounds like a job for AST macros.

-- 
/Jacob Carlborg

On 2014-04-17 15:08, Orvid King via Digitalmars-d wrote:

> Lastly, I'll add support for stack allocated
> classes, however that will likely have to be disabled until DMD gets
> full escape analysis. As a final note, this will be the 3rd GC I've
> written, although it will be the most complex by far. The first was
> just heap precise, the second a generational compacting version of it.

It's already possible to stack allocate classes. Either using the now deprecated (removed?) "scope" or a library solution.

-- 
/Jacob Carlborg

On 4/18/2014 10:53 AM, Andrei Alexandrescu wrote:
> On 4/18/14, 10:12 AM, Walter Bright wrote:
>> On 4/18/2014 8:34 AM, Andrei Alexandrescu wrote:
>>> Well there's been work on that. I mentioned this recent paper in this
>>> group:
>>> http://goo.gl/tavC1M, which claims RC backed by a cycle collector can
>>> reach
>>> parity with tracing. Worth a close read.
>>
>> A couple crucial points:
>>
>> 1. It achieves near parity with tracing, i.e. with a regular GC. It says
>> nothing about performance for regular pointer code, when those pointers
>> are replaced with ref counts.
>
> This is moving the goalposts. "Regular pointer code" is unsafe, and safety has
> been part of your past arguments. This is tracing GC compared to refcounting,
> cut and dried.

It applies equally to D arrays. Take a look at optimized array loops in D - the generated code is as good as C++ pointer style.


>> 2. It's a Java VM implementation. You can bet that the VM internally
>> isn't using ref counting - too slow.
>
> Not sure what this means in context.

Dogfood.


>> 3. I picked a GC for D because a GC coexists peacefully with pointers of
>> all types. This is not remotely true with ref counting. It's not an
>> issue with Java, which has no pointers, but this coexistence problem
>> would be a huge one for D.
>
> Agreed.

Phew! That's a fundamental point, and I'm glad we agree on it.

On 4/18/2014 10:54 AM, John Colvin wrote:
> My understanding is that a more sophisticated GC will also not coexist quite so
> peacefully with pointers of all types. Is it not the conservativeness* of the GC
> that enables this coexistence?

Yes. Which is one reason why D doesn't emit write gates for indirect assignment.

On 4/18/2014 12:44 PM, Jacob Carlborg wrote:
> It's already possible to stack allocate classes. Either using the now deprecated
> (removed?) "scope" or a library solution.

dmd could do a better job of escape analysis, and do this automatically.