Author: Tom Kerrigan
Date: 23:49:32 05/27/03
Go up one level in this thread
On May 28, 2003 at 00:23:55, Robert Hyatt wrote: >On May 27, 2003 at 22:56:54, Tom Kerrigan wrote: > >>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. > >You stopped reading _too soon_. The post right below this one was pretty >clear in saying that the kernel I am running is _not_ issuing halts at all, Well, whoop-dee-frickin-doo. You never said that YOUR OS didn't issue halts. You said that no OS you knew of (except for possibly Windows Server 2003) issues halts. Anybody who's concerned themselves in the least about power consumption or CPU temperatures knows that pretty much every OS except for Win95 and Win98 issues halts. For example, the Athlon goes into a low power mode when it's halted and a certain motherboard setting is set. The motherboard setting is usually not set by default, but "CPU Coolers" for the Athlon do set it. When I run a CPU cooler, my CPU temperature drops from ~130 degrees to nearly room temperature when I'm doing anything besides, say, running my chess program or playing a video game. That means the CPU is almost ALWAYS halted in Windows. All the interrupts generated by casual computer use aren't enough to warm the processor up more than a few degrees. Programs like Waterfall and CpuIdle for Win95 and Win98 cause those OSs to issue halts when idle and improve laptop battery life dramatically. Why aren't the programs intended for other OSs? Oh, gee, because other OSs already issue halts. I also remember using Linux, years and years ago, and every time I booted, it would say "Checking for hlt." What would it use that instruction for, if not halting when idle? So I've known for YEARS that OSs issue halts. Now let's go back to some things you've said on the subject: "That makes _zero_ sense. Define "idle"? Typically, in any O/S I know of, all processors are _always_ executing an instruction stream." "I know a _lot_ about what I am talking about. Do you know what a "processor" does when there is no process ready to schedule? Didn't think so." "And again, so what? Who does a "halt"? Windows .net server _might_. But no others I have tested..." And more recently: "Not embarassing for me at all. The point I referred to was that the scheduler _first_ spins for a while, _then_ issues a halt." How do you explain yourself now, Bob? >>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.) > >It's pretty clear what I was talking about. My _first_ post specifically >asked the question about "what was being measured? a single thread, or two >threads.?" It was _very_ specific. Who cares what your first post said? You said the thread is about single thread RC5. So show me THAT post. "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." Show me the post, Bob. >>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? > >The _other_ thread. the _other_ thread. What is _it_ doing? It is taking >advantage of those "stalled cycles"... So it isn't a total loss... Maybe it takes advantage of some, but it also needs the cache, and that bandwidth is being sucked up by the first thread. And if the 2nd thread is ALSO thrashing its WC buffers, then cache bandwidth is decreased even more. This is NOT hard to understand. >>We're talking about Intel here. Do you think you can bring yourself to use >>Intel's semantics? > >I believe I am. I can't imagine anyone saying "execution units are not a >part of the processors set of core resources." > >Makes no sense to me. Look, Intel obviously uses "resources" as an abbreviation for "out of order execution resources," which typically means instruction window entires and reorder buffer entries, among other things. Haven't you read any papers on this? The fact remains that it's taken you a week to finally mutter that the execution units aren't "split." Fine, you can make a case for that. What's pissing me off is the week of drivel and condescention you've been spouting in an effort to make it sound like you're some kind of expert and always knew what you were talking about... hmmm, here's a quote from one of your earlier posts: "If Eugene is right, and I don't know as he was not sure and I haven't read anything similar to what he mentioned, that _could_ explain it (ie if some resources are split 50-50 between the two logical processors even if one could use more than the other due to the particular application being run. However that seems like a _bad_ design decision if it is true...) However there are probably other plausible explanations as well. What is the _real_ explanation? That will likely take some time to figure out." -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.