Kein-Hong Man wrote:
Robert Roessler wrote:
Neil Hodgson wrote:
Robert Roessler:
...
[snip snip snip]
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!
This is a bug waiting to happen on any app that wants to be portable.
Rip it out. Write clear code.
And yes, I also abhor the algorithm's apparent complexity - I just
like what it does. ;)
So Hsieh's code uses unaligned 16-bit accesses? Leaving out all the
levels of caching, an unaligned access (i.e. 16-bit or bigger memory
access with an odd address) always ends up causing two memory accesses
on modern x86 processors. If it straddles a cache line, big ouch. If
both bytes are not in the caches, this causes two cache lines (2 x 16
bytes or more) to be fetched.
Sorry, typed too fast. Whether there is one or two memory fetches
depends on the cache design and the memory design. A 32-bit fetch
with an odd address on a 80386 for instance, will cause two memory
access. Other cases depends on a lot of things. But my point is
that, it is not appropriate to do it anymore for many situations,
and I personally wouldn't want this in a module where extreme
levels of performance is not needed.
Such optimizations has no place in modern code, at least, in an app such
as Scintilla or SciTE. If you understand modern microprocessor
architecture, you will understand that many old-style optimizations are
not worth putting in an app where high-quality code is important.
HTH,
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest
