![]() If the implementation uses a very high performance math-library FFT appropriately, then basically all Prime95 becomes is an excuse/justification for using that math-library FFT. FFTs are of course very SIMD optimizable. Prime95 is a very curious algorithm in that if you go and look at how it does what it does, it is doing FFTs. If your lappie can't run Cinebench "full tilt". The major advantage of Cinebench for our purposes is that it delivers a nice performance score, and people on the MacAch can't argue with its relevance. but actually its pretty far from the "hottest" real-world code. And the power virus will be something like that which squeezes in whatever extra useless instruction it can.Ĭinebench is a pretty well optimized FP code. but this is another story, nobody's talking Core2 here.įor any of these processors, maximum "real world" thermal stress (meaning an algorithm which really does some useful task, not a "power virus") will almost certainly be some pretty well optimized HPCish floating point code. depending).)Ĭore2 doubles the FP execution resources and gets back into the league with P4, G5, etc on peak resources per cycle. ![]() (All of the great benchmark scores Core1 turns in are ipso-facto demonstrations that the algorithm in question is very poorly optimized (and may or may not be intrinsically hard to optimize. But its also why the chip can be "cool." Core1's peak scalar floating point execution resources per cycle are on par with G4+, and less than one half of the G4+ peak vector resources per cycle. That's all P4 did but then P4 had/has almost double the Hz. It can only issue one per cycle to a 64bit-wide ALU. ![]() you are flogging a bazallion transistors.Ĭore1 has piss-poor peak execution resources for floating point and SSE compared to previous processors. So if you can keep that pipeline full (which well-optimized "HPC" codes can do or at least get close), and particularly if it is a vector-wide pipeline. Given the tremendous pressure to shorten the pipeline (for code which has serial dependencies) there's big pressure on the designers to use "hot" transistors and design techniques on critical paths, and they generally do. This is simply because floating point pipelines tend to be deep and have a lot of transistors at each stage and are generally fully pipelined. and if the microarch has a SIMD extension then commonly and rather obviously a very well optimized SIMD floating point algorithm. If you want to heat test essentially any modern CPU (ignoring very exotic ones like Niagara etc) what you find when you look at the execution resources is that worst-case thermal loads generally occur when doing very well optimized floating point. If you have a Core1Duo at 2 GHz this ought to be 575+ or you have a dud machine, if you have a 2.16 it should be 620 or greater. USE CINEBENCH It's the easiest way to get a good Multiprocessor intensive thermal test and the multiprocessor rendering score actually tells you what is getting done. You need a very CPU-intensive SSE-optimized (and well optimized task) to see what the system can sustain. * as far as workloads are concerned "100% cpu usages" are nothing like equal. Only if you bump a thread to really high priorities can you preempt these * unless the command itself resets its own thread priorities, you never get really full utilization of the CPUs because osX "guards" some at standard priorities to keep "glitz" tasks going on for the UI etc. The short answer is that there is no simple command you can enter from the terminal which will provide a good thermal-test workload for two really basic and ahem fucking obvious reasons: Will people please stop posting ignorant bullshit as though they "know it?" View image here: - View image here: - View image here:.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |