From ...
Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!supernews.com!news-x2.support.nl!easynet-monga!easynet.net!news.ebone.net!news1.ebone.net!194.177.33.107.MISMATCH!hamster.europeonline.net!newsfeed.europeonline.net!nslave.kpnqwest.net!nloc2.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail
Newsgroups: comp.lang.lisp
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
References: <gat-1203021200230001@eglaptop.jpl.nasa.gov> <87u1rkl068.fsf@charter.net> <87wuwg1b05.fsf@photino.sid.rice.edu> <87ofhrc3ed.fsf@charter.net> <874rjj1ve1.fsf@photino.sid.rice.edu> <b84e9a9f.0203141902.24ce7c85@posting.google.com> <87it7yz2sf.fsf@photino.sid.rice.edu> <sfwr8mlewux.fsf_-_@shell01.TheWorld.com> <87d6y5heq2.fsf@becket.becket.net> <87elilwsnx.fsf@photino.sid.rice.edu> <87u1rfn07o.fsf@becket.becket.net> <87k7sbtzp5.fsf@photino.sid.rice.edu> <871yej1v0h.fsf@becket.becket.net> <3225566321428508@naggum.net> <3C97C8EA.38FFD47A@motorola.com> <3225571208798099@naggum.net> <3C9806B8.B239D290@interaccess.com> <3225694232096978@naggum.net> <3C99D8D6.CA34A3D6@interaccess.com> <3225739029050571@naggum.net> <sfwk7s5o7gy.fsf@shell01.TheWorld.com> <gat-2103021907160001@192.168.1.50> <41yedf67z.fsf@beta.franz.com> <3225772799804783@naggum.net> <gat-2203020802540001@192.168.1.50>
Mail-Copies-To: never
From: Erik Naggum <erik@naggum.net>
Message-ID: <3225807274641011@naggum.net>
Organization: Naggum Software, Oslo, Norway
Lines: 27
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 22 Mar 2002 17:34:21 GMT
X-Complaints-To: newsmaster@KPNQwest.no
X-Trace: nreader2.kpnqwest.net 1016818461 193.71.199.50 (Fri, 22 Mar 2002 18:34:21 MET)
NNTP-Posting-Date: Fri, 22 Mar 2002 18:34:21 MET
Xref: archiver1.google.com comp.lang.lisp:29883

* Erann Gat
| It turns out Duane was right and what I was really measuring was the
| difference in implementation efficiency between the built-in getf and
| assoc (which became blatantly obvious when I disassembled *those*.
| Duh!).  When I wrote my own the difference was much smaller, but
| interestingly still there:

  To make this a useful basis of comparison, you should post the code, too.
  I posted my code for alist-get and plist-get with optimized versions with
  hand-tweaked expanded tagbodies.

| Whether this difference is due to the effect that Paul is describing or
| simply due to a compiler quirk is unclear.  I obviously need more
| practice reading disassembly listings.

  You will _never_ have the potential of stalling if you have so short
  lists that they are all in level 1 cache.  Optimizing the access pattern
  of what is basically 16K of registers on the IA32, for instance, is a
  major waste of time.  I have found it useful to use lists of 1 million
  key-value pairs for testing. to ensure that no caching can possibly
  intervene and the cost of memory latency is predominant, which means you
  can repeat the function 100 times without deterioration of maasurements.

///
-- 
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.