Author: Tom Kerrigan
Date: 10:23:24 05/27/03
Go up one level in this thread
On May 27, 2003 at 11:05:27, Robert Hyatt wrote: >>So how do you explain your statement that no OSs you've "tested" issue halts? I >>mean, Linux issues halts. Did you not "test" Linux? > >I'll leave that for _you_ to figure out. You can find an explanation >in the "scheduler idle loop" code. Suck it up, Bob, and admit you were wrong. It's painfully obvious that you're not contradicting me, just handwaving and backpedaling enough to give yourself a heart attack. "I fiddle with the source code" and "I'll leave that for you to find out." Yeah, right, Bob. Do you think that if you continue with this asinine behavior, everybody will get confused and just assume you're right? From LinuxHQ, "The Linux Information Headquarters," "Regardless, you should be aware that even if you don't enable any power management on your laptop, on the x86 architecture Linux will always issue the "hlt" instruction to your processor whenever nothing needs to be done. This results in lowering the power consumption of your CPU. Note that the system doesn't power down when it receives the hlt instruction; it just stops executing instructions until there is an interrupt." http://www.linuxhq.com/ldp/howto/mini/Battery-Powered/powermgm.html I can find a dozen other pages that say Linux issues halts at the drop of a hat. Just say the word and I'll make this even more embarrassing for you. (Although that's hard to imagine, isn't it?) >>>First, your statement is wrong. There have been reports that running a >>>single thread with SMT on runs slower than a single thread with SMT off. >>> >>>That was where this discussion started on RC5 in fact. >> >>Really... what post was that? Because I can only find posts saying that RC5 >>slows down with two threads, not one. > >It was not clear in the post I responded to. Which is why I specifically >asked "did this run one thread on a SMT-enabled cpu or did it run _two_ >threads?" That's great, Bob. "It was not clear"?? How can you begin to justify telling me I'm wrong when "it was not clear" how many threads were running? (And, BTW, it became clear that multiple threads were running.) >>>So I don't quite see what your point is unless it is to reinforce _my_ point >>>about SMT not slowing things down in any way I can see... Unless we talk about >>>the case of running two threads using two logical cpus being slower than running >>>one thread on one real cpu. I can see where _that_ could cause speed issues in >>>lots of ways, particularly with a parallel search. >> >>Hmm, that's interesting, because you couldn't understand that a few days ago. > >I've understood that from the beginning. Because I have reported that SMT >does _not_ run twice as fast except for a rare program here and there. Whoa, you're going to blow me down with the handwaving. Is your point that SMT might slow things down (towards the beginning of the quote) or that it's not twice as fast (end of quote). >>"Could it be slower in some? Of course. But then the algorithm(s) in question >>need work, obviously..." > >And that is certainly true... I can't believe you're saying this. Right from the quote above: "Unless we talk about the case of running two threads using two logical cpus being slower than running one thread on one real cpu. I can see where _that_ could cause speed issues in lots of ways, particularly with a parallel search." What did you mean by "a lot of ways" if the only possibility is algorithmic inefficiency? >>The "pipes," as you so eloquently call them, involve all the buffers that Intel >>says are split, and the memory read/write buffers are also split. The only thing >>that may be duplicated, instead of split, is the rename register file. And >>really, if you're talking about how balanced the processors are, duplicated >>might as well be the same as split. >> > >The "pipes" I am talking about are the "functional units" that actually do >integer and floating point operations. I don't see _any_ documentation that >suggests that they are evenly "split" between the logical cpus. Just because >they "involve" the buffers don't mean that they are split evenly... which >testing seems to verify. Ah, so after days of arguing, you finally come up with one single thing that might support your point. Execution units aren't considered part of the processor's resources by Intel, but if you want to talk about them, fine. "The memory instruction queue and general instruction queues send uops to the five scheduler queues as fast as they can, alternating between uops for the two logical processors every clock cycle, as needed." So the execution units are split 50-50 temporally. -Tom
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.