 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
>
I ran the latest update to the tokenizer and here is a summary of the
parse times.
Ver 3.7.0
Parse Time: 0 hours 5 minutes 11 seconds (311.541 seconds)
Ver 3.8
Parse Time: 0 hours 3 minutes 50 seconds (230.366 seconds)
Ver x.tokenizer.9999
Parse Time: 0 hours 4 minutes 18 seconds (258.998 seconds)
Ver x.tokenizer.9673626
Parse Time: 0 hours 3 minutes 19 seconds (199.541 seconds)
Aside.
I run Throttle.exe to monitor my CPU and GPU temperatures. I noticed
that during the rendering of the scene. My CPU was being throttled back
when I was using Ver 3.8 and the tokenizers. I cleaned my fans and
filters last week so I don’t think it is an airflow problem.
Has anyone else noticed an increase in temperature with 3.8?
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/05/2018 09:04, Kenneth wrote:
> 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(?)
Before I cleaned up the scene for posting. There were two large mesh2
opjects that were declared but not called. Using a density of 5000,
there was no significient difference in parsing times.
I thought you might be onto something as the difference in Pov file size
is 2230 KB to 596 KB.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/24/2018 05:25 AM, Stephen wrote:
> On 23/05/2018 22:07, clipka wrote:
...
>
> Aside.
> I run Throttle.exe to monitor my CPU and GPU temperatures. I noticed
> that during the rendering of the scene. My CPU was being throttled back
> when I was using Ver 3.8 and the tokenizers. I cleaned my fans and
> filters last week so I don’t think it is an airflow problem.
> Has anyone else noticed an increase in temperature with 3.8?
>
>
I've noted nothing with CPU temperature, but I don't routinely watch it.
Do you see the throttling if you cut back on the number of cores you use?
What I am seeing in recent work is more volatility in performance
measures than has been typical. In the range of -+0.5% run to run of
late where I'd been getting <<0.1%. Makes it more difficult to determine
whether a local code change has much affected performance. Basically
need many more renders or renders with much longer run times.
Aside: Not talking about parser run times here. I expect those to be
more volatile due memory allocations as the scene is digested.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.05.2018 um 11:25 schrieb Stephen:
> Aside.
> I run Throttle.exe to monitor my CPU and GPU temperatures. I noticed
> that during the rendering of the scene. My CPU was being throttled back
> when I was using Ver 3.8 and the tokenizers. I cleaned my fans and
> filters last week so I don’t think it is an airflow problem.
> Has anyone else noticed an increase in temperature with 3.8?
Since I haven't touched the rendering itself, this must be a general
v3.8 thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.05.2018 um 10:04 schrieb Kenneth:
> 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(?)
There is no speedup to be expected in the trace() function, nor is there
any speedup to be expected in mesh2 /per se/.
Just as a hunch, does your loop invoke any macros?
If so, it's fundamentally different from Stephen's loop: The latest
v3.8.0-x.tokenizer version can execute his loop from memory without
performing any file access during the loop, but only because it does not
invoke any macros.
Each return from macro currently causes the file buffer to be re-loaded.
To make matters worse, this re-loads only the portion /after/ the
location the macro returns to, so when the end of the loop is reached,
the next iteration requires another buffer re-load to get back to the
start of the loop.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/05/2018 12:13, William F Pokorny wrote:
> On 05/24/2018 05:25 AM, Stephen wrote:
>> On 23/05/2018 22:07, clipka wrote:
> ...
>>
>> Aside.
>> I run Throttle.exe to monitor my CPU and GPU temperatures. I noticed
>> that during the rendering of the scene. My CPU was being throttled
>> back when I was using Ver 3.8 and the tokenizers. I cleaned my fans
>> and filters last week so I don’t think it is an airflow problem.
>> Has anyone else noticed an increase in temperature with 3.8?
>>
>>
>
> I've noted nothing with CPU temperature, but I don't routinely watch it.
For years I ran Pov on a laptop. When your lap starts to burn it makes
you think. Now it is just a habit.
> Do you see the throttling if you cut back on the number of cores you use?
>
Looking at the temp graph. I see that one core is running about 5°C
above the lowest. And yes if I deny that core to Pov then it does not
throttle. I have set the throttling level at 89°C that is 6°C below the
CPU shutdown level*. There is a distinct difference between 3.7 and 3.8.
Ach well, it will give me something to do in my free time. Like moving
the box away from a glass partition.
*
If the internet can be believed. There are a lot of conflicting opinions
(crap) out there. Obviously no one on the over-clocker forums uses Pov. :)
> What I am seeing in recent work is more volatility in performance
> measures than has been typical. In the range of -+0.5% run to run of
> late where I'd been getting <<0.1%. Makes it more difficult to determine
> whether a local code change has much affected performance. Basically
> need many more renders or renders with much longer run times.
>
> Aside: Not talking about parser run times here. I expect those to be
> more volatile due memory allocations as the scene is digested.
>
That is a bit above my pay grade. ;)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/05/2018 12:42, clipka wrote:
> Am 24.05.2018 um 11:25 schrieb Stephen:
>
>> Aside.
>> I run Throttle.exe to monitor my CPU and GPU temperatures. I noticed
>> that during the rendering of the scene. My CPU was being throttled back
>> when I was using Ver 3.8 and the tokenizers. I cleaned my fans and
>> filters last week so I don’t think it is an airflow problem.
>> Has anyone else noticed an increase in temperature with 3.8?
>
> Since I haven't touched the rendering itself, this must be a general
> v3.8 thing.
>
Understood, you are working on the parser. That is why I said "aside"
and mentioned it in case it might have some significance for something.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.05.2018 um 14:19 schrieb Stephen:
> Looking at the temp graph. I see that one core is running about 5°C
> above the lowest. And yes if I deny that core to Pov then it does not
> throttle. I have set the throttling level at 89°C that is 6°C below the
> CPU shutdown level*. There is a distinct difference between 3.7 and 3.8.
If by "3.7" you mean v3.7.0, then a potential reason for such a
difference might arise from the build tools used: While POV-Ray v3.7.0
was built using Visual Studio 2010, more recent versions are built using
Visual Studio 2015. Differences in how the compilers optimize the code
may well result in differences in how heavily the CPU can be utilized.
In a similar vein, the hand-optimized noise generator implementations
may also play a role: While v3.7.0 could only utilize AVX/FMA4 for this
purpose, newer versions can also utilize AVX2/FMA3 as well as "pure" AVX
(and the AVX/FMA4 version has been improved).
TL;DU: There are plausible explanations why current versions of POV-Ray
may be utilizing your CPU more heavily (or at least differently) than
v3.7.0 did.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.05.2018 um 10:22 schrieb Stephen:
> On 22/05/2018 01:28, clipka wrote:
>> - Backward compatibility with scenes that use single backslashes in
>> literal filenames has been sacrificed, and will most likely not be
>> restored.
>
> This is going to cause me problems using SDL generated by modellers.
I'm zeroing in on the conclusion that this is a problem that's not
easily solved in the new parser architecture, especially with respect to
the future plans.
The aim is to scan/tokenize a file only once, cache the result, and from
then on only operate on the resulting token stream. Maybe even have a
separate scanner/tokenizer thread go ahead with its job while the parser
thread is still busy with earlier portions of the scene.
This means that whatever looks identical, must be scanned/tokenized
identically. Most notably, backslashes in string literals must be
treated consistently: "foo\nbar" must always be translated as the
character sequence `foo` followed by a newline followed by the character
sequence `bar`, no matter whether the parser - based on neighboring
tokens - expects a filename or a generic string at that particular location.
-OR- the scanner/tokenizer would always have to translate such a string
literal as the character sequence `foo\nbar`. But then the job of
resolving the escape sequence would fall to the parser proper, and would
have to be done over and over again each time the parser encounters the
string literal. Since strings are comparatively heavyweight to process,
that would be bad news in terms of performance.
A similar problem exists with respect to character encoding: Without
understanding of `global_settings { charset utf8 }`, the
scanner/tokenizer cannot decide whether a non-ASCII byte sequence in a
string literal should be interpreted according to UTF-8 or according to
Windows-1252, Latin-1 or whatever.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
