Warp wrote:
>   In the good old days the CPU and the RAM had the same speed. In other
> words, the RAM controller could supply the CPU with data at the exact
> speed at which the CPU could read it. This made both the CPU and the
> RAM controllers very simple and straightforward to implement.
> 
>   Then at some point CPU speeds started growing faster than RAM speeds.
> At some points it got so ridiculous that the CPU could theoretically
> read hundreds of times faster than the RAM controller could feed it.
> Of course since basically everything the CPU can do is in RAM (including
> the very code the CPU is trying to execute), something had to be done,
> or else the CPU would simply be idle most of the time while waiting for
> the data to arrive from RAM.

On the PrimeGrid distributed computing project, the LLR app (to test if a
number is prime) is a *lot* heavier on the CPU than the sieve app (finding
lots of composite numbers to filter them out so LLR doesn't have to test
them). Users report hotter CPUs when running LLR.

And indeed, sieve uses quite a bit more memory. I guess LLR can fit most of
its data in the CPU cache, making the CPU process more and wait less, and
making it heat more.

Post a reply to this message