View mode: basic / threaded / horizontal-split · Log in · Help
January 09, 2013
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home