Re: push parser implemenation

[Bob Rossi]

Sorry for the delayed response. I've been in the hospital since Saturday
with my wife and son and just got home today. It turns out that he is perfectly
OK! However, since we've been home today, both my wife and I have caught
some sort of throat cold. So, I probably won't do anything with this
until next week.

On Mon, Apr 24, 2006 at 11:03:00AM +0200, Akim Demaille wrote:
> >>> "Bob" == Bob Rossi <address@hidden> writes:
> 
>  > OK, what do you think of this patch? Again, I didn't bother cleaning
>  > it up to much, I'll do that if the numbers are acceptable. What do you
>  > think of the numbers? For some reason the push_opt yacc parser is faster
>  > than the regular yacc parser. Go figure.
> 
> These figures are very encouraging!  I have a bit more loss in push
> mode than you have (me: 9%, you: 2%), but anyway as I already said I
> don't consider push-non-pure to be a requirement and I would not try
> to support it.
> 
> (popt = push-opt)
> 
> popt-pure: 48 wallclock secs (36.65 cusr +  1.08 csys = 37.73 CPU) @  1.33/s 
> (n=50)
> popt-push: 74 wallclock secs (54.77 cusr +  1.25 csys = 56.02 CPU) @  0.89/s 
> (n=50)
> popt-yacc: 51 wallclock secs (37.94 cusr +  1.11 csys = 39.05 CPU) @  1.28/s 
> (n=50)
> push-pure: 58 wallclock secs (44.92 cusr +  1.21 csys = 46.13 CPU) @  1.08/s 
> (n=50)
> push-push: 61 wallclock secs (50.26 cusr +  1.20 csys = 51.46 CPU) @  0.97/s 
> (n=50)
> push-yacc: 57 wallclock secs (45.34 cusr +  1.16 csys = 46.50 CPU) @  1.08/s 
> (n=50)
> yacc-pure: 45 wallclock secs (36.84 cusr +  1.06 csys = 37.90 CPU) @  1.32/s 
> (n=50)
> yacc-yacc: 47 wallclock secs (37.97 cusr +  1.07 csys = 39.04 CPU) @  1.28/s 
> (n=50)
>              Rate popt-push push-push push-yacc push-pure popt-yacc yacc-yacc 
> yacc-pure popt-pure
> popt-push 0.893/s        --       -8%      -17%      -18%      -30%      -30% 
>      -32%      -33%
> push-push 0.972/s        9%        --      -10%      -10%      -24%      -24% 
>      -26%      -27%
> push-yacc  1.08/s       20%       11%        --       -1%      -16%      -16% 
>      -18%      -19%
> push-pure  1.08/s       21%       12%        1%        --      -15%      -15% 
>      -18%      -18%
> popt-yacc  1.28/s       43%       32%       19%       18%        --       -0% 
>       -3%       -3%
> yacc-yacc  1.28/s       43%       32%       19%       18%        0%        -- 
>       -3%       -3%
> yacc-pure  1.32/s       48%       36%       23%       22%        3%        3% 
>        --       -0%
> popt-pure  1.33/s       48%       36%       23%       22%        3%        3% 
>        0%        --
> 
> I don't really understand why the system time should differ
> significantly between all our parsers (e.g., push-opt-pure 1.08
> vs. push-opt-push 1.25; on another run I have 1.15 vs. 1.35).  Can
> there be *good* reasons (ie., due to our programming only, not random
> issues on the machine we run the bench on) for them to change like
> this?  

I don't think there is a good programming reason, but I really don't
know. The only thing I can think of is we may make more system calls in
a particular parser mode. However, I don't think this should be the
case.

> So as far as I'm concerned, I'm ready to switch to a new skeleton.
> Now let's focus on making the code nicer to read.  But what do the
> other members of the team (the Pauls and Joel) think?

This sounds like a good idea to me, at least to track changes like
you've stated. However, I don't think I have write privileges to the
CVS repository. Can this be granted? or should I just post patches here?

I already have write after approval permission on the GDB repository.
Do you have a similar mechanism?

>  > I've attached push_opt.c, and the new bench.pl script I'm using. You can
>  > diff it to yours to see the difference.
> 
> I have checked in the bench script in etc/, that will ease the
> tracking of changes.  I have added other changes on top of yours.
> I did not checkin the push parsers because I don't remember whether we
> have all the copyright issues settled.  If we do, then how about
> checking in your skeleton so that we can also easily track the
> differences?  As long as the tarball is not touched, I see no problem
> with adding files even before the 2.2 release.

I have only verbally been told that Odd signed a copyright assignment.
You'll have to check up on that. I have defiantly signed a copyright
assignment with the FSF several years ago to work on GDB. If that same
assignment covers me for bison then all is good. Of course, if you are
already double checking for Odd, ...

Thanks,
Bob Rossi