Re: Making Guile slower (3.4 and 6.7%). (was Re: NIMP thing)

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Jim Blandy <jimb@red-bean.com> writes:

> If Guile's performance were within 10% of the top Scheme interpreters,
> then I would worry about changes like this.  But we're not even in the
> ballpark.
> 
> For now, Guile developers should be looking for major algorithmic and
> structural improvements that will give us speedups in the 30% - 50%
> range, and all other efforts should be bent towards readibility.
> So I think Greg's approach was correct.
> 
> Mikael, you've spent time working on SCM, which was, for a long time,
> the fastest Scheme interpreter around.  I think your approach makes
> sense for that situation, but not for Guile's.

OK, I give up.  Even this kind of ridiculously extensive discussion
isn't enough to convey the basic messages.  I'll repeat the basic
points once more:

* "My" approach should not be confused with my goal which is very
  similar to Greg's: The goal would be to replace SCM_NIMP && SCM_FOOP
  at all places except at a few critical places which wouldn't matter
  much for maintainability and readability.  [This wasn't my initial
  reaction, which was just that I couldn't immediately overview the
  consequences.  After a while I realized that including SCM_NIMP in
  the type macros was a good idea---sorry for being slow at
  understanding.]

* The idea of "my" approach is that changes to the infrastructure
  should be made in a way that you have better knowledge of the
  consequences.  There was too much guessing involved here, and I
  don't think that is good for Guile in the long run.  "My" approach
  would be to start renaming all SCM_FOOP to SCM_SLOPPY_FOOP, convert
  SCM_NIMP && SCM_SLOPPY_FOOP combinations (semi-)mechanically, and
  then take care of the rest in a gradual way, with benchmarks when
  changing critical places of the evaluator.  The idea is that making
  changes to the infrastructure in this way makes it easier to ensure
  stability and efficiency.

  People just assumed that there would be _no_ performance impact from
  this change.  I felt that I couldn't overview what kind of impacts
  would follow---and still don't.  The change is, sort of, made in
  blind.  For most changes to Guile, you don't need to have much
  overview, so there's no problem, but for some changes, you need to
  go about more carefully.

  However, I'm no longer saying we should do this this time.

* I don't give a damn in _one_ 5% slowdown, but I _do_ care about a
  50% slowdown.  At what point in time do you suggest that I start
  yelling about it?  Who keeps track of the starting point?

Now people, _please_ read what I'm saying before posting more things
like this.  I'd very much like to just enjoy the improved readability
of the Guile code now, hope that at least someone has learnt something
from this discussion and forget about the rest.