Ok, folks -- I've just submitted an update to the macro caching
mechanism. The 64k (Windows) / 0.5k (Linux) buffer is now bypassed,
further increasing the parsing speed of Thomas' demo scene on my machine
from 60 to 50 seconds.

Please test intensively.

Post a reply to this message

On 20-7-2016 1:16, clipka wrote:
> Ok, folks -- I've just submitted an update to the macro caching
> mechanism. The 64k (Windows) / 0.5k (Linux) buffer is now bypassed,
> further increasing the parsing speed of Thomas' demo scene on my machine
> from 60 to 50 seconds.
>
> Please test intensively.
>

Looking good. I tested with/without little counter:

av155; macros in; counter yes: 57 sec (57.283)
av155; macros in; counter no: 53 sec (53.836)
av155; macros out; counter yes: 1 min 10 sec (70.232)
av155; macros out; counter no: 1 min 6 sec (66.862)

v3.7.0; macros in; counter yes: 56 sec (56.145)
v3.7.0; macros in; counter no: 53 sec (53.118)

I leave the in-between comments testing to Jaime ;-)

-- 
Thomas

Post a reply to this message

El 20/07/16 a las 01:16, clipka escribió:
> Ok, folks -- I've just submitted an update to the macro caching
> mechanism. The 64k (Windows) / 0.5k (Linux) buffer is now bypassed,
> further increasing the parsing speed of Thomas' demo scene on my
> machine from 60 to 50 seconds.
>
> Please test intensively.
>

   Hmmm... here the new version is a bit slower parsing: from 1m20s to
1m23s, either with macros defined inside or outside, and even with
in-between comments no matter the size (I tried several MB of comments
and it still parsed in 1m23s).


3.7.1-alpha.8704732.unofficial (g++ 5.4.0 @ x86_64-pc-linux-gnu)

--
jaime

Post a reply to this message

Am 20.07.2016 um 12:40 schrieb Jaime Vives Piqueres:
> El 20/07/16 a las 01:16, clipka escribió:
>> Ok, folks -- I've just submitted an update to the macro caching
>> mechanism. The 64k (Windows) / 0.5k (Linux) buffer is now bypassed,
>> further increasing the parsing speed of Thomas' demo scene on my
>> machine from 60 to 50 seconds.
>>
>> Please test intensively.
>>
> 
>   Hmmm... here the new version is a bit slower parsing: from 1m20s to
> 1m23s, either with macros defined inside or outside, and even with
> in-between comments no matter the size (I tried several MB of comments
> and it still parsed in 1m23s).

Hmm... maybe that's due to the top layer in the file access
(ITextStream, the one where the buffer used to reside in) now using
polymorphism. Still, it puzzles me a bit why the copying-around of the
macro content does so little to counteract that penalty. Might even have
to do with CPU properties.

Since this 3.6% performance loss on your machine buys a 12% performance
bonus on Thomas' machine, I guess I'm willing to pay that price.

Post a reply to this message

On 7/20/2016 12:43 PM, clipka wrote:
> Since this 3.6% performance loss on your machine buys a 12% performance
> bonus on Thomas' machine, I guess I'm willing to pay that price.

You put that in, to be commented upon. Didn't you? ;)

-- 

Regards
     Stephen

Post a reply to this message

On 07/19/2016 07:16 PM, clipka wrote:
> Ok, folks -- I've just submitted an update to the macro caching
> mechanism. The 64k (Windows) / 0.5k (Linux) buffer is now bypassed,
> further increasing the parsing speed of Thomas' demo scene on my machine
> from 60 to 50 seconds.
>
> Please test intensively.
>

Ubuntu 14.04 (i3-4130). Latest always came in faster for me using a 
scene of my own. Inserted an error statement to stop after parsing so 
these times are for the parsing phase. Command suffix the commit.

-------------------------- Disk ----------------------------
povray371_2965368:
Command exited with non-zero status 1
158.46user 3.64system 2:42.42elapsed 99%CPU (0avgtext+0avgdata 
151536maxresident)k
0inputs+6608outputs (0major+28992minor)pagefaults 0swap

povray371_8e965a9:                       -8.60% (elapsed)
Command exited with non-zero status 1
148.02user 0.08system 2:28.45elapsed 99%CPU (0avgtext+0avgdata 
151548maxresident)k
0inputs+6608outputs (0major+28482minor)pagefaults 0swaps

-------------------------- Memory disk ---------------------
povray371_2965368:
Command exited with non-zero status 1
153.68user 3.26system 2:37.26elapsed 99%CPU (0avgtext+0avgdata 
151676maxresident)k
0inputs+0outputs (0major+28482minor)pagefaults 0swaps

povray371_8e965a9:
Command exited with non-zero status 1    -3.85% (elapsed)
150.72user 0.14system 2:31.20elapsed 99%CPU (0avgtext+0avgdata 
151460maxresident)k
0inputs+0outputs (0major+28477minor)pagefaults 0swap

-------------------------- Memory disk (one file) ----------
povray371_2965368:
Command exited with non-zero status 1
151.63user 1.63system 2:33.59elapsed 99%CPU (0avgtext+0avgdata 
151628maxresident)k
0inputs+0outputs (0major+28479minor)pagefaults 0swaps

povray371_8e965a9:
Command exited with non-zero status 1    -3.37% (elapsed)
148.01user 0.07system 2:28.41elapsed 99%CPU (0avgtext+0avgdata 
151556maxresident)k
0inputs+0outputs (0major+28988minor)pagefaults 0swaps

Post a reply to this message

Am 20.07.2016 um 14:15 schrieb Stephen:
> On 7/20/2016 12:43 PM, clipka wrote:
>> Since this 3.6% performance loss on your machine buys a 12% performance
>> bonus on Thomas' machine, I guess I'm willing to pay that price.
> 
> You put that in, to be commented upon. Didn't you? ;)

Absolutely. Substantial ones preferred, thanks :P

Post a reply to this message

Am 20.07.2016 um 16:59 schrieb William F Pokorny:

> povray371_2965368:

Just wondering -- which one is that? I failed to find any commit with
that id in the repository.

Post a reply to this message

On 07/20/2016 11:23 AM, clipka wrote:
> Am 20.07.2016 um 16:59 schrieb William F Pokorny:
>
>> povray371_2965368:
>
> Just wondering -- which one is that? I failed to find any commit with
> that id in the repository.
>

POV-Ray 3.7.1-alpha.8697045.unofficial

No idea what happened...

git log --oneline currently shows me:

8e965a9 Improved cached macro performance.
fa3a1dc Fixed a code flaw in macro caching.
39a6c9f [ci skip] Minor changes to comments and dev documentation.
edfae26 Fixed a bug in cleanup of fog with turbulence.
3b5b4eb added missing file pavement_s3_t6_p12.txt / issue #37 (#77)
051b674 Implemented macro caching.
2d0a42c fix filenames / issue #36 (#76)

And looking back through my bash command history 2d0a42c is what I 
checked out ahead of the compile to the pre-cached macro version.

"git checkout 2d0a42c"

Bill P.

Post a reply to this message

El 20/07/16 a las 13:43, clipka escribió:
> Hmm... maybe that's due to the top layer in the file access
> (ITextStream, the one where the buffer used to reside in) now using
> polymorphism. Still, it puzzles me a bit why the copying-around of
> the macro content does so little to counteract that penalty. Might
> even have to do with CPU properties.

   AMD FX-6300 here...

> Since this 3.6% performance loss on your machine buys a 12%
> performance bonus on Thomas' machine, I guess I'm willing to pay that
> price.
>

   Well, it's still a little loss compared to the huge gain respect to
the old macros mechanism. Good job!

--
jaime

Post a reply to this message