On 23/05/2018 16:30, clipka wrote:
> Am 23.05.2018 um 16:38 schrieb Stephen:
>> On 23/05/2018 13:55, clipka wrote:
>>> Am 23.05.2018 um 10:22 schrieb Stephen:
>>>
>>>> Test:
>>>>
>>>> v 3.8.0-alpha.9475849+av541.msvc14 is faster than
>>>> v 3.8.0-x. tokenizer.9999+av5 60.msvc
>>>>
>>>> On the second run of the file. The parse time was a second or two slower
>>>> than the first time. Except when using Ver 3.7 when it was the same.
>>>
>>> I take that as good news, presuming the scene in question does call
>>> macros across files. Such a scenario would explain the superior
>>> performance of v3.8.0-alpha over v3.7.0 as the result of macro caching,
>>> as well as the inferior performance of v3.8.0-x.tokenizer vs.
>>> v3.8.0-alpha as the result of disabled macro caching.
>>>
>>
>> Sorry it does not use macros. It did but I de-constructed the grass
>> macro it was using as it was declaring an array of meshes from within a
>> while loop. [Watch the memory usage rise and the HDD thrash.]
> 
> Hmm... then that begs the question, which change between v3.7.0 and
> v3.8.0-alpha would have improved parsing speed?
> 

You mean it is not deliberate? o_O

> Besides, what loop size are we talking about? Would that happen to be
>> 64k characters in the loop body?
> 

I am not too sure I understand.

The loop size depends on the size of the target heightfield and the 
required density of the grass.

Relevant code.

             #declare BoxMin  = min_extent (Trace_patch_aa_) ;
             #declare BoxMax = max_extent (Trace_patch_aa_)  ;
             #declare Density =10000 ;  // User variable
             #declare RootDensity = sqrt(Density) ;




               #local Ox = BoxMin.x;
               #local Oz = BoxMin.z;
               #local Nx = int(RootDensity*sqrt(BoxMax.x - BoxMin.x));
               #local Nz = int(RootDensity*sqrt(BoxMax.z - BoxMin.z));
               #local Dx = Nx/Density;
               #local Dz = Nz/Density;

             union {
               #local I = 0;
               #while(I<Nx)
                #local J = 0;
                #while(J<Nz)
                 #local Z = Oz + ( J + 0.5 ) * Dz + ( rand( Pseed ) - 
0.5 ) * Dz * Pdev;
                 #local Z = ( ( Z < Oz ) ? Z - 2 * Oz : ( Z > -Oz ) ? Z 
+ 2 * Oz : Z );
                 #local X = Ox + ( I + 0.5 ) * Dx + ( rand( Pseed ) - 
0.5 ) * Dx * Pdev;
                 #local X = ( ( X < Ox ) ? X - 2 * Ox : ( X > -Ox ) ? X 
+ 2 * Ox : X );
                 #local W = 2 + ( rand( Wseed ) - 0.5 ) * Wdev;

                        #local Inter = trace ( Trace_object_ , < X , 
BoxMax.y + 100 , Z>,  < 0  ,  -1, 0 >, Norm);

                   #if (vlength (Norm)!=0)

USW


>> I have already had jr complain that I sent him the code in one file and
>> not split into include files.
>> So, what is wrong with 54317 lines in one file, anyway? ;-)
> 
> Nothing. It might actually be perfect for my parser tests. ;)
> 


I thought you might ask for a copy and started to look at how many image 
maps it was using.
It seems that when I was modifying the file manually I forgot to remove 
a couple of flower meshes. I had used in B3D. I cleaned it up and it is 
only 13500 lines now. And one heightfield image.

If you still want a copy. I will post it.
-- 

Regards
     Stephen

Post a reply to this message

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.

-- 

Regards
     Stephen

Post a reply to this message

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.)

Post a reply to this message

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'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.

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`.)

Post a reply to this message

Am 23.05.2018 um 19:31 schrieb Stephen:

>>> Sorry it does not use macros. It did but I de-constructed the grass
>>> macro it was using as it was declaring an array of meshes from within a
>>> while loop. [Watch the memory usage rise and the HDD thrash.]
>>
>> Hmm... then that begs the question, which change between v3.7.0 and
>> v3.8.0-alpha would have improved parsing speed?
>>
> 
> You mean it is not deliberate? o_O

I don't recall having done anything to the parser between v3.7.0 and
v3.8.0-alpha with the intent to speed up parsing in general, with the
sole exception of macro caching. I hate the code, so it has never gotten
much love & care from me ;)

There /may/ have been side effects from a bit of code cleanup here and
there. But usually I've just given the parser more jobs to do.


>> Besides, what loop size are we talking about? Would that happen to be
>>> 64k characters in the loop body?
>>
> 
> I am not too sure I understand.
> 
> The loop size depends on the size of the target heightfield and the
> required density of the grass.

I mean the raw number of characters in the scene (or include) file, from
the `#while` or `#for` to the corresponding `#end`.

For example, the body of the following loop is 31 characters long:

    #for(I,0,100) #debug "Another iteration.\n" #end


