On 9/22/14, 12:18 PM, "Nordlöw" wrote:
> On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu wrote:
>> http://dpaste.dzfl.pl/817283c163f5
>
> You implementation seems to hold water at least in my tests and save
> memory at
>
> https://github.com/nordlow/justd/blob/master/conceptnet5.d

Awesome, thanks for doing this. How did you measure and what results did you get? -- Andrei

On 9/22/14, 12:34 PM, Dmitry Olshansky wrote:
> 22-Sep-2014 01:45, Ola Fosheim Grostad пишет:
>> On Sunday, 21 September 2014 at 17:52:42 UTC, Dmitry Olshansky wrote:
>>> to use non-atomic ref-counting and have far less cache pollution (the
>>> set of fibers to switch over is consistent).
>>
>> Caches are not a big deal when you wait for io.
>>
>>>> Go also check fiber
>>>> stack size... But maybe Go should not be considered a target.
>>>
>>> ??? Just reserve more space. Even Go dropped segmented stack.
>>> What Go has to do with this discussion at all BTW?
>>
>> Because that is what you are competing with in the webspace.
>
> E-hm Go is hardly the top dog in the web space. Java and JVM crowd like
> (Scala etc.) are apparently very sexy (and performant) in the web space.
> They try to sell it as if it was all the rage though.
>
> IMO Go is hardly an interesting opponent to compete against. In pretty
> much any use case I see Go is somewhere down to 4-th+ place to look at.

I agree. It does have legs however. We should learn a few things from it, such as green threads, dependency management, networking libraries. Also Go shows that good quality tooling makes a lot of a difference. And of course the main lesson is that templates are good to have :o).

Andrei

On 16 September 2014 00:51, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 9/15/14, 3:30 AM, bearophile wrote:
>
>> Andrei Alexandrescu:
>>
>>  Walter, Brad, myself, and a couple of others have had a couple of
>>> quite exciting ideas regarding code that is configurable to use the GC or alternate resource management strategies.
>>>
>>
>> An alternative design solution is to follow the Java way, leave the D strings as they are, and avoid to make a mess of user D code. Java GC and runtime contain numerous optimizations for the management of strings, like the recently introduced string de-duplication at run-time:
>>
>> https://blog.codecentric.de/en/2014/08/string-deduplication-new-feature- java-8-update-20-2
>>
>
> Again, it's become obvious that a category of users will simply refuse to use a GC, either for the right or the wrong reasons. We must make D eminently usable for them.


I still think most of those users would accept RC instead of GC. Why not support RC in the language, and make all of this library noise redundant? Library RC can't really optimise well, RC requires language support to elide ref fiddling.

On 9/22/14, 8:03 PM, Manu via Digitalmars-d wrote:
> I still think most of those users would accept RC instead of GC. Why not
> support RC in the language, and make all of this library noise redundant?

A combo approach language + library delivers the most punch.

> Library RC can't really optimise well, RC requires language support to
> elide ref fiddling.

For class objects that's what's going to happen indeed.


Andrei

On 23 September 2014 14:41, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 9/22/14, 8:03 PM, Manu via Digitalmars-d wrote:
>
>> I still think most of those users would accept RC instead of GC. Why not support RC in the language, and make all of this library noise redundant?
>>
>
> A combo approach language + library delivers the most punch.


How so? In what instances are complicated templates superior to a language RC type?

 Library RC can't really optimise well, RC requires language support to
>> elide ref fiddling.
>>
>
> For class objects that's what's going to happen indeed.


Where is this discussion? Last time I raised it, it was fiercely shut down and dismissed.

On 9/22/14, 9:53 PM, Manu via Digitalmars-d wrote:
> On 23 September 2014 14:41, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
>     On 9/22/14, 8:03 PM, Manu via Digitalmars-d wrote:
>
>         I still think most of those users would accept RC instead of GC.
>         Why not
>         support RC in the language, and make all of this library noise
>         redundant?
>
>
>     A combo approach language + library delivers the most punch.
>
>
> How so? In what instances are complicated templates superior to a
> language RC type?

It just works out that way. I don't know exactly why. In fact I have an idea why, but conveying it requires building a bunch of context.

>         Library RC can't really optimise well, RC requires language
>         support to
>         elide ref fiddling.
>
>
>     For class objects that's what's going to happen indeed.
>
>
> Where is this discussion? Last time I raised it, it was fiercely shut
> down and dismissed.

Consider yourself vindicated! (Not really, the design will be different from what you asked.) The relevant discussion is entitled "RFC: reference counted Throwable", and you've already participated to it :o).


Andrei

On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via Digitalmars-d wrote:
> I still think most of those users would accept RC instead of GC. Why not
> support RC in the language, and make all of this library noise redundant?
> Library RC can't really optimise well, RC requires language support to
> elide ref fiddling.

I think a library solution + intrinsic for increment/decrement (so they can be better optimized) would be the best option.

23-Sep-2014 03:11, Andrei Alexandrescu пишет:
> On 9/22/14, 12:34 PM, Dmitry Olshansky wrote:
>> 22-Sep-2014 01:45, Ola Fosheim Grostad пишет:
>>> On Sunday, 21 September 2014 at 17:52:42 UTC, Dmitry Olshansky wrote:
>>>> to use non-atomic ref-counting and have far less cache pollution (the
>>>> set of fibers to switch over is consistent).
>>>
>>> Caches are not a big deal when you wait for io.
>>>
>>>>> Go also check fiber
>>>>> stack size... But maybe Go should not be considered a target.
>>>>
>>>> ??? Just reserve more space. Even Go dropped segmented stack.
>>>> What Go has to do with this discussion at all BTW?
>>>
>>> Because that is what you are competing with in the webspace.
>>
>> E-hm Go is hardly the top dog in the web space. Java and JVM crowd like
>> (Scala etc.) are apparently very sexy (and performant) in the web space.
>> They try to sell it as if it was all the rage though.
>>
>> IMO Go is hardly an interesting opponent to compete against. In pretty
>> much any use case I see Go is somewhere down to 4-th+ place to look at.
>
> I agree. It does have legs however. We should learn a few things from
> it, such as green threads, dependency management, networking libraries.

Well in short term that would mean..

green threads --> better support for fibers (see std.concurrency pull by Sean)
dependency management --> package dub with dmd releases, use it to build e.g.g Phobos? ;)
networking libraries -> there are plenty of good inspirational libraries out there in different languages. vibe.d is cool, but we ought to explore more and propagate stuff to std.net.*

> Also Go shows that good quality tooling makes a lot of a difference. And
> of course the main lesson is that templates are good to have :o).
>

Agreed.

> Andrei
>


-- 
Dmitry Olshansky

On 23 September 2014 15:37, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 9/22/14, 9:53 PM, Manu via Digitalmars-d wrote:
>
>> On 23 September 2014 14:41, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>>
>>     On 9/22/14, 8:03 PM, Manu via Digitalmars-d wrote:
>>
>>         I still think most of those users would accept RC instead of GC.
>>         Why not
>>         support RC in the language, and make all of this library noise
>>         redundant?
>>
>>
>>     A combo approach language + library delivers the most punch.
>>
>>
>> How so? In what instances are complicated templates superior to a language RC type?
>>
>
> It just works out that way. I don't know exactly why. In fact I have an idea why, but conveying it requires building a bunch of context.
>

The trouble with library types like RefCounted!, is that they appear to be
conceptually backwards to me.
RefCounted!T suggests that T is a parameter to RefCounted, ie, RefCounted
is the significant object, not 'T', which is what I actually want. T is
just some parameter... I want a ref-counted T, not a T RefCounted, if that
makes sense.
When we have T* or T[], we don't lose the 'T'-ness of the object, we're
just appending a certain type of pointer, and I really think that RC should
be applied the same way.

All these library solutions make T into something else, and that has a tendency to complicate generic code in my experience. In most cases, templates are used to capture some type of thing, but in these RefCounted style cases, it's backwards, it effectively obscures the type. We end out with inevitable code like is(T == RefCounted!U, U) to get U from T, which is the thing we typically want to know about, and every instance of a template like this must be special-cased; they can't be rolled into PointerTarget!T, or other patterns like Unqual!T can't affect these cases (not applicable here, but the reliable pattern is what I refer to).

I guess I'm saying, RC should be a type of pointer, not a type of thing... otherwise generic code that deals with particular things always seems to run into complications when it expects particular things, and gets something that looks like a completely different sort of thing.


         Library RC can't really optimise well, RC requires language
>>         support to
>>         elide ref fiddling.
>>
>>
>>     For class objects that's what's going to happen indeed.
>>
>>
>> Where is this discussion? Last time I raised it, it was fiercely shut down and dismissed.
>>
>
> Consider yourself vindicated! (Not really, the design will be different from what you asked.) The relevant discussion is entitled "RFC: reference counted Throwable", and you've already participated to it :o).


I see. I didn't really get that from that thread, but I only skimmed it quite quickly, since I missed most of the action.

I also don't think I ever insisted on a particular design, I asked to have
it *explored* (I think I made that point quite clearly), and suggested a
design that made sense to me. The idea was shut down in principle, no
competing design's explored.
I'm very happy to see renewed interest in the topic :)

On 23 September 2014 16:19, deadalnix via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via Digitalmars-d wrote:
>
>> I still think most of those users would accept RC instead of GC. Why not support RC in the language, and make all of this library noise redundant? Library RC can't really optimise well, RC requires language support to elide ref fiddling.
>>
>
> I think a library solution + intrinsic for increment/decrement (so they can be better optimized) would be the best option.
>

Right, that's pretty much how I imagined it too. Like ranges, where foreach
makes implicit calls to contractual methods, there would also be a contract
for refcounted objects, and the compiler will emit implicit calls to
inc/dec if they exist?
That should eliminate 'RefCounted', you would only need to provide
opInc()/opDec() and rc fiddling calls would be generated automatically?
Then we can preserve the type of things, rather than obscuring them in
layers of wrapper templates...