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

>   It's not the only benefit. The other benefit would be precision. If you
> use very large integers, floats may lose information.

Just like integer precision decreases the smaller the numbers get.  Try 3/2
for example ;-)

You should also consider that POV-Ray uses floats/doubles for nearly every
internal calculation, so the use of integers does not make sense for a lot
of things.  Only as counters and array indices they would be really useful,
but within the common ranges (those that don't blow the memory limits) of
for example +-1000000 the precision limit of doubles should be far (enough)
behind the comma even after several calculations with it.


     Thorsten

Post a reply to this message

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

> Thorsten Froehlich <tho### [at] trfde> wrote:
> : POV-Ray does not do massive string
> : searches, there are much better ways of finding them and they don't require
> : a binary file format or something.
>
>   Yes, parsing doesn't need repetitive string search (even if we have
> several keywords with identical beginnings), but what about interpreting
> the string?

I agree, POV-Ray should really use a DFA for this...


     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 <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