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

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

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

> > The reality in this case is quite the opposite.  Marius and myself
> > worry because you are using an approach which is not solid, an
> > approach where you are replacing knowledge of the effects of the
> > change with _belief_ in the effects.  You have demonstrated that in
> > one type of case, on one platform, the compiler optimizer eliminates
> > the redundant operations.  I trust your judgment that it is common
> 
> But my point is slightly different, that we should defer those kinds of
> things to the optimizer because that's its job.  Not the programmer's.
> Now, if important platforms have optimizers that fail to do this job,
> then I fall more towards your side.  I demonstrated that the most
> prevalent platform works great.

Again, for one type of case.  Again, this is not relevant for
performance since, with this approach, you would have to examine the
_critical_ place.  You don't know where this place is, and you'll not
find it with a profiler.

To automatically eliminate all unnecessary extra NIMP's, you'll need
an AI optimizer doing optimization on the global level.

> > Marius proposed a way to make this change with preserved knowledge of
> > the effects of the change, while you have let go of this knowledge and
> > just _believe_ that the changes won't influence efficiency.  In this
> > perspective, I find it strange that the burden of demonstration is put
> > on us.
> 
> But I've always wanted a *different* end product than Marius and you
> have been clamouring for:  I don't believe that *every* SCM_FOOP that
> would need to be turned into a SCM_SLOPPY_FOOP should be-- but instead
> that many should be left as SCM_FOOP for maintainability and
> understandability and leave the micro-optimization to the compiler.

With Marius approach it is possible to successively convert the
SCM_SLOPPY_FOOP cases into SCM_FOOP cases (when anyone has time to do
it), e.g. on a file by file basis, and test the impact on performance.

I expect that the critical places where SCM_SLOPPY_FOOP should be
preserved are only to be found in eval.c and gc.c, so the total amount
of extra work wouldn't be unrealistic, and the impact on
maintainability of preserving these wouldn't be too great.

[In any case, I think the current eval.c is quite hopeless when it
 concerns maintainability anyway.  (And I don't complain much about
 this, since you quite seldom have to poke around in it.)  To achieve
 maintainability, which is a worthy goal, we need to replace the
 current evaluator with a byte-code interpreter.]

> And the burden of demonstration is on whoever is willing to do it

Well, according to the policy which Maciej now has expressed the
burden is upon the one who is doing a change expected to influence
performance.  I think this is good.


Anyway, note again that I think the change itself is basically good.

/mdj