In article <39A### [at] faricynet> , David Fontaine 
<dav### [at] faricynet>  wrote:

> Hmm, it takes 30 seconds to generate one layer of my dome, but each layer has
> <300 pieces.

Memory consumption is not directly related to the number of objects to
generate...

> Accuracy and calculation speed.

Accuracy maybe, but speed no.  All modern processors used in personal
computers (and better) have floating-point unit(s) which will be able to
perform basic mathematical operations in the same (if not less, i.e. for
divisions) time as the integer unit(s) do.


      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

Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: Indeed. If you compute this with standard 32 bit integer arithmetic, the
: result is 925. Probably not what you had in mind. 

  I didn't check if the values would fit into a 32-bit integer, but you get
the idea.
  And if integers are ever implemented in povray, there should be a very long
integer type (at least 64 bits) anyways :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

David Fontaine <dav### [at] faricynet> wrote:
: I was thinking, not compiling it to machine code, but compressing the text.

  Machine code and byte-code are different things.
  Well, yes, they are very similar. The difference is that machine code is
the one that the processor reads directly (the textual representation of
machine code is called assembler (or assembly, I'm not sure)). Byte-code is
similar to machine code, but it's interpreted by the program. Byte-code has
more freedom on what commands you can implement and what things it can do.
You can put support for very application-specific commands in your byte-code
interpreter; this is not usually possible with machine code. The avantage
of byte-code over interpreted source code is speed.

  Compressing the text has little effect in speed. It may have some minor
speed improvement since you don't have to compare 8 characters but just 2,
but in the average the speed improvement will probably be very small. The
length of the keywords, identifier names and so on is not so important.
  Parsing and interpreting a file doesn't need string search. Even when
you are looking for several keywords which have an identical beginning
(such as int, interior, interpolate, intersection, intervals) you only have
to go through the text once, without having to go back and forth.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:

> No, the reason for the slow parsing of POV-Ray scenes are mostly related to
> memory allocation.  Please note that this topic has been discussed for an
> endless time before, just go back far enough in either povray.general or
> povray.programming .

I've kind of wondered about that.  I have a scene that parses in 15 minutes,
or rather, all the *code* is read in in 15 minutes.  All the #render lines
are printed, but it's another 2.5 hours before it gets around to setting up
the scene.  Why is this?  Does it do a preparse, where it checks the code,
then allocates memory?  The scene is memory intensive, so that would make
sense.

However, it's really annoying.  I use the #render messages to know how far
it's gotten in the parse, but it's useless if it only tells how far it is in
the parse and not how far along it is towards actually starting on the
scene.

The other question I have is, why does memory allocation take so long
compared to the inital parse?

Geoff

Post a reply to this message

In article <39ad151a@news.povray.org> , Geoff Wedig 
<wed### [at] darwinepbicwruedu>  wrote:

> I've kind of wondered about that.  I have a scene that parses in 15 minutes,
> or rather, all the *code* is read in in 15 minutes.  All the #render lines
> are printed, but it's another 2.5 hours before it gets around to setting up
> the scene.  Why is this?  Does it do a preparse, where it checks the code,
> then allocates memory?  The scene is memory intensive, so that would make
> sense.
>
> However, it's really annoying.  I use the #render messages to know how far
> it's gotten in the parse, but it's useless if it only tells how far it is in
> the parse and not how far along it is towards actually starting on the
> scene.

Once parsing is done, POV-Ray generates bounding boxes.  This will take
additional memory, and if at this time your system runs out of physical
memory, it will cause a significant slowdown due to swapping.

You can turn off building of bounding boxes which will make this stage
faster at the expense of rendering speed.  As building the bounding boxes in
an internal process that happens after parsing, you can't see anything.

> The other question I have is, why does memory allocation take so long
> compared to the inital parse?

Memory is managed by the operating system and in general requires more or
less advanced algorithms (depending on whether you expect lots of small or a
few big blocks, average number expected per application, and millions of
other small issues).


     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

Thorsten Froehlich wrote:

> > Hmm, it takes 30 seconds to generate one layer of my dome, but each layer has
> > <300 pieces.
>
> Memory consumption is not directly related to the number of objects to
> generate...

Each layer takes just over 5 megs. 30 seconds to alocate that?? I've done scenes
where 10 megs are allocated in five seconds, because there is no CPU-intensive
parsing. Of course, comparing, say, POV to C, wouldn't be remotely fair, but I'd be
willing to bet even interpreted BASIC could run my code faster.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

Warp wrote:

>   Machine code and byte-code are different things.
>   Well, yes, they are very similar. The difference is that machine code is
> the one that the processor reads directly (the textual representation of
> machine code is called assembler (or assembly, I'm not sure)). Byte-code is
> similar to machine code, but it's interpreted by the program. Byte-code has
> more freedom on what commands you can implement and what things it can do.
> You can put support for very application-specific commands in your byte-code
> interpreter; this is not usually possible with machine code. The avantage
> of byte-code over interpreted source code is speed.

Okay, but how can byte-code be platform dependant then?

>   Compressing the text has little effect in speed. It may have some minor
> speed improvement since you don't have to compare 8 characters but just 2,
> but in the average the speed improvement will probably be very small. The
> length of the keywords, identifier names and so on is not so important.
>   Parsing and interpreting a file doesn't need string search. Even when
> you are looking for several keywords which have an identical beginning
> (such as int, interior, interpolate, intersection, intervals) you only have
> to go through the text once, without having to go back and forth.

What about control aids? They would process much faster in byte-code. Thorsten
says it already does something like this though...

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Once parsing is done, POV-Ray generates bounding boxes.  This will take
: additional memory, and if at this time your system runs out of physical
: memory, it will cause a significant slowdown due to swapping.

  I think that the light buffers also take a considerable amount of memory
and time when you have a lot of light sources.
  I have run out of memory due to light buffers caused by excessive amount
of light sources.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

David Fontaine <dav### [at] faricynet> wrote:
: Okay, but how can byte-code be platform dependant then?

  Well, it depends how you make your byte code.

  The most efficient way of storing numbers (integers and floats) is to
write their byte values in memory directly to the file as raw binary data.
In this way they will take the least space and they can be read very fast
(you don't have to parse it, you just read that binary data directly into
the memory location that represents your variable).

  This is, however, very system-dependant. Some systems use big-endian
numbers while others use low-endian numbers. If you try to read a big-endian
number directly into a variable, as described above, but the system uses
low-endian numbers, the value assigned to the variable will be little less
than rubbish.

  You could of course change the endianess of the number while reading if
you know that you have to, but that destroys the point why we are making
this in the first place: Speed.

  Endianess, however, is not the only problem. Some systems can use a
different floating point number format than other systems. Even when using
the same format (usually the IEEE standard format), the size (in bytes) of
the numbers may differ.
  When we are dealing with integers, there might be some systems that do
not use a complement-of-2 format for them, as most systems do. Again, if
we try to read raw binary data of the wrong format, we get just rubbish.

  Another way of storing the numbers is to use a povray-specific and
platform-independent format and then for each specific system parse this
number and convert it to the native format.
  The ascii representation of a number (the one we use in povray code) is,
in fact, this kind of platform-independent coding.
  The ascii representation as one drawback: It's long and inefficient.
  A more compact and efficient representation could be designed, but still
we have to problem of slow parsing and conversion between formats.

: What about control aids? They would process much faster in byte-code. Thorsten
: says it already does something like this though...

  I don't know how isosurface functions are implemented in megapov, but I
wouldn't be surprised if they were converted to byte-code (which uses
stack arithmetic) which is interpreted while rendering. And we all know
how fast isosurfaces are (they are incredibly fast).
  Someone who knows could tell us how it is done.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39ad99dd@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   The most efficient way of storing numbers (integers and floats) is to
> write their byte values in memory directly to the file as raw binary 
> data.
> In this way they will take the least space and they can be read very fast
> (you don't have to parse it, you just read that binary data directly into
> the memory location that represents your variable).
...snip...

This only applies to *saving* the byte code data. And as you mentioned, 
it is possible to save/read the data on platforms of both endianness. 
While this is slower, it isn't as slow as reading ASCII.
But this doesn't really matter, since you don't need to save the byte 
code to a file that will go to another system. At most, a temporary file 
will be needed. Most or all of it can reside in RAM, and be processed 
much faster than POV can parse now. Since you can always use the 
original source file, there isn't any need for the byte codes to be 
saved to their own format.


> : What about control aids? They would process much faster in byte-code.

What are "control aids"?


>   I don't know how isosurface functions are implemented in megapov, but I
> wouldn't be surprised if they were converted to byte-code (which uses
> stack arithmetic) which is interpreted while rendering. And we all know
> how fast isosurfaces are (they are incredibly fast).
>   Someone who knows could tell us how it is done.

I think the isosurface functions do use byte codes or a similar 
technique. I don't understand either one of them well enough to say for 
sure, though.
And I wouldn't call them "incredibly fast"...well, if you compare them 
to the POV-Script parser...and they are surprisingly fast. Just not 
"incredibly" fast. :-)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message