[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #\a octothorpe syntax vs SRFI 10
| 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
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.