Hi Folks,

Until now, each and every invocation of a macro from a file other than
the one it was declared in, inevitably caused the latter file to be
opened again for the macro code to be re-read -- a process that
seriously bogged down the parser. It therefore used to be recommended to
copy frequently used macros into the main scene file (or whatever file
they were called from).

I have now implemented a mechanism that keeps a copy of each and every
macro's code in memory (except for macros more than 65536 characters in
size), greatly increasing the execution speed of macros in such
scenarios, to the point that said recommendation should be obsolete from
now on.


While I'm satisfied with the cross-file macro execution speed, I would
like additional feedback from you guys about execution speed of macros
declared in the same file. I see a slight increase there, too -- can you
confirm?

Also, I'd like you folks to go wild trying to find scenarios where the
caching of macros has any drawbacks, and of course find that one bug I
have hidden there.


As usual, both Windows binaries and source code packages can be found at
https://github.com/POV-Ray/povray/releases. The source code can also be
found as the current master branch at https://github.com/POV-Ray/povray.

(The source code in question carries the version number
v3.7.1-alpha.8697421, the Windows binaries carry the build suffix +av151.)

Post a reply to this message

On 7/14/2016 7:15 PM, clipka wrote:
> I have now implemented a mechanism

when i went to document this ... noticed syntax diagram /might/ be 
missing the term optional in a couple of places. agreed?

http://wiki.povray.org/content/Reference:User_Defined_Macros

Post a reply to this message

On 15-7-2016 1:15, clipka wrote:
> While I'm satisfied with the cross-file macro execution speed, I would
> like additional feedback from you guys about execution speed of macros
> declared in the same file. I see a slight increase there, too -- can you
> confirm?

Slight? You are kidding! :-)
The speed increase is huge in fact compared to version 3.7.
With the attached quick-and-dirty scene I get the following results 
using 1 million iterations:

+av151; macro inside scene parsing time: 1 minute 5 seconds (65.988 seconds)
+av151; macro outside scene parsing time: 1 minute 6 seconds (66.971 
seconds)

V 3.7; macro inside scene parsing time: stopped parsing manually after 
more than 10 minutes!

Note: for using the test scene with outside macro, just copy the macro 
to another place and uncomment the macro's include.

>
> Also, I'd like you folks to go wild trying to find scenarios where the
> caching of macros has any drawbacks, and of course find that one bug I
> have hidden there.
>

Not found any yet.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'clipka_cached macros_test.pov.txt' (2 KB)

Am 17.07.2016 um 21:25 schrieb Jim Holsenback:
> On 7/14/2016 7:15 PM, clipka wrote:
>> I have now implemented a mechanism
> 
> when i went to document this ... noticed syntax diagram /might/ be
> missing the term optional in a couple of places. agreed?
> 
> http://wiki.povray.org/content/Reference:User_Defined_Macros

I guess that's a matter of philosophy: Do you want the documentation to
generally reflect the newest version (even if that's still under
development), with side notes mentioning what features aren't available
in earlier versions, or do you want the documentation to generally
reflect a well-established version, with side notes mentioning the
features added in newer version?

So far I have been following the latter approach for documenting the new
3.7.1 features, mostly because 3.7.1 hasn't even reached beta phase yet;
theoretically, any modifications since 3.7.0 are still subject to
change, and 3.7.0 is still the latest version for which we provide a
Windows installer.

But if you are significantly more comfortable with the former approach,
I can live with that as well.

Post a reply to this message

Am 18.07.2016 um 10:05 schrieb Thomas de Groot:
> On 15-7-2016 1:15, clipka wrote:
>> While I'm satisfied with the cross-file macro execution speed, I would
>> like additional feedback from you guys about execution speed of macros
>> declared in the same file. I see a slight increase there, too -- can you
>> confirm?
> 
> Slight? You are kidding! :-)

Actually no, I'm not.

> The speed increase is huge in fact compared to version 3.7.
> With the attached quick-and-dirty scene I get the following results
> using 1 million iterations:
> 
> +av151; macro inside scene parsing time: 1 minute 5 seconds (65.988
> seconds)
> +av151; macro outside scene parsing time: 1 minute 6 seconds (66.971
> seconds)
> 
> V 3.7; macro inside scene parsing time: stopped parsing manually after
> more than 10 minutes!

I was quite puzzled about your results, until I saw your test scene, and
found that the in-file macro you presumably tested actually calls
various other macros, which are declared in rand.inc. So what you are
actually measuring is the speed of macro invocations across file boundaries.

With the macros RRand, VRand_In_Box and VRand_In_Obj moved to the scene
itself and "rand.inc" no longer included, I actually see a noteworthy
_slowdown_ in parsing time on my machine: about 60 seconds, as opposed
to 45 seconds with 3.7.0.


The picture changes a bit when the scene file is large -- or, more
precisely, when the macro is declared far away from where it is invoked:
With approximately 64k worth of comments inserted between the macro
declaration and its invocation, the parse time increases to about 95
seconds with 3.7.0, while remaining at about 60 seconds with the new
version.

This is to be expected, since the parser uses buffered file access, with
a 64k buffer on Windows machines, so in 3.7.0 a macro invoked from near
its declaration may still be included in the buffer, in which case
parsing can proceed without actual file access, while a farther-away
macro will trigger a 64k read to fill the buffer with different content.
It's still a good deal faster than cross-file invocation, since there is
no need to re-open another file. As for why macro caching is slower than
3.7.0's "near invocation", that's because it also adds a bit of overhead
every time a macro is invoked from the cache.

I'd be interested to hear from the Linux jockeys how they are faring
with in-file macro invocation. I'd expect a similar picture as with
Windows, but the "sweet spot" may be around 0.5k worth of code between
macro declaration and invocation, since that's the size of the buffer on
Unix. Then again, Unix may provide additional buffers for file access --
there must be a reason why POV-Ray's own buffers where chosen that small
on the Linux platform.


One thing seriously worrying me, however, is that the version using
cached macros exhibits seriously worse parsing performance on the 2nd
and any subsequent runs, taking about 100 seconds instead of 60 seconds.
Not sure yet what's going on there.

Post a reply to this message

On 7/18/2016 4:17 AM, clipka wrote:
> Am 17.07.2016 um 21:25 schrieb Jim Holsenback:
>> On 7/14/2016 7:15 PM, clipka wrote:
>>> I have now implemented a mechanism
>>
>> when i went to document this ... noticed syntax diagram /might/ be
>> missing the term optional in a couple of places. agreed?
>>
>> http://wiki.povray.org/content/Reference:User_Defined_Macros
>
> I guess that's a matter of philosophy: Do you want the documentation to
> generally reflect the newest version (even if that's still under
> development), with side notes mentioning what features aren't available
> in earlier versions, or do you want the documentation to generally
> reflect a well-established version, with side notes mentioning the
> features added in newer version?
>
> So far I have been following the latter approach for documenting the new
> 3.7.1 features, mostly because 3.7.1 hasn't even reached beta phase yet;
> theoretically, any modifications since 3.7.0 are still subject to
> change, and 3.7.0 is still the latest version for which we provide a
> Windows installer.
>
> But if you are significantly more comfortable with the former approach,
> I can live with that as well.
>

well yikes ... was hoping for a less vague response. i was just trying 
to be proactive. back when the new / change template request was 
suggested i roughed something out quickly but didn't get a chance to 
implement, then noticed it's usage in the documentation. couple of day 
ago had some time to put towards this and finished up the templates, 
found ALL the old usage and changed to new, even added code to 
wikidocgen to translate template to it's html equivalent. now i'm unsure 
what to do next because i was under the impression that we were running 
as fast as we can towards 3.7.1 release ... well like i said now i'm not 
sure anymore

Post a reply to this message

On 7/18/2016 6:08 AM, Jim Holsenback wrote:
> On 7/18/2016 4:17 AM, clipka wrote:
>> Am 17.07.2016 um 21:25 schrieb Jim Holsenback:
>>> On 7/14/2016 7:15 PM, clipka wrote:
>>>> I have now implemented a mechanism
>>>
>>> when i went to document this ... noticed syntax diagram /might/ be
>>> missing the term optional in a couple of places. agreed?
>>>
>>> http://wiki.povray.org/content/Reference:User_Defined_Macros
>>
>> I guess that's a matter of philosophy: Do you want the documentation to
>> generally reflect the newest version (even if that's still under
>> development), with side notes mentioning what features aren't available
>> in earlier versions, or do you want the documentation to generally
>> reflect a well-established version, with side notes mentioning the
>> features added in newer version?
>>
>> So far I have been following the latter approach for documenting the new
>> 3.7.1 features, mostly because 3.7.1 hasn't even reached beta phase yet;
>> theoretically, any modifications since 3.7.0 are still subject to
>> change, and 3.7.0 is still the latest version for which we provide a
>> Windows installer.
>>
>> But if you are significantly more comfortable with the former approach,
>> I can live with that as well.
>>
>
> well yikes ... was hoping for a less vague response. i was just trying
> to be proactive. back when the new / change template request was
> suggested i roughed something out quickly but didn't get a chance to
> implement, then noticed it's usage in the documentation. couple of day
> ago had some time to put towards this and finished up the templates,
> found ALL the old usage and changed to new, even added code to
> wikidocgen to translate template to it's html equivalent. now i'm unsure
> what to do next because i was under the impression that we were running
> as fast as we can towards 3.7.1 release ... well like i said now i'm not
> sure anymore

just a follow up ... to address the concern that i /might/ be getting 
ahead of the game here.

Welcome to the POV-Ray version 3.7.x documentation repository ... if 
you're looking for the most up to date documentation, you've found it! 
This content is used to generate the documentation included with the 
distribution, so occasionally it can get ahead of the current release.

this preamble /is/ there for /everyone/ to see at:
http://wiki.povray.org/content/Documentation:Contents

Post a reply to this message

El 18/07/16 a las 11:48, clipka escribió:
> I'd be interested to hear from the Linux jockeys how they are faring
> with in-file macro invocation. I'd expect a similar picture as with
> Windows, but the "sweet spot" may be around 0.5k worth of code
> between macro declaration and invocation, since that's the size of
> the buffer on Unix. Then again, Unix may provide additional buffers
> for file access -- there must be a reason why POV-Ray's own buffers
> where chosen that small on the Linux platform.

   Using Thomas example on my recently installed Ubuntu 16.04:

   current alpha, inside : 1m20s
   current alpha, outside: 1m20s
   previous alpha, inside: 8m11s
   previous alpha, outside: 12m46

   Can I just say "wow!"?


> One thing seriously worrying me, however, is that the version using
> cached macros exhibits seriously worse parsing performance on the
> 2nd and any subsequent runs, taking about 100 seconds instead of 60
> seconds. Not sure yet what's going on there.
>

   Cannot see that here... subsequent runs still take 1m20s.


--
jaime

Post a reply to this message

On 18/07/2016 20:30, Jim Holsenback wrote:
> http://wiki.povray.org/content/Reference:User_Defined_Macros

[snip]

> this preamble /is/ there for /everyone/ to see at:
> http://wiki.povray.org/content/Documentation:Contents

I like how you've done these. Seems pretty clear to me.

-- Chris

Post a reply to this message

On 15/07/2016 09:15, clipka wrote:
> I have now implemented a mechanism that keeps a copy of each and every
> macro's code in memory (except for macros more than 65536 characters in
> size), greatly increasing the execution speed of macros in such
> scenarios, to the point that said recommendation should be obsolete from
> now on.

Nice improvement there Christoph :)

-- Chris

Post a reply to this message