This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> [I said I wouldn't push any more for reverting the change.  I won't do
>  that---you guys do as you like.  But since you persist in not
>  understanding Marius' and my viewpoint I'll use some new data (3.4
>  and 6.7% slowdown of the evaluator as measured on two different
>  machines) as an excuse to give some counter fire.  This counter fire
>  is mainly motivated by the picture you have painted in your replies
>  to Marius and me, and not by the NIMP change itself.]

So profile it and find where the extra time is spent (I mostly write
this rhetorically, since I believe it's my responsibility to do that,
and I will).  

<snip>

> I think you're not using straight arguments.  In your replies you
> paint a picture of Marius and me having subjective worries while your
> actions are based on solid software engineering.

My actions are based on a different perspective on the tradeoff between
code reusability, maintainability, evolvabilty vs. performance.  I care
more about the former, and less about microoptimizations in performance
(Guile is factors of 10 or more slower loading code than, say, perl--
that kind of performance I care substantially about).

Nevertheless, I'll get the performance back (and then some, as I wrote
earlier). 

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

> among optimizers to have this ability but I don't know how common this
> case is in Guile and I actually don't care, because it's enough to
> make an unfortunate change in just one or two critical places to slow
> down the evaluator (which is, BTW, highly hand-optimized).

And subject to spurious and non-understood performance fluctuations.
I'm incredibly glad to see someone *finally* put real numbers out there.

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

And the burden of demonstration is on whoever is willing to do it-- I've 
spent a ton of time on guile in the last 2 weeks... time that I really
should be spending on my dissertation.  My priority was making the code
more readable and maintainable, knowing that we need to do full
profiling to figure out where the performance problems are, and when
that is done other performance issues can be addressed, too.

> In any case, I configured a Guile from 1999-12-10 and a current Guile
> with configure option --disable-shared, compiled, and ran the `eval1'
> benchmark on an i686 and a sparc machine.  The results are 3.4%
> slowdown on the i686 and 6.7% slowdown on the sparc.  While one should
> of course always be suspicious of benchmarks (can we get it repeated
> elsewhere?) it is an indication that Guile has now taken a step down
> the slippery slope which I talked about earlier.

I'll try to repeat it on my laptop (AMD k6) and see what I get.  Also,
remember, though, that 12-10 to current has my argument validation
changes, too, independent of the NIMP changes.  Though it's helpful to
know that you've seen a very slight slowdown, w/o results of a profile,
it's impossible to attribute the  performance change to a specific
change in the source.

<snip>

Thanks for the benchmarks!

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]