Am 21.04.2018 um 17:03 schrieb Bald Eagle:

> Just for my own information, I'm wondering why POV-Ray is so painfully slow to
> process non-rendering information (parse time).
> 
> I'm asking, because I converted some of Paul Nylander's Mathematica code for the
> reaction-diffusion algorithm to SDL, and although I knew beforehand that it has
> a fair amount of looping through a 'large' array (160x120), I was still somewhat
> amazed and dismayed that it was as slow as it was.
> 
> This is thrown into even starker contrast when I run the reaction-diffusion code
> from Coding Challenge into Processing - which somehow manages to crank out
> results on a 700 x 500 grid at 60 frames per second (that's what's in the code,
> and the default speed - no idea if this is actual)
> I'm pretty sure Processing is as high a level language as SDL, and it's not
> compiled... so what IS the difference?

From the Processing web page:

"The idea of sketching is identical to that of scripting, except that
you're not working in an interpreted scripting language, but rather
gaining the performance benefit of compiling to Java class files."

So yes, Processing /does/ make use of compilation.

The fact that a language has an interactive mode (which /may/ be using
an interpreter) doesn't mean the language can't be compiled.


> Is there some sort of bottleneck or fundamental reason that the programmatic
> handling of data is so slow in comparison to other languages?

Yes, there is.

Every reasonably fast contemporary programming language makes use of at
least /some/ degree of compilation. For instance, functions, procedures
and/or classes might use proper compilation, or at least "compiled" into
an internal intermediate representation that is faster to interpret.

POV-Ray's parser is a genuine interpreter. No compiling going on /at
all/ (*)

(* Except for user-defined functions. Those are compiled into bytecode
for a proprietary virtual machine.)


The structure of POV-Ray's SDL differs significantly from that of
contemporary scripting languages, in that it is essentially a linear
data description language without any control flow (no branches, no
loops, no macros, no nothing), intermingled with an entirely different
scripting language providing control flow features /at the token level/;
i.e. the control flow portion of the language is blissfully unaware of
the structure of the data description language.

This allows constructs such as:

    #ifdef(Object2)
      union {
    #end
    object { Object1 }
    #ifdef(Object2)
      object { Object2 } }
    #end

Note how this construct even defies indentation rules: You can indent it
according the control flow statements, /or/ you can indent it according
to the data description, but not both. And this is still a very tame
example compared to what's possible.

Worse yet, the variables mechanism woven into the whole smash can't be
clearly assigned to either of the two portions of the language: On the
one hand, it is an essential part to /drive/ the control flow (e.g. via
`#if(MyVar)`); on the other hand, they can be assigned values
/generated/ via the control flow language.

For example:

    #declare Fnord = (Foo #ifdef(Add) + #else - #end Bar);

This makes it virtually(?) impossible not only to compile POV-Ray's SDL
as a whole, but also to even just compile its control flow portion into
a generator for a linear data description.


So in order to really speed up parsing, you'd need to re-invent
POV-Ray's language.

Post a reply to this message