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
