Warp wrote:
>   My point is very valid.

No, it's really not. How much have you looked into the research on this 
issue?

> You complain that handling reference counts
> larger than the natural word size of the system is inefficient, yet you
> don't take into account that *every* data handling in that same program
> would be inefficient too

No. There are things you can cache to be smaller in memory than on disk. 
  Non-overflowing reference counts aren't one of them.

> of everything else. In other words, the reference counter adds only just
> a very small percentage to the total inefficiency of the program and thus
> is negligible.

And I'm sure you've read this in research papers written by people 
building OO database systems, right? And you're not just guessing based 
on the first way you thought up of implementing such a thing?

>   I wouldn't use a GC engine in a 64K system either. We are comparing
> reference counting to GC here.

Why wouldn't you use GC in a 64K system? Lots of people do. But then, 
they know how to write an efficient GC.

>   Unpredictable? :D

In the sense that a given "free" may take lots of different times, 
depending on how far the cascade goes. For example, if you free the root 
of a tree, the amount of work is proportional to the number of nodes in 
the tree. There's no upper bound on how long you spend freeing a node, 
so it's inappropriate for real-time systems, for example.

>   A reference counting system is exactly the opposite: You know exactly
> when things are freed and how much is freed. It's the Java-style GC which
> is completely unpredictable.

Java-style GC isn't unpredictable. You can make such a system real-time 
and say exactly what percentage of CPU usage it should max out at.

>   You have somehow succeeded in completely turning the issue around and
> are accusing RC for the exactly problem that GC has. Incredible.

Nope. You just don't understand that GC doesn't have the problems you 
think it does. Maybe Java's GC does, but that's not a problem in 
general. It's just a crappy implementation.

Plus, no matter what you argue in terms of efficiency, reference 
counting is BROKEN.  It doesn't work. It doesn't collect the garbage. So 
I'm not sure why you seem to be arguing that it's better than actual 
garbage collection.

Warp wrote:
 >   You seem to have this obsession about RC "not being fast". Apparently
 > this is compared to not using RC but instead... what? Manually freeing
 > all instances?

Compared to generational garbage collection (as one example), wherein 
you discard a whole bunch of objects without looking at them 
individually. Kind of like the difference between deleting a file whose 
location is stored in an i-node compared to deleting a file whose 
location is stored as a pointer to the next cluster at the start of each 
cluster. Or like freeing the memory used by a process instead of freeing 
each allocation using free().

There are lots of GCs faster than reference counting, just like there 
are lots of program optimizations.

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message