From: Stas B. <sta...@gm...> - 2014-07-08 19:03:07
|
"Douglas Katzman" <sn...@us...> writes: > The branch "master" has been updated in SBCL: > via 956aa35502b93740679842bb38f50481777c0b08 (commit) > from 7354854c14241b7d8def7ab4953257e55f3c00f7 (commit) > > - Log ----------------------------------------------------------------- > commit 956aa35502b93740679842bb38f50481777c0b08 > Author: Douglas Katzman <do...@go...> > Date: Mon Jul 7 23:34:57 2014 -0400 > > Improve STRING= on x86[-64] by using memcmp() sometimes. > > Also the unequal length pre-test, like in STRING-EQUAL, was missing. > > This benchmarked twice as fast for strings of 20 characters in length > on two different pieces of hardware and approached 70x for huge strings. > > Hopefully it will not be ruined with Unicode normalization, which > presumably occurs on creation of strings, not in every call to string=. I really don't like calling foreign functions for lisp code like that. It's something that can't be controlled, there's no guarantee that it's actually faster on all supported OSes. The cut off point appears to be based on some particular implementation of memcmp. -- With best regards, Stas. |
From: James Y K. <fo...@fu...> - 2014-07-08 20:28:43
|
So what if some platforms *might* have a crappy memcmp? They should improve it, of course, it affects all other software as well... And if some platform *is* shown to have a 70x slower memcmp and anyone cares, change it for that platform, at that point? On July 8, 2014 3:02:56 PM EDT, Stas Boukarev <sta...@gm...> wrote: >"Douglas Katzman" <sn...@us...> writes: > >> The branch "master" has been updated in SBCL: >> via 956aa35502b93740679842bb38f50481777c0b08 (commit) >> from 7354854c14241b7d8def7ab4953257e55f3c00f7 (commit) >> >> - Log >----------------------------------------------------------------- >> commit 956aa35502b93740679842bb38f50481777c0b08 >> Author: Douglas Katzman <do...@go...> >> Date: Mon Jul 7 23:34:57 2014 -0400 >> >> Improve STRING= on x86[-64] by using memcmp() sometimes. >> >> Also the unequal length pre-test, like in STRING-EQUAL, was >missing. >> >> This benchmarked twice as fast for strings of 20 characters in >length >> on two different pieces of hardware and approached 70x for huge >strings. >> >> Hopefully it will not be ruined with Unicode normalization, which >> presumably occurs on creation of strings, not in every call to >string=. >I really don't like calling foreign functions for lisp code like that. >It's something that can't be controlled, there's no guarantee that it's >actually faster on all supported OSes. >The cut off point appears to be based on some particular implementation >of memcmp. > >-- >With best regards, Stas. > >------------------------------------------------------------------------------ >Open source business process management suite built on Java and Eclipse >Turn processes into business applications with Bonita BPM Community >Edition >Quickly connect people, data, and systems into organized workflows >Winner of BOSSIE, CODIE, OW2 and Gartner awards >http://p.sf.net/sfu/Bonitasoft >_______________________________________________ >Sbcl-commits mailing list >Sbc...@li... >https://lists.sourceforge.net/lists/listinfo/sbcl-commits -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |
From: Stas B. <sta...@gm...> - 2014-07-09 10:37:04
|
James Y Knight <fo...@fu...> writes: > So what if some platforms *might* have a crappy memcmp? They should improve it, of course, it affects all other software as well... > > And if some platform *is* shown to have a 70x slower memcmp and anyone cares, change it for that platform, at that point? It's 70 slower because the current string comparer is just that slow, simply dispatching on the string types will make it faster. Then there is SB-KERNEL:%VECTOR-RAW-BITS, which will benefit simple-base-string and x86-64. And that's still portable, and fast on small strings. And to catch up with memcmp on the larger ones, it's possible to write some SIMD code. -- With best regards, Stas. |
From: Douglas K. <do...@go...> - 2014-07-09 12:56:45
|
> > > And to catch up with memcmp on the larger ones, it's possible to write > some SIMD code. > > But why bother? The C library should be taking care of that. FD-STREAM-READ-N-BYTES uses 'memmove' (eventually). Would you rewrite it in pure Lisp also? By analogy, the Go runtime uses pseudo-abstractions 'xmemmove' and 'xmemcmp' which are nothing more than 'memmove' and 'memcmp' for all their platforms. |