> I thought you might ask for a copy and started to look at how many image
> maps it was using.
> It seems that when I was modifying the file manually I forgot to remove
> a couple of flower meshes. I had used in B3D. I cleaned it up and it is
> only 13500 lines now. And one heightfield image.
> 
> If you still want a copy. I will post it.

Please go ahead. I'm curious which feature of the file makes
v3.8.0-alpha like it better than v3.7.0.

Post a reply to this message

On 05/23/2018 02:05 PM, clipka wrote:
> Am 23.05.2018 um 19:31 schrieb Stephen:
> 
...
> 
> I don't recall having done anything to the parser between v3.7.0 and
> v3.8.0-alpha with the intent to speed up parsing in general, with the
> sole exception of macro caching. I hate the code, so it has never gotten
> much love & care from me ;)
> 
> There /may/ have been side effects from a bit of code cleanup here and
> there. But usually I've just given the parser more jobs to do.
> 
> 

There was somewhat recently this commit :

commit 26e2d47a35cebb91961642de0293d059b4fad071
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date:   Sat Jan 6 09:07:00 2018 +0100

     Improve parsing speed of skipped conditional blocks.

(some change from uberpov I think)

Bill P.

Post a reply to this message

On 05/23/2018 09:18 AM, clipka wrote:
> Am 22.05.2018 um 02:28 schrieb clipka:
...
> 
> The fact that none of you has reported any bugs yet makes me a bit
> uneasy... the new code can't be /that/ good ;)
> 

FYI. I've not run my personal set of parser tests against the new stuff. 
Takes time to turn and I'm working on other code (a.k.a. dazed and 
confused) at the moment.

Bill P.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Please give this version a thorough shakedown, with focus on parsing:
>

(running my original 'city buildings' code-- which is not very 'efficient',
although that might be a good thing for this test. With 1500 buildings.)

No #read's, no #include's, LOTS of #macros as simple containers (under 64K), of
this general form...
           #macro HO_16()
           jpeg "building windows 16.jpg" interpolate 2
           #end

.....which are used repeatedly, another *large* macro, two functions, LOTS of
comments, LOTS of image_maps, lots of #while loops.

v3.7.0: 35.54 seconds parse time

v3.8 tokenizer: 34.29 seconds

Hmm, too close to call (probably because of all those un-cached #macros, in the
tokenizer version.)

And no bugs! Sorry!! :-P

Post a reply to this message

Am 23.05.2018 um 20:37 schrieb William F Pokorny:

>> I don't recall having done anything to the parser between v3.7.0 and
>> v3.8.0-alpha with the intent to speed up parsing in general, with the
>> sole exception of macro caching. I hate the code, so it has never gotten
>> much love & care from me ;)
...

> There was somewhat recently this commit :
> 
> commit 26e2d47a35cebb91961642de0293d059b4fad071
> Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
> Date:   Sat Jan 6 09:07:00 2018 +0100
> 
>     Improve parsing speed of skipped conditional blocks.

Dang - I guess I must love the parser more than I would ever publicly admit.

When I stumbled across the code again now for the overhaul, I somehow
was of the impression that it had been in there for ages.

Post a reply to this message

On 23/05/2018 19:05, clipka wrote:
> Am 23.05.2018 um 19:31 schrieb Stephen:
> 
>>>> Sorry it does not use macros. It did but I de-constructed the grass
>>>> macro it was using as it was declaring an array of meshes from within a
>>>> while loop. [Watch the memory usage rise and the HDD thrash.]
>>>
>>> Hmm... then that begs the question, which change between v3.7.0 and
>>> v3.8.0-alpha would have improved parsing speed?
>>>
>>
>> You mean it is not deliberate? o_O
> 
> I don't recall having done anything to the parser between v3.7.0 and
> v3.8.0-alpha with the intent to speed up parsing in general, with the
> sole exception of macro caching. I hate the code, so it has never gotten
> much love & care from me ;)
> 
> There /may/ have been side effects from a bit of code cleanup here and
> there. But usually I've just given the parser more jobs to do.
> 
> 
So Bill says. ;)


>>> Besides, what loop size are we talking about? Would that happen to be
>>>> 64k characters in the loop body?
>>>
>>
>> I am not too sure I understand.
>>
>> The loop size depends on the size of the target heightfield and the
>> required density of the grass.
> 
> I mean the raw number of characters in the scene (or include) file, from
> the `#while` or `#for` to the corresponding `#end`.
> 
> For example, the body of the following loop is 31 characters long:
> 
>      #for(I,0,100) #debug "Another iteration.\n" #end
> 

That is how I read it.
Including tabs. Word counts 399 characters

> 
>> I thought you might ask for a copy and started to look at how many image
>> maps it was using.
>> It seems that when I was modifying the file manually I forgot to remove
>> a couple of flower meshes. I had used in B3D. I cleaned it up and it is
>> only 13500 lines now. And one heightfield image.
>>
>> If you still want a copy. I will post it.
> 
> 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"

-- 

Regards
     Stephen

Post a reply to this message