In article <web.3dcde797195c50e4178f7f9c0@news.povray.org>,
 "normdoering" <nor### [at] yahoocom> wrote:

> I'm confused. Are you saying a macro that was translated into C code and
> compiled wouldn't parse the same size arrays much faster?

Correct. First, a macro can't be compiled, it's a macro, it operates at 
parse/compile time. You can easily write things that can't be translated 
to C functions.
POV functions could be compiled, and are...to bytecodes run by a VM. 
They are fast enough to use as patterns and as functions for 
isosurfaces, and probably aren't as fast as they could be.


> I know that's not
> true. I've done a limited bit of 2D and 3D array coding in C and parsed
> larger arrays, written in text, translated to floats, doing more complex
> math much faster than POV is parsing the HF_ macros.

Yes, compiled C code is faster than the directly interpreted POV code. 
It would also be faster than an virtual machine running compiled 
bytecode, though not by anywhere near as much. For most things, a VM 
will be fast enough, patching the source code could be done if it isn't.

For the last time:
Plugins would not bring POV any closer to "compiled macros", either a VM 
or native machine code. I don't know why you think it would.

Compiling scene files to native machine code is a bit ridiculous. It is 
completely platform dependant, adds a huge amount of complexity, and 
adds speed where it is needed least. However, a VM could include hooks 
for translating to native code where needed, without breaking 
portability of the core code.

Plugin loading code would not be portable. You either have chunks of 
core code that need to be rewritten for each platform, making porting 
much harder, or you end up with a situation where some POV versions just 
don't support plugins.

Plugins themselves would not be portable, you would need to recompile 
for every platform, possibly with modifications to the plugin code. This 
*would* be a problem. You would need complete source code to port a 
plugin, not just "includes and headers".

So, you have a practically 100% platform dependant solution with lots of 
other headaches like plugins not being available for your platform, and 
only really speeding up a few things that weren't often used anyway. 
Again, little benefit with lots of problems. Unless you have come up 
with some miracle code that lets a plugin load and run on any platform, 
it isn't going to happen.
When you have alternatives that are as portable as the existing code, 
that will provide more speedups in the areas that really need it, though 
not quite as fast as compiled C code, is it so hard to understand why 
plugins aren't being added?

This has all been discussed before, I really suggest you go back and 
read some of the other threads on it and get yourself up to date.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message