For anyone curious, I just ran a couple benchmarks on my new D610 (P-M 760 2.0GHz, 1024 DDR2, 80GB HDD 5400RPM); both were done under Linux (kernel 2.6.10 recompiled with gcc 3.4.2 and processor type set as pentium-m).
First off: John the Ripper 1.6.37
I compiled it with CFLAGS = -c -Wall -O3 -fomit-frame-pointer -march=pentium-m -msse -msse2
[root@stewie src]# make linux-x86-mmx-elf
[root@stewie src]# cd ../run
[root@stewie src]# john -test > results-x2
root@stewie run]# cat results-x2
Benchmarking: Traditional DES [64/64 BS MMX]... DONE
Many salts: 585868 c/s real, 587042 c/s virtual
Only one salt: 651980 c/s real, 651980 c/s virtual
Benchmarking: BSDI DES (x725) [64/64 BS MMX]... DONE
Many salts: 24820 c/s real, 24870 c/s virtual
Only one salt: 24499 c/s real, 24499 c/s virtual
Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw: 5019 c/s real, 5019 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 337 c/s real, 338 c/s virtual
Benchmarking: Kerberos AFS DES [48/64 4K MMX]... DONE
Short: 273817 c/s real, 273817 c/s virtual
Long: 788787 c/s real, 788787 c/s virtual
Benchmarking: NT LM DES [64/64 BS MMX]... DONE
Raw: 4641472 c/s real, 4650773 c/s virtual
For a basis of comparison to desktop CPU's check out anandtech's recent article on pentium-m blades. Note: anandtech was using a blade server with the older pentium-m (755, I used the 760.
The second benchmark I did was some Xvid4 transcoding (DVD to Xvid, for my XBox) using dvd::rip as my front end and an RPM'ed version of transcode (transcode-0.6.14-1.1.fc3.rf). The video was NTSC (23.976 FPS), and encoded at 47.4 FPS in phase 1 and 27.3 FPS (better than real time!) in phase 2. The audio was passed through and the video bitrate was 1438kbps. I was not performing any cropping or interlace filtering. I don't know of a site which does this comparison, but from my experience transcoding on a P4 2.8E, phase 1 time is reasonable, but phase 2 is great. I would have even better performance if I compiled transcode myself (but let me assure you it's a hassle). Another thing to note is you could probably get even better performance if you use Intel's compiler instead of GCC, but again it may be more work than what it's worth.
First off: John the Ripper 1.6.37
I compiled it with CFLAGS = -c -Wall -O3 -fomit-frame-pointer -march=pentium-m -msse -msse2
[root@stewie src]# make linux-x86-mmx-elf
[root@stewie src]# cd ../run
[root@stewie src]# john -test > results-x2
root@stewie run]# cat results-x2
Benchmarking: Traditional DES [64/64 BS MMX]... DONE
Many salts: 585868 c/s real, 587042 c/s virtual
Only one salt: 651980 c/s real, 651980 c/s virtual
Benchmarking: BSDI DES (x725) [64/64 BS MMX]... DONE
Many salts: 24820 c/s real, 24870 c/s virtual
Only one salt: 24499 c/s real, 24499 c/s virtual
Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw: 5019 c/s real, 5019 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 337 c/s real, 338 c/s virtual
Benchmarking: Kerberos AFS DES [48/64 4K MMX]... DONE
Short: 273817 c/s real, 273817 c/s virtual
Long: 788787 c/s real, 788787 c/s virtual
Benchmarking: NT LM DES [64/64 BS MMX]... DONE
Raw: 4641472 c/s real, 4650773 c/s virtual
For a basis of comparison to desktop CPU's check out anandtech's recent article on pentium-m blades. Note: anandtech was using a blade server with the older pentium-m (755, I used the 760.
The second benchmark I did was some Xvid4 transcoding (DVD to Xvid, for my XBox) using dvd::rip as my front end and an RPM'ed version of transcode (transcode-0.6.14-1.1.fc3.rf). The video was NTSC (23.976 FPS), and encoded at 47.4 FPS in phase 1 and 27.3 FPS (better than real time!) in phase 2. The audio was passed through and the video bitrate was 1438kbps. I was not performing any cropping or interlace filtering. I don't know of a site which does this comparison, but from my experience transcoding on a P4 2.8E, phase 1 time is reasonable, but phase 2 is great. I would have even better performance if I compiled transcode myself (but let me assure you it's a hassle). Another thing to note is you could probably get even better performance if you use Intel's compiler instead of GCC, but again it may be more work than what it's worth.
