Author: Robert Hyatt
Date: 13:11:27 05/27/03
Go up one level in this thread
On May 27, 2003 at 13:23:24, Tom Kerrigan wrote: >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.