Re: Making Guile slower?

[Greg Harvey <Greg dot Harvey at thezone dot net>]

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

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

No, that was me :)

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

That it is (though having a good time on the mailing list also doesn't
hurt). 

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

(Other Greg's change... we should have to wear badges or something I
think ;). Actually, no; usually, the best thing to do when you're
worrying about something is to actually look at the code and see if
that's the case; before I suggested that it wasn't a big deal, I did
look at critical points of the evaluator; it really isn't a common
occurance to have a non-immediate type check not next to SCM_NIMP. If
the whole file was liberally sprinkled with this, I would've thought
differently, but that just isn't the case (then again, I did see a few
places in the evaluator that already use unneccessary checks, but I
guess those are ok, because they were there before). You always have
to make sure that you don't crash and burn, inside the evaluator as
well as without (we could get a speedup if we didn't have to use
ilength, until that fateful day when we get a malformed list and loop
for eternity).

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

Yeah, but they don't tho, 'cause I said so >;'). The branch makes
modern cpu's quite happy, because they have something to predict. If
not, they just have to do that whole serial thing, and we know how
much that sucks >:'P

I do think we can be overly cautious at times, though, to the point
where we expend a lot of energy doing nothing (well, maybe just I
spend a lot of energy doing nothing, because I'm stupid enough to look
at the code before throwing around vague inferrences that don't apply
to the actual code).

-- 
Greg