 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How come POV is so slow when it comes to parsing a complex script?
Specifically, loops seem to take a very long time to run (compared to
say C++ / BASIC etc.), even if the maths inside is simple. Is there
some fundamental reason for this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew <ast### [at] hotmail com> wrote:
: How come POV is so slow when it comes to parsing a complex script?
: Specifically, loops seem to take a very long time to run (compared to
: say C++ / BASIC etc.), even if the maths inside is simple. Is there
: some fundamental reason for this?
There are many reasons for this.
Firstly, the main reason is that the POV-Ray scripting language is an
_interpreted_ language. This makes comparison with _compiled_ languages
(eg. C++) very unfair.
A compiled language is parsed and the compiled to the native machine code
of the system. The result of this is a stand-alone program which doesn't need
the compiler anymore in order to make it run. The program is, in practice,
converted to machine code which the CPU understands by itself. This, of course,
makes it very fast. The biggest disadvantage of this is that the code will
run on that processor alone. It will not run in any other processor (unless
the other processor can emulate it). (In practice these programs won't run
in another OS even if the computer is identical, but the reasons for this
are a bit different.)
An interpreted language is "executed" while it is parsed. For this you
always need the interpreter in order to run the program. The interpreter
parses the program and executes the commands at the same time. It should be
needless to say that this is a LOT slower than having a pre-compiled machine
code program. The biggest advantage and the main reason why this is done at
all is that the code becomes system-independent (as long as there's an
interpreter for that system).
There is also a third type of execution, which is a mix between the two:
The code is first parsed and compiled to a "machine code" or "bytecode"
(which isn't necessary any machine code known by any processor) and then
this "machine code" is interpreted by an interpreter.
I know of two languages which use this approach: Perl and Java. (Even they
do it a bit differently: Perl compiles the program on the fly to memory and
then interpretes the compiled code, while Java compiles the program to a
separate file and then this file can be interpreted as if it was a compiled
program.)
This approach takes advantage of the two types of execution: The program
is still system-independent and its execution is pretty fast. (It's not as
fast as native machine code, of course, but much faster than regular a
interpreted language.) It still has the disadvantage of needing the interpreter
in order to run the program.
POV-Ray is an interpreter in the most basic definition. It just parses the
code and "executes" at the same time.
A negative thing about this is that POV-Ray is an extremely slow interpreter.
Most interpreters are optimized to be fast (eg. most BASIC interpreters for
instance) even though they don't byte-compile the code but parse it directly.
Usually they load the program to memory and do all kinds of tricks to speed up
the execution.
However, POV-Ray does it the really slow way. POV-Ray interpretes the source
by readind directly the source file. Even #while-loops are done this way: A
loop will simply seek the file to the proper location. File I/O, even when
cached by the OS, is much slower than reading the source directly from memory.
With macros residing in other files then where they are called from, this
gets even worse: Each time the macro is called, the file is opened, seeked to
the right location, then the macro is read and interpreted from the file, and
then the file is closed. This is very slow!
POV-Ray was never intended to be a scripting language interpreter. It
didn't even have loops before version 3! (Please correct me here if I remember
wrong.) The original purpose of the pov-file was to contain the object
descriptions; POV-Ray would just read the file once and create the objects
and that's it. It wasn't designed to be a scripting language containing
loops and macros.
Now it is such a thing, however. Optimizing the parser for speed isn't,
however, a light task. There have been more important things to develop
instead of this "secondary" feature.
But perhaps in the future... (That is, POV-Ray 4).
The best way to go, in my opinion, is to do the same thing as Perl:
First parse the file and compile it to some type of bytecode to memory
(the format of the bytecode is completely free; it should be something that
best suits the needs of POV-Ray) and then this bytecode is interpreted with
a highly optimized interpreter (which isn't a hard thing to do, in fact).
This has a double-effect, however: Sources with no loops and macros will
parse slower than before! (Although not too much slower, I would say.) It's
only if the source has long loops and lots of macro calls when it starts to
get fast.
With a source which makes huge amounts of loops and macro calls (as isn't
very unusual nowadays), I would say that the parsing speedup would be in the
order of 10 to 100 times faster. Even if the parsing of "straightforward"
files (ie. no loops nor macros) gets a bit slower, I think it's a very
reasonable price to pay.
Of course one could go further and allow POV-Ray to dump the byte-coded
source to a file. Afterwards one could render just this file. POV-Ray would
just read it into memory and start interpreting right away, without any need
for parsing. This would speed up *everything* a lot.
This has a drawback, though: If POV-Ray does the byte-coding only internally,
it can trust that it's always syntactically correct. That is, it doesn't have
to make sanity checks to the byte-code, which allows making a faster
interpreter for it. If, however, a user-made bytecode is given to POV-Ray,
it would have to make a sanity-check to it when it interpretes it, which may
cause some overhead.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for that very educational read, Warp. :)
Hey, we should start making a short list of things that simply must be in
4.0, like this improved parser you're talking about. That way the Team won't
forget about these things when making 4.0.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wow! That was more of an answer than I was hoping for! I had feared
that POV's scripting had simply never been designed for speed above all
other considerations. I guess it's time I learn C++ properly and
generate some of my scenes that way...
I think I would have to agree - compiling to memory and then
interpreting the code would be a *very* welcome addition for v4. Any
time lost in interpreting "normal" scenes would probably be negligible
on the vast majority of computers running POV by that time (I'm guessing
POV 4 is at least 2 years off?), and the benefits in terms of scripting
capability would be enourmous.
As regards sanity-checking of a compiled POV file, a flag at the start
of the file identifying it as a user-generated file could be used to
perform sanity-checking only when necessary. One would then have to
trust people to use this flag properly, though...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Theoretically then, a performance increase could be gained by unrolling
loops of fixed length? For example, if this piece of code...
#declare loop=0;
#while (loop<10)
#declare my_array [loop] = loop;
#declare loop=loop+1;
#end
...appeared in the middle of a macro called hundreds and hundreds of
times, would the scene parse faster if the following were substituted?
#declare my_array [0] = 0;
#declare my_array [1] = 1;
#declare my_array [2] = 2;
#declare my_array [3] = 3;
#declare my_array [4] = 4;
#declare my_array [5] = 5;
#declare my_array [6] = 6;
#declare my_array [7] = 7;
#declare my_array [8] = 8;
#declare my_array [9] = 9;
Presumably it would as there would be fewer I/O calls to seek back to
the beginning of the loop each time. Or am I simply wrong :-) ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3be69fc4@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> A negative thing about this is that POV-Ray is an extremely slow
> interpreter.
Actually, there is nothing fundamentally slow about the interpreter itself,
just the design depends on disk reading. In fact the parser is spending
most of the time doing some kind of disk reading, and the speed increases
significantly if disk reading is faster. If you copy your files to a RAM
disk* you will see a difference!
Thorsten
* One that actually fits into the RAM, not one in virtual memory!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3be6b7fd$1@news.povray.org Andrew wrote:
> would the scene parse faster if the following were substituted?
>
> #declare my_array [0] = 0;
Had to try
100000 x #declare I=I+1; in a script versus a loop:
kernel user total
loop : 2.98 10.20 13.19
script: 0.90 4.19 5.09 sec.
Ingo
--
Photography: http://members.home.nl/ingoogni/
Pov-Ray : http://members.home.nl/seed7/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How can I make a RAM disk to try that out? :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So this isn't the same as letting Windows or whatever cache the file and
serve it from memory anyway?
> Actually, there is nothing fundamentally slow about the interpreter
itself,
> just the design depends on disk reading. In fact the parser is
spending
> most of the time doing some kind of disk reading, and the speed
increases
> significantly if disk reading is faster. If you copy your files to a
RAM
> disk* you will see a difference!
>
> Thorsten
>
>
> * One that actually fits into the RAM, not one in virtual memory!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo <ing### [at] homenl> wrote:
: 100000 x #declare I=I+1; in a script versus a loop:
: kernel user total
: loop : 2.98 10.20 13.19
: script: 0.90 4.19 5.09 sec.
Loop-unrolling is indeed one of the oldest optimization tricks. The basic
idea is that if you unroll the loop, the interpreter doesn't have to parse
the #while and #end in each loop, but it just has to interpret the commands
inside the loop n times.
The speedup seen above is most probably caused by the fact that POV-Ray
doesn't need to read and interpret the "#while" and "end" strings anymore to
do the same thing. Also not having to seek the file might speed up a bit, but
I don't think that's the main bottleneck here.
(Note that when we are optimizing assembly code for a current processor,
loop-unrolling may not be a good optimization anymore; it may even be that
it slows down the program. Nowadays processors have extremely advanced
loop optimizations in themselves and usually we don't need to "guide" the
processor in doing it. On the other hand, loop unrolling means more code,
which means that the code cache will fill up faster, which means slower code.
Of course this is not the case in POV-Ray, which is, may I say, an extremely
primitive interpreter.)
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3be6c02d@news.povray.org> , "Tony[B]" <ben### [at] catholicorg>
wrote:
> How can I make a RAM disk to try that out? :)
Go to the "Memory" control panel, select "RAM Disk: On" and then decide for
the size of your future RAM disk. On your way out, make sure that the
"Virtual Memory: Off" setting is in place. Then reboot.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3be6c45b$1@news.povray.org> , "Andrew"
<ast### [at] hotmailcom> wrote:
> So this isn't the same as letting Windows or whatever cache the file and
> serve it from memory anyway?
No. The operating system uses the cache together for all running
applications, background processes and so on. The RAM disk will only
contain the whole file, and it will contain it immediately while the disk
cache can only cache the file after it had to be read from disk once
already.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm, I just tried this with a file that took 1m45s to parse, and the
time was exactly the same from the RAM disk (512k in size) :-(
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Go to the "Memory" control panel, select "RAM Disk: On" and then decide
for
> the size of your future RAM disk. On your way out, make sure that the
> "Virtual Memory: Off" setting is in place. Then reboot.
Are we talking Windows 2000 or some other OS?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> The best way to go, in my opinion, is to do the same
> thing as Perl: First parse the file and compile it to
> some type of bytecode to memory (the format of the
> bytecode is completely free; it should be something
> that best suits the needs of POV-Ray) and then this
> bytecode is interpreted with a highly optimized
> interpreter (which isn't a hard thing to do, in fact).
If these two steps are strictly separated, then how will script I/O work,
where (1) the script writes POV-script to an external file and (2) later
includes that file to be parsed?
(1) would not happen until the interpretation stage while (2) require the
parsing stage. However, the parsing comes before the interpretation stage
you say.
Or maybe you mean that the whole process happen on a per-file basis where
both steps are performed every time a new file is opened?
This would for some scenes require switching back and fourth between parser
and interpreter a whole lot of times because a lot of files a included (just
think of heavy use of the parse_string macro). Is that would you propose?
(I'm not saying that's bad (it might be very good), I'm just curious if
that's what you mean.)
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3be6ceb2@news.povray.org> , "Tony[B]" <ben### [at] catholicorg>
wrote:
>> Go to the "Memory" control panel, select "RAM Disk: On" and then decide
> for
>> the size of your future RAM disk. On your way out, make sure that the
>> "Virtual Memory: Off" setting is in place. Then reboot.
>
> Are we talking Windows 2000 or some other OS?
Well, as Tony didn't specify the OS I took the one I use every day...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3be6c99a@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Nowadays processors have extremely advanced
> loop optimizations in themselves and usually we don't need to "guide" the
> processor in doing it.
Which will still fail when the exit condition of the loop cannot be
determined early enough. Unless you assume every processor design today
supports speculative execution of both possible branch directions. And even
more important, speculative execution takes a lot of resources, which not
only adds to the complexity of the processor, but most notably to the power
consumption. That is why most embedded processors have only minimal (if any
at all) support for branch prediction and other optimizations most of which
a good compiler could have made in the first place (i.e. out of order
execution) thus a very low power consumption. For those a partial unrolling
of a loop with be a major performance gain at a relatively low cost of
memory.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The obvious solution to this problem is to get rid of the need for writing
pov-script to a file which is then included.
You could create a string with all the pov-script you want to be executed
and then call an evaluation function which reads the string as if it was
pov-script.
Whether it parses, compiles and then interprets it, or just interprets it
while parsing, could be a question of which one is best and more optimal (and
perhaps both options could be given to the user).
But if the user really creates an include file on the fly, then it's
treated as any include file which has always existed. This method would just
be obsolete due to the evaluation function described above.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> But if the user really creates an include file on the fly,
> then it's treated as any include file which has always existed.
But how is the include file being treated? The same optimized way as the
main file I hope?
> This method would just be obsolete due to the evaluation
> function described above.
Yeah, if it allows strings that are several thousands of lines long and
which can be accesses in all the frames of an animation, then it'd be
obsolete (I often generate a very large include file on the fly in the first
frame of an animation and then include it in all the frames).
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tony[B] wrote:
> How can I make a RAM disk to try that out? :)
>
What OS?
Setting up a ram drive is a bit different on Linux than on OS/2 or DOS,
or Windows9x, or 2000.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* videotron.ca */}camera{location<6,1.25,-6>look_at a orthographic}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There is also a third type of execution, which is a mix between the two:
> The code is first parsed and compiled to a "machine code" or "bytecode"
> (which isn't necessary any machine code known by any processor) and then
> this "machine code" is interpreted by an interpreter.
> I know of two languages which use this approach: Perl and Java. (Even they
> do it a bit differently: Perl compiles the program on the fly to memory and
> then interpretes the compiled code, while Java compiles the program to a
> separate file and then this file can be interpreted as if it was a compiled
> program.)
>
Actually, Smalltalk used bytecodes and pre-dated Perl and Java. The first versions
of Smalltalk using bytecodes came out around 1980. Modern versions translate the
bytecodes to machine code on the fly. Some Basic interpreters also translated into
a bytecode-like language and Pascal used P-Code.
Getting back to POV-Ray, what is really needed is a better parser and interpreter.
Even interpreting bytecodes can be dramatically faster than parsing the text
directly from a file. As was mentioned elsewhere in this thread, POV-Ray's parser
was designed for reading the input file once, not looping, macros, etc. You need a
more sophisticated engine to do those efficiently.
David Buck
Simberon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Item #2: GLOWS!! GLOWS!!
:-)
--
//Mahalis
camera{location<0,0.25,-2> look_at 0.5*y} #declare T=texture{pigment{crackle
scale 0.5 rotate 90 turbulence 0.75 color_map{[0 rgb 1][0.05 rgb 1][0.1
rgb<1,0.25,1>][0.25 rgbf 1][1 rgbf 1]}} finish{ambient 1}} #declare
c=difference{torus{0.5,0.1 rotate -90*x}box{<0.7,0,0.2>,<-0.7,-0.7,-0.2>}}
merge{object{c translate<0.5,0.5,0>} object{c translate<-0.5,0.5,0>}
cylinder{<1,0.5,0>,<1,0,0>,0.1} cylinder{<-1,0.5,0>,<-1,0,0>,0.1}
cylinder{0.5*y,0,0.1} texture{T}}
--
"Tony[B]" <ben### [at] catholicorg> wrote in message
news:3be6a86c@news.povray.org...
> Thanks for that very educational read, Warp. :)
>
> Hey, we should start making a short list of things that simply must be in
> 4.0, like this improved parser you're talking about. That way the Team
won't
> forget about these things when making 4.0.
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] mobilixnetdk> wrote in message
news:3be723d9@news.povray.org...
> "Warp" wrote:
> > But if the user really creates an include file on the fly,
> > then it's treated as any include file which has always existed.
>
> But how is the include file being treated? The same optimized way as the
> main file I hope?
>
I would say, yes, include files would be optomized as well. I've recently been
thinking about this as well. That started when I learned that #include'd macros
open the include file each time the macro is called.
A good way is to parse an included file and keep the parsed file in memory for
the entire execution. When a macro is read it would be parsed into bytecode and
stored in memory. An index to it would be stored and anytime the macro is
encountered in the following code the bytecode is looked up and executed. No
need to open the included file again.
> > This method would just be obsolete due to the evaluation
> > function described above.
>
> Yeah, if it allows strings that are several thousands of lines long and
> which can be accesses in all the frames of an animation, then it'd be
> obsolete (I often generate a very large include file on the fly in the first
> frame of an animation and then include it in all the frames).
>
Many interpreters have no theoretical limit on the size of a string. The
SLang[1] interpreter, for instance, can handle strings hundreds of megabytes in
size.
As for keeping an instance across frames of an animation, this could be handled
with a form of persistent variable. Also, the parsed bytecode could be stored
between animation frames with no need to re-parse. Simply re-interpret. And
since you're just re-interpreting parsed code, which should be very fast, the
need for the large generated include file *might* not be necessary. It might be
just as fast, or nearly as fast and easier, to generate the data on the fly each
time. But again, a type of persistent variable could help here.
Michael
[1] SLang is the language that the JED editor is written with. Well, sort of.
Compiled code performs the core functionality of the editor, but much of that is
being taken over by SLang functionality. The rest of the functionality of JED
(such as context sensitive actions and language dependant formatting) is handled
strictly through SLang scripts files. It's at least as fast as any other editor
I've used, and since you can see 98% of the functionality, you can modify it to
suite your tastes. SLang, by the way, is a parse then interpret language that
can optionally store the bytecode to disk for faster parsing. See
http://www.s-lang.org/ and http://space.mit.edu/~davis/jed/ for more info.
--
#macro M(D)#local J=strlen(D);#local _=""#while(J>0)#local _=concat(_,substr(D
,J,1))#local J=J-1;#end _#end sphere{z*9,5pigment{rgb x}}#macro N(D,J)text{ttf
"timrom.ttf"M(D)1,0 translate-J}#end#macro O(E,K)#local _=N(E,K)light_source{-
z*9rgb 1projected_through{_}}#end O("leahciM"<1.6,-.3.9>)O("nosnhoJ"<1.6.9.9>)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Redbeard" <red### [at] wvadelphianet> wrote in message
news:3be8b2d5@news.povray.org...
>
[snip]
>
> I would say, yes, include files would be optomized as well. I've recently
been
> thinking about this as well. That started when I learned that #include'd
macros
> open the include file each time the macro is called.
>
> A good way is to parse an included file and keep the parsed file in memory for
> the entire execution. When a macro is read it would be parsed into bytecode
and
> stored in memory. An index to it would be stored and anytime the macro is
> encountered in the following code the bytecode is looked up and executed. No
> need to open the included file again.
>
[snip]
I think an exception should be made for mesh includes though eh? They are
already referenced similar to your description (if I understand correctly) as
objects and I wouldn't really want the include text hanging around in memory any
longer than necessary, considering the size they can achieve. ( And of course
I'm not referring to includes that generate meshes algorithmically)
Batronyx ^"^
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
YES!
And how about persistence of variables too? Or was there a good reason
they were left out?
Mahalis <don### [at] fakeycom> wrote in message
news:3be8946a$1@news.povray.org...
> Item #2: GLOWS!! GLOWS!!
> :-)
>
> --
>
> //Mahalis
> camera{location<0,0.25,-2> look_at 0.5*y} #declare
T=texture{pigment{crackle
> scale 0.5 rotate 90 turbulence 0.75 color_map{[0 rgb 1][0.05 rgb
1][0.1
> rgb<1,0.25,1>][0.25 rgbf 1][1 rgbf 1]}} finish{ambient 1}} #declare
> c=difference{torus{0.5,0.1
rotate -90*x}box{<0.7,0,0.2>,<-0.7,-0.7,-0.2>}}
> merge{object{c translate<0.5,0.5,0>} object{c translate<-0.5,0.5,0>}
> cylinder{<1,0.5,0>,<1,0,0>,0.1} cylinder{<-1,0.5,0>,<-1,0,0>,0.1}
> cylinder{0.5*y,0,0.1} texture{T}}
> --
>
>
> "Tony[B]" <ben### [at] catholicorg> wrote in message
> news:3be6a86c@news.povray.org...
> > Thanks for that very educational read, Warp. :)
> >
> > Hey, we should start making a short list of things that simply must
be in
> > 4.0, like this improved parser you're talking about. That way the
Team
> won't
> > forget about these things when making 4.0.
> >
> >
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Redbeard <red### [at] wvadelphianet> wrote:
: A good way is to parse an included file and keep the parsed file in memory for
: the entire execution.
This might introduce some problems with self-modifying code. Of course it
shouldn't be a big loss to disallow this (most programming languages do).
I also wonder if a pov-file including itself may cause some problem (yes,
this IS possible without creating an infinite include loop). Of course this
is also a trick not really necessary to be supported.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3be91b7f@news.povray.org...
> Redbeard <red### [at] wvadelphianet> wrote:
> : A good way is to parse an included file and keep the parsed file in memory
for
> : the entire execution.
>
> This might introduce some problems with self-modifying code. Of course it
> shouldn't be a big loss to disallow this (most programming languages do).
>
Self modifying code could be allowed relatively simply, I think. If the date of
a file has changed between includes, POV-Ray should re-parse it. Then, of
course, if variables, macros, etc. get changed, the interpreter calls the new
ones.
> I also wonder if a pov-file including itself may cause some problem (yes,
> this IS possible without creating an infinite include loop). Of course this
> is also a trick not really necessary to be supported.
>
Should work similar to what I mentioned above. There might be some logistical
problems, but what an include file does when it includes itself is to reparse
itself. If the file hasn't been changed, the interpreter could just start from
the beginning of the file again.
For some reason, this has got me thinking about namespaces. Namespaces, for
those who don't know, are ways of segregating variables between sets of files.
Say I write a set of include files that need to use global variables. Right
now, I have to be careful about naming my globals so no one else tries to use
them. With namespaces this is somewhat alleviated. At the top of the file you
add something like "#namespace MDJ" and every global variable referred to in
that file is prefixed with "MDJ::" (this is similar to C++ syntax... the actual
syntax probably would differ). Within the file I could use the variable "I"
without worrying about it being used outside the file, because it would actually
be "MDJ::I". Outside the group of files the variable could still be accessed
with "MDJ::I" but that wouldn't be as likely. I believe other languages use
similar concepts under different names. Packages are used (I can't remember
what language that is from...) as well as any number of different ways of
distinguising variables from one set of files to another.
What that long-winded paragraph boils down to is that there should be some
consideration made for "macro packages," sets of include files that are
associated with each other but not other include files. At this point I don't
know how it should be implemented, but I believe it should be discussed.
Well... enough jabbering from me for now.
Michael
--
camera{location<8,20>look_at<6,0,4>}light_source{<8,8>rgb 1}difference{union{
#macro M(D,J)#local R=asc(substr(D,J,1))-32;<div(R,10)*2,mod(R,10)>#end#macro
E(D,B,R)prism{-D,4+D,R#local C=1;#while(C<R+1)M(B,C)#local C=C+1;#end}#end E(
0," (2:FPKAD80* U_dZU"18)sphere{2,2}#macro T(N)cylinder{<9,-N,3><9,4+N,3>3-N}
#end T(0)}T(2)E(1"45LNXUK4"8)pigment{rgb x+y/2}}//(c)2001 MDJohnson(Redbeard)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Batronyx" <bat### [at] alliancecablenet> wrote in message
news:3be8ba1f@news.povray.org...
>
> "Redbeard" <red### [at] wvadelphianet> wrote in message
> news:3be8b2d5@news.povray.org...
> >
> [snip]
> >
> >
> > A good way is to parse an included file and keep the parsed file in memory
for
> > the entire execution. When a macro is read it would be parsed into bytecode
> and
> > stored in memory. An index to it would be stored and anytime the macro is
> > encountered in the following code the bytecode is looked up and executed.
No
> > need to open the included file again.
> >
> [snip]
>
> I think an exception should be made for mesh includes though eh? They are
> already referenced similar to your description (if I understand correctly) as
> objects and I wouldn't really want the include text hanging around in memory
any
> longer than necessary, considering the size they can achieve. ( And of course
> I'm not referring to includes that generate meshes algorithmically)
>
> Batronyx ^"^
>
Things that are currently objects should remain objects. Thus, a mesh, unless
it is redefined in a macro, is a mesh. Right now, I believe, if you set up a
mesh in a macro and then call the macro again, an entirely new object is made.
All references to the first mesh are completely separate from the references to
the second. Thus:
#macro Mesh()
mesh { ... }
#end
#declare M1 = Mesh()
#declare M2 = M1
#declare M3 = Mesh()
results in, and would result in, two meshes in memory. M1 and M2 refer to one
mesh and M3 refers to the other. The reason for this is that POV-Ray has no way
of knowing that executing the mesh statement a second won't result in a
completely different shape. It could be defined with variables that can change
from call to call.
Now, if you want to *really* optimize the interpreter, you can have it figure
out if it's going to change. If it isn't, some sort of global instance of the
mesh can be made and all other instances refer to the original.
I'd better stop now before I get into too big a discourse of optimizing objects
in POV-Ray... I need to look at the way objects are stored now before I go too
far :-)
Michael
--
#macro M(D,J)text{ttf"cyrvetic.ttf"D 1,0translate-J}#end#macro N(E,K)#local A=
M(E,K)light_source{-z*30rgb 1projected_through{A}}#end N("Michael"<1.6,-.2,5>)
N("Johnson"<1.9.8,5>)sphere{z*9,4pigment{gradient x+y scale 10color_map{[0 rgb
x][1rgb x+y]}sine_wave}} // (c)2001 Michael D Johnson red### [at] wvadelphianet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Redbeard wrote:
> Packages are used (I can't remember
> what language that is from...) as well as any number of different ways of
> distinguising variables from one set of files to another.
Java is one language that uses packages.
Their naming is to use a hierarchial tree of dot-separated names, and the standard
for choosing names is to start with reversed domain names. This latter way adds an
extra layer of safety against name collisions.
package org.xml.sax;
...
interface Parser {
...
}
Then in other code, one could use:
org.xml.sax.Parser thing = new org.apache.xerces.parsers.SAXParser();
or
import org.xml.sax.Parser;
import org.apache.xerces.parsers.SAXParser;
...
Parser thing = new SAXParser();
And here are the example docs I was just looking at:
http://xml.apache.org/xerces-j/apiDocs/overview-summary.html
Anyway, I find it more usefull than C++ namespaces where you have a single
top-level collection of naming shared by the entire world. Among other things, you
start to see names decorated with package naming like:
xmlSaxParser thing = new apacheXercesSAXParser();
And don't get the option of short-cutting.
--
Jon A. Cruz
http://www.geocities.com/joncruz/action.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3be91b7f@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> I also wonder if a pov-file including itself may cause some problem (yes,
> this IS possible without creating an infinite include loop). Of course this
> is also a trick not really necessary to be supported.
Well, I think POV-ray stores the absolute position os macros ina file, so
the macro would have to start at the exact location again.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jon A. Cruz" <jon### [at] geocitiescom> wrote in message
news:3BE9710A.59F6A388@geocities.com...
>
... useful java references snipped
> or
> import org.xml.sax.Parser;
> import org.apache.xerces.parsers.SAXParser;
> ...
> Parser thing = new SAXParser();
>
> And here are the example docs I was just looking at:
> http://xml.apache.org/xerces-j/apiDocs/overview-summary.html
>
> Anyway, I find it more usefull than C++ namespaces where you have a single
> top-level collection of naming shared by the entire world. Among other things,
you
> start to see names decorated with package naming like:
>
> xmlSaxParser thing = new apacheXercesSAXParser();
>
> And don't get the option of short-cutting.
>
Actually, C++ namespaces are more useful than that. Unfortunately, they are not
wide implemented (properly) yet. It would be more like[1]:
namespace apache_Xerces
{
class SAXParser ...
}
...
[other file]
using apache_Xerces::SAXParser; // SAXParser can be used undecorated.
using namespace apache_Xerces; // Imports entire namespace.
I'll agree that Java's approach is probably better. Namespaces were one of the
more debated issues in the C++ standardization process. It's not the best, but
it's better than what existed before.
Michael
[1] It's been a while and I'm rusty, so don't take me for 100% correct. Some of
the using directives may be incorrect.
--
camera{location<8,20>look_at<6,0,4>}light_source{<8,8>rgb 1}difference{union{
#macro M(D,J)#local R=asc(substr(D,J,1))-32;<div(R,10)*2,mod(R,10)>#end#macro
E(D,B,R)prism{-D,4+D,R#local C=1;#while(C<R+1)M(B,C)#local C=C+1;#end}#end E(
0," (2:FPKAD80* U_dZU"18)sphere{2,2}#macro T(N)cylinder{<9,-N,3><9,4+N,3>3-N}
#end T(0)}T(2)E(1"45LNXUK4"8)pigment{rgb x+y/2}}//(c)2001 MDJohnson(Redbeard)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: Well, I think POV-ray stores the absolute position os macros ina file, so
: the macro would have to start at the exact location again.
Does this mean that if I make a pov-file which writes another pov-file
containing a macro, then I include it (so POV-Ray reads the macro), then
I write the file again, but so that the macro changes place in the file,
and then call the macro, POV-Ray will issue some type of parse error?
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8 Nov 2001 05:12:35 -0500, Warp <war### [at] tagpovrayorg> wrote:
> Does this mean that if I make a pov-file which writes another pov-file
>containing a macro, then I include it (so POV-Ray reads the macro), then
>I write the file again, but so that the macro changes place in the file,
>and then call the macro, POV-Ray will issue some type of parse error?
Have you not readed thread
http://news.povray.org/0ok4utgnfkrc4tc0elpvt4a0ggn41cnkvk@4ax.com ?
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3bea5a92@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Does this mean that if I make a pov-file which writes another pov-file
> containing a macro, then I include it (so POV-Ray reads the macro), then
> I write the file again, but so that the macro changes place in the file,
> and then call the macro, POV-Ray will issue some type of parse error?
I don't know what will happen! I never tried it. All I know is how POV-Ray
stores the macro position. And you don't want it to parse the while file
again just to call a macro, do you?
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> Does this mean that if I make a pov-file which
> writes another pov-file containing a macro, then
> I include it (so POV-Ray reads the macro), then
> I write the file again, but so that the macro
> changes place in the file, and then call the macro,
> POV-Ray will issue some type of parse error?
Correct, though the parse error is different dependent on the details and
sometimes you don't get an error at all. I suppose that's because it's a
situation not considered by POV-Ray, so it doesn't have a specific way to
handle it.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Redbeard wrote:
> "Jon A. Cruz" <jon### [at] geocitiescom> wrote in message
> news:3BE9710A.59F6A388@geocities.com...
>
> > Anyway, I find it more usefull than C++ namespaces where you have a single
> > top-level collection of naming shared by the entire world. Among other things,
> you
> > start to see names decorated with package naming like:
> >
> > xmlSaxParser thing = new apacheXercesSAXParser();
> >
> > And don't get the option of short-cutting.
> >
> Actually, C++ namespaces are more useful than that. Unfortunately, they are not
> wide implemented (properly) yet. It would be more like[1]:
> namespace apache_Xerces
> {
> class SAXParser ...
> }
> ...
> [other file]
> using apache_Xerces::SAXParser; // SAXParser can be used undecorated.
> using namespace apache_Xerces; // Imports entire namespace.
Ahh, but what you see there is just a single name that lives in the top-level
namespace. (terms are just close, probably not precise to the actual ANSI spec).
You just put an underscore in the middle of that namespace. With Java, you could
have "org.apache", "org.apache.xerces", "org.apache.xml", each one being the
equivalent of nestled subdirectories. With C++ names, you'd have one top-level
directory with "apache", "apache_xerces" and "apache_xml" all living as
subdirectories in that main directory. In practice there's not so much difference,
but semanticly there is.
But I think the most important dinstinction is how those names are chosen. With
C++, each developer anywhere in the world picks what he hopes will be a short but
unique name for his work. Pick the same name for a namespace as someone else, and
you'll have trouble if you ever try to integrate with his code. But the Java trick
of standardizing on reversed domain names solves that problem quite nicely, and on
a world-wide basis.
--
Jon A. Cruz
http://www.geocities.com/joncruz/action.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jon A. Cruz" <jon### [at] geocitiescom> wrote in message
news:3BEAAFC2.8E01E69E@geocities.com...
> Ahh, but what you see there is just a single name that lives in the top-level
> namespace. (terms are just close, probably not precise to the actual ANSI
spec).
>
> You just put an underscore in the middle of that namespace. With Java, you
could
> have "org.apache", "org.apache.xerces", "org.apache.xml", each one being the
> equivalent of nestled subdirectories. With C++ names, you'd have one top-level
> directory with "apache", "apache_xerces" and "apache_xml" all living as
> subdirectories in that main directory. In practice there's not so much
difference,
> but semanticly there is.
>
> But I think the most important dinstinction is how those names are chosen.
With
> C++, each developer anywhere in the world picks what he hopes will be a short
but
> unique name for his work. Pick the same name for a namespace as someone else,
and
> you'll have trouble if you ever try to integrate with his code. But the Java
trick
> of standardizing on reversed domain names solves that problem quite nicely,
and on
> a world-wide basis.
>
As I said, I think Java has a better and more flexible way of doing it. One
limitation of using the reversed domain name, though, is that not everyone has
one.
I namespaces (or packages, or whatever) should be considered for POV-Ray 4.0,
but I don't how best to implement. There are other ways to do it beyond what
we've discussed here.
Michael
--
#macro M(D)#local J=strlen(D);#local _=""#while(J>0)#local _=concat(_,substr(D
,J,1))#local J=J-1;#end _#end sphere{z*9,5pigment{rgb x}}#macro N(D,J)text{ttf
"timrom.ttf"M(D)1,0 translate-J}#end#macro O(E,K)#local _=N(E,K)light_source{-
z*9rgb 1projected_through{_}}#end O("leahciM"<1.6,-.3.9>)O("nosnhoJ"<1.6.9.9>)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3be69fc4@news.povray.org...
> Firstly, the main reason is that the POV-Ray scripting language is an
> _interpreted_ language. This makes comparison with _compiled_ languages
> (eg. C++) very unfair.
Hmm... I wonder if we could make a POV-Ray "compiler"? As in, it would
parse your scene, and then create an executable which would render that
scene (and that scene only) at a resolution specified on the command line?
This would allow for various speedups and optimizations to be done, wouldn't
it? :)
Of course I realize it would be a nightmare to try and code, so maybe we'll
wait until pov4 comes out...
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <bdc### [at] hotmailcom> wrote:
: Hmm... I wonder if we could make a POV-Ray "compiler"? As in, it would
: parse your scene, and then create an executable which would render that
: scene (and that scene only) at a resolution specified on the command line?
: This would allow for various speedups and optimizations to be done, wouldn't
: it? :)
If you want to code a compiler for every possible platform and OS, be my
guest.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9 Nov 2001 03:57:38 -0500, Warp <war### [at] tagpovrayorg> wrote:
> If you want to code a compiler for every possible platform and OS, be my
> guest.
I wonder what size could have executable with all tracing loops unrolled ;-)
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 9 Nov 2001 00:09:05 -0800, "Ben Chambers" <bdc### [at] hotmailcom>
wrote:
>
>"Warp" <war### [at] tagpovrayorg> wrote in message
>news:3be69fc4@news.povray.org...
>> Firstly, the main reason is that the POV-Ray scripting language is an
>> _interpreted_ language. This makes comparison with _compiled_ languages
>> (eg. C++) very unfair.
>
>Hmm... I wonder if we could make a POV-Ray "compiler"? As in, it would
>parse your scene, and then create an executable which would render that
>scene (and that scene only) at a resolution specified on the command line?
Hmm, IIRC OORT did something like that. It's fairly straightforward to
call POV-Ray code directly for a hard-coded scene thus by-passing the
parser. OTOH the render speed would be identical and you would have to
add time for compile & link, thus no net gain.
/Erkki
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Erkki Søndergaard" <Erk### [at] povrayorg> wrote in message
news:3beda714.170951229@news.povray.org...
> >Hmm... I wonder if we could make a POV-Ray "compiler"? As in, it would
> >parse your scene, and then create an executable which would render that
> >scene (and that scene only) at a resolution specified on the command
line?
>
> Hmm, IIRC OORT did something like that. It's fairly straightforward to
> call POV-Ray code directly for a hard-coded scene thus by-passing the
> parser. OTOH the render speed would be identical and you would have to
> add time for compile & link, thus no net gain.
>
> /Erkki
Well, probably not very practical, but you could probably throw in some
scene specific optimizations in there. For instance, if you don't use
radiosity, you could just drop all of that code from the end compile. You
could check reflections, and hardcode which objects will (and won't)
reflect. Things like this. Like I said, probably not worth it, and more
tongue in cheek than anything :)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
