Neil Hodgson wrote:
Robert Roessler:
...
1) is line-count a good determinant in evaluating hash algos?
2) source code size/layout may not be a good indicator of the length
of runtime code paths
Complexity for the code reader should be avoided. My reaction to the
Hsieh code was:
1) What's this preprocessor stuff? Is it alignment trickery?
Not really "alignment" in the sense of processor architectures - it
just facilitates the processing of 2 16-bit chunks per cycle of the
main loop without blowing past the end.
3) Is it reading past the end due to the blocking?
No - see above.
4) I hope those typedefs aren't duplicating stuff from system headers
leading to warnings when this is combined with other code.
The typedefs are sort of a convenience in bringing over the code with
minimal molestation - clearly we can rewrite without them. OTOH, they
are "confined" scope-wise to the PropSet class.
After a while you can work the issues out but its not immediately
obvious. Extra complexity can be justified by performance and it would
be much more convincing if there was a measurement of either an overall
performance improvement (PropSet::Get 20% faster by changing hash
function) or something less direct (fewer empty buckets or shorter
chains on the distributed properties files or someone's particularly
large configuration).
Instrumentation per se is easy - but it adds more to the perceived
complexity of the code, and subtracts from its readability.
But a potential show-stopper anyway is that, since you want Scintilla
to compile across the widest possible set of architectures, Hsieh's
code as it stands will fail on non-x86 CPUs where aligned memory
accesses are *required*. Or at least I *think* unaligned 16-bit
accesses are as evil as unaligned 32-bit access on these arches - if
16-bit accesses are even allowed in these cases!
And yes, I also abhor the algorithm's apparent complexity - I just
like what it does. ;)
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest
