 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
When POV parses, does it directly parse the text file? If so, perhaps it
could load a compressed version into memory: replace keywords with
binary code, so no tedious text searching slows down a big parse; when
using loops and such, give #end statements an address refering to the
beginning, etc
For all I know, POV could already do this, but I know text parses much
slower than binary...
Perhaps it is asking too much...
Also, perhaps, different variable types. I don't know how many times
I've stored integers between 0 and 10 in an array of doubles...
--
David Fontaine <dav### [at] faricy net> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39AB5302.A39A21D7@faricy.net> , David Fontaine
<dav### [at] faricynet> wrote:
> When POV parses, does it directly parse the text file? If so, perhaps it
> could load a compressed version into memory: replace keywords with
> binary code, so no tedious text searching slows down a big parse; when
> using loops and such, give #end statements an address refering to the
> beginning, etc
POV-Ray already does what you are suggesting. in general, your suggestions
are necessary to get any working parser. 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.
> For all I know, POV could already do this, but I know text parses much
> slower than binary...
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 .
> Perhaps it is asking too much...
Why this remark?
> Also, perhaps, different variable types. I don't know how many times
> I've stored integers between 0 and 10 in an array of doubles...
What is wrong with this in POV-Ray, it will store the integers in the array
just fine? And they should also work just like any other numbers, after
all, "real" math doesn't really make a difference between 'doubles' and
'integers' either (for the functions POV-Ray offers).
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 <39AB5302.A39A21D7@faricy.net>, David Fontaine
<dav### [at] faricynet> wrote:
> Also, perhaps, different variable types. I don't know how many times
> I've stored integers between 0 and 10 in an array of doubles...
This is harder than you think...the POV language (and a good chunk of
the parser) would have to be redesigned to allow different types to be
specified manually and to allow different types of scalars to exist with
each other. And the only benefit would be lower memory usage, which is
really only relevant if you are storing huge arrays.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine <dav### [at] faricynet> wrote:
: When POV parses, does it directly parse the text file? If so, perhaps it
: could load a compressed version into memory
This is exactly what I have suggested some time ago. However, it's not
a simple task and I think the pov-team has more important things to do right
now :)
Byte-compiled code will be faster to parse only when you have big loops
(I mean "big" in number of iterations), macros and so on. Reading a regular
file without them will only slow the parsing (because it has to first parse
it, as it does now, byte-compile it and then interpret that byte code).
One advantage of byte-compiling is that you could save the binary data
to a file and then read it afterwards, saving the parsing and compilation
steps.
A disadvantage of writing byte-coded binary data is that it's
system-specific and something written in one system may not work in another
system (because of different endianess, different floating point number
formats and so on). This, however, shouldn't matter when you are only
working for yourself. You can always give the source code in plain ascii
to others.
By the way, as far as I know perl uses this tactique, that is, it first
parses the source script, byte-compiles it and then interprets this byte code.
This makes perl one of the fastest scripting languages in existence.
And since perl "compiles" in the background, hidden from the user, the user
doesn't have to worry about the compilation step (as happens with java).
But as I said, byte-compiling is beneficial only when there are loops and
other similar things in the code.
: I've stored integers between 0 and 10 in an array of doubles...
Usually a bad idea :)
(Well, for integer values between 0 and 10 it's ok, but don't use much
larger or smaller values... :) )
--
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:
: 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?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] maccom> wrote:
: And the only benefit would be lower memory usage, which is
: really only relevant if you are storing huge arrays.
It's not the only benefit. The other benefit would be precision. If you
use very large integers, floats may lose information.
This may be important when making mathematical operations. For example:
25^7/1953125 ( = 3125 )
may give a different result if we use integers or if we use floats.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Chris Huff <chr### [at] maccom> wrote:
> : And the only benefit would be lower memory usage, which is
> : really only relevant if you are storing huge arrays.
>
> It's not the only benefit. The other benefit would be precision. If you
> use very large integers, floats may lose information.
> This may be important when making mathematical operations. For example:
>
> 25^7/1953125 ( = 3125 )
>
> may give a different result if we use integers or if we use floats.
... and this is why one should never check equality between two floats!
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Byte-compiled code will be faster to parse only when you have big loops
> (I mean "big" in number of iterations), macros and so on. Reading a regular
> file without them will only slow the parsing (because it has to first parse
> it, as it does now, byte-compile it and then interpret that byte code).
I frequently find myself making the cimputer do the work, as in the research
outpost I just posted, my spiral forest, my crystal macro, my polyhedral
snowflakes.
> One advantage of byte-compiling is that you could save the binary data
> to a file and then read it afterwards, saving the parsing and compilation
> steps.
Yup!
> A disadvantage of writing byte-coded binary data is that it's
> system-specific and something written in one system may not work in another
> system (because of different endianess, different floating point number
> formats and so on). This, however, shouldn't matter when you are only
> working for yourself. You can always give the source code in plain ascii
> to others.
I was thinking, not compiling it to machine code, but compressing the text. Ie,
have a one or two byte code for each keyword. Searching through that would be
instantaneous compared to text searching. But word seems to have it POV already
does this type of thing to some extent.
> By the way, as far as I know perl uses this tactique, that is, it first
> parses the source script, byte-compiles it and then interprets this byte code.
> This makes perl one of the fastest scripting languages in existence.
> And since perl "compiles" in the background, hidden from the user, the user
> doesn't have to worry about the compilation step (as happens with java).
> But as I said, byte-compiling is beneficial only when there are loops and
> other similar things in the code.
I don't think it would add much to parse time for non-cpu-intensive-parsing
scenes, which usualy parse fast anyway. My big LEGO scenes parse in a matter of
minutes if not seconds, compared to half an hour or an hour for cpu-intensive
parses.
> : I've stored integers between 0 and 10 in an array of doubles...
>
> Usually a bad idea :)
Yes, but it's the only option in POV-script!
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> POV-Ray already does what you are suggesting. in general, your suggestions
> are necessary to get any working parser. 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.
Ooh, good.
> 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 .
Hmm, it takes 30 seconds to generate one layer of my dome, but each layer has
<300 pieces.
> > Perhaps it is asking too much...
>
> Why this remark?
Parsers are kinda tedious to write, no?
> > Also, perhaps, different variable types. I don't know how many times
> > I've stored integers between 0 and 10 in an array of doubles...
>
> What is wrong with this in POV-Ray, it will store the integers in the array
> just fine? And they should also work just like any other numbers, after
> all, "real" math doesn't really make a difference between 'doubles' and
> 'integers' either (for the functions POV-Ray offers).
Accuracy and calculation speed.
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29 Aug 2000 11:56:31 -0400, Warp wrote:
>Chris Huff <chr### [at] maccom> wrote:
>: And the only benefit would be lower memory usage, which is
>: really only relevant if you are storing huge arrays.
>
> It's not the only benefit. The other benefit would be precision. If you
>use very large integers, floats may lose information.
> This may be important when making mathematical operations. For example:
>
>25^7/1953125 ( = 3125 )
>
>may give a different result if we use integers or if we use floats.
Indeed. If you compute this with standard 32 bit integer arithmetic, the
result is 925. Probably not what you had in mind.
hp
--
_ | Peter J. Holzer | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR | sondern an der Einrichtung (aka Content).
| | | hjp### [at] wsracat | -- Ale### [at] univieacat
__/ | http://www.hjp.at/ | zum Thema Portale in at.linux
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
