Re: Making Guile slower?

[Marius Vollmer <mvo at zagadka dot ping dot de>]

"Greg J. Badros" <gjb@cs.washington.edu> writes:

> There is *absolutely* no difference in the assembly code that GCC 2.95.2
> generates (with -O, -O2, -O6) on my PIII processor for:
> 
> #include "ports.h"
> #include "pairs.h"
> #include "tags.h"
> 
> int main(char *argv, int argc)
> {
>   SCM x = SCM_EOL;
>   /* remember SCM_CONSP and SCM_OPENP below have the 
>      SCM_NIMP test folded into them */
>   int f = (SCM_CONSP(x) || SCM_OPENP(x));
>   return f;
> }
> 
> vs.
> 
> #include "ports.h"
> #include "pairs.h"
> #include "tags.h"
> 
> #define SCM_OPN		(1L<<16) /* Is the port open? */
> 
> #define SCM_SLOPPY_OPENP(x) (SCM_OPN & SCM_CAR(x))
> #define SCM_SLOPPY_CONSP(x) (!(1 & SCM_CAR(x)))
> 
> int main(char *argv, int argc)
> {
>   SCM x = SCM_EOL;
>   int f = (SCM_NIMP(x) && (SCM_SLOPPY_CONSP(x) || SCM_SLOPPY_OPENP(x)));
>   return f;
> }

Yes, I believe that, but I wasn't really worried about this case, or
any other specific change you did.  I only take issue with your
approach.  The above experiment gives no evidence that there isn't
some peculiar code in libguile that the optimizer can't handle but
that is unfortunately in an inner loop.  I agree that I should really
be making the benchmark if I wanted to complain about lost
performance, but likewise, I'm really only complaining about your
approach, which has a higher risk of degrading performance than I
think is necessary.

[ Incidentally, on my box, gcc optimized everything away.  I used

    SCM foo ();
    SCM x = foo ();

  to get it to produce real code, but your point is still valid. ]

> You guys need more faith in optimizers.  That's not to say that there
> might be some obscure places in the code where the generated assembly
> won't differ, but they will be rare, and are easy to handle using
> whatever SCM_SLOPPY_FOOPs we need to introduce.

But we first need to find them.  I would be happier if you would have
first tackled the trivial cases like

    if (SCM_NIMP (x) && SCM_SLOPPY_CONSP (x))

    =>

    if (SCM_STRICT_CONSP (x))

where nobody can argue that the change affects the generated code, and
then we could gradually find more complicated uses of SCM_SLOPPY and
after thinking very hard about each individual case, we could maybe
change some more to be using SCM_STRICT if it indeed improves
readability of the code.

> <snip>
> 
> > agree much more than we disagree.  Your plan of introducing sloppy
> > variants is exactly the Right Thing.
> 
> But only as they are necessary.  Trust in your compiler.

Again, I would much happier if you wouldn't _reintroduce_ the sloppy
variants individually in the aftermath, but if you had taken them out
individually.

> > But I'm worried that you are not aproaching the thing with the
> > appropriate conservatism.  Your change might have affected the most
> > time critical code of all in Guile, it could maybe have slowed down
> > looking up ilocs significantly.
> 
> And if someone posts evidence that that is the case, then I will get
> whatever performance I lost back.  I promise.

You could have ruled out the possibility of loosing performance from
the start, and I would have preferred that.
 
> > You are going to do that, and that is a good thing, but I still don't
> > like the handwaving about how two instructions don't matter within the
> > type checking code, and the temporary distortion of known-good code.
> 
> It's the *same* code that gets generated nearly everywhere.  And yes,
> I'm aware that *nearly* is a significant qualification, but we have an
> obvious way to handle those remaining places if they turn out to be a
> performance problem.

There is an obvious approach for avoiding the danger of performance
problems in the first place.

> > Anyway, although you might not believe it, I'm still having a lot of
> > fun with Guile, and I'm very happy that you all do this huge amount of
> > work.  Really.  I may sound like I have some authority, which in fact
> > I don't have, so you can simply ignore me if you like.
> 
> It's not wise to ignore your users (and even less wise to ignore
> co-developers).  But I'd love it if people's concerns were supported by
> real evidence, instead of just "maybes".

Yes, I agree.  I feel somewhat goofy about this rambling of mine, and
I have been on your side of such a discussion myself, and I didn't
like it at all, because I thought my `opponent' was totally dense and
unwilling to listen, and this was actually part of why I stopped doing
much Gtk work, and so I really hope I can handle this in a better way.

But anyway, I think I have the real evidence to support my concerns.
My concern is that you didn't approach your approach your software
engineering face-lift with the appropriate conservatism, and my
evidence is what you did.

I don't care if Guile has actually gotten slower or more unstable or
not, the possibility alone that it might be the case is troubling
enough to me.

> My improvements are real and definite.

Yes, but you rushed it.

I have to rush to the movies now, and I will explain in greater detail
why I'm being so un-jolly here (which I don't like to be!) later.

All the best, and don't let me stop you, but please try to understand
my position.

- Marius