dfox wrote on Sun, Jul 07, 2002 at 10:53:12AM -0700 : > Well, looking at the burnK7 (or other portions of cpuburn) I was > very skeptical as to how it could really stress the system, as it > ks just a couple of floating point instructions in an endless > loop. But from others' input, it seems to peg the cpu temperature > meter pretty high, higher than i would think for such a piece of > software. The loop is too short to not fit in cache (or probably > the instruction pipeline itself -- that depends on the size, I'm not > sure) and depending on CPU timing issues and stalls (usually affecting > older Pentiums) it might not exercise the processor as much as is > desireable.
To me this means that it *will* exercise the processor. Don't forget about cache speed. L1 cache is much faster than L2 (external) cpu cache. If the entire program fits inside cache and never has to insert the wait states for external cache to reply, it can run faster, which should be roughly equivalent to more heat generation (ie flipping state generates xxx microcalories of heat, flipping state more often generates more heat). The second option that you mentioned I had not even considered. That it can fit inside the pipeline means it should be able to run even faster (and parallelization means even more heat generation). But I would expect it to be designed such that no pipeline ever finishes before the previous one. They can all finish staged in the same ordered they started, but not out of order. And it also seems like you would want the program to be larger than the size of the pipelines so that you never have idle states waiting for the result. Interesting thoughts, I like your line of thinking. Blue skies... Todd -- Todd Lyons -- MandrakeSoft, Inc. http://www.mandrakesoft.com/ UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn Cooker Version mandrake-release-8.3-0.2mdk Kernel 2.4.18-21mdk
msg56124/pgp00000.pgp
Description: PGP signature
