I just realized I said a nonsense in my previous post about those 16 threads (I've gotta sleep more). Sorry. 8 threads should be actually fine, since there are only 8 logical processors. Not sure whether increasing the # of threads beyond the # of logical CPUs improves error finding, but GFlops-wise it usually produces a bit lower results than with the number of threads equal to the number of logical CPUs (8 for an i7).
Now what you said about UAC is interesting. Will try to fix this, thanks a lot.
OT: I don't like AVs too. Haven't been using any for half a year now, still doing fine.
Yes, Linpack did take a performance hit back when i7s only entered the scene, but this was due to the fact that Linpack by default (I still don't get why Intel suggests this) runs in 4 threads on an i7 CPU, no matter HT on or off. While this is OK with HT off (4 cores, 4 threads), it is apparently not with it on (8 cores visible to Windows, but only 4 threads, causing perhaps a Windows thread manager to switch the threads between all 8 visible cores without regard to their nature, so that two threads may sometimes run on two logical processors from a single real core thus causing a performance hit). But then a way has been found to make it possible to override the number of threads Linpack creates and run it in 8 threads or even more on 8 logical cores on an i7.Originally Posted by jcool
I never had a chance to run Linpack on Core i7 but I did run it on an old P4 Prescott and on Atom 270. On P4 with HT on running Linpack in 2 threads vs 1 thread as Intel suggests was counter-productive indeed (only a tad but still), while on Atom it produced a nice boost in GFlops (like 0.51 vs 0.37 or something like that). So I figure HT of our days isn't as bad as it was back in P4 times. Correct me if I'm wrong.






Reply With Quote

Bookmarks