Am Wed, 15 Apr 2009 15:35:33 -0300 schrieb nemesis:
> 
> Now, I'm probably all wrong and messed up here so if anyone cares may
> correct me.  But I do feel JIT-compiled, bytecode compiled or even
> native code compiled SDL would do nothing for performance except perhaps
> make it worse should a more expressive and general language be used for
> the next SDL.

Ideally parsing would take only a fraction of the time used for scene 
creation and actual script execution. I suspect, although I cannot prove 
it, that POV 3 spends most its time used for parsing in string comparison 
routines (that means, i could try to prove it with a profiler...) and 
things like that. Any implementation that eliminates the need for 
repeated string matching (you have to do it once, but not each time a 
loop is executed) would be fine.

> I've recently been taking a look at Povray beta source, in particular
> parse.hpp and associated.  It is the purpose of parse to create a long
> list of povray objects and it does that by analizing the SDL code,
> breaking it down into tokens and calling as it goes the internal
> functions which will create the objects, like Create_Sphere or
> Create_Plane.

And actually its quite good at it. If this was all we used SDL for, then 
everybody would be happy. But no, we want loops and macros and 
identifiers.

> 
> Quite frankly, hardly any external general-purpose language would do
> much better at pure speed than using this method.  They'll still have to
> parse and create the objects in the same manner, by binding some of its
> particular calls to calls to povray object-creating functions and
> methods.  But there's also a compilation step.  And I don't believe
> parsing itself would be faster by going with a general purpose language,
> even lightweight ones like Lua, Tcl or Scheme.

That's for simple scenes where the whole file is processed only once. I'm 
sure the most simple scenes would load a bit slower with a bytecode-
compiled language. All scenes where parse time currently is an issue 
would load faster, because parsing of loops and macros is done only once, 
loops are then executed as often as they need to be.

> How can you be faster for a general purpose language that would allow
> for creation of unrestricted user-level functions rather than pov's
> textual macros and still bring possibly much more unecessary stuff to
> the table?  How can that be faster than the SDL's straightforward
> parsing by directly calling the creation functions?
> 
> I was thinking even if I would use a native compiled language perhaps it
> would not be worth it because I believe most users of povray SDL enjoy
> an iteractive development style:  write a little, parse with low quality
> settings, go back, loop.  Would the time taken on parsing and
> compilation be worth it?  Current SDL only takes time on parsing,
> compilation merely means calling the internal creation functions.

Let's take a Perl script. I write it in pretty the same manner as you 
describe because I'm not too good at Perl. The perl interpreter compiles 
it to bytecode and executes it, but I don't even notice the time it needs 
to start up, even though Perl brings loads of features most of which I 
never use.

> I'm not against a better, more expressive SDL that would allow for far
> better and convenient scripting and do away with many name clashes with
> true scoping rules.  Just pointing out that that kind of power may also
> mean slower rather than higher performance.

Post a reply to this message