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

Chris Huff <chr### [at] maccom> wrote:
: 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. :-)

  Well, since isosurfaces are faster than many builtin primitives, like
polys or superellipsoids, I'd say that isosurfaces are incredibly fast.
  Polys and superellipsoids don't have to parse anything the user has written.
Only the numeric values are stored at parse time into variables (which don't
differ in any way of any other variable used by the machine code) and at
render time a fixed-type code is run to test intersections etc.
  Isosurface functions, however, have to be somehow interpreted each time you
want a value. The function is not coded in a native machine code, but it's
a byte code (or whatever) that has to be interpreted (much like java byte
code, for example).
  Moreover, you need to get several values from the function for each
intersection test, which makes its speed even more incredible.

-- 
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 <39AD60A7.E24533EC@faricy.net> , David Fontaine 
<dav### [at] faricynet>  wrote:

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

No, I didn't say it uses byte-code.  I said that it does what you were
suggesting, and that was "binary code" :-)

I interpreted "binary code" as using "hash value"...

A hash table is basically a binary shortcut for a string, so all you need to
do is generate the hash value and then compare two integers.  Of course
there will be duplicate hash values, so you then compare just a few strings
(or use another method - there are textbooks full of it).


    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

Chris Huff wrote:

> What are "control aids"?

do while for next if then elseif endif
switch case call goto gosub break
teehee           ^^^^
                 EVIL


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

Post a reply to this message

Thorsten Froehlich wrote:

> No, I didn't say it uses byte-code.  I said that it does what you were
> suggesting, and that was "binary code" :-)
>
> I interpreted "binary code" as using "hash value"...
>
> A hash table is basically a binary shortcut for a string, so all you need to
> do is generate the hash value and then compare two integers.  Of course
> there will be duplicate hash values, so you then compare just a few strings
> (or use another method - there are textbooks full of it).

Oh, well then I demand byte-code! :-)

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

Post a reply to this message

In article <39ADE0D3.BE78C21D@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> Chris Huff wrote:
> 
> > What are "control aids"?
> 
> do while for next if then elseif endif
> switch case call goto gosub break
> teehee           ^^^^
>                  EVIL

Oh...I always called those "flow control keywords". I've never heard 
them called "control aids"...
And I agree about goto, I have never used it. In fact, I barely ever use 
"break" outside of a switch statement...I think the first time was just 
yesterday, in the #set patch...and even there I considered using a while 
loop instead.
I don't recognize some of those keywords(elseif, endif, call, teehee), 
are they from a BASIC variant?
Hmm, the POV-Script list would be:
#while, #if, #else, #switch, #case, #range, #macro, #end, #break...did I 
miss any?
Oh, #include, I guess...and MegaPOV functions.

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

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

>   Well, since isosurfaces are faster than many builtin primitives, like
> polys or superellipsoids, I'd say that isosurfaces are incredibly fast.
...snip...
>   Moreover, you need to get several values from the function for each
> intersection test, which makes its speed even more incredible.

Ok, ok...isosurfaces are incredibly fast, especially when you consider 
what they have to do. But I think most of this advantage is in the 
solving method, not in the functions themselves. I have always wondered 
how much faster it would be if the same functions were written in C and 
called directly.

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

Chris Huff wrote:

> #while, #if, #else, #switch, #case, #range, #macro, #end, #break...did I
> miss any?
> Oh, #include,

#local

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <39AE849E.C1C91C82@pacbell.net>, lin### [at] povrayorg 
wrote:

> Chris Huff wrote:
> 
> > #while, #if, #else, #switch, #case, #range, #macro, #end, #break...did I
> > miss any?
> > Oh, #include,
> 
> #local

I wouldn't call #local and #declare flow control keywords/control aids, 
sorry. :-)
Though they certainly are necessary for any useful amount of work to be 
done.

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