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