 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] tag povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
