Author: Tom Kerrigan
Date: 19:56:54 05/27/03
Go up one level in this thread
On May 27, 2003 at 16:39:08, Robert Hyatt wrote: >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?) > >Not embarassing for me at all. The point I referred to was that the >scheduler _first_ spins for a while, _then_ issues a halt. The "for a Right, well, you said it didn't issue halts. You can write a dozen posts about how exactly halts are issued but that doesn't change the fact that you were wrong. >>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.) > >It never was 'clear' to me, which is _why_ I asked the question. > >However, back to your "idea" about shared write-combine buffers. You claim Ha ha, sure, let's change the subject. No, wait, let's not. I want to see the post where it says single-thread RC5 slows down with HT enabled. You said that's what this thread is about, so where's the post, Bob? It should be easy to find, right? So where is it? Or are you going to blither on about how you weren't clear about something? (Well, that's pretty obvious.) >that if a single thread needs 5, then running two such threads will slow >such things down. I'm not sure I buy that. Because if you run _two_ threads >they need 10, and they get 8 combined. The two threads combined should run >_faster_ combined, than a single thread. I _still_ don't see any particularly >reasonable explanation for why two threads would run slower _combined_ than >one would run by itself. Even if one thread needs all 8 WC buffers, running >would mean each gets 1/2 of what it needs, and combined they should run at the >_same_ speed. If a program uses 4 WC buffers effectively and you limit it to 3, then your writes don't get combined effectively, so you issue more writes, which sucks up your cache bandwidth, which stalls your program. Really, what's not to get? >>Execution units aren't considered part of the processor's resources by Intel, >>but if you want to talk about them, fine. > >Then this becomes a "semantics argument". Because in the world of >computing, "execution units" are part of the CPU. The Cray has used this >design since the 1970's. We're talking about Intel here. Do you think you can bring yourself to use Intel's semantics? >>"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. > >except that _no_ application really drives a processor at 100% duty cycle. What does that have to do with anything? A program might not use all the reorder buffer entries. Does that mean you can't split the reorder buffer? -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.