On 9/12/2016 4:21 PM, deadalnix wrote:
> I stay convinced that an hybrid approach is inevitable and am surprised why few
> are going there (hello PHP, here is a thing you get right).

Interestingly, Warp (the C preprocessor I developed in D) used a hybrid approach. The performance critical code was all hand-managed, while the rest was GC'd.

On Tuesday, 13 September 2016 at 10:58:50 UTC, Walter Bright wrote:
>
> Interestingly, Warp (the C preprocessor I developed in D) used a hybrid approach. The performance critical code was all hand-managed, while the rest was GC'd.

Manual Memory management is key for performance oriented code.

On 13/09/16 02:21, deadalnix wrote:
>
> RC itself is not panacea, it doesn't work well with exceptions, generate
> a huge amount of code bloat,

I will need explanation to those two. Assuming we have RAII, why doesn't RC work well with exceptions?

Also, please note that explicit memory management also means we support the equivalent of unique_ptr, which is what most memory allocations actually are.

> But first and foremost, it is a disaster for shared data.

Again, please elaborate.

>
> I stay convinced that an hybrid approach is inevitable and am surprised
> why few are going there (hello PHP, here is a thing you get right).
>

Here's my worries about the hybrid approach. The GC run time is proportional not to the amount of memory you manage with the GC, but to the amount of memory that might hold a pointer to a GC managed memory. In other words, if most of my memory is RC managed, but some of it is GC, I pay the price of both memory manager on most of my memory.

Shachar

On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote:
> Do you have a citation? The number I know is 3x from Emery Berger's (old) work. -- Andrei

IIRC there was a thread about GC here where somebody posted a bunch of links to resources and benchmarks.

On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote:
> Do you have a citation? The number I know is 3x from Emery Berger's (old) work. -- Andrei

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf
Probably these.

On Tuesday, September 13, 2016 03:58:50 Walter Bright via Digitalmars-d wrote:
> On 9/12/2016 4:21 PM, deadalnix wrote:
> > I stay convinced that an hybrid approach is inevitable and am surprised why few are going there (hello PHP, here is a thing you get right).
>
> Interestingly, Warp (the C preprocessor I developed in D) used a hybrid approach. The performance critical code was all hand-managed, while the rest was GC'd.

Folks have posted here before about taking that approach with games and the like that they've written. In a number cases, simply being careful about specific pieces of code and avoiding the GC in those cases was enough to get the required performance. In some cases, simply disabling the GC during a critical piece of code and re-enabling it afterwards fixes the performance problems trigged by the GC without even needing manual memory management or RC. In others, making sure that the critical thread (e.g. the rendering thread) was not GC-managed while letting the rest of the app us the GC takes care of the problem.

We need reference counting to solve certain problems (e.g. cases where deterministic destruction of stuff on the heap is required), but other stuff (like array slices) work far better with a GC. So going either full-on RC or full-on GC is not going to be good move for most programs. I don't think that there's any question that we'll be best off by having both as solid options, and best practices can develop as to when to use one or the other.

- Jonathan M Davis

On Tuesday, 13 September 2016 at 11:59:46 UTC, Shachar Shemesh wrote:
> On 13/09/16 02:21, deadalnix wrote:
>>
>> I stay convinced that an hybrid approach is inevitable and am surprised
>> why few are going there (hello PHP, here right).
>>
>
> Here's my worries about the hybrid approach. The GC run time is proportional not to the amount of memory you manage with the GC, but to the amount of memory that might hold a pointer to a GC managed memory. In other words, if most of my memory is RC managed, but some of it is GC, I pay the price of both memory manager on most of my memory.
>
> Shachar

Hi Shachar.

I hope you're well.

Would you mind elaborating a bit on why the cost of GC managed memory is as high as you imply when combined with other approaches, at least on a 64 bit machine and presuming you have a degree of hygiene and don't directly use a pointer allowed to point to either.   Eg if you use GC for long lived allocations and RC for short lived ones (and the RC constructor makes sure the thing is not registered with the GC so that takes care of short lived parts of long lived structures),  how in practice would this be a problem  ? I am no GC expert,  but keen to update my mental model.


Laeeth

On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote:
> On 9/13/16 3:53 AM, Kagamin wrote:
>> The rule of thumb is that for efficient operation an advanced GC
>> consumes twice the used memory.
>
> Do you have a citation? The number I know is 3x from Emery Berger's (old) work. -- Andrei

I assume it is going to depend of the rate at which the application produces garbage.

On 9/13/16 11:58 AM, Kagamin wrote:
> On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote:
>> Do you have a citation? The number I know is 3x from Emery Berger's
>> (old) work. -- Andrei
>
> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

This suggests the ratio is 4x not 2x:

====
What this chart says is “As long as you have about 6 times as much memory as you really need, you’re fine.  But woe betide you if you have less than 4x the required memory.”
====

> http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf
> Probably these.

This is Berger's paper I was referring to. It concludes the ratio is 3x not 2x:

====
With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%.
====

So do you agree you were wrong in positing 2x as the rule of thumb?


Andrei

On 9/13/16 1:51 PM, deadalnix wrote:
> On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote:
>> On 9/13/16 3:53 AM, Kagamin wrote:
>>> The rule of thumb is that for efficient operation an advanced GC
>>> consumes twice the used memory.
>>
>> Do you have a citation? The number I know is 3x from Emery Berger's
>> (old) work. -- Andrei
>
> I assume it is going to depend of the rate at which the application
> produces garbage.

That's why Berger uses a relatively large battery of benchmark from multiple domains. See http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf. -- Andrei