January 09, 2013
On Wednesday, 9 January 2013 at 10:09:42 UTC, Mehrdad wrote:
> On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote:
>> Reference counting tend to create big pauses when deallocating as objects tends to dies in group.
>
>
>
>
> I don't get it... it's slower to deallocate a bunch of objects together with refcounting than to deallocate all of them individually over a longer period of time?

*YOU* mentionned pause time. In regard of pause time, yes, it is very different.
January 09, 2013
Am 09.01.2013 11:09, schrieb Mehrdad:
> On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote:
>> Reference counting tend to create big pauses when deallocating
>> as objects tends to dies in group.
>
>
>
>
> I don't get it... it's slower to deallocate a bunch of objects
> together with refcounting than to deallocate all of them
> individually over a longer period of time?
>

could be - think of an large hierarchy of objects which tends to take some time to deconstruct ... a background gc could be better for your application speed in this situation - by the cost of smaller pause and more resource usage

or better - what is the real reason for Java and C# for using garbage collectors if ref-counting will be always better (except cyclic stuff)?
January 09, 2013
On Wednesday, 9 January 2013 at 10:13:03 UTC, deadalnix wrote:
> On Wednesday, 9 January 2013 at 10:09:42 UTC, Mehrdad wrote:
>> On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote:
>>> Reference counting tend to create big pauses when deallocating as objects tends to dies in group.
>>
>>
>>
>>
>> I don't get it... it's slower to deallocate a bunch of objects together with refcounting than to deallocate all of them individually over a longer period of time?
>
> *YOU* mentionned pause time. In regard of pause time, yes, it is very different.


Yes I did, but I didn't realize you were talking about a background GC, sorry.

Yeah, if you can have a background GC that can keep up with your needs, then the world is great. Trouble is, I don't see how that can be true for a intensive applications like games.
January 09, 2013
On Wednesday, 9 January 2013 at 10:14:07 UTC, dennis luehring wrote:
> Am 09.01.2013 11:09, schrieb Mehrdad:
>> On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote:
>>> Reference counting tend to create big pauses when deallocating
>>> as objects tends to dies in group.
>>
>>
>>
>>
>> I don't get it... it's slower to deallocate a bunch of objects
>> together with refcounting than to deallocate all of them
>> individually over a longer period of time?
>>
>
> could be - think of an large hierarchy of objects which tends to take some time to deconstruct ... a background gc could be better for your application speed in this situation - by the cost of smaller pause and more resource usage


Come to think of it, C++ allocators are meant for exactly this: throwing away an entire batch of objects in 1 go. Beats GCs any day.


>
> or better - what is the real reason for Java and C# for using garbage collectors if ref-counting will be always better (except cyclic stuff)?

Pretty sure the only reason C#/Java use a GC _is_ for cyclic stuff, and that's it.


If you have any other reasons please show me a benchmark that shows a GC being faster than the equivalent refcounted code (I've seen lots of talks in theory about how it _COULD_ be different but never seen any examples in practice; would love to see one).
January 09, 2013
On Wednesday, 9 January 2013 at 10:21:29 UTC, Mehrdad wrote:
> Come to think of it, C++ allocators are meant for exactly this

s/are meant for/are used for/
January 09, 2013
On Wednesday, 9 January 2013 at 10:19:24 UTC, Mehrdad wrote:
> Yes I did, but I didn't realize you were talking about a background GC, sorry.
>
> Yeah, if you can have a background GC that can keep up with your needs, then the world is great. Trouble is, I don't see how that can be true for a intensive applications like games.

You are changing the subject discussed every 2 posts. I'm loosing my time here, that will be my last answer to you.

For a game, latency is more important than actual performance. You prefers very much to guarantee 60fps than to have 100fps but with some frame that may take 200ms to compute.

At this game, stop the world GC and reference counting are very bad as both causes large pauses.

A concurrent GC is a viable option, granteed you don't generate an insane amount of garbage (which is problematic whatever the memory management used anyway). It is even a good way to increase parralelism in the program and to better exploit the resource of a multicore machine.

In fact, most code critical in video games avoid memory allocation altogether.
January 09, 2013
Am 09.01.2013 11:21, schrieb Mehrdad:
> Come to think of it, C++ allocators are meant for exactly this:
> throwing away an entire batch of objects in 1 go. Beats GCs any
> day.

but a gc is much more generic then a specialized allocator

redefine you scenario please: are we talking about many,any or special program situations?

for my understanding there is no one-for-all-perfect-solution but many perfect-solution-for-excatly-this-case

that is the reason for having ref-counting & GCs around

January 09, 2013
On Wednesday, 9 January 2013 at 10:31:51 UTC, deadalnix wrote:
> On Wednesday, 9 January 2013 at 10:19:24 UTC, Mehrdad wrote:
>> Yes I did, but I didn't realize you were talking about a background GC, sorry.
>>
>> Yeah, if you can have a background GC that can keep up with your needs, then the world is great. Trouble is, I don't see how that can be true for a intensive applications like games.
>
> You are changing the subject discussed every 2 posts. I'm loosing my time here, that will be my last answer to you.


That wasn't my intention, but the subject suddenly changed to background GCs which I didn't expect to be talking about either... but if you don't have the time to continue then I'll avoid responding too.
January 09, 2013
On Wednesday, 9 January 2013 at 11:10:40 UTC, dennis luehring wrote:
> Am 09.01.2013 11:21, schrieb Mehrdad:
>> Come to think of it, C++ allocators are meant for exactly this:
>> throwing away an entire batch of objects in 1 go. Beats GCs any
>> day.
>
> but a gc is much more generic then a specialized allocator
>
> redefine you scenario please: are we talking about many,any or special program situations?

We're talking about a language that should be able to handle any realistic situation.

>
> for my understanding there is no one-for-all-perfect-solution but many perfect-solution-for-excatly-this-case
>
> that is the reason for having ref-counting & GCs around

Yeah we agree on that, no discussion there.


Speaking of which, I have a feeling what I said didn't send the message I meant:

I didn't mean we should reference-count EVERYTHING. Allocators, etc. have their places too -- and they all under manual (or automatic, whatever you wish to call it) memory management.


My entire point during this discussion has been that you _don't_ _require_ a GC for anything, unlike what Walter said. Manual (/automatic/whatever you want to call it) memory management can take its place just fine.
January 09, 2013
On Wednesday, January 09, 2013 12:16:46 Mehrdad wrote:
> My entire point during this discussion has been that you _don't_ _require_ a GC for anything, unlike what Walter said. Manual (/automatic/whatever you want to call it) memory management can take its place just fine.

Walter wasn't arguing that there wasn't a place for manual memory management. He was arguing that you can't guarantee memory safety if you're using manual memory management - hence why malloc and free are @system. @system code is not memory safe like @safe code is, but it still very much has it's place.

- Jonathan M Davis