Waldek Hebisch <[EMAIL PROTECTED]> writes: | I did a little experiment testing heapsort algorithm with | various array implementations. I tried to use arrays of 32 bit | numbers -- such arrays should work faster than generic arrays and | also should use less memory. I defined a new domain 'U32Vctor' | which is similar to primitive array, but specialized to | 32-bit values. My first version used Lisp type 'array' and | default Spad/sbcl settings (in particular access was via function | calls). Then I turned on inlinig (adding U32Vctor to | $optimizableConstructorNames). Be biggest win come from | using 'simple-array' as Lisp type (instead of 'array'). I also | tried to declare indices as fixnum and declare type of | values in array assignment, but this gave me speed loss.
This matches any single Lisp benchmark report I've read so far in the literature and in the wild. You probably saw that in OpenAxiom I use newShell, declared to return SIMPLE-ARRAY (my boot translator automtically add the declaims), instead of using GETREFVEC. Those declamations, however, have effects only in Lisp systems like SBCL -- CLisp, for example, can't care much less, and GCL seems to be agnostic. I added the automatic declamation to help metpe annotate Boot codes -- I'm of the old school that thinks that, given a choice, I would rather catch errors earlier than later. Since I'm planning to throw away the Lisp runtime system in the future, I'm unsure how much time I should be spending on `speeding' up. -- Gaby ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel