Quote Originally Posted by some_one View Post

Gautam, I don't know why there are so may low GFlops. What if you try with less memory, maybe using "all" hits the OSes resources too much. Even running 4GHz and a problem size of 6000 should hopefully give some results in the 60GFlops range with 12 threads and only take a few seconds to do 3 runs. Might also be worth checking the taskmanager to see if the CPU is being fully utilized.
I don't know enough about Linpack to be sure, but I think it could be due to the earlier libraries, but then again it seems like those don't have such a big impact either. I can say I've never seen gflops anywhere past 50 ever, but I've never turned HT off either. We all have our standards, and for me disabling HT is the closest thing to "cheating" (j/k) My chip was a junker with IMC/uncore though, but I recall pushing memory even into the 2100 range along with a ~3.8ghz uncore and still never achieved anywhere close to 50. Of course, no one else had either, so I thought nothing of it. You might have a point with the memory utilization, however, it seemed to be tradition in this thread to have the "all" button checked off...not only that, doing so is certainly more stressful. It doesn't sit well with me for lower memory utilization and HT being disabled in the name of higher GFLOPS. Regardless of the GFLOPS, enabling HT and increasing memory usage increase stress on the processor, and significantly at that. While I haven't looked into any of this at any depth, I can make a generalization and say that higher performance != higher utilization/stress. It's fairly likely that the GFLOPS being lowered by HT being enabled is due to their being so much contention between the additional threads that the overall performance just goes down. The CPU still is being taxed more heavily though, that's the nature of HT. But being taxed more doesn't necessarily mean more performance.

P.S. grats to all new members/entries to the club