>>169
interesting. can i get the code you used somewhere?

i just did some benchmarking again too, not using the sodomized 4brute as framework, but the "speeds.c" that comes with ufc. runs the crypt() for 10sec cpu time, reports number of done cycles. no saltchanges at all. it has defines for ufc and libc, i added a ossl variant.
Results from my trusty Duron900 (64kB cache):

• 37956.700000 crypt(libc)s per second.
• 49705.200000 fcrypt(UFC)s per second.
• 71742.300000 DES_fcrypt(ossl)s per second.

code here: http://4dist.yi.org/misc/ufc-crypt/
the speeds.c and Makefile are modified to add ossl.

this agrees with the numbers i had for 4brute using different backends.
perhaps i am using somethings that calls itself ufc, but really is outdated, wrong, or so?
from patchlevel.h: "UFC-crypt, patchlevel 1c, @(#)patchlevel.h 1.9 03/02/92"

from the README (most people reading this probably dont know any of those except the 386. ;):

• Tested on 680x0, 386, SPARC, MIPS, HP-PA, Convex, Cray, Pyramid and IBM RS/6000 systems as well as with gcc on IBM PS/2(DOS) and Linux on a 386 PC.

but, the README contains also a possible reason for the sucky performance i am seeing:

• Requires 165 kb for tables.

165 > 64. uh-oh.
let me guess, the Penti-M has 1MB cache?
goes to find something with bigger cache to rerun benches