manual memory management

[Paulo Pinto]

On Wednesday, 9 January 2013 at 10:21:29 UTC, Mehrdad wrote:
> 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).

Reference counting always implies extra booking code per memory 
access, I fail to see how it can be made faster than any parallel 
GC.

The Aonix VM for example is used in military scenarios like 
missile radar systems and battleship gun's control systems, beats 
any game timing requirements, I would say.

--
Paulo