Christopher James Huff wrote:
>In article <web.3dcde797195c50e4178f7f9c0[at]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/
>

You've lost me.

However, I'm looking at this from a user's perspective, not a programmers.
Other programs I use have plugins, like Corel Draw and photopaint, and they
have script languages that seem to loop arrays faster. So I think the way I
do because I'm a user who's comparing different programs.

normdoering

Post a reply to this message