 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
New version:
https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.tokenizer.9673626
Cached macros back in action.
Also includes an optimization that may reclaim some lost performance in
loops.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/05/2018 18:51, clipka wrote:
> Am 23.05.2018 um 18:53 schrieb Stephen:
>
>>>> Which reminds me. I use that facility to overwrite the version number
>>>> B3D exports by declaring it after the first one. Will that workaround
>>>> still work?
>>>
>>> Uh... please elaborate. How would the resulting scene file look like?
>>>
>>
>> #version 3.6;
>>
>>
>> //------- Scene Raw Script Begin -------
>> #version 3.7 ;
>> //------- Scene Raw Script End ---------
>>
>> [The rest of the scene...]
>
> If `#version 3.6;` is the very first statement in the scene, then that's
> fine.(*)
>
> If there's anything before that (other than whitespace and/or comments),
> it is still fine unless you replace `#version 3.7;` with `#version 3.8;`.
>
>
> (* In the sense that you won't get a parse error. It may have side
> effects, e.g. the new v3.8 default values currently don't apply unless
> you specify `#version 3.8` at the very first line. I intend to change
> that though.)
>
Thanks for clearing that up for me.
I seem to remember a warning that the version number must be the first
statement and thought it might mean the final version number.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/05/2018 18:55, clipka wrote:
> Am 23.05.2018 um 19:35 schrieb Stephen:
>> On 23/05/2018 16:26, clipka wrote:
>>> Not sure I understand what you mean. Would you change B3D, or would you
>>> change POV-Ray?
>>
>> Sorry I missed this.
>> B3D comes compiled with no source code. So for that to work it would
>> need be a change in PovRay.
>
> Then such a switch would add more trouble than it would solve.
>
I must be over thinking. :)
> I'll try to re-implement v3.8.0-alpha behaviour, which is to provide
> special treatment for filename literals if `#version 3.7` or earlier is
> specified, while treating them like regular string literals if `#version
> 3.8` or later is specified.
>
Great! That means that I can use 3.7 for testing and manually change the
file when I want to use 3.8.
> In either case, a warning shall be printed if single backslashes are
> encountered in filename literals.
>
>
> ("filename literal" being any string literal in a place where the parser
> specifically expects a file name, such as in `#include`.)
>
Another thought. (Don't judge me. ;) )
What about the library paths defined in povray.ini?
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.05.2018 um 22:16 schrieb Stephen:
> Another thought. (Don't judge me. ;) )
> What about the library paths defined in povray.ini?
Totally different story: Those don't go through the scanner/tokenizer,
so they are entirely unaffected by any change made to those parser
stages with regards to escape sequences.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> New version:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.tokenizer.9673626
>
Using my 'city buildings' scene again...
v3.7.0-- 35.54 seconds
v3.8 tokenizer-- 34.2 seconds (average of five runs)
(both versions running 'hot', as described earlier)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.05.2018 um 21:55 schrieb Stephen:
>> Please go ahead. I'm curious which feature of the file makes
>> v3.8.0-alpha like it better than v3.7.0.
>>
>
> Done.
> Posted in povray.binaries.scene-files as "Flowers for clipka"
>
I think I nailed it: On my system I get just shy of 300 seconds parsing
time on v3.7.0, a bit over 200 seconds on v3.8.0-alpha, and a bit shy of
200 seconds on v3.8.0-x.tokenizer.9673626 now.
Didn't bother to test with v3.8.0-x.tokenizer.9999, as I would have had
to "rewind" to old source code, but I'm satisfied with having a
reasonably plausible theory as to why it may have been slower.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/05/2018 22:07, clipka wrote:
> Am 23.05.2018 um 21:55 schrieb Stephen:
>
>>> Please go ahead. I'm curious which feature of the file makes
>>> v3.8.0-alpha like it better than v3.7.0.
>>>
>>
>> Done.
>> Posted in povray.binaries.scene-files as "Flowers for clipka"
>>
>
> I think I nailed it: On my system I get just shy of 300 seconds parsing
> time on v3.7.0, a bit over 200 seconds on v3.8.0-alpha, and a bit shy of
> 200 seconds on v3.8.0-x.tokenizer.9673626 now.
>
> Didn't bother to test with v3.8.0-x.tokenizer.9999, as I would have had
> to "rewind" to old source code, but I'm satisfied with having a
> reasonably plausible theory as to why it may have been slower.
>
Excellent!
I'll download the new version you posted, tomorrow and rerun the scene.
BTW The scene I uploaded had twice the density of grass blades (10000)
than the one I used originally to test them (5000).
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/05/2018 21:33, clipka wrote:
> Am 23.05.2018 um 22:16 schrieb Stephen:
>
>> Another thought. (Don't judge me. ;) )
>> What about the library paths defined in povray.ini?
>
> Totally different story: Those don't go through the scanner/tokenizer,
> so they are entirely unaffected by any change made to those parser
> stages with regards to escape sequences.
>
I imagine that would be the case. I was thinking more of consistency in
the windoze environment.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23-5-2018 14:20, clipka wrote:
> Am 23.05.2018 um 08:54 schrieb Thomas de Groot:
>
>> Where the longer parse time comes from is in the while loop distributing
>> the cubes. This loop resides in a separate inc file. and looks like this:
>>
[snip] ^^^^^^^^^^^^
> Unless you copied that to your file with the loop, that's a macro in a
> different file...
[snip]
>
> So yes, that pretty much explains the poor performance with the
> overhauled parser -- or, more to the point, the better performance with
> v3.8.0-alpha: The latter features cached macros, while the overhauled
> parser currently has those disabled.
>
> I would expect v3.7.0 to show roughly similar performance as the
> overhauled parser.
>
Of course. I forgot about this. With version 3.7.0 the performance is as
you say. Better performance starting with 3.7.1 according to my test.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> New version:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.tokenizer.9673626
>
.... and running Stephen's "Flowers For Clipka" scene. (I reduced his 'Density'
value from 10,000 down to 5,000, to be practical; and simply substituted his
image_map NAME in his height_field, instead of the library path.)
(Win7 64-bit, dual-core)
v3.7.0: 344 seconds parse (average of three runs)
v3.7.1 beta 9: 321 seconds (average of three runs)
v3.8 tokenizer: 225 seconds (average of three runs)
Nice! About a 35-percent decrease in parse time between 3.7.0 and 3.8-tokenizer,
very similar to Clipka's results.
Now I'm wondering why my 'city buildings' scene showed almost identical times
(3.7.0 vs. the 3.8 tokenizer), whereas Stephen's scene shows such a nice change.
The bulk of his scene is basically composed of four 'structures':
mesh2 meshes
trace(...)
#while loops (three)
height_field (one)
My own scene has only two of those four:
trace(...) -- but not nearly as many trace 'rays' as Stephen's
#while loops
From this, it makes me wonder if the bulk of the parse-time-speedup is in mesh2
meshes and/or trace. Or maybe it isn't that simple to separate out where the
improvements originate from(?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
