It might be the HZ value (I'm not at my alpha now, so I can't chek what
OSF/1 uses), but I suspect it's simply a library issue. I don't think
caches should matter _that_ much for dhrystone (I think it should fit
even in a 256kB cache), but I seem to remember dhrystone being very
sensitive to the performance of such library routines as "strcpy()". So
assuming the OSF/1 library is much more optimized for things like that
(and I'm willing to bet it is), the two-fold increase in performance
isn't totally unlikely.
I'm in Santa Cruz right now, and the line is very slow, so I don't want
to try to find any linux libc.a or dhrystone sources. But if the linux
libc.a does the straightforward but stupid implementation of strcpy(),
you'll easily see a _huge_ difference to a handcrafted assembly version
that does the copy and zero-compare 8 bytes at a time.
(similar comments hold for strcmp/memcmp etc: strlen and memcpy should
be reasonably optimized already)
Linus