[hashcash] Re: Hashcash performance improvements
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Sun, 30 May 2004 18:52:39 +0100
btw it dumps core with -O3 -funroll-loops -march=pentium4 -mmmx before
outputting anything on P4.
Hmm. I suspect a bug in the cpuid test, which I've corrected just now
- the cpuid instruction clobbers several registers, which need to be
accounted for along with the actual result code.
I did a minor optimisation that might remove a data-dependency stall
between each round - it appears to be slightly faster on the Athlon,
but no change on the Pentium-MMX. I also updated the "MMX Compact"
routine to use optimised assembly in the right places. The latter is
still a little slower than the MMX Standard routine on both my PCs, so
I've moved it out of the "preferred" position in the list.
These updates are attached.
3515196 AMD64/x86 MMX Standard 1x2-pipe
1432117 AMD64/x86 MMX Compact 1x2-pipe *
The P4 likes the mmx assembler!
Indeed it does. It's still not quite as fast per-clock as my Athlon,
but it obviously does respond well to code optimisation.
I think what we're seeing here is the Athlon having a preponderance of
decode and scheduling logic, when compared to it's back-end execution
resources. This is a tradeoff that makes a lot of sense, given that
the x86 ISA has an unusually small amount of instruction-level
parallelism available, as a direct result of the tiny register file.
The Athlon-64 keeps a similar decode engine (though expanded for the
AMD64 support), but optimises the execution units to be more efficient.
The P4 has higher back-end throughput from it's deep pipelines and high
clock, but it pays for the high clock with a far less flexible decode
engine. That's why the P4 works so well with SIMD instructions, which
have few instructions (taking up less decode bandwidth) compared with
the amount of work to do. Based on this insight, we can extrapolate
that if SSE2 has a similar range of integer instructions to MMX, we
might see as much as twice the performance over MMX - assuming it
doesn't run out of back-end resources first.
The G4 also has this kind of property, since the RISC design allows an
exceptionally simple decode unit to have high throughput, but most of
it's execution resources are dedicated to the Altivec engine, and are
completely unavailable to scalar programs. Both the P4 and Athlon use
the normal scalar execution units for most SIMD work, so they have less
peak throughput per clock, but have more available to scalar programs.
I think the G5 is a bit more balanced than the G4. It has a heavier
decode engine, despite the RISC background, which allows it to
effectively address more scalar units. The Altivec engine in the G5 is
relatively weak, though it still offers a throughput advantage over the
scalar units. However, I don't have one to hand, so I can't tell you
how fast it does hashcash. =)
btw I was thinking it would be useful to have a selection of hardware
with linux shell accounts for people who are working on this.
Don't OSDL, or people like them, have a facility for that?
--------------------------------------------------------------
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:
