This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.
| Date: Wed, 29 Dec 2004 14:14:04 -0800 | From: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx> | | 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.