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?


Greg Harvey <Greg.Harvey@thezone.net> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > Greg Harvey <Greg.Harvey@thezone.net> writes:
> > 
> > > It is something that needs to be considered in every case, but I
> > > really don't think that this particular case could possibly effect
> >                ^^^^^
> > 
> > Men have erred on simpler `thinks'.  
> 
> Did you not read what lead me to `think' this?

Yes, I did read it.  But I should also say that I'm patently confused
about the many Gregs on this list who are doing significant thinks.
Thus, the "you" in this article is addressed at the union of all
Gregs.

> I'll state it again: given the rarity of places in the code where
> nimp is not used in close proximity to the other predicate, as well
> as the fact that the nimp test should not be compiled to code any
> more complex than 2 simple instructions, on a value that's about to
> be used anyway, there is no way it's going to cause a significant
> performance degradation.

What worries me is that you are so sure about your reasoning without
hard evidence.  One of these simple instructions is a branch which is
*the* instruction for throwing modern CPUs off track.  Your own tests
have shown that the resulting performance of a piece of code can be
very counter-intuitive and given that I trust Aubrey very much when it
comes to bumming code to the edge, I am hard pressed to accept your
reasoning just because you say "it's cool, son".

Now, I recognize that I sound not very constructive and that I give
the impression of wanting to harm the new found enthusiasm in the
Guile camp.  This is not what I intend.  I _do_ think that the Guile
project is about more than having a good time on a mailing list, and I
_am_ prepared to be the one who spoils all the fun, but only when I
think it is, in fact, constructive.

I am all in favor of your cleanup of the libguile sources, and I think
it is an important step towards making it easy to use Guile as an
embedded Scheme interpreter or generic data type library.  I think we
agree much more than we disagree.  Your plan of introducing sloppy
variants is exactly the Right Thing.

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.

In my view, the conservative thing would have been to alias the
existing macros to names including SLOPPY, to introduce STRICT
variants of these macros (that include the SCM_NIMP test) and then
gradually change the NIMP && SLOPPY combos to STRICT, with amble
public testing on the way, and backward compatability.  When no
references to the old names (without SLOPPY or STRICT) are present,
you could then rename the STRICT variants to the old, simple names.
The resulting machine code of Guile would stay unaffected all the
time, but the clarity of the source would be improved.

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.

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.

- Marius

-- 
Experienced managers know how to identify bad ideas.
Bad ideas come from other people.  - PHB

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