POV-Ray : Newsgroups : povray.advanced-users : the POV-ray SDL--similar to Java and/or Python? : Re: the POV-ray SDL--similar to Java and/or Python? Server Time
7 Oct 2024 00:25:23 EDT (-0400)
  Re: the POV-ray SDL--similar to Java and/or Python?  
From: Darren New
Date: 13 Sep 2006 21:19:52
Message: <4508ae38$1@news.povray.org>
Warp wrote:
>   Oh, of course handling more data than the natural pointer size of the
> system is very efficient. It's just the reference counter which is
> inefficient because it has to be able to count more than the natural
> word size. Everything else is efficient even though everything else
> also needs to handle values larger than the natural word size. Yes,
> makes sense. Or then not.

Thank you for that lovely strawman.

>   Besides, not everything *has* to be reference-counted.

Um, yes?  So?   You're correct: Where something isn't reference-counted, 
the size of the reference counter adds no overhead.

>>Most 
>>reference-counted systems allocate between five and eight bits for 
>>reference counts.

>   Doesn't sound like a very smart thing to do. Sounds like over-optimization.

When you're trying to put 20,000 objects into 64K of ram, yes, it's 
actually quite a smart thing to do.

>>Incidentally, that's another reason reference counting 
>>isn't used much - the size penalty.
> 
>   And incidentally many (most? all?) garbage-collected languages will force
> every single class to be allocated dynamically

Only semantically.

> (which will add at the
> very least the type or size of the object to be stored alongside it
> so that it can be properly freed)

Only if the semantics of the language aren't already requiring that 
information.

>, which in turn forces every object
> to be handled through at least one reference (which will add the size
> of a pointer to the total memory consumption of the object)

That would be incorrect.

>, plus they
> also usually automatically make every object dynamically bound (which
> will add at least the size of some kind of pointer to the total memory
> consumption of the object).

That would also be incorrect.

>   Even by a rather conservative estimate we could estimate that each
> object requires at least 12 bytes of overhead in such a language.

Your ignorance of modern technology in this field is showing.

> of course that is nothing to worry about. The size of a reference count
> on the other hand is something to be very worried about.

I didn't say they weren't something to be worried about. I said that 
it's *a* thing to be worried about.

Reference counting doesn't solve the problem of knowing when to collect 
the garbage. It's inefficient in both time and space, it causes 
unpredictable performance by requiring large amounts of time to free 
arbitrarily large structures all at once due to cascading reference 
counts going to zero, and virtually nobody who knows anything about 
garbage collection uses it anymore.

That you could design a system that's even *more* inefficient than 
reference counting by not having followed the research over the last 20 
years or so of how to do things right should surprise nobody.

-- 
   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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.