Greetings! Great to hear. The new stuff as you see generates more garbage. Mostly in type manipulations, I thought in the compiler, but apparently not from your results. I had wanted to put in some sort of type hash consing at least when compiling. equal hashing is a no brainer, but I know you and Warren have experience with a more ambitions eq hash cons ensuring that every type form (in this case) is unique in the system. Any advice, suggestions or warnings most appreciated. I tried this once on subtypep itself, but sped up compiles at the expense of performance running Paul's subtypep tests for example.
Basically, we just need to hash type-and and type-or, each taking two arguments and returning one, that is eq to one of the arguments in the case that subtypep holds in the obvious direction, and is a substantive intersection or union otherwise. Should this be a one off, or should we have some standard memoization facility in the compiler? Also need to do the SSE et.al. gbc accelerations, which as you've shown can approach a factor of two, unbelievably as it may seem. The easiest way to do this is to depend on an external library which does optimized copying and selects an appropriate shared lib version at runtime depending on the running CPU, like blas/atlas. Perhaps newer libc already does this in memcpy/memmove. I do know that the newest ldconfig searches certain directories under /usr/lib preferentially depending on the capabilities of the running cpu. P.S. which if any of the following functions to you and the acl2 crowd use if any? I.e. any sequence (vector or list) objects as opposed to pure lists? P.P.S. If you post your full gprof output of anything that is performance critical to you, I'd be happy to take a look. There is a lot of information in there in the call frequencies and hierarchy. P.P.P.S. On equal -- as you can see the initial type check and branch-to-eq at the head of the list searches is basically always a win or insignificant. The way we have written equal and type_of, however, still makes (member x y :test 'equal) about 75% slower (on big lists where almost every equal result is false) than 2.6.6 when x is a character, for example, and twice as fast when x is a symbol, for example. As stated earlier, I think the big cause here is the new tyoe_of overhead. I hope this is not a problem, though if so there may be yet further things we can do. declarations or other type inferencing, btw, eliminate the type check and branch altogether. Take care, ============================================================================= 17.3 Sequences Dictionary ========================= * Menu: * sequence:: * copy-seq:: * elt:: * fill:: * make-sequence:: * subseq:: * map:: * map-into:: * reduce:: * count:: * length:: * reverse:: * sort:: * find:: * position:: * search:: * mismatch:: * replace:: * substitute:: * concatenate:: * merge:: * remove:: * remove-duplicates:: ============================================================================= Take care, Robert Boyer <[EMAIL PROTECTED]> writes: > Thanks for the equal-is-eq optimizer. 2.7.0 is now better than 2.6.6 by a > hair on the Nqthm-1992 tests. (all times on elgin.cs.utexas.edu). > > 2.6.6 > > run-gbc time : 2117.740 secs > child run time : 144.790 secs > gbc time : 102.050 secs > > 2364.58 > > 2.7.0 with equal-is-eq opt > > run-gbc time : 2003.040 secs > child run time : 156.230 secs > gbc time : 217.580 secs > > 2376.85 > > Thanks, > > Bob > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
