On Fri, Mar 23, 2018 at 7:40 PM, Ray Dillinger <bear AT sonic.net
> On 03/23/2018 06:05 PM, Henry Baker wrote:
>> Great idea.
>> Let's see how well it works in practise.
>> # stuff finally shows up at yyyyy in the cache at this point in time
>> # I just received this $$$ box from Amazon that I ordered 5 months ago.
>> # I can't remember what I was doing at the time, or why I ordered it.
>> # Well, gotta go now, so throw it in the trash or give it away.
> You're being facetious of course. Compilers don't need to "remember"
> what they were doing and why they asked for data to be precached; like
> every other instruction, pre-caching instructions are generated in the
> first place from the actions and reasons.
> But obviously you know that. So you must be making a joke but I don't
> know what you're making a joke about.
> Determining when to undertake these actions is not too hard for the
> logic overhead expressed in silicon which presently runs during the code
> execution. Moving that overhead to the compiler doesn't make it more
> complex than it already is.
Doing this bakes in details of what execution units are available and their latencies into the generated machine code. This is acceptable for specialized DSP designs, but not acceptable for CPUs where a wide range of CPUs should all get good performance on a wide amount of precompiled software. Most software has a small number of live variables in each basic block and unpredictable branching: speculative execution is necessary to access parallelism.
> The cryptography mailing list
> cryptography AT metzdowd.com
"Man is born free, but everywhere he is in chains".