Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news1.optus.net.au!optus!spool01.syd.optusnet.com.au!spool.optusnet.com.au!not-for-mail
Sender: a...@gondolin.local.net
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp wish list item
References: <3238779012022126@naggum.no> <ey3znvh2n70.fsf@cley.com> <47kilcd2l.fsf@beta.franz.com>
From: Alain Picard <apicard+die-spammer-...@optushome.com.au>
Date: 21 Aug 2002 19:30:33 +1000
Message-ID: <86fzx87e4m.fsf@gondolin.local.net>
Organization: Picard's Enterprise
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 30
NNTP-Posting-Host: 210.49.13.124
X-Trace: 1029922277  28866 210.49.13.124


I recently had the fun (!) of discovering how hard it can
be to really optimize CL code while implementing BLOWFISH.
What an eye opener!

Duane Rettig <du...@franz.com> writes:

> But what happens then when the "naturally 32 bit" algorithms start
> becoming "naturally 64 bit"?

Which they will --- Bruce Schneier states that making blowfish run
fast on "typical 32 bit hardware"(*) was an _explicit_ design goal.
So we'll be back to square one.

For the record, the CMUCL hacks (to unbox 32bit modulo adds and xors)
make blowfish run 120 times faster than the bignum calls in Lispworks 4.2.

Even then, I'm surely missing something basic, because Schneier says
blowfish should run at 8 Mb/s on a 150Mhz pentium (18 clock
cycles/byte), and mine runs at 3 Mb/s on a 433Mhz Celeron.

I've read that in Lisp you can write slow code fast, and then
have to work for the speed.  I didn't realize just _how_ _hard_,
however.  :-)


(*) Interestingly, Schneier conjectures that blowfish is _probably_ strong
    using 16 bit blocks (which _would_ fit into fixnums of essentially
    all current lisps).  I ran out of enthusiasm and didn't write that
    code to benchmark it.