Re: Making Guile slower?

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> "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:

<snip>

> 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

We find performance bottlenecks the way that any good programmer finds
them--- we profile and only optimize the parts that matter.  If you
concede that the general common case is no problem, then there's no
worry that it's an all-around 2% slowdown -- it'll instead be an
isolated fixable issue.

Incidentally, my inlining enhancement (based on profiling Scwm startups) 
will give us a 20 - 40% improvement (I can't remember exactly any
longer, but it was significant) in start-up time with lots of libraries
being loaded.  (My point just is that I care about performance, too --
but I just don't see the point of wasting time when performance isn't
noticeably compromised).

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

Using SCM_STRICT_FOOP won't improve readability-- it just adds another
decision for programmers to make (choosing between STRICT and SLOPPY)
that we can and should avoid because it's something better left to the
optimizer. 

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

So we philosophically disagree.  I think I should only spend my time
optimizing the parts that matter and I'll use profiling tools to find
those parts.

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

At a cost of programming effort.  And again, I stress that no-one has
shown *any* lost performance yet. 

<snip more of the same arguments>

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

And I'm sympathetic to *that* as an argument.  But the diffs are always
there for others to look at.  I reviewed the 101 pages of diffs last
night very carefully and found only the 2 bugs that Mikael already
pointed out and was kind enough to fix.

I'm certain I introduced bugs in the code doing the argument validation
change several days earlier (I still have those 400 pages of diffs to
read carefully -- probably on my plane flight in a couple days).  But I
also know I fixed a half-dozen or so bugs in the process... as I've
argued before, trading bugs is a good things since when testing against
existing code, old bugs are less likely to be found than new ones.  Plus 
some of my new bugs are going to be caught once I statically check some
of the new code conventions.

> > My improvements are real and definite.
> 
> Yes, but you rushed it.

Maybe so, but I sure as hell wish more people working on Guile would
rush to action.

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

Please instead search for places where performance has sufferred and, if
there are any, fix them.  (And I hope you enjoyed the movie!)

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

I do understand the concern about *uncertainty* of slowdown and
instability.  The former you can convince yourself of as not being a
problem by running some benchmarks.  I guaranteee you that the net
performance change to the next release of Guile due to code changes by
me will be substantial in the faster direction.  Again, I remind you of
the anecdotes of losing 30% performance just be reordering functions in
eval.c -- performance is notoriously hard to predict, so we *measure* it 
instead.

As for instability, it's true that pervasive changes can have a
destabilizing effect.  That's why there's time before the next release
to work out some kinks.  Improving the test suite is a nice goal so that
we don't rely on trust in developers to gain confidence in the code.  I
read my diffs incredibly carefully... and nearly always read them very
carefully before committing the change.  Since I touched so many lines
of source in my docstring change, I made the engineering decision that
it was more important to commit those changes to avoid conflicts with
other developers, and have deferred careful reading of the diffs.  I
will inevitably find that I made some mistakes and I will fix them.

Let's focus on the *concrete* and *immediate* benefits of the changes I
made to Guile instead of *wondering* if things *might* be a little bit
worse.

Greg Badros