I don't understand what the problem is, as far as array functionality goes one can use (get), and for hash functionality (assoc) or (idx), did I miss something?
During development of http://vizreader.com which is quite a big application, I never wished I had either native arrays or hashes. However, some features would have been impossible to implement without the index tree functionality, the below method is a good example: (dm words> (L) (let Words NIL (for W L (and (setq W (lowc (pack W))) (not (common?> This W)) (if (idx 'Words W T) (inc (car @)) (set W 1)))) (idx 'Words))) It will count all words in an article by using the word as the "key" in hash terminology and the amount of times said word appears as the "value". The information is later stored as a +Blob and used for NLP as well as the full word search which I wrote about earlier here: http://picolisp.com/5000/-2-I.html I mean of course I could have used (assoc) in theory but not practically. On Tue, Feb 22, 2011 at 4:22 AM, dexen deVries <dexen.devr...@gmail.com> wr= ote: > On Monday 21 of February 2011 21:54:17 you wrote: >> Hi Dexen & Jos=3DE9, >> >> >> Now if you access the array in a semi-random order, so-called `cache >> >> trashing' will ensue. Pretty much like reading random data from the >> >> harddrive (for example from swap). The CPU, starved of data, will >> >> idle uselessly. >> >> this is quite a low level detail and the effect on lists is the same. >> The PicoLisp lists live on the heap which is an array of cells in the C >> terms after all. =A0However, for lists this happens more often, dependin= g >> on how the list came into existence because the data will be quite >> likely spread over many different memory pages. > > I'm not much experienced in details, but I'd guess `yes and no' ;) > > A `naive' implementation of compiler would emit code that *just* operates= on > the data, and a`naive' CPU would *just* execute explicit instructions. > > However, modern CPUs have instructions for data pre-fetch & prefetching h= ints > (for explicit indication of prefetch) and a competent compiler can be exp= ected > to include such ones in proper places. Also, the CPU performs some analys= is of > all opcodes & is free to pre-fetch any data & code it considers likely to= be > used in future -- up to and including speculative execution of future > instructions. > > In the end, I'd guess walking a (linked) list can be more explicit indica= tor > for CPU to get the right data pre-fetched. > > But then again, that's just speculative fiction :) > > Greetz, > -- > dexen deVries > > ``One can't proceed from the informal to the formal by formal means.'' > -- > UNSUBSCRIBE: mailto:firstname.lastname@example.org?subject=3DUnsubscribe > -- UNSUBSCRIBE: mailto:email@example.com?subject=Unsubscribe