Thomas Koenig wrote:
> Paul A. Clayton <paaronclayton@gmail.com> schrieb:
>
>> I think case 2 presents some potential for architectural
>> innovation. Microarchitecturally, indexes and pointers could be
>> cached using a kind of lossy cache block compression that retains
>> the timing critical data. This would reduce the storage overhead
>> and allow more pointers to be cached, but the tag overhead would
>> be significant — particularly for a 32- or even 16-bit index. It
>> seems plausible that software could help reduce the overheads.
>>
>> (Cache compression seems desirable and lossy compression may be
>> reasonable even if no criticality information is used. If one has
>> storage for a tag and some spare storage in a chunk due to
>> compression of other cache blocks, even keeping the first bytes of
>> a cache block might be worthwhile.)
>
> I don't get what you are getting at. "Lossy compression" means that
> information is not retained during the compression/decompression
> step. If you apply that to a cache, you will get wrong results.
> Or do you mean something else?

Lossy in the sense that data which was present in a cache block is
dropped from the cache block while still retained in outer
storage. This is similar to compressing with byte-valid
indicators. The data decompresses to not-valid not to arbitrary
values. (There may be an existing term for this.)

The information is not retained in that level of caching but the
metadata of what information is valid is retained. A trivial
example would be a contiguous data chunk starting at the beginning
of the cache block, when the decompressed stream ends, the cache
block valid data ends.

[snip]
> Grouping data that is used together for better cache access
> is a good idea, see the "array of structs" vs. "struct of
> arrays", depending on the data use.
>
> Not something that a compiler can easily do for a language
> like C or Fortran, ABIs are likely to break.

Yes, sigh.