Re: GETF Speedup?
"Tim Bradshaw (as tfb at cley dot com)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
Yes, my inner loop does (when <lookup fn> (incf hits)) and then returns hits as a second value. I figure a compiler smart enough to work out that, say, the lookup will always fail or succeed is so smart that it is not usefully possible to benchmark it. That conditional and increment costs time but it's the same overhead for each version as the code is closely the same. --tim > On 13 Oct 2025, at 15:02, Martin Simmons <[email protected]> wrote: > > This code might not be timing what you think it is. > > If you call GETHASH or GETF without using the result, then the compiler can > throw that call away. LispWorks is doing that for GETF, but not for GETHASH. > I suspect SBCL is doing it for both of them. That means you are just timing > DOLIST! > > You need to setq some variable to the result of the call. Even then, a > sufficiently smart compiler might be able to remove all but the last call. > > -- > Martin Simmons > LispWorks Ltd > http://www.lispworks.com/ > > > >>>>>> On Sat, 11 Oct 2025 07:07:42 -0700, David McClain (as dbm at refined-audiometrics dot com) said: >> >> Here’s the source code for the simple minded test. >> >> SBCL 2.5.9 performs better than LWM on the tests, and does especially well on the Red-Black Tree data structures (the MAPS). Just leave out the MAPS clauses to test against Hashtable and Property lists alone. >> >> #F is just Comer’s reader macro for (OPTIMIZE (SPEED 3) (SAFETY 0) (FLOAT 0)). >> >> I have my Lispworks and SBCL both accepting embedded #\_ in numbers, for improved readability. Advice patches can be made available. >> >> >> >> (defun tst (&key (nel 20) (niter 1_000_000)) >> #F >> (let* ((keys (loop repeat nel collect >> #+:LISPWORKS (lw:mt-random (* 5 nel)) >> #-:LISPWORKS (random (* 5 nel)) >> )) >> (vals (loop repeat nel collect >> #+:LISPWORKS (lw:mt-random 1000) >> #-:LISPWORKS (random 1000) >> )) >> (queries (loop repeat niter collect >> #+:LISPWORKS (lw:mt-random (* 5 nel)) >> #-:LISPWORKS (random (* 5 nel)) >> )) >> (ht (make-hash-table)) >> (lst (mapcan 'list keys vals)) >> (map (maps:empty))) >> (loop for key in keys >> for val in vals >> do >> (setf (gethash key ht) val) >> (maps:addf map key val)) >> >> ;; -------------------------------------------- >> ;; HT - minor amount of allocation, no page faults, no GC, 20 ms >> (print "Timing HT") >> (time (dolist (query queries) >> (gethash query ht))) >> >> ;; -------------------------------------------- >> ;; LST - no allocation, no page faults, no GC, 3 ms >> (print "Timing Lst") >> (time (dolist (query queries) >> (getf lst query))) >> >> ;; -------------------------------------------- >> ;; MAP - lots of allocation, 38 page faults, no GC, 2449 ms. >> (print "Timing Map") >> (time (dolist (query queries) >> (maps:find map query))) >> )) >> >> (tst :nel 1000) >> >> >>>> On Oct 11, 2025, at 04:41, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote: >>> >>> >>> >>>> On 11 Oct 2025, at 04:27, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote: >>>> >>>> I am delighted that GETF is so efficient now. It really needs to be, given functions with keyword argument lists. >>> >>> Hm. Would you be able to share the test code? I wonder how that could be done given that lists have to be traversed sequentially to find the value. If anything, that could be saying that hash tables are not as fast as they probably should be, which is not good since a package symbol lookup is essentially a hash table search, as I understand it. >>> >>> Also, did you happen to profile assoc lists while at that to see how they compare to plists? >>> >>> _______________________________________________ >>> Lisp Hug - the mailing list for LispWorks users >>> [email protected] >>> http://www.lispworks.com/support/lisp-hug.html >> >> > > _______________________________________________ > Lisp Hug - the mailing list for LispWorks users > [email protected] > http://www.lispworks.com/support/lisp-hug.html _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html