 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, that was educational and clarifies even more of the morass of issues
you're dealing with to unravel the POV-Ray source code.
Let me throw this out there:
POV-Ray has some things like the parametric that can be "precomputed".
Perhaps there's a way to create some new things that POV-Ray does that can be
compiled cleanly, and give rise to a significant increase in speed for those who
desire/need it, and those who want to write scenes in "legacy code" aren't
affected.
#precompile
code
code
code
#end
Another idea is to have some other engine running alongside the main POV-Ray
that tasks can get handed off to. And surely no one wants to do that.
But just to think out loud, because sometimes bad ideas spark good ideas:
Do something along the lines of define a flag, start a block of precompile code,
and hand-off the contents of this block of code to the compiler. While the flag
doesn't exists, wait. When the flag exists (code compiled, optionally saved)
then run the compiled code and continue parsing.
If the compiled code gets saved, invoking this method would check to see if the
code's already been compiled and saved, and skip recompiling.
And all of this is likely a delusional pipe dream, but as usual, thanks for
listening. :) ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/23/2018 03:15 PM, Bald Eagle wrote:
> Well, that was educational and clarifies even more of the morass of issues
> you're dealing with to unravel the POV-Ray source code.
>
> Let me throw this out there:
>
> POV-Ray has some things like the parametric that can be "precomputed".
>
>
For reference a related github issue mentioned in a prior thread or two:
https://github.com/POV-Ray/povray/issues/313
"Proposal for easy generation of SDL code from within SDL."
---
I see a few ways to improve performance after which not much is easy.
Someone posted a program to 'shorten/strip?' comments after an earlier
parser performance discussion. Where SDL is easy to parse(1) suppose not
too hard to extend such a program to create unique IDs and substantially
compress the SDL text which you'd then include in your scene. Sort of an
auto SDL for short-code contest generator(2).
Bill P.
(1) Unfortunately not true once higher level program constructs exist in
the SDL...
(2) Except it would create flat/unrolled output from loops.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> wrote:
>
> Someone posted a program to 'shorten/strip?' comments after an earlier
> parser performance discussion....
http://news.povray.org/povray.binaries.misc/thread/%3C59de3b93%241%40news.povray.org%3E/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 21.04.2018 um 21:30 schrieb Alain:
>
> > If you use any macro in a loop, it will get expanded and parsed each
> > time it's used.
> >
> > If that macro is in an include file, that file will get opened and read
> > each time the macro is invoked.
>
> As of v3.8.0-alpha, this is no longer true: Macros up to a certain size
> (currently hard-coded to, IIRC, 64 kiB) are now cached in memory.
Thanks for the clairification about macro caching. I know it's been mentioned
before, but I wasn't clear about the details-- the exact memory limit. I
assume(?) that the caching occurs for *any* entity placed in the macro... even a
pigment{image_map...} for example (just so it's under the 64K limit).
>
> > EVERYTHING before the macro definition
> > need to be read and skipped. Example : If you use any colour
> > manipulation macro from colors.inc, they are located at the end, forcing
> > the parser to read the whole include every time they are used.
>
> That's not true even for v3.7 and earlier: The parser does remember the
> offset of the macro within the include file, and jumps directly to that
> offset when executing the macro.
I didn't know that; a VERY useful bit of info.
And Clipka said...
> Every reasonably fast contemporary programming language makes use of at
> least /some/ degree of compilation. For instance, functions, procedures
> and/or classes might use proper compilation, or at least "compiled" into
> an internal intermediate representation that is faster to interpret.
>
> POV-Ray's parser is a genuine interpreter. No compiling going on /at
> all/ (*)
>
> (* Except for user-defined functions. Those are compiled into bytecode
> for a proprietary virtual machine.)
William F Pokorny mentioned something about this in an earlier thread, but it
'slipped through my radar' at the time...
http://news.povray.org/povray.general/thread/%3Cweb.59d95c8e31ae2f125cafe28e0@news.povray.org%3E//povray.general/thread
/%3C59d9670e@news.povray.org%3E/
"In using functions we use our VM which already pre-calculates everything
it can. In other words in using functions we take the parsing /
re-parsing / re-calculating which happens with macros and turn it into
VM 'compiled' code which can be called."
So POV-Ray has its own little virtual machine for such compiling tasks.
Fascinating.
Using my image_map example again (because images are generally
parse-time-intensive), does this VM/compile idiom still work when turning an
image into a function? Not that it's a practical scheme in most cases, but just
as a clarification of the idea. Like...
pigment {
image_map {
function 500,500 {
pigment {image_map{png "MY_IMAGE.png} }
}
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.04.2018 um 18:46 schrieb Kenneth:
>>> If that macro is in an include file, that file will get opened and read
>>> each time the macro is invoked.
>>
>> As of v3.8.0-alpha, this is no longer true: Macros up to a certain size
>> (currently hard-coded to, IIRC, 64 kiB) are now cached in memory.
>
> Thanks for the clairification about macro caching. I know it's been mentioned
> before, but I wasn't clear about the details-- the exact memory limit. I
> assume(?) that the caching occurs for *any* entity placed in the macro... even a
> pigment{image_map...} for example (just so it's under the 64K limit).
Just to be clear: It's not the /result/ of the macro that is cached -
just the SDL code snippet.
> So POV-Ray has its own little virtual machine for such compiling tasks.
> Fascinating.
>
> Using my image_map example again (because images are generally
> parse-time-intensive), does this VM/compile idiom still work when turning an
> image into a function? Not that it's a practical scheme in most cases, but just
> as a clarification of the idea. Like...
>
> pigment {
> image_map {
> function 500,500 {
> pigment {image_map{png "MY_IMAGE.png} }
> }
> }
> }
When you turn an image into a function (aka "image function"), the VM
actually isn't involved; rather, the image is used as a "data table" for
a hard-coded function, which just interpolates the image data and is
even faster.
At a first glance I would strongly discourage the above construct:
You're not just constructing an image function, but rather turing the
resulting function back into an image again (aka "function image"), so
what you really have is an "image function image". As there's nothing to
be "executed" about an image (it's just a (colour) data container, after
all), there's also nothing to be "compiled", and hence no performance to
be gained.
However, at second glance, the construct is still interesting, albeit
for another reason: Nobody stops you from specifying a resolution in the
function image that differs from the image function; so you can use it
to re-sample the image.
Since the function can be discarded right after the function image has
been constructed, and the underlying original image can be discarded
along with it, this may reduce the memory footprint of a scene if your
image has a very high resolution but you only need a very low resolution.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> > Thanks for the clairification about macro caching. I know it's been
> > mentioned before, but I wasn't clear about the details-- the exact
> > memory limit. I
> > assume(?) that the caching occurs for *any* entity placed in the
> > macro... even a pigment{image_map...} for example (just so it's under
> > the 64K limit).
>
> Just to be clear: It's not the /result/ of the macro that is cached -
> just the SDL code snippet.
Oh! I think I see now. So with the following silly example...
#macro FOO()
30.716 + 57.362 - 11.602
#end
....... it's not the total result or even the math operations that are preformed
or
cached, it's just the bytes representing 3,0,7,1,6, etc (and whatever the byte
designations of "=" and "-" and the decimal points are). In other words, the
macro is just a 'container' to cache those data bytes...with a 64K maximum
storage limit for the bytes. Am I correct?
And I'm guessing that anything in the macro over 64K-- any 'remainder bytes'--
are not actually cached, although they are still a useful part of the macro and
are still used later somehow, when the macro is invoked. (?) Or does a macro
have a HARD 64K limit, that can't be exceeded? (That's a lot of bytes, of
course!)
---
About the image_map example...
> >
> > pigment {
> > image_map {
> > function 500,500 {
> > pigment {image_map{png "MY_IMAGE.png} }
> > }
> > }
> > }
>
>
> ...
> However, at second glance, the construct is still interesting, albeit
> for another reason: Nobody stops you from specifying a resolution in the
> function image that differs from the image function; so you can use it
> to re-sample the image.
>
> Since the function can be discarded right after the function image has
> been constructed, and the underlying original image can be discarded
> along with it, this may reduce the memory footprint of a scene if your
> image has a very high resolution but you only need a very low resolution.
Ah, OK.
Then a more conceptually useful 'cached function' memory-saving example would
be...
pigment {
average
pigment_map{
[1 bozo]
[1
image_map {
function 27,27 {
pigment {image_map{png "MY_IMAGE.png"}}
// The image itself is, say, 3000 X 3000 pixels
}
}
]
}
}
So the image_map function here would have a very-much-reduced memory footprint,
compared to the original gigantic image.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Ah, OK.
> Then a more conceptually useful 'cached function' memory-saving example would
> be...
My apologies; I'm confusing the terms. Not 'cached function', but 'VM/compiled
function'.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.04.2018 um 23:25 schrieb Kenneth:
> And I'm guessing that anything in the macro over 64K-- any 'remainder bytes'--
> are not actually cached, although they are still a useful part of the macro and
> are still used later somehow, when the macro is invoked. (?) Or does a macro
> have a HARD 64K limit, that can't be exceeded? (That's a lot of bytes, of
> course!)
A macro is either cached in its entirety (in which case it is parsed
from memory when it is invoked), or it is not cached at all (in which
case it is parsed from file when it is invoked). The former is done if
the macro size is below the threshold of 64 kiB, while the latter is
done if the macros size is above the threshold.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/22/2018 6:16 AM, clipka wrote:
> So in order to really speed up parsing, you'd need to re-invent
> POV-Ray's language.
>
What is the ETA on that? Can you tell us when you're nearly done?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.05.2018 um 00:19 schrieb Mike Horvath:
> On 4/22/2018 6:16 AM, clipka wrote:
>> So in order to really speed up parsing, you'd need to re-invent
>> POV-Ray's language.
>>
>
> What is the ETA on that? Can you tell us when you're nearly done?
:-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
