Warp wrote:

 > Darren New <dne### [at] sanrrcom> wrote:
 >
 >>>  The only other alternative is that it performs memory defragmentation
 >>> before freeing the objects.
 >
 >
 >
 >> No. It usually performs memory defragmentation as a concurrent part 
of freeing the objects.
 >
 >
 >
 >   If it performs memory defragmentation, that means that memory does get
 > fragmented (and thus need the defragmentation in the first place).


You're oversimplifying. You asked if I have an efficient way to avoid 
fragmentation. The answer is "yes".

 > Your
 > original claim was that there's *no* fragmentation at all and that's why
 > freeing a group of objects is faster.


No. My claim is that's why the whole system overall is faster. I take it 
from this description that you didn't bother to read yet the pages I 
linked to? Did you not understand the description, or the explanation of 
why it's more efficient than individual allocations and deallocations?

But yes, Bruno is right. It doesn't make any sense to discuss the 
benefits and flaws of the details of various systems before you learn 
how they work.

 >   So it's faster only under certain conditions, not all?


See the other post. Of course every algorithm that works for all uses 
will have a situation under which a specific pattern is inefficient. If 
you only ever create files and never delete them or move them, having an 
i-node listing individual blocks is inefficient compared to just listing 
the start sector and length. If you only ever allocate and never free, 
or you always allocate in a LIFO order, GC is a net loss compared to 
using a stack. If nothing you allocate dynamically ever has an embedded 
pointer to something else, reference counting isn't too bad. Even 
bubble-sort is efficient with few enough items in your list.

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

>> Go through memory, find all the dead objects, and *then* defrag the 
>> whole lot in a single pass. Done.
> 
>   And how is that faster from simply freeing the dead objects? The original
> point was that GC is much faster than freeing each object individually.
> Moving the dead objects around in memory before freeing them isn't going
> to help.

Nooo... move the *live* objects around. Not the dead ones.

And typically you use some kind of algorithm which reduces the amount 
you need to do even that.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>
>   There are basically three requirements for an OOP language:
>
> 1) Modules.

#include, like you pointed out.

> 2) Inheritance.

now w/  operator overloading!

#declare Sphere = sphere { <0,0,0>, 1 pigment { rgb 1 } }
#declare Sphere_Child = sphere { Sphere pigment  { rgb 0 } }

> 3) Dynamic binding.

Well, gosh.

:P

--
jussi

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> Nooo... move the *live* objects around. Not the dead ones.

  Well, you have to know *somehow* which objects are dead and which ones
aren't. IOW, you need to go through the dead objects and mark them as
dead. Or you need to go through live objects and mark them as alive.
Which basically means there are many situations where you can't simply
mark a whole set of objects as freed with one instruction, as was the
initial claim.

  And of course if the objects may have destructors, things get more
complicated, I suppose. (But of course, as Java fanatics say, who needs
destructors?)

-- 
                                                          - Warp

Post a reply to this message

jute <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >
> >   There are basically three requirements for an OOP language:
> >
> > 1) Modules.

> #include, like you pointed out.

  A module is something which you can instantiate. You can thus have
several instances of the same module, each with their own state. You
can even make these instances refer to other instances of the same
module (to create, for example, linked lists).

  An #include file is a really, really ascetic "module" which has only
one single static "instance" and that's it. You can't make several
instances of it and you can't have every instance have their own state.
It can hardly be called a module at all.

  In object-oriented programming modules become extra important because
of inheritance: You can make modules which are inherited from other
modules, and you can make functions which handle base type modules and
give then derived type instances instead, and it will work ok. You can,
for example, have a linked list where each node is of a different type
(but inherited from a common base module).

> > 2) Inheritance.

> now w/  operator overloading!

> #declare Sphere = sphere { <0,0,0>, 1 pigment { rgb 1 } }
> #declare Sphere_Child = sphere { Sphere pigment  { rgb 0 } }

  That isn't even valid syntax. You probably meant "object { Sphere ...".
And even then it doesn't work: The second object will be white too.

  And even if it did work as you wanted, it would still not be inheritance.
What you are doing there is making a copy of an object and modifying (or
trying to, if POV-Ray supported it) its attributes. That's not inheritance.
The first sphere is not a more abstract object and the second one a more
specialized one. IOW, there's no "is a" relationship. There's more like
an "attributes were copied from" relationship.

> > 3) Dynamic binding.

> Well, gosh.

  Inheritance is quite pointless without dynamic binding.

  Ok, it can be used to group common functionality and contents into
one base class, but that's about it. You can't specialize anything
in the inherited classes in such way that the specializations will
be called even in code which only handles base class type references.

-- 
                                                          - Warp

Post a reply to this message

>> Nooo... move the *live* objects around. Not the dead ones.
> 
>   Well, you have to know *somehow* which objects are dead and which ones
> aren't. IOW, you need to go through the dead objects and mark them as
> dead. Or you need to go through live objects and mark them as alive.

Mark the live objects as alive.

> Which basically means there are many situations where you can't simply
> mark a whole set of objects as freed with one instruction, as was the
> initial claim.

Actually, my initial claim was not "GC is faster than RC". My initial 
claim was "RC doesn't work properly, but GC does", that's all.

>   And of course if the objects may have destructors, things get more
> complicated, I suppose.

I've never had the misfortune to try that, but I would imagine it does...

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> jute <nomail@nomail> wrote:

> > #declare Sphere = sphere { <0,0,0>, 1 pigment { rgb 1 } }
> > #declare Sphere_Child = sphere { Sphere pigment  { rgb 0 } }
>
>   That isn't even valid syntax. You probably meant "object { Sphere ...".
> And even then it doesn't work: The second object will be white too.
>

Yeah, how irritating. (...he says, in a small voice barely heard above the
din...)   :-P

Post a reply to this message

Warp wrote:
  >> #declare Sphere = sphere { <0,0,0>, 1 pigment { rgb 1 } }
>> #declare Sphere_Child = sphere { Sphere pigment  { rgb 0 } }
> 
>   That isn't even valid syntax. You probably meant "object { Sphere ...".
> And even then it doesn't work: The second object will be white too.
> 

Well, I know it is a little off-topic but POV-Ray (POV-Ray 3.6 at least) 
will happily parse the fragment

#declare Sphere = sphere { <0,0,0>, 1 pigment { rgb 1 } }
#declare Sphere_Child = sphere { Sphere pigment  { rgb 0 } }

Or even some weirder things like

#declare Sphere = sphere { <0,0,0>, 1 pigment { rgb 1 } }
#declare Sphere_Child = box { Sphere pigment  { rgb 0 } }

But I assume that it is just something unintentionally left behind in 
the code of the parser.

Regards,
Hugo.

-- 
www.bishop3d.com

Post a reply to this message

oh, man... java guys are completely bonkers!

compare this:

import org.pov.*;
import org.pov.vegetation.*;
import org.pov.hormann.isowood.*;
import org.pov.tran.clouds.*;
import org.pov.someguru.WonderfulFeature4;
import org.pov.cabasson.PoorFeature1;

public class MyScene extends BasicOutDoorScene // Which extends POVScene,
and already has a light_source, a sun, and methods for the seasons and
Earth rotation ....
{
    public static main (int argc, String [] argv)
    {
        SetHandedness(LEFT_HANDEDNESS);

        GlobalSetting gs = new GlobalSettings();
        Radiosity rad = new RadiositySettings(); // Empty constructor with
defaults
        rad.setPretrace(0.04, 0.01);
        rad.setErrorbound(0.6);

        gs.setRadiosity(rad); // Or
gs.setRadiosity(Radiosity.OUT_DOOR_LOW_QUALITY)

        BuildScene();

        Render(640, 480);
    }

    private void BuildScene() // virtual method
    {
        final RADIUS = Double.parseDouble(argv[0]).doubleValue();

        Sphere s = new Sphere (0, RADIUS); // promotion is implemented by
method overloading: could be new Sphere (new Position(0,0,0), RADIUS) or so
.....

        s.translate(10, 0, 0);
        s.rotate(-20, 0, 0);
        Pigment p = new Pigment(new Rgbt(1));
        Interior interior = new Interior();
        interior.setIor(Consts.GLASS_IOR);
        interior.setFadeColor(Colors.Blue);
        interior.setFadeDistance(s.getRadius()/2);
        s.setPigment(p);
        s.setInterior(interior);
        set.setPhotons(new ObjectPhotons(...));
        this.add(s);

        Plane ground = new Plane
        (
            y, 0,
            new Pigment
            (
                CHECKER,
                new ColorMap
                (
                    .../...
                ),
                new Turbulence(0.5, 2.0, 0.65, 8)
            )
        )
        ground.getPigment().setWarp(BLACK_HOLE, new Position(...));
        ground.getPigment().scale(2.0);
        this.add(ground);

        /// Etc ....

    }
}


to this:

// +W640 +H480

#include "org/pov/vegetation"
#include "org/pov/hormann/isowood"
#include "org/pov/tran/clouds"
#include "org/pov/someguru/WonderfulFeature4"
#include "org/pov/cabasson/PoorFeature1"

/* user-adjustable params */
#declare RADIUS = 1;


// "method"
#macro setPretrace( s, e )
  pretrace_start s
  pretrace_end e
#end

global_settings {
 radiosity {
  setPretrace(0.04, 0.01)
  error_bound .6
  OUT_DOOR_LOW_QUALITY() // a macro
 }
}

#local MyScene =
union {
 object { BasicOutDoorScene } /* Which extends POVScene,
and already has a light_source, a sun, and methods for the seasons and
Earth rotation .... */

        SetHandedness(LEFT_HANDEDNESS); // user povray macro

        #local s = sphere { 0, RADIUS }
 object { s
  translate 10*x
  rotate -20*x
  pigment { rgbt 1 }
  interior { ior GLASS_IOR fade_color z fade_distance RADIUS/2 ... }
 }

        #local ground = plane {
            y, 0
            pigment
            {
                checker,
                colorMap //?? for checker?!
                {
                    .../...
                },
                turbulence <0.5, 2.0, 0.65>*8
            }
        }
        object { ground pigment { warp{ BLACK_HOLE, NEWPOS } scale 2.0 } }
    }
}

object { MyScene }


None of those declarations are really needed, but i decided to do a straigh
conversion to compare...

Java guys truly hate conciseness and practical matters.  Why would someone
want to transform the latter into the former is way beyond me...

Besides, just waiting for the JVM startup and load all the wrappers libs
would take an eternity, *before* any parsing or trace whatsoever!

well, programming language pissing is always a popular sport... :)

povray SDL has C syntax and scripting language semantics.  However, it's not
that much of an imperative language, being much more of a declarative
language, like HTML.

Post a reply to this message

Hugo <hug### [at] yahoocombr> wrote:
> #declare Sphere = sphere { <0,0,0>, 1 pigment { rgb 1 } }
> #declare Sphere_Child = sphere { Sphere pigment  { rgb 0 } }
>
> But I assume that it is just something unintentionally left behind in
> the code of the parser.

I don't think so:  i believe it's intentional it makes perfect sense.  You
define an object with a texture and then later modify a few more
attributes.  It's like in Ruby where you can later "open" a class
definition and modify some methods or something.  You can declare an object
with a default texture and later, when actually using it, altering the
pigment, or finish or the whole texture altogether...

Post a reply to this message