[hashcash] Re: status of hashcash version 1?

  • From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
  • To: hashcash@xxxxxxxxxxxxx
  • Date: Tue, 3 Aug 2004 17:44:17 +0100

OK, I remembered I had an account on a newer alpha machine (EV6,
666MHz), which has gcc 3.2.

Yes, that looks a whole lot healthier. I think the newer GCC version has a lot to do with that - I heard 2.9x was pretty dire at RISC in general.

On the Debian package question, I suggest using something similar to -march=i586 -mcpu=athlon-xp - this will make a binary that will run on any i586 or better, while being mostly tuned for the Athlon. (For the RISC equivalent, try something like -mcpu=750 -mtune=970, which makes a G3-compatible binary that will be optimised for a G5 in 32-bit mode.)

The trick is to make a binary that will run on the 95th percentile of available machines, while being properly (or nearly properly) optimised for the majority. For best results, at least a cursory understanding of the pipeline and issue structure of the available processors in the family is highly desirable.

However, there's a tricky question with x86 and PPC machines, because there are carefully hand-optimised cores for most of the newer models - eg. the MMX cores will run on anything from a Pentium-MMX and K6 upwards (but not a Pentium Pro), and will almost certainly be the fastest cores available (at least until someone writes an SSE2 version). For that reason, there's no benefit in optimising this package for Pentium-4, because the MMX cores are the fastest anyway and aren't affected in the least, even though the scalar cores benefit noticeably on their own.

So, for an x86 package, I suggest providing a package that will run on an i486 but is optimised for Pentium Classic. The 486 can run Pentium-optimised code just about as fast as native 486-optimised code in most cases, but the Pentium needs more special treatment. Pentium Pros are now quite uncommon, and can probably run Pentium code reasonably well, so can safely be ignored for generic purposes - their users can recompile it themselves if they want to.

For a PPC package, optimise for 604e or 750, depending on your target OS - MacOS X won't run on a 604e, which is otherwise the most complex scalar-only PPC. The code will still be fairly optimal for other PPCs, because the PPC architecture and the Motorola processors' short pipelines are quite forgiving. Don't forget to enable Altivec at the compiler - the code will automatically determine whether it's present at runtime.

from:     Jonathan "Chromatix" Morton
mail:     chromi@xxxxxxxxxxxxxxxxxxxxx
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.

Other related posts: