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