Which performs best: C loop calling short Io or Io loop calling short C routine?

[dennisf486]

For the game I'm working on, I have a very complicated data structure for storing the terrain (it works directly with compressed terrain data in memory without needing to decompressing it first!).  I have some C++ code already finished that abstracts away the details of the data structure so that the code displaying the terrain only needs to implement a callback function that accepts the 3-d coordinates to draw.  Something like:

void draw_callback(const Box& draw_this_box)
{
    ThreeDEngine.DrawBox(draw_this_box);
}

Obviously it gets called back thousands of times to draw a frame.  The calling loop looks a little like this:

void draw_terrain(FUNC_PTR callback)
{
   for (i=bytestream.begin(); i != bytestream.end(); i++)
   {
       Box b = decompress_box_at(i);
       (*callback)(b);
   }
}

If this were calling Io it would be going from C++ to Io to C++ to Io to C++, etc.

With a little bit of work I could rewrite the C++ portion of the code to work with a Cursor object (like cursors in database programming).  The Cursor object would store where in the bytestream the decompression routine is at, and the extra housekeeping data it needs at each point to decompress that box.  The interpretation of each next byte in this compressed stream depends on the box you decompressed last time, so you have to know what the last box is.  It isn't shown in the pseudocode, but this is actually also a tree structure, so the Cursor object will have to maintain its own internal Stack object too!

If I did this then the Io code wouldn't run out of a callback; instead it would look like this:

cursor := Cursor clone
while (cursor hasBoxes,
   DisplayOpenGLCube(cursor next_box)
)

Now it's just an Io routine calling a C routine (next_box) over and over.  The C routine should be fairly fast, but I will have to do a lot of work to make it maintain its place in the datastructure on a custom stack object, instead of implicitly remembering where it was using recursive functions as it does now.

So my question is, is the second version likely to perform better than the first version, and is it worth doing?

[Jeremy Tregunna-2]

A simple answer would be an Io loop calling C++ primitives. It will  
likely involve less message sends and block activations.

On 14-Jun-09, at 12:10 PM, dennisf486 wrote:

> For the game I'm working on, I have a very complicated data  
> structure for storing the terrain (it works directly with compressed  
> terrain data in memory without needing to decompressing it first!).  
> I have some C++ code already finished that abstracts away the  
> details of the data structure so that the code displaying the  
> terrain only needs to implement a callback function that accepts the  
> 3-d coordinates to draw.  Something like:
>
> void draw_callback(const Box& draw_this_box)
> {
>    ThreeDEngine.DrawBox(draw_this_box);
> }
>
> Obviously it gets called back thousands of times to draw a frame.  
> The calling loop looks a little like this:
>
> void draw_terrain(FUNC_PTR callback)
> {
>   for (i=bytestream.begin(); i != bytestream.end(); i++)
>   {
>       Box b = decompress_box_at(i);
>       (*callback)(b);
>   }
> }
>
> If this were calling Io it would be going from C++ to Io to C++ to  
> Io to C++, etc.
>
> With a little bit of work I could rewrite the C++ portion of the  
> code to work with a Cursor object (like cursors in database  
> programming).  The Cursor object would store where in the bytestream  
> the decompression routine is at, and the extra housekeeping data it  
> needs at each point to decompress that box.  The interpretation of  
> each next byte in this compressed stream depends on the box you  
> decompressed last time, so you have to know what the last box is.  
> It isn't shown in the pseudocode, but this is actually also a tree  
> structure, so the Cursor object will have to maintain its own  
> internal Stack object too!
>
> If I did this then the Io code wouldn't run out of a callback;  
> instead it would look like this:
>
> cursor := Cursor clone
> while (cursor hasBoxes,
>   DisplayOpenGLCube(cursor next_box)
> )
>
> Now it's just an Io routine calling a C routine (next_box) over and  
> over.  The C routine should be fairly fast, but I will have to do a  
> lot of work to make it maintain its place in the datastructure on a  
> custom stack object, instead of implicitly remembering where it was  
> using recursive functions as it does now.
>
> So my question is, is the second version likely to perform better  
> than the first version, and is it worth doing?
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Regards,

Jeremy Tregunna
jeremy.tregunna@...

[Steve Dekorte]

On 2009-06-14, at 10:08 AM, Jeremy Tregunna wrote:
> A simple answer would be an Io loop calling C++ primitives. It will
> likely involve less message sends and block activations.

That would be my guess too.

[Steve Dekorte]

On 2009-06-14, at 9:10 AM, dennisf486 wrote:

> If I did this then the Io code wouldn't run out of a callback;  
> instead it would look like this:
>
> cursor := Cursor clone
> while (cursor hasBoxes,
>   DisplayOpenGLCube(cursor next_box)
> )
>
> Now it's just an Io routine calling a C routine (next_box) over and  
> over.  The C routine should be fairly fast, but I will have to do a  
> lot of work to make it maintain its place in the datastructure on a  
> custom stack object, instead of implicitly remembering where it was  
> using recursive functions as it does now.
>
> So my question is, is the second version likely to perform better  
> than the first version, and is it worth doing?

If the number of iterations is high, then you'd probably want to put  
the cursor enumeration bit in C - something like:

cursor := Cursor clone
cursor display // display is a C function which will handle the loop  
in C

[dennisf486]

Right, but the 'display' method uses Io + OpenGL to do the displaying!  Of course I could just call OpenGL functions directly from the C/C++ routine and not touch Io at all, but that kind of defeats the purpose.
 
> If the number of iterations is high, then you'd probably want to put  
> the cursor enumeration bit in C - something like:
>
> cursor := Cursor clone
> cursor display // display is a C function which will handle the loop  
> in C
>

[Steve Dekorte]

On 2009-06-17, at 1:45 PM, dennisf486 wrote:
> Right, but the 'display' method uses Io + OpenGL to do the  
> displaying!  Of course I could just call OpenGL functions directly  
> from the C/C++ routine and not touch Io at all, but that kind of  
> defeats the purpose.

I see. Another trick is to use a display list so you only need to send  
the render instructions for the object once and then just tell the  
display list to render after that.