From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.vmunix.org!news.ebone.net!news1.ebone.net!194.177.33.107.MISMATCH!hamster.europeonline.net!newsfeed.europeonline.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?] References: <87u1rkl068.fsf@charter.net> <87wuwg1b05.fsf@photino.sid.rice.edu> <87ofhrc3ed.fsf@charter.net> <874rjj1ve1.fsf@photino.sid.rice.edu> <87it7yz2sf.fsf@photino.sid.rice.edu> <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> <87y9grsf <3225739210766179@naggum.net> <3C9A6917.FFC1C4ED@motorola.com> <3225746969252089@naggum.net> <3C9A89E4.F6CAF696@interaccess.com> Mail-Copies-To: never From: Erik Naggum Message-ID: <3225770541321057@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 50 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 07:22:08 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader1.kpnqwest.net 1016781728 193.71.199.50 (Fri, 22 Mar 2002 08:22:08 MET) NNTP-Posting-Date: Fri, 22 Mar 2002 08:22:08 MET Xref: archiver1.google.com comp.lang.lisp:29832 * "Paul F. Dietz" | This is a *trivial* consequence of the structure of the dependency graph | of the loads. Both graphs have ~3 N nodes, but the length of the | critical path in the alist search is N vs. 2N for the plist. This is just plain wrong. Please understand that we are doing assoc, not member, on alists, OK? The car of an alist is just as much on the critical path as the cdr of a plist. This is frighteningly obvious if you spend the time to __study it rather than make up your mind and then spend your time to "prove" it. | As Mr. Pitman requested, let's see the code. Here's a software | pipelined implementation of (assoc ... :test #'eq), concentrating | on the case of a non-null key. What does "concentrating on the case of a non-null key" mean? | You will notice that in the main loop (not counting epilogue code), | between any load and the first use of its result you will find at least | two other loads. You can't do as well with plist search -- there aren't | as many other loads to fit between the cdrs. I have asked you to work this out for plists, too, but you keep posting only code relevant to alists. I am not interested in what you have to say about alists as long as you make _no_ effort to show what you can do similarly with plists. Can you please understand this? | If we're on a machine in which (1) load latency dominates, and (2) three | loads can be in progress at once, then this algorithm will take time | N+O(1) (in units of load latency). *Any* plist algorithm would take time | 2 N in this model of computation -- you can't start one critical path | load until the previous one is completed, and there are 2 N such loads. *sigh*. Yes, that is precisely what you can do. There is no difference. Work it out similarly for plists. CAN YOU DO THIS, PLEASE!? Christ! Your code is extremely unlikely to have any effect, by the way. If you have to grab data from external memory, you need _way_ more than two intervening loads. An L1 cache hit is basically free, so the point is to get stuff into the L1 cache. This does not happen any differently in your code than in a straight version of alist-get and plist-get that I posted. I wonder why you are so stubborn about something that is clearly wrong. /// -- 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.