Just to say that i dont want POV++ ...the syntax is boring..


my_object->box_class(size)
this_object->transform {rotate 30*y ..}




news:web.4505f74fccfb62ebc3ac5be40@news.povray.org...
> In my first-ever attempt at trying to decide on an object-oriented
> programming language to learn (other than POV-Ray itself, that is!), I've
> been looking at both Java and Python. In doing so, I'm beginning to see
> similarities between the POV-ray scene description language and some of
> Java (and perhaps some of Python as well, but I'm not sure yet!) POV
> *seems* to use good parts of both...as well as improvements of it own...
> but that's my rather uninformed opinion at this point.  I find the POV-ray
> SDL easier and easier to work with, and would like to branch out into
> learning one of the major, similarly-constructed languages. (Not C++ -- 
not
> yet, anyway -- that's just too arcane for me right now. Big learning
curve.)
>
> My (really basic) question is this: Which OOP language is the POV-ray SDL
> most similar to? (This question probably begs other questions, but it will
> do for now.)
>
> Ken W.
>
>
>

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> 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.

  I think that you just used a kind of "meta-strawman": Your accusation
of me making a "strawman" argument was a strawman in itself. It's an
easy way of disregarding a valid argument.

  My point is very valid. 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 because of the exact same reason (having to
handle values larger than the word size) and thus the "inefficiency"
of the reference counter gets more or less buried under the inefficiency
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.

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

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

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

  Unpredictable? :D

  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.
  You have somehow succeeded in completely turning the issue around and
are accusing RC for the exactly problem that GC has. Incredible.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> But sure, if you're limited by what you can implement in C or 
> C++ at the application level, it's not too bad, as long as you remember 
> to manually break cycles everywhere and you're not trying to make it fast.

  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?

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >>You can allocate 100,000 individual objects and 
> >>free them all with one instruction.
> > 
> >   Assuming no memory fragmentation, of course.

> How do you think allocation in a garbage collected system works? Of 
> *course* there's no fragmentation.

  Oh, you have discovered a method to completely avoid memory
fragmentation? :-o Is it efficient?
  I think that the world would be very interested in hearing that
method.

> Um, why would it have to "put it somewhere"? The problem isn't "freeing 
> the object". The problem is running through all the pointers in the 
> object whose reference went to zero and marking those as freed also.

  Instead your non-fragmenting memory allocation engine knows by magic
all the objects which are not used anymore and those which are,
with no reference counts, with no going through allocated objects
to see if anything points to them, with nothing?

> And you still haven't solved the major problem, which is that reference 
> counting DOES NOT WORK.  Reference counting, even with sufficiently 
> large counters, does not free all the garbage, even if you do it 
> inefficiently.

  Ok, it doesn't work and it's slow.

> >   Btw, how does the GC engine know that the object is not used anymore?

> There are a number of ways, from simplistic to convoluted. Generally, GC 
> engines assume they can find the live pointers.

  Can't you give me even some idea?

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Thorsten Froehlich wrote:
>> Care to provide some credible links/evidence for this claim?
> 
> Smalltalk-80: The Language and Implementation. Or look into any LISP
> implementation.

Done before 19 - what - 85, at times when there were few 32 bit processors
available near and far? I was almost certain you would did out something
ancient to show "your point".

> As for a newer reference? Not too many around, as people don't use
> reference counting seriously

No, because, frankly, you just neither know what you are talking about, nor
that it is actually being used frequently. In fact, it is so "flawed" that
it made it into ISO/IEC PDTR 19768, aka TR1 for C++ standard library
extensions to be added to ISO C++ 200X. But hey, many string class libraries
(for various languages) use reference counting internally as well.

So sure, even though in fact the very program you use to write your messages
posted to this newsgroup uses reference counting, you say it isn't used
frequently. Maybe you want to change your argument from "people don't use
reference counting seriously", to "Darren New doesn't use programs using
reference counting seriously"? - Because as I take it, as in so many
programming related discussions/flamewars you started before, you managed to
dig a nice big hole for yourself to fall into and not even notice ... oh
well :-(

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Done before 19 - what - 85, at times when there were few 32 bit processors
> available near and far? I was almost certain you would did out something
> ancient to show "your point".

Yep. As I said.

>>As for a newer reference? Not too many around, as people don't use
>>reference counting seriously
> 
> No, because, frankly, you just neither know what you are talking about, nor
> that it is actually being used frequently. In fact, it is so "flawed" that
> it made it into ISO/IEC PDTR 19768, aka TR1 for C++ standard library
> extensions to be added to ISO C++ 200X. But hey, many string class libraries
> (for various languages) use reference counting internally as well.

And this reference counting system -- does it do reference counting on 
objects that include arbitrary pointers in them? That would be a trick. 
Or is it only a reference-counted pointer to a value that contains no 
pointers?  I'll grant you that the latter is sometimes useful, as you 
can actually collect the garbage when there aren't any circular 
references, as long as you remember to free all the links you're 
pointing to manually.

> So sure, even though in fact the very program you use to write your messages
> posted to this newsgroup uses reference counting, you say it isn't used
> frequently.

Thank you for completely ignoring the second half of the message I posted.

> Because as I take it, as in so many
> programming related discussions/flamewars you started before, you managed to
> dig a nice big hole for yourself to fall into and not even notice ... oh
> well :-(

Thank you for completely ignoring the second half of the message I posted.

And neener neener to you too.

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

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

Warp wrote:
>   Oh, you have discovered a method to completely avoid memory
> fragmentation? :-o Is it efficient?

Yes, and yes.

>   I think that the world would be very interested in hearing that
> method.

Go look up "compacting generational garbage collection" and get back to 
me. That you think this is something new tells me there's not much point 
in me discussing it with you.

>   Instead your non-fragmenting memory allocation engine knows by magic
> all the objects which are not used anymore and those which are,
> with no reference counts, with no going through allocated objects
> to see if anything points to them, with nothing?

No. Go read up on how garbage collection works. GIYF.

>   Ok, it doesn't work and it's slow.

Right.

>>>  Btw, how does the GC engine know that the object is not used anymore?

>>There are a number of ways, from simplistic to convoluted. Generally, GC 
>>engines assume they can find the live pointers.

>   Can't you give me even some idea?

So, the fact that I said "GC engines assume they can find the live 
pointers" doesn't give you an idea? I just told you how a GC engine 
knows an object isn't used any more - they base it on the fact that they 
can find the live pointers.

When a full GC is needed, they scan the tree of pointers starting at the 
root. This is called "mark and sweep". Primitive and slow, but functional.

Generational GC is an oldish technique. It's pretty efficient, based on 
normal programming usage. That is, it can be slow, but usually isn't, 
just like virtual memory can be slow for programs with no locality of 
reference, but usually isn't. It works by having several generations of 
collections. The newest generation is allocated as "unsaved." Whenever a 
pointer to something in generation 0 is assigned into an object in a 
higher generation, that gen-0 object is marked as "maybe live". (Note 
that that particular test is a trivial address comparison.) When 
generation 0 fills up, you walk all the objects that have that bit set 
(or which are in the linked list, or whatever), promote them to 
generation 1, and throw away everything you didn't promote. When that 
memory starts getting tight, you do the same with generation 1, from 
generation 2. Etc. This is complicated, of course, by finalization.

If you're actually interested in how (for example) Microsoft's GC works,
http://msdn.microsoft.com/msdnmag/issues/1100/gci/

Now, that wasn't hard to find, was it?

How about this one?
http://citeseer.ist.psu.edu/bacon03realtime.html
A realtime garbage collector with Low Overhead and Consistent 
Utilization for Java.  Good thing Java-style GC is so unpredictable, 
huh? So unpredictable you can plug in a real-time GC engine.

Now, since this hasn't anything to do with POV, let's take it to 
off-topic if you actually want to discuss it. But I have the feeling 
from your words here that you're more interested in arguing than 
actually learning anything. Maybe that's just a cultural thing, tho.

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

Btw, could you finally give me even a slight hint at how GC knows
that an object is not used anylonger?

  What you write sounds like it knows it by magic. Of course that can't
be, so there must be some other way. There must be *some* way for the
GC engine to know that in the code being currently executed there are
no references pointing to the objects. Assuming that the references
themselves don't tell the GC engine when they die (because that would
be reference counting!) then how? The GC has to also make a difference
between a reference being actually used in the currently-executed code
and an orphan reference.
  If object of type A has a reference to an object of the B, and the
latter also has a reference to the former, what does the GC engine do
to see that these are actually just orphan references? Does it follow
the references and see the recursion? What if there's a million objects
linked like this? Does it go through all of them? What happens if one
of the objects was still in use in the code? Was the traversal a waste
of time?

  I don't get it.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Oh, you have discovered a method to completely avoid memory
> > fragmentation? :-o Is it efficient?

> Yes, and yes.

  That would mean that the memory allocation engine knows ahead of time
the order in which objects will be "forgotten" (ie. nothing points to them
anymore so they can be freed) so that it can group them in contiguous
memory. Of course this is impossible (not even by analyzing the program
because the order in which objects are "forgotten" may depend on things
like user input).

  The only other alternative is that it performs memory defragmentation
before freeing the objects. But that doesn't sound any faster than
freeing the objects directly. (Memory defragmentation is something
useful per se, but doesn't sound like a fast way of freeing objects
in highly fragmented memory before the defragmentation has happened.)

  Oh, of course there's a third possibility: It doesn't free objects if
freeing them would cause fragmentation. But then they would consume
memory even though they are not used. Doesn't sound reasonable if that
memory would be needed for something else.

-- 
                                                          - Warp

Post a reply to this message