| Date: Wed, 29 Dec 2004 14:14:04 -0800
 | From: "Bradd W. Szonye" <xxxxxx@szonye.com>
 |
 | Bear wrote:
 | >> Many recent RISC processors have no 8-bit operations.  Some in
 | >> the fairly near future will probably also lack 16-bit
 | >> operations.  It would be far more efficient for these systems to
 | >> allocate 16 bits where an 'au8' is requested;
 |
 | Aubrey Jaffer wrote:
 | > No, it won't.  Modern CPUs are almost always (I/O-bound or)
 | > limited by their memory bandwidth through the cache.  If you
 | > double or quadruple the data movement necessary, you will execute
 | > at half or quarter the speed.
 |
 | That depends on your data access patterns and cache sizes.  If your
 | working set still fits in L1 cache after aligning the data, you get
 | better performance, and some of the big servers on the market now
 | have huge amounts of L1 cache.

The largest I found was 32.kiB inst + 64.kiB data on Suns
<http://www.sun.com/servers/family-comp.html>.
A stripped down SCM interpreter is 40.kB, but even if the interpreter
fit, it would be getting swapped out to bring in SUBRs.  64.kiB would
be a much better fit.

 | In some architectures, byte-aligned access may even be more
 | expensive than L2 cache.

That sounds like a poorly designed CPU.

 | However, still a good practical argument against word-aligning byte
 | arrays.  Text strings are the main application for byte arrays.  If
 | you're worried about the performance of byte strings, and you have
 | a big enough, fast enough cache, you could word-align the
 | characters.  But why do that when you could use a text encoding
 | /designed/ for word alignment?

Disk-based b-trees, used extensively for database indexes, are an
important example of byte-intensive algorithms not tied to text
strings.  Other examples are cryptography and data-compression.