![]() ![]() 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?" Has anyone else noticed this behaviour? I can verify that this machine and at least 1 other have displayed this behaviour with Coreduotemp.ĭoes anyone know what it could be, and any possible workarounds? I've tried installing Speedit v0.5 instead of the v0.32 that is included in the Coreduotemp installer, but v0.5 caused some serious system instability.- View image here: - View image here: - View image here:. The only times that it will update properly that I've noticed so far have been:ġ) When Coreduotemp is already running, the program will start updating OK after waking up from sleepĢ) It will update fine the first time you run it after installing it But if I then restart the machine and run it again, the temperature that is displayed at first stays constant (or flickers between 2 temperatures neither of which ever changes) even when running MemtestOSX or the "yes >/dev/null" command, which of course must be raising the CPU temperature markedly. So basically, I've noticed on this and last couple machines I had (before they died) that Coreduotemp works fine when it's run straight after a fresh install, and also after waking from sleep, but other than those times, the temperature readout doesn't update.įor example - I install Coreduotemp and run it, then I run MemtestOSX or the "yes >/dev/null" command and the temperature increases accordingly. It's technically the 6th machine I've had in my possession, since my Mac store lent me one while this machine was being built, but who's counting anyway. I'm on my 5th Macbook, since my first 4 were all duds. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |