See anything special in this benchmark render?

Nothing?

Well, that's good then, because the only difference is in how the scene
was parsed.

At the moment the restructured parser has some known issues (can't
`#read` yet, `\\` in strings are currently broken, and macro caching is
currently disabled), but overall it appears to do its job.

Performance is another issue, with parsing of the benchmark scene still
taking about 40% longer, but I'm optimistic that I can trim that down
quite a bit.

Post a reply to this message

Attachments:
Download 'benchmark.png' (450 KB)

Preview of image 'benchmark.png'

On 05/17/2018 06:49 AM, clipka wrote:
> See anything special in this benchmark render?
> 
> Nothing?
> 
> Well, that's good then, because the only difference is in how the scene
> was parsed.
> 
> At the moment the restructured parser has some known issues (can't
> `#read` yet, `\\` in strings are currently broken, and macro caching is
> currently disabled), but overall it appears to do its job.
> 
> Performance is another issue, with parsing of the benchmark scene still
> taking about 40% longer, but I'm optimistic that I can trim that down
> quite a bit.
> 

Cool! :-)

Bill P.

Post a reply to this message

Am 17.05.2018 um 12:49 schrieb clipka:

> Performance is another issue, with parsing of the benchmark scene still
> taking about 40% longer, but I'm optimistic that I can trim that down
> quite a bit.

... and already close to normal performance again: Difference on
benchmark scene is now within measurement tolerances, while a 45M token
mesh2-heavy scene is now just 8% slower than with the current GitHub
master version.

Post a reply to this message

Am 17.05.2018 um 16:06 schrieb clipka:
> Am 17.05.2018 um 12:49 schrieb clipka:
> 
>> Performance is another issue, with parsing of the benchmark scene still
>> taking about 40% longer, but I'm optimistic that I can trim that down
>> quite a bit.
> 
> ... and already close to normal performance again: Difference on
> benchmark scene is now within measurement tolerances, while a 45M token
> mesh2-heavy scene is now just 8% slower than with the current GitHub
> master version.

Well, it gets better and better: I'm already 7% /faster/ now. And I
haven't even started on the optimizations I originally had in mind. So
far it's more or less a byproduct of the new dedicated scanner and
related refactoring.

I guess linear scenes won't get much improvement on top of this (at
least not as long as the parser remains single-threaded), but I'm pretty
sure I can do something about non-linear scenes.

Post a reply to this message

On 05/17/2018 01:06 PM, clipka wrote:
> Am 17.05.2018 um 16:06 schrieb clipka:
>> Am 17.05.2018 um 12:49 schrieb clipka:
>>
>>> Performance is another issue, with parsing of the benchmark scene still
>>> taking about 40% longer, but I'm optimistic that I can trim that down
>>> quite a bit.
>>
>> ... and already close to normal performance again: Difference on
>> benchmark scene is now within measurement tolerances, while a 45M token
>> mesh2-heavy scene is now just 8% slower than with the current GitHub
>> master version.
> 
> Well, it gets better and better: I'm already 7% /faster/ now. And I
> haven't even started on the optimizations I originally had in mind. So
> far it's more or less a byproduct of the new dedicated scanner and
> related refactoring.
> 
> I guess linear scenes won't get much improvement on top of this (at
> least not as long as the parser remains single-threaded), but I'm pretty
> sure I can do something about non-linear scenes.
> 

Guessing the magnitude of linear improvement will depend on the SDL 
writer's characteristic verbosity(1)?

Bill P.

(1) - I'll be able to crank it to 11... :-)

Post a reply to this message

Am 18.05.2018 um 13:11 schrieb William F Pokorny:

>> I guess linear scenes won't get much improvement on top of this (at
>> least not as long as the parser remains single-threaded), but I'm pretty
>> sure I can do something about non-linear scenes.
>>
> 
> Guessing the magnitude of linear improvement will depend on the SDL
> writer's characteristic verbosity(1)?

Absolutely. Every character you type (including whitespace) is a
character the scanner has to scan. So minimizing your WCV will continue
to be good advice(*).

(*for getting top parsing speeds; legibility is another matter)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 18.05.2018 um 13:11 schrieb William F Pokorny:
> >
> > Guessing the magnitude of linear improvement will depend on the SDL
> > writer's characteristic verbosity(1)?
>
> Absolutely. Every character you type (including whitespace) is a
> character the scanner has to scan. So minimizing your WCV will continue
> to be good advice(*).
>
> (*for getting top parsing speeds; legibility is another matter)

Pity the poor SDL programmer who includes copious comments in his scene (and
long variable names) just to make sense of his or her complex scene code. Uh,
like me :-/

I guess the best recourse is to wait until the scene is 'sealed in stone', then
make a copy of it for 'real' rendering, stripping out ALL unnecessary stuff
(including as much whitespace as possible), to get a lean and efficient parse.
(I'm thinking mostly of a complex animation scene.) I assume that this would be
good practice in ANY high-level language.

Post a reply to this message

I'm still looking this over and trying to construct some test cases worthy of
posting.  I've got everything in reservedwords.cpp to play with, so that ought
to keep me busy once I get a chance to actually `work on it.


Great job, Christoph, getting the scanner up to speed (and beyond!)


Also:

"Kenneth" <kdw### [at] gmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:

> > Absolutely. Every character you type (including whitespace) is a
> > character the scanner has to scan.

> Pity the poor SDL programmer ...

Well, something I would like added to SDL is at least one other way to tag
comments, which would be displayed in a different hue.
Because it would certainly be useful to be able to highlight some very important
text in a long /*   ...   */ comment block

Along those lines, perhaps if there were an "expert mode" comment tag, then the
scanner could just ignore the rest of everything on that line, or perhaps
something like #comment(100) would treat the following hundred lines as
comments....

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> >
> > Absolutely. Every character you type (including whitespace) is a
> > character the scanner has to scan.

For sheer parse-time efficiency, I'm wondering if the number of separate code
lines in a scene also makes a difference. In other words, is this more
efficient...

#declare S=32+64+17;

..... than this:

#declare S=
32
+
64
+
17
;

Does the scanner have to 'scan' the ENTER key's entry, when starting new
lines like this?

Post a reply to this message

Am 18.05.2018 um 21:45 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 18.05.2018 um 13:11 schrieb William F Pokorny:
>>>
>>> Guessing the magnitude of linear improvement will depend on the SDL
>>> writer's characteristic verbosity(1)?
>>
>> Absolutely. Every character you type (including whitespace) is a
>> character the scanner has to scan. So minimizing your WCV will continue
>> to be good advice(*).
>>
>> (*for getting top parsing speeds; legibility is another matter)
> 
> Pity the poor SDL programmer who includes copious comments in his scene (and
> long variable names) just to make sense of his or her complex scene code. Uh,
> like me :-/

Don't worry - hand-made (and thus documented) /linear/ scenes are rarely
ever long enough to have any noticeable parsing time; and when I'm done
with the parser improvement, in /non-linear/ scenes the WCV will make
virtually no difference anymore, as any comments and whitespace will
then be processed (and discarded) exactly once, even in loops and macros.


> I guess the best recourse is to wait until the scene is 'sealed in stone', then
> make a copy of it for 'real' rendering, stripping out ALL unnecessary stuff
> (including as much whitespace as possible), to get a lean and efficient parse.
> (I'm thinking mostly of a complex animation scene.) I assume that this would be
> good practice in ANY high-level language.

No; with good contemporary high-level languages, WCV makes little
difference, so comments should always stay in there (unless your primary
goal is not to improve parsing speed, but to deliberately obfuscate the
code).

Pretty much the only thing that's slowed down by high WCV is the scanner
stage; and unless a language is implemented as daft as POV-Ray's, that
stage makes for only a very tiny fraction of the time required to
process a program's source code.

Post a reply to this message