OT: Yet Another Unhappy Customer for Vista

On Jun 12, 6:15 am, krw wrote: [....]

Yes.

How does that work? Are multiple instruction streams (with different program counters) interleaved in the execution pipeline?

That makes my head hurt.

John

No, a term becomes accepted when the majority of practitioners agree on its meaning. "Multitasking" was a common term by the 1970's, long before multicore CPUs came along.

Did you fine a definition of "multitasking" in the Bible? Actuually, Wikipedia is almost as good:

Why in the world would anybody even think of writing an os that uses cooperative multitasking?

John

Geez, you really told me. BTW, I meant to put Jackoff a Shepard. Much funnier.

Jim

I didn't know Pascal programmers were TSR's, Jackoff a Shepard.

Intel has a cute little presentation on their website, but basically, if a stream is using the integer unit that leaves the floating point unit free to be used by another stream. If both program streams need the same execution unit, you are stuck with the same performance as a single thread core. The idea is to get more utilization of the entire CPU. SO, I guess you do kinda have interleaved streams in the pipe. I'm sure there are thousands of little transistors dedicated to just keeping track of the PC's and other assorted context registers for the interleaved streams.

Jim

Surely you meant millions!

I always thought that the ultimate processor would have, say, 256 cores, so every process could have its own cpu. No context switching overhead!

John

Well, a million is "only" a thousand thousand ;) I checked my performance indicator and I have 66 total processes running. That would leave me 190 cores free for other stuff. Sounds fun. When can I have one? I'm still waiting for bigger memory sticks to become available before I jump into one of the 64 bit flavors of Windoze.

Jim

Because it's simpler?

For an embedded system, I think cooperative multitasking can work just fine. For a general purpose computer (or as the complexity of an embedded system becomes large), a general purpose, pre-emptive multitasking OS is certainly the way to go.

(on hyperthreading's transistor utilization)

I doubt it. The whole point of hyperthreading is that is uses something like only 10% more transistors that *can* (when everything is set up just right) get you something *approaching* the utility of two full-fledged cores.

Yes, but the problem there is memory access. Even if you're willing to spend the money for decent-sized caches on all your CPUs, cache misses become

*really* painfully expensive when you have to arbitrate between 256 cores trying to access it. At that point, realistically you have to switch to a very style of programming (as done on, e.g., Connection Machines -- if you want to get decent performance out of the silicon.

Program counters? Who needs those?

It's actually very simple. The processor keeps track of two instruction streams. There is an A/B bit in the register files that indicates the stream executing, then let the renaming hardware figure out what threads belong to what resources. Since almost every register in a modern processor is renamed anyway, multi-threading almost comes out in the wash.

Multi-threading doesn't add much complication, once you look at the guts of a modern out-of-order processor.

--
  Keith

Yes, but I think they're stretching the truth here. They can only issue instructions from one stream each cycle, so just because an execution unit is free doesn't mean the other thread can use that slot.

--
  Keith

If "set up just right" == "degenerate case", maybe. I reality it buys less than 10% and in many cases, nothing. It may even have a negative effect. Intel's P4 version of HT isn't all that great.

NUMA solves many of these problems. AMDs K8 is a much system better architecture for MPs.

--
  Keith

Stretching? That is exactly what they imply.

Jim

Cheers, James Arthur

You mean, cooperative vs preemptive, right?

Thanks, Rich

for

That's funny. I bought my 13 year old son the game development kit from Parallax. He spends hours farting around with an old Toshiba laptop I had laying around running DOS. He loves to play the old DOS games and writing little programs using QBASIC. I thought he would enjoy hacking away on some different hardware.

Jim

Then, you get the I/O bottleneck. ;-)

Cheers! Rich

If instructions are being executed at the speed they pour out of L2 (or whatever) cache, the compute power indeed does not grow linearly with the number of cpu's. But the context switch overhead is still zero. And if each cpu has a small local cache of its own, it can run tight loops without impacting the others. The real point is that OS design would be a lot different.

Only one of the cpu's runs the actual OS, assigning tasks to other cpu's, and that's *all* it would do. A bunch more could be in charge of stuff like file systems, device drivers, ethernet ports, things like that. It could be crashproof.

John