From: Nathan F. <fr...@cs...> - 2005-04-02 18:01:30
|
On Sat, Apr 02, 2005 at 06:08:51PM +0100, Christophe Rhodes wrote: > > Performance of this scenario should be much improved under SBCL > > 0.8.21.5; quick benchmarks showed that the new optimized REPLACE is > > nearly an order of magnitude faster than the standard REPLACE on > > (unsigned-byte 8) vectors. (Of course, you need to declare your > > array types for this optimization to kick in.) > > There's something that's possibly slightly wrong here. Andreas' > benchmarks (at <http://sbcl.boinkor.net/bench/>) show a net slowdown > in the BENCH-STRINGS and STRING-CONCAT benchmarks. I don't know why > that is; I do remember that string output streams are sensitive to > REPLACE performance. Is it possible that there's some needless bounds > checking going on in some inner loop in your new implementation? The %VECTOR-RAW-BITS vops don't (AFAIK) introduce bounds checking like the DATA-VECTOR-REF vops would. The one change that might have caused this is that the body of UBFOO-BASH-COPY is now compiled at (SAFETY 1). Previously, BIT-BASH-COPY's body was compiled at (SAFETY 0). When I was testing my standalone code, SBCL was compiling the (SAFETY 1) code with nary a type or bounds check. And comments in BIT-BASH-COPY and friends made me think that it might be more prudent to use (SAFETY 1). But it's possible the cross-compiler might have inserted some checking code that's slowing things down--I have not closely examined the generated code. Can't see anything else that might be responsible for the change... -- Nathan | From Man's effeminate slackness it begins. --Paradise Lost The last good thing written in C was Franz Schubert's Symphony Number 9. --Erwin Dieterich |