Sign in with
Sign up | Sign in
Your question

The end of Netburst in 2006

Last response: in CPUs
Share
Anonymous
a b à CPUs
May 12, 2005 1:28:25 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

X-bit labs - Hardware news - Intel Confirms New CPU Architecture to
Launch in Late 2006.
http://www.xbitlabs.com/news/cpu/display/20050512111032...

One interesting thing they mentioned is that they're going to attempt
to retain Hyperthreading even with the new less-pipelined core.
Hyperthreading is easy on a highly-pipelined core like with the Pentium
4, which has a lot of idle slots in its pipeline to fit two threads. In
a shallow pipelined architecture, with fewer idle slots, fitting a
second thread in there would probably end up making one thread or the
other, or both slower. The only way around it is to actually do proper
Symettrical MultiThreading (SMT), and install more execution units for
each thread. The difference between SMT and Hyperthreading is like the
difference between a Concorde and a jumbojet -- they both achieve the
same thing, but go about it in different ways. SMT is also much more
difficult to design than not only Hyperthreading, but also more
difficult than multicores.

It would be interesting to know if they're just going to try to graft
simple HT onto the new core with any additional execution units, for a
cheap marketing stunt, despite the fact that it might slow down
applications badly. Or if they're going to do true SMT and just call it
HT to keep people from being confused.

Yousuf Khan

More about : end netburst 2006

Anonymous
a b à CPUs
May 26, 2005 6:59:02 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

YKhan wrote:
> X-bit labs - Hardware news - Intel Confirms New CPU Architecture to
> Launch in Late 2006.
> http://www.xbitlabs.com/news/cpu/display/20050512111032...
>
> One interesting thing they mentioned is that they're going to attempt
> to retain Hyperthreading even with the new less-pipelined core.
> Hyperthreading is easy on a highly-pipelined core like with the Pentium
> 4, which has a lot of idle slots in its pipeline to fit two threads. In
> a shallow pipelined architecture, with fewer idle slots, fitting a
> second thread in there would probably end up making one thread or the
> other, or both slower. The only way around it is to actually do proper
> Symettrical MultiThreading (SMT), and install more execution units for
> each thread. The difference between SMT and Hyperthreading is like the
> difference between a Concorde and a jumbojet -- they both achieve the
> same thing, but go about it in different ways. SMT is also much more
> difficult to design than not only Hyperthreading, but also more
> difficult than multicores.
>
> It would be interesting to know if they're just going to try to graft
> simple HT onto the new core with any additional execution units, for a
> cheap marketing stunt, despite the fact that it might slow down
> applications badly. Or if they're going to do true SMT and just call it
> HT to keep people from being confused.

I think what you are calling SMT is really multicore. The whole benefit
of HT is that it uses idle execution units with the addition of minimal
complexity, and by the time you add a lot of execution units it becomes
simpler to have individual cores with shared cache. Feel free to clarify
if you're not looking for that level of added Xunits.

What you said about pipeline length is correct, but there may be ways
around it. Consider as an example some sort of system where there are
several pipelines, one per thread, and an execution unit traffic control
which offers all available execution units to one thread, get zero or
more micro-ops started and then offers any remaining units to another
thread. Clearly this could slow a thread at some point in the future,
but would allow better use of all Xunits, and probably more work done by
the CPU overall. No matter how you add CPU Xunits, they compete for
cache and eventually total memory bandwidth.

I note that as the Linux HT scheduler has gotten better the CPU time has
stayed the same but the clock time has dropped for some benchmarks.

--
bill davidsen (davidsen@darkstar.prodigy.com)
SBC/Prodigy Yorktown Heights NY data center
Project Leader, USENET news
http://newsgroups.news.prodigy.com
Anonymous
a b à CPUs
June 9, 2005 8:52:49 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

> In your dreams, perhaps. But that's not how processors work. Execution
> units can be kept busy even bound to a single thread. There is no
> requirement, nor reason, to dedicate execution units to a thread. To do
> so is simply silly, when a single thread may be able to use them more
> effectively.

You totally lost me here. You said (a) Xunits can be kept busy when
bound to a single thread, then (b) there's no reason to do that, then
(c) a single thread can use them more effectively.

>>Not only does the CPU do more work, but it actually can use HT to make
>>less work (fewer context switches) needed. That shows up as less cache
>>misses as well. More work done, less work needed, better cache
>>performance. Not a waste in my book!
>
>
> You must be an Intel marketeer. Screw SMT and go SMP, if you must.

What does marketing have to do with it? HT makes programs run faster ON
than OFF. Any arguments that it can't are suspect.


--
bill davidsen (davidsen@darkstar.prodigy.com)
SBC/Prodigy Yorktown Heights NY data center
Project Leader, USENET news
http://newsgroups.news.prodigy.com
Related resources
Anonymous
a b à CPUs
June 9, 2005 2:16:01 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Thu, 09 Jun 2005 04:52:49 GMT, Bill Davidsen
<davidsen@darkstar.prodigy.com> wrote:

>>>Not only does the CPU do more work, but it actually can use HT to make
>>>less work (fewer context switches) needed. That shows up as less cache
>>>misses as well. More work done, less work needed, better cache
>>>performance. Not a waste in my book!
>>
>>
>> You must be an Intel marketeer. Screw SMT and go SMP, if you must.
>
>What does marketing have to do with it? HT makes programs run faster ON
>than OFF. Any arguments that it can't are suspect.

It's also pretty obvious that in some, not so rare, task mixes HT can make
all tasks/threads run slower... i.e. longer time to complete than if run
consecutively. I'd hesitate to use it for any situation where I had a
compute bound task.

--
Rgds, George Macdonald
Anonymous
a b à CPUs
June 9, 2005 6:59:24 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

I'd rather think that HT will slow down for L1-cache bound tasks. You
effectively have half of each cache and half of uOP cache for each thread.

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
news:9obga1dmsvok9fl9f6b9bc2cfot6hucf8u@4ax.com...
> On Thu, 09 Jun 2005 04:52:49 GMT, Bill Davidsen
> <davidsen@darkstar.prodigy.com> wrote:
>
>>>>Not only does the CPU do more work, but it actually can use HT to make
>>>>less work (fewer context switches) needed. That shows up as less cache
>>>>misses as well. More work done, less work needed, better cache
>>>>performance. Not a waste in my book!
>>>
>>>
>>> You must be an Intel marketeer. Screw SMT and go SMP, if you must.
>>
>>What does marketing have to do with it? HT makes programs run faster ON
>>than OFF. Any arguments that it can't are suspect.
>
> It's also pretty obvious that in some, not so rare, task mixes HT can make
> all tasks/threads run slower... i.e. longer time to complete than if run
> consecutively. I'd hesitate to use it for any situation where I had a
> compute bound task.
>
> --
> Rgds, George Macdonald
June 10, 2005 1:31:26 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Thu, 09 Jun 2005 04:52:49 +0000, Bill Davidsen wrote:

>
>
>> In your dreams, perhaps. But that's not how processors work. Execution
>> units can be kept busy even bound to a single thread. There is no
>> requirement, nor reason, to dedicate execution units to a thread. To do
>> so is simply silly, when a single thread may be able to use them more
>> effectively.
>
> You totally lost me here. You said (a) Xunits can be kept busy when
> bound to a single thread, then (b) there's no reason to do that, then
> (c) a single thread can use them more effectively.

You obviously don't read very well.

A) You stated that execution units were only necessary for multiple
threads. False. A single thread can use multiple execution units in a
super-scalar processor. An OoO processor has more opportunity to find
parallelism in a single thread. Multiple execution units came long before
multi-threaded processors (well, ignoring the 360/91).

B) THere is *every* reason to have multiple execution units for a single
threaded processor (see: A).

C) Since there is no reason that multiple threads are necessary to keep
many execution units busy, this is *not* a reason for multi-threaded
processors. In fact multiple threads (at least as Intel does things)
isn't much of a gain at all and often a negative.

--
Keith


>
>>
>> You must be an Intel marketeer. Screw SMT and go SMP, if you must.
>
> What does marketing have to do with it? HT makes programs run faster ON
> than OFF. Any arguments that it can't are suspect.

Because Intel's HT is a marketing gimmick that you've obvioulsy fallen
for. ...and you're spreading the FUD.

--
Keith
Anonymous
a b à CPUs
June 10, 2005 1:31:27 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"keith" <krw@att.bizzzz> wrote in message
news:p an.2005.06.10.01.31.25.341612@att.bizzzz...

> A) You stated that execution units were only necessary for multiple
> threads. False. A single thread can use multiple execution units in a
> super-scalar processor. An OoO processor has more opportunity to find
> parallelism in a single thread. Multiple execution units came long before
> multi-threaded processors (well, ignoring the 360/91).

Correct.

> B) THere is *every* reason to have multiple execution units for a single
> threaded processor (see: A).

Correct.

> C) Since there is no reason that multiple threads are necessary to keep
> many execution units busy, this is *not* a reason for multi-threaded
> processors.

Wrong. The general form of your argument is wrong and it's wrong in this
particular situation as well.

The flaw in the general form of your argument can easily be seen if you
try the argument on other things. For example, you don't need to brush your
teeth daily to have healthy teeth. You could, for example, go to a dental
hygienist daily. It does not, however, follow that having healthy teeth is
not a reason to brush daily.

It's wrong in this particular case because one of the main benefits of
multi-threaded processors is that execution units that would otherwise lie
idle can do useful work. The more parallelism you can exploit, the greater
percentage of your execution units you can keep busy. Multi-threaded
processors give the processor more parallelism to exploit.

> In fact multiple threads (at least as Intel does things) isn't much of a
> gain at all and often a > negative.

Actually, in my experience is has been a *huge* benefit on machines that
only have a single physical CPU. Not as useful on machines that have
multiple CPUs already.

DS
Anonymous
a b à CPUs
June 10, 2005 12:54:38 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Thu, 09 Jun 2005 14:59:24 GMT, "Alexander Grigoriev"
<alegr@earthlink.net> wrote:

>I'd rather think that HT will slow down for L1-cache bound tasks. You
>effectively have half of each cache and half of uOP cache for each thread.

Yup and the TLB, which is a *big* part of CPU performance is going to get
soiled.

>"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
>news:9obga1dmsvok9fl9f6b9bc2cfot6hucf8u@4ax.com...
>> On Thu, 09 Jun 2005 04:52:49 GMT, Bill Davidsen
>> <davidsen@darkstar.prodigy.com> wrote:
>>
>>>>>Not only does the CPU do more work, but it actually can use HT to make
>>>>>less work (fewer context switches) needed. That shows up as less cache
>>>>>misses as well. More work done, less work needed, better cache
>>>>>performance. Not a waste in my book!
>>>>
>>>>
>>>> You must be an Intel marketeer. Screw SMT and go SMP, if you must.
>>>
>>>What does marketing have to do with it? HT makes programs run faster ON
>>>than OFF. Any arguments that it can't are suspect.
>>
>> It's also pretty obvious that in some, not so rare, task mixes HT can make
>> all tasks/threads run slower... i.e. longer time to complete than if run
>> consecutively. I'd hesitate to use it for any situation where I had a
>> compute bound task.

--
Rgds, George Macdonald
Anonymous
a b à CPUs
June 10, 2005 7:55:50 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Tony Hill wrote:

> Now, obviously I'll take dual-core over SMT any day, but by it's very
> nature dual-core involves doubling the transistors.

Not if part of the cache hierarchy is shared between cores,
e.g. Intel's Yonah.

By the way, you often write "it's" instead of its ;-)
Anonymous
a b à CPUs
June 10, 2005 10:50:43 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

keith wrote:
> On Thu, 09 Jun 2005 04:52:49 +0000, Bill Davidsen wrote:
>
>
>>
>>>In your dreams, perhaps. But that's not how processors work. Execution
>>>units can be kept busy even bound to a single thread. There is no
>>>requirement, nor reason, to dedicate execution units to a thread. To do
>>>so is simply silly, when a single thread may be able to use them more
>>>effectively.
>>
>>You totally lost me here. You said (a) Xunits can be kept busy when
>>bound to a single thread, then (b) there's no reason to do that, then
>>(c) a single thread can use them more effectively.
>
>
> You obviously don't read very well.

Given that zero of the things you reply to below are in the test you
quoted, or in the original article, I don't think the problem is mine.
>
> A) You stated that execution units were only necessary for multiple
> threads. False. A single thread can use multiple execution units in a
> super-scalar processor. An OoO processor has more opportunity to find
> parallelism in a single thread. Multiple execution units came long before
> multi-threaded processors (well, ignoring the 360/91).
>
> B) THere is *every* reason to have multiple execution units for a single
> threaded processor (see: A).
>
> C) Since there is no reason that multiple threads are necessary to keep
> many execution units busy, this is *not* a reason for multi-threaded
> processors. In fact multiple threads (at least as Intel does things)
> isn't much of a gain at all and often a negative.
>



>Because Intel's HT is a marketing gimmick that you've obvioulsy fallen
>for. ...and you're spreading the FUD.

I ran real benchmarks, for large compiles, DNS servers, and NNTP
servers. The compiles ran in 10-30% less clock time, the max tps of the
servers went up 10-15%. That's not FUD that's FACT.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com
Anonymous
a b à CPUs
June 10, 2005 10:58:52 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

David Schwartz wrote:
> "keith" <krw@att.bizzzz> wrote in message
> news:p an.2005.06.10.01.31.25.341612@att.bizzzz...
>
>
>>A) You stated that execution units were only necessary for multiple
>>threads. False. A single thread can use multiple execution units in a
>>super-scalar processor. An OoO processor has more opportunity to find
>>parallelism in a single thread. Multiple execution units came long before
>>multi-threaded processors (well, ignoring the 360/91).
>
>
> Correct.

I assume you mean he's correct in his technical statement, and not that
you agree I ever said any such thing...
>
>
>>B) THere is *every* reason to have multiple execution units for a single
>>threaded processor (see: A).
>
>
> Correct.
>
>
>>C) Since there is no reason that multiple threads are necessary to keep
>>many execution units busy, this is *not* a reason for multi-threaded
>>processors.
>
>
> Wrong. The general form of your argument is wrong and it's wrong in this
> particular situation as well.
>
> The flaw in the general form of your argument can easily be seen if you
> try the argument on other things. For example, you don't need to brush your
> teeth daily to have healthy teeth. You could, for example, go to a dental
> hygienist daily. It does not, however, follow that having healthy teeth is
> not a reason to brush daily.
>
> It's wrong in this particular case because one of the main benefits of
> multi-threaded processors is that execution units that would otherwise lie
> idle can do useful work. The more parallelism you can exploit, the greater
> percentage of your execution units you can keep busy. Multi-threaded
> processors give the processor more parallelism to exploit.
>
>
>>In fact multiple threads (at least as Intel does things) isn't much of a
>>gain at all and often a > negative.
>
>
> Actually, in my experience is has been a *huge* benefit on machines that
> only have a single physical CPU. Not as useful on machines that have
> multiple CPUs already.

Thank you, I'm not sure I've seen *huge* gains, but 10-30% for free is a
nice bonus. I've never seen a negative on real work, although there was
a benchmark showing that. Gain appear larger on threaded applications
than general use, probably because of more shared code and data in cache.

The real gain I see is when multiple threads exchange data via shared
memory. With one CPU there are constant context switches between the
producer and consumer threads. With SMT the number of CTX goes down,
which means that the CPU not only does more work in unit time, but that
the work to be done is reduced. User CPU percentage goes up, CTX rate
goes down, system time goes down. Win-win-win!

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com
June 11, 2005 2:21:24 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Thu, 09 Jun 2005 20:19:00 -0700, David Schwartz wrote:

>
> "keith" <krw@att.bizzzz> wrote in message
> news:p an.2005.06.10.01.31.25.341612@att.bizzzz...
>
>> A) You stated that execution units were only necessary for multiple
>> threads. False. A single thread can use multiple execution units in a
>> super-scalar processor. An OoO processor has more opportunity to find
>> parallelism in a single thread. Multiple execution units came long before
>> multi-threaded processors (well, ignoring the 360/91).
>
> Correct.
>
>> B) THere is *every* reason to have multiple execution units for a single
>> threaded processor (see: A).
>
> Correct.
>
>> C) Since there is no reason that multiple threads are necessary to keep
>> many execution units busy, this is *not* a reason for multi-threaded
>> processors.
>
> Wrong. The general form of your argument is wrong and it's wrong in this
> particular situation as well.

Nope. I'm now rather more confident that you haven't a clue.

<how you wash you hog deleted>

> It's wrong in this particular case because one of the main benefits of
> multi-threaded processors is that execution units that would otherwise lie
> idle can do useful work. The more parallelism you can exploit, the greater
> percentage of your execution units you can keep busy. Multi-threaded
> processors give the processor more parallelism to exploit.

That is *not* the point. Modern processors are more limited in dispatch
and completion slots than they are in execution units (e.g. the developers
don't kow how many FP instructions you're going to run togethr). As long
as a single thread can dispatch the processor will be full. Another thread
is *ONLY* useful if the pipe stalls. Even then, it's only useful to
restart another thread if your caches aren't trashed. Another thread can
muck up the works in any number of ways other than the caches.

>> In fact multiple threads (at least as Intel does things) isn't
much of
>> a gain at all and often a > negative.
>
> Actually, in my experience is has been a *huge* benefit on machines
> that
> only have a single physical CPU. Not as useful on machines that have
> multiple CPUs already.

Your workload is quite unique then. No one else, other than Intel's
marketing department, has found such workload.

--
Keith
Anonymous
a b à CPUs
June 11, 2005 2:21:25 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"keith" <krw@att.bizzzz> wrote in message
news:p an.2005.06.11.02.21.23.761332@att.bizzzz...

> On Thu, 09 Jun 2005 20:19:00 -0700, David Schwartz wrote:

>> Wrong. The general form of your argument is wrong and it's wrong in
>> this
>> particular situation as well.

> Nope. I'm now rather more confident that you haven't a clue.

Always good to throw in a few insults while someone's trying to reason
with you. Your mother dresses you funny.

>> It's wrong in this particular case because one of the main benefits
>> of
>> multi-threaded processors is that execution units that would otherwise
>> lie
>> idle can do useful work. The more parallelism you can exploit, the
>> greater
>> percentage of your execution units you can keep busy. Multi-threaded
>> processors give the processor more parallelism to exploit.

> That is *not* the point. Modern processors are more limited in dispatch
> and completion slots than they are in execution units (e.g. the developers
> don't kow how many FP instructions you're going to run togethr). As long
> as a single thread can dispatch the processor will be full. Another thread
> is *ONLY* useful if the pipe stalls. Even then, it's only useful to
> restart another thread if your caches aren't trashed. Another thread can
> muck up the works in any number of ways other than the caches.

This doesn't sound like anything even remotely resembling a reasonable
argument. It is a fact that a single thread is just not going to keep all
the execution units busy. Another thread could use those execution units.

>>> In fact multiple threads (at least as Intel does things) isn't
>>> much of
>>> a gain at all and often a > negative.

>> Actually, in my experience is has been a *huge* benefit on machines
>> that
>> only have a single physical CPU. Not as useful on machines that have
>> multiple CPUs already.

> Your workload is quite unique then. No one else, other than Intel's
> marketing department, has found such workload.

Here's a trivial example -- one program goes into a 100% CPU spin. With
HT, the system stays responsive (because the program can, at most, grab half
the CPU resources). Without it, it doesn't. Now you think a program that has
to do a lot of work while I'd prefer the system remain responsive is
unique?!

DS
June 11, 2005 2:22:50 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 10 Jun 2005 19:39:43 -0700, David Schwartz wrote:

>
> "keith" <krw@att.bizzzz> wrote in message
> news:p an.2005.06.11.02.21.23.761332@att.bizzzz...
>
>> On Thu, 09 Jun 2005 20:19:00 -0700, David Schwartz wrote:
>
>>> Wrong. The general form of your argument is wrong and it's wrong in
>>> this
>>> particular situation as well.
>
>> Nope. I'm now rather more confident that you haven't a clue.
>
> Always good to throw in a few insults while someone's trying to reason
> with you.

Hmm, I didn't see much "reason".

> Your mother dresses you funny.

s/mother/wife

I went on my way 34 years ago.

>>> It's wrong in this particular case because one of the main benefits
>>> of
>>> multi-threaded processors is that execution units that would otherwise
>>> lie
>>> idle can do useful work. The more parallelism you can exploit, the
>>> greater
>>> percentage of your execution units you can keep busy. Multi-threaded
>>> processors give the processor more parallelism to exploit.
>
>> That is *not* the point. Modern processors are more limited in dispatch
>> and completion slots than they are in execution units (e.g. the developers
>> don't kow how many FP instructions you're going to run togethr). As long
>> as a single thread can dispatch the processor will be full. Another thread
>> is *ONLY* useful if the pipe stalls. Even then, it's only useful to
>> restart another thread if your caches aren't trashed. Another thread can
>> muck up the works in any number of ways other than the caches.
>
> This doesn't sound like anything even remotely resembling a reasonable
> argument. It is a fact that a single thread is just not going to keep all
> the execution units busy. Another thread could use those execution units.

All the execution units won't be busy because there aren't enough
issue/completion slots to fill all units. Another thread doesn't increase
the number of I/C slots. A single thread can easily fill the slots
available.

The argument for a second thread isn't execution units, rather OoO,
speculative execution, long pipes, and slow memory, thus expensive
flushes. Adding a thread adds more speculative execution and resourse
thrashing for *perhaps* a chance of utilizing the pipeline when one thread
flushes. If it's done right it even works. Apparently Intel has an
"issue" with their implementation. It's not a clear win like you folks
believe it to be.

>>>> In fact multiple threads (at least as Intel does things) isn't much
>>>> of
>>>> a gain at all and often a > negative.
>
>>> Actually, in my experience is has been a *huge* benefit on
>>> machines that
>>> only have a single physical CPU. Not as useful on machines that have
>>> multiple CPUs already.
>
>> Your workload is quite unique then. No one else, other than Intel's
>> marketing department, has found such workload.
>
> Here's a trivial example -- one program goes into a 100% CPU spin.
> With
> HT, the system stays responsive (because the program can, at most, grab
> half the CPU resources). Without it, it doesn't. Now you think a program
> that has to do a lot of work while I'd prefer the system remain
> responsive is unique?!

Like all trivial examples and hand-waving...

This is perhaps a good argument for SMP, but SMT will likely still
choke because the thread that's "spinning" isn't likely flushing the pipe,
since the pre-fetching/branch prediction is trying it's best to keep the
pipe full. Of course for any implementation it's possible to come up with
a degenerative case. As noted elsewhere in this thread a "spinning thread"
can trash the L1, perhaps even L2, causing SMT make things even worse.
Indeed, this is shown in several benchmarks.

Sometimes (Intel's implementation of) SMT is a win, sometimes a loss.
It's not at all clear whether it's worth it, but in any case it has
*nothing* to do with filling execution units (the OP's argument).
Multiple issue/completion slots will fill execution units from a single
thread.

--
Keith
Anonymous
a b à CPUs
June 11, 2005 3:05:40 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 10 Jun 2005 15:55:50 +0200, Grumble <devnull@kma.eu.org>
wrote:

>Tony Hill wrote:
>
>> Now, obviously I'll take dual-core over SMT any day, but by it's very
>> nature dual-core involves doubling the transistors.
>
>Not if part of the cache hierarchy is shared between cores,
>e.g. Intel's Yonah.

Perhaps I should have specified that you're doubling the transistors
in the core at the very least and possibly doubling cache transistors
as well.

>By the way, you often write "it's" instead of its ;-)

Yeah, I do it mainly to piss of Keith who has commented on this more
than once! :> (actually I'm just lazy and never did learn me that
grammar stuff none too good!)

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
June 11, 2005 4:42:33 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Robert Redelmeier wrote:
>
> AFAIK, the only case where SMT is a win is when a thread
> stalls like waiting for uncached data, IO or frequent branch
> misprediction. Otherwise it is a loss because of lower cache
> hits (caches split). Some apps, like relational databases
> are pointer chasing exercises and need a lot of uncached data.
> I think compilers suffer a lot of misprediction.
>

It's amazing that this topic just won't die. The only thing that's new
about, say, Pentium-M and HT is that Pentium-M's shorter pipeline makes
hyperthreading less valuable than on NetBurst, where it is already
marginal in the sense that it seems to cost just about the same
increase in power and transistors as you get in increased performance.
If you had no other way of jamming more throughput onto the die and you
could swallow the hit in power, HT is almost always a clear win. If
you include the cost in power or transistors, it's almost always a
wash.

The biggest win I remember (about 35% IIRC) seeing for HT was on a
chess playing program, where I assume the win came from stalled
pointer-chasing threads. Server applications, which also typically
spend significant (~50%) time stalled for memory, should benefit
significantly, as well.

HT may, in practice, do little more than to reduce the hit that Intel
takes in latency from having the memory controller off the die, but it
does do that (up to whatever effect cache-trashing has in the other
direction).

HT does give Intel marketeers a feature that AMD doesn't have to talk
about. The fact that AMD doesn't have nearly the need for SMT because
memory latency is lower and the pipeline is shorter isn't something
you'd really expect Intel to emphasize in its advertising. The way HT
is used in Intel advertising is just market babble. As a part of the
design philosophy of Intel microprocessors, HT actually does make
sense.

RM
Anonymous
a b à CPUs
June 11, 2005 10:52:17 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips keith <krw@att.bizzzz> wrote:
> All the execution units won't be busy because there
> aren't enough issue/completion slots to fill all units.
> Another thread doesn't increase the number of I/C slots.
> A single thread can easily fill the slots available.

Very true, especially on a CPU like the iP7 (Pentium4)
that has lots of execution units, but very few issue ports.

AFAIK, the only case where SMT is a win is when a thread
stalls like waiting for uncached data, IO or frequent branch
misprediction. Otherwise it is a loss because of lower cache
hits (caches split). Some apps, like relational databases
are pointer chasing exercises and need a lot of uncached data.
I think compilers suffer a lot of misprediction.

-- Robert
June 12, 2005 1:35:20 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Sat, 11 Jun 2005 18:52:17 +0000, Robert Redelmeier wrote:

> In comp.sys.ibm.pc.hardware.chips keith <krw@att.bizzzz> wrote:
>> All the execution units won't be busy because there
>> aren't enough issue/completion slots to fill all units.
>> Another thread doesn't increase the number of I/C slots.
>> A single thread can easily fill the slots available.
>
> Very true, especially on a CPU like the iP7 (Pentium4)
> that has lots of execution units, but very few issue ports.

IIRC, the P4 can only issue from the same thread, which reduces the
benefit of INTC's version of SMT.

> AFAIK, the only case where SMT is a win is when a thread stalls like
> waiting for uncached data, IO or frequent branch misprediction.

I thought I said that. ;-) It has *nothing* to do, as the OP proposed,
with execution units.

> Otherwise it is a loss because of lower cache hits (caches split). Some
> apps, like relational databases are pointer chasing exercises and need a
> lot of uncached data. I think compilers suffer a lot of misprediction.

....particularly with the miniscule P4 I-Cache.

--
Keith
Anonymous
a b à CPUs
June 12, 2005 7:17:28 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Bill Davidsen" <davidsen@deathstar.prodigy.com> wrote in message
news:Mplqe.7544$_A5.24@newssvr19.news.prodigy.com...

> David Schwartz wrote:

>> "keith" <krw@att.bizzzz> wrote in message
>> news:p an.2005.06.10.01.31.25.341612@att.bizzzz...

>>>A) You stated that execution units were only necessary for multiple
>>>threads. False. A single thread can use multiple execution units in a
>>>super-scalar processor. An OoO processor has more opportunity to find
>>>parallelism in a single thread. Multiple execution units came long
>>>before
>>>multi-threaded processors (well, ignoring the 360/91).

>> Correct.

> I assume you mean he's correct in his technical statement, and not that
> you agree I ever said any such thing...

Yes.

> Thank you, I'm not sure I've seen *huge* gains, but 10-30% for free is a
> nice bonus. I've never seen a negative on real work, although there was a
> benchmark showing that. Gain appear larger on threaded applications than
> general use, probably because of more shared code and data in cache.

The huge gains are not measurable but are in terms of usability and
interactive responsiveness. Benchmark gains do tend to be modest.

I think a lot of the usability gains are due to design problems with the
hardware and software. On a single CPU system without HT, for example, an
interrupt that takes too long to service makes the system non-responsive and
frustrates the user. On a system with either multiple CPUs or HT, the system
remains responsive.

DS
June 13, 2005 6:09:16 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Sat, 28 May 2005 01:01:32 -0400, Tony Hill
<hilla_nospam_20@yahoo.ca> wrote:

>I think you're kind of hitting the nail on the head with the second
>option. My understanding is that SMT added only a very small number
>of transistors to the core (the numbers I've heard floated around are
>5-10%, though I have no firm quote and I'm not sure if that's for
>Northwood or Prescott). With IBM's Power5, where the performance
>boost from SMT is much larger, I understand that they were looking at
>a 25% increase in the transistor count.
>
>That actually brings up a rather interesting point though. At some
>point SMT may become counter-productive vs. multi-core. In the case
>of the Power5, if you need to increase you're transistor count by 25%
>per core for SMT, you only need 4 cores before you've got a enough
>extra transistors for another full-fledged core. That of course leads
>to the question, are you better off with 4 cores with SMT or 5 cores
>without? My money is on 5 cores without.
>
....snip...
>
>-------------
>Tony Hill
>hilla <underscore> 20 <at> yahoo <dot> ca

Now a question: why we didn't see the dual cores many years
earlier? The main (OK, in overly simplistic view) difference between
486 and P5(AKA Pentium) was the second integer pipeline. While I
don't have the transistor count per pipeline in P5 and proportion of
it to the total count, I may suppose (just hypothetically) that making
a dual core of 486-style single pipeline (minus branch prediction
logic, plus extra FPU for second core) would not be much more
complicated than a single core P5, using the same logic as above.
Besides, 486 was even easier to crank up the clock - when Pentium was
around 100 (or 120 - too ancient history to remember exactly) AMD had
its 586 (486 with bigger L1 cache) at 133, easily overclockable to 160
- did it myself. So why nobody back then jumped to make dual cores?
My answer - no software to take advantage of it, at least on
consumer level. Win95 had nothing in it to take advantage of SMP.
Ditto Quake 1 ;-). And in corporate world, it was more than a year
before the introduction of NT4 that might (or might not) have been
benefitted.
Any other answers?
Just another 'what if' speculation with no practical meaning...
June 13, 2005 6:09:17 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Mon, 13 Jun 2005 02:09:16 +0000, nobody@nowhere.net wrote:

> On Sat, 28 May 2005 01:01:32 -0400, Tony Hill
> <hilla_nospam_20@yahoo.ca> wrote:
>
>>I think you're kind of hitting the nail on the head with the second
>>option. My understanding is that SMT added only a very small number
>>of transistors to the core (the numbers I've heard floated around are
>>5-10%, though I have no firm quote and I'm not sure if that's for
>>Northwood or Prescott). With IBM's Power5, where the performance
>>boost from SMT is much larger, I understand that they were looking at
>>a 25% increase in the transistor count.
>>
>>That actually brings up a rather interesting point though. At some
>>point SMT may become counter-productive vs. multi-core. In the case
>>of the Power5, if you need to increase you're transistor count by 25%
>>per core for SMT, you only need 4 cores before you've got a enough
>>extra transistors for another full-fledged core. That of course leads
>>to the question, are you better off with 4 cores with SMT or 5 cores
>>without? My money is on 5 cores without.
>>
> ...snip...
>>
>>-------------
>>Tony Hill
>>hilla <underscore> 20 <at> yahoo <dot> ca
>
> Now a question: why we didn't see the dual cores many years
> earlier?

There is a simple answer to that. There were other, better, things to
do with transistors.

> The main (OK, in overly simplistic view) difference between
> 486 and P5(AKA Pentium) was the second integer pipeline.

I think there was a tad more than that, but...

> While I
> don't have the transistor count per pipeline in P5 and proportion of
> it to the total count, I may suppose (just hypothetically) that making
> a dual core of 486-style single pipeline (minus branch prediction
> logic, plus extra FPU for second core) would not be much more
> complicated than a single core P5, using the same logic as above.
> Besides, 486 was even easier to crank up the clock - when Pentium was
> around 100 (or 120 - too ancient history to remember exactly) AMD had
> its 586 (486 with bigger L1 cache) at 133, easily overclockable to 160
> - did it myself. So why nobody back then jumped to make dual cores?
> My answer - no software to take advantage of it, at least on
> consumer level. Win95 had nothing in it to take advantage of SMP.
> Ditto Quake 1 ;-). And in corporate world, it was more than a year
> before the introduction of NT4 that might (or might not) have been
> benefitted.
> Any other answers?

Yes! Caches were a better use of transistors.

> Just another 'what if' speculation with no practical meaning...

What if the Earth were flat sorta thing? ;-)

--
Keith
Anonymous
a b à CPUs
June 13, 2005 12:59:49 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

nobody@nowhere.net wrote:
> On Sat, 28 May 2005 01:01:32 -0400, Tony Hill
> <hilla_nospam_20@yahoo.ca> wrote:
>
>
>>I think you're kind of hitting the nail on the head with the second
>>option. My understanding is that SMT added only a very small number
>>of transistors to the core (the numbers I've heard floated around are
>>5-10%, though I have no firm quote and I'm not sure if that's for
>>Northwood or Prescott). With IBM's Power5, where the performance
>>boost from SMT is much larger, I understand that they were looking at
>>a 25% increase in the transistor count.
>>
>>That actually brings up a rather interesting point though. At some
>>point SMT may become counter-productive vs. multi-core. In the case
>>of the Power5, if you need to increase you're transistor count by 25%
>>per core for SMT, you only need 4 cores before you've got a enough
>>extra transistors for another full-fledged core. That of course leads
>>to the question, are you better off with 4 cores with SMT or 5 cores
>>without? My money is on 5 cores without.
>>
>
> ...snip...
>
>>-------------
>>Tony Hill
>>hilla <underscore> 20 <at> yahoo <dot> ca
>
>
> Now a question: why we didn't see the dual cores many years
> earlier? The main (OK, in overly simplistic view) difference between
> 486 and P5(AKA Pentium) was the second integer pipeline. While I
> don't have the transistor count per pipeline in P5 and proportion of
> it to the total count, I may suppose (just hypothetically) that making
> a dual core of 486-style single pipeline (minus branch prediction
> logic, plus extra FPU for second core) would not be much more
> complicated than a single core P5, using the same logic as above.
> Besides, 486 was even easier to crank up the clock - when Pentium was
> around 100 (or 120 - too ancient history to remember exactly) AMD had
> its 586 (486 with bigger L1 cache) at 133, easily overclockable to 160
> - did it myself. So why nobody back then jumped to make dual cores?
> My answer - no software to take advantage of it, at least on
> consumer level. Win95 had nothing in it to take advantage of SMP.
> Ditto Quake 1 ;-). And in corporate world, it was more than a year
> before the introduction of NT4 that might (or might not) have been
> benefitted.
> Any other answers?
> Just another 'what if' speculation with no practical meaning...
>

A dual core 486 would have performed no better than a 486 on any single
program. The paradigm of use in that era was a single process on a
single processor. Dual core would require two programs to be running.
Adding a second core would add no value to the customers. On the other
hand, adding additional decode and execution pipes makes the single
program go faster, something every customer was screaming at intel for.
The choice was obvious, and correct at the time.

Alex
Anonymous
a b à CPUs
June 14, 2005 12:13:57 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Mon, 13 Jun 2005 08:59:49 -0400, Alex Johnson <compuwiz@psualum.com>
wrote:

>nobody@nowhere.net wrote:

>> Now a question: why we didn't see the dual cores many years
>> earlier? The main (OK, in overly simplistic view) difference between
>> 486 and P5(AKA Pentium) was the second integer pipeline. While I
>> don't have the transistor count per pipeline in P5 and proportion of
>> it to the total count, I may suppose (just hypothetically) that making
>> a dual core of 486-style single pipeline (minus branch prediction
>> logic, plus extra FPU for second core) would not be much more
>> complicated than a single core P5, using the same logic as above.
>> Besides, 486 was even easier to crank up the clock - when Pentium was
>> around 100 (or 120 - too ancient history to remember exactly) AMD had
>> its 586 (486 with bigger L1 cache) at 133, easily overclockable to 160
>> - did it myself. So why nobody back then jumped to make dual cores?
>> My answer - no software to take advantage of it, at least on
>> consumer level. Win95 had nothing in it to take advantage of SMP.
>> Ditto Quake 1 ;-). And in corporate world, it was more than a year
>> before the introduction of NT4 that might (or might not) have been
>> benefitted.
>> Any other answers?
>> Just another 'what if' speculation with no practical meaning...
>>
>
>A dual core 486 would have performed no better than a 486 on any single
>program. The paradigm of use in that era was a single process on a
>single processor. Dual core would require two programs to be running.
>Adding a second core would add no value to the customers. On the other
>hand, adding additional decode and execution pipes makes the single
>program go faster, something every customer was screaming at intel for.
> The choice was obvious, and correct at the time.

There *were* multi-tasking environments available at the time. It's even
remotely possible that if dual cores had been available at a reasonable
price, DesqView, which did real pre-emptive multi-tasking for 386 Protected
Mode progs, would not have disappeared into oblivion. Then again.....:-)

--
Rgds, George Macdonald
June 14, 2005 2:06:09 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Mon, 13 Jun 2005 20:13:57 -0400, George Macdonald wrote:

> On Mon, 13 Jun 2005 08:59:49 -0400, Alex Johnson <compuwiz@psualum.com>
> wrote:
>
>>nobody@nowhere.net wrote:
>
>>> Now a question: why we didn't see the dual cores many years
>>> earlier? The main (OK, in overly simplistic view) difference between
>>> 486 and P5(AKA Pentium) was the second integer pipeline. While I
>>> don't have the transistor count per pipeline in P5 and proportion of
>>> it to the total count, I may suppose (just hypothetically) that making
>>> a dual core of 486-style single pipeline (minus branch prediction
>>> logic, plus extra FPU for second core) would not be much more
>>> complicated than a single core P5, using the same logic as above.
>>> Besides, 486 was even easier to crank up the clock - when Pentium was
>>> around 100 (or 120 - too ancient history to remember exactly) AMD had
>>> its 586 (486 with bigger L1 cache) at 133, easily overclockable to 160
>>> - did it myself. So why nobody back then jumped to make dual cores?
>>> My answer - no software to take advantage of it, at least on
>>> consumer level. Win95 had nothing in it to take advantage of SMP.
>>> Ditto Quake 1 ;-). And in corporate world, it was more than a year
>>> before the introduction of NT4 that might (or might not) have been
>>> benefitted.
>>> Any other answers?
>>> Just another 'what if' speculation with no practical meaning...
>>>
>>
>>A dual core 486 would have performed no better than a 486 on any single
>>program. The paradigm of use in that era was a single process on a
>>single processor. Dual core would require two programs to be running.
>>Adding a second core would add no value to the customers. On the other
>>hand, adding additional decode and execution pipes makes the single
>>program go faster, something every customer was screaming at intel for.
>> The choice was obvious, and correct at the time.
>
> There *were* multi-tasking environments available at the time. It's even
> remotely possible that if dual cores had been available at a reasonable
> price, DesqView, which did real pre-emptive multi-tasking for 386 Protected
> Mode progs, would not have disappeared into oblivion. Then again.....:-)

Not to mention OS/2. ...but the "official" veiw from Mt. Redomond was
that no one needed to multi-task. ...which is obvious because Win
*couldn't*.

No, the real reason was that caches, OoO, and speculation, were a better
use of the real estate until quite recently.

--
Keith
Anonymous
a b à CPUs
June 15, 2005 2:13:30 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Mon, 13 Jun 2005 02:09:16 GMT, "nobody@nowhere.net"
<mygarbage2000@hotmail.com> wrote:

>On Sat, 28 May 2005 01:01:32 -0400, Tony Hill
><hilla_nospam_20@yahoo.ca> wrote:
>
>>That actually brings up a rather interesting point though. At some
>>point SMT may become counter-productive vs. multi-core. In the case
>>of the Power5, if you need to increase you're transistor count by 25%
>>per core for SMT, you only need 4 cores before you've got a enough
>>extra transistors for another full-fledged core. That of course leads
>>to the question, are you better off with 4 cores with SMT or 5 cores
>>without? My money is on 5 cores without.
>
> Now a question: why we didn't see the dual cores many years
>earlier? The main (OK, in overly simplistic view) difference between
>486 and P5(AKA Pentium) was the second integer pipeline.

I'd say that is a grossly over-simplistic view which ignores the
improvements in cache, memory bus, FPU, branch prediction, pipelining,
etc. The two chips were really quite different, to the extent that
the Pentium was easily twice as fast, clock for clock, as a 486.

> While I
>don't have the transistor count per pipeline in P5 and proportion of
>it to the total count, I may suppose (just hypothetically) that making
>a dual core of 486-style single pipeline (minus branch prediction
>logic, plus extra FPU for second core) would not be much more
>complicated than a single core P5, using the same logic as above.

The 486 weighed in at 1.2M transistors, the P5 had 3.1M transistors.
I don't know the exact break-down of the transistor count, but it is
certainly quite reasonable to assume you could build a dual-core 486
for no more (and probably less than) a single-core P5.

Of course, the 486 would be a LOT slower. In fact, in '93 when the
Pentium was released a dual-core 486 would really struggle to be more
than 5% faster than a single-core 486 in any application at all, most
would end up being slower. The first problem was lock of software,
but it didn't end there.

>Besides, 486 was even easier to crank up the clock - when Pentium was
>around 100 (or 120 - too ancient history to remember exactly) AMD had
>its 586 (486 with bigger L1 cache) at 133, easily overclockable to 160
>- did it myself.

Of course the 100MHz Pentium was MUCH faster than the 160MHz AMD 486.

> So why nobody back then jumped to make dual cores?

Because they could get more performance in 99% of the cases by going
with a beefier single-core.

> My answer - no software to take advantage of it, at least on
>consumer level. Win95 had nothing in it to take advantage of SMP.

Win95 (and '98 and Me) didn't support SMP at all. If you booted Win95
on a dual-processor (either dual-core or two separate processors) then
the second processor would simply be disabled because it had
absolutely zero support.

Oh, and the Pentium pre-dated Win95 by 2 years, so really we're
talking about Win3.1 timeframe.

>Ditto Quake 1 ;-). And in corporate world, it was more than a year
>before the introduction of NT4 that might (or might not) have been
>benefitted.

WinNT 4.0 at least support multiple processors, but most of the
software would have made little to no use of it. I suppose you could
have done ok in OS/2 as well, though really only the weirdos like
Keith ran OS/2 :>

> Any other answers?
> Just another 'what if' speculation with no practical meaning...

Back with the 486 vs. Pentium, doubling the transistors resulted in
roughly doubling the performance in single-core chips. Since this
gave you twice as much performance in ALL situations, going to
dual-core which only gave you a small increase in performance in a
very few applications available at the time made no sense.

Now the tables are very much turned. With the Northwood P4 vs.
Prescott P4, Intel more than doubled their transistor count. The
result was basically a negligible increase in performance. On the
other hand a LOT more software is available now that can take
advantage of multiple processing cores and we do a lot more
multitasking than we did back in the Win3.1 or even Win9x days.

Processor design is always a question of trade-offs, what feature
gives you the most performance for most users with a given number of
transistors and/or power consumption. Back in the 486 -> Pentium days
it was pretty clear that adding logic transistors was the best way to
go. This held true when going from the Pentium to the PPro as well,
though after that time the trend shifted to adding cache transistors.
Now we're starting to see the benefits of extra cache trailing off,
but multiple cores is becoming more interesting. Eventually it's
likely that adding more cores will no longer buy you much and people
will have to think up something altogether new to do with their
transistors.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
June 15, 2005 4:52:11 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Alex Johnson wrote:
> A dual core 486 would have performed no better than a 486 on any single
> program. The paradigm of use in that era was a single process on a
> single processor. Dual core would require two programs to be running.
> Adding a second core would add no value to the customers. On the other
> hand, adding additional decode and execution pipes makes the single
> program go faster, something every customer was screaming at intel for.
> The choice was obvious, and correct at the time.

Also let's not forget that the majority of operating systems that could
run on it at the time were single-processor oriented, such as Windows
3.x and Windows 95.

Yousuf Khan
Anonymous
a b à CPUs
June 15, 2005 4:53:33 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

George Macdonald wrote:
> There *were* multi-tasking environments available at the time. It's even
> remotely possible that if dual cores had been available at a reasonable
> price, DesqView, which did real pre-emptive multi-tasking for 386 Protected
> Mode progs, would not have disappeared into oblivion. Then again.....:-)

Desqview disappeared because nobody wanted to do DOS apps anymore, they
wanted to do nice and easy GUIs from that point forward.

Yousuf Khan
Anonymous
a b à CPUs
June 15, 2005 10:56:15 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Wed, 15 Jun 2005 00:53:33 -0400, Yousuf Khan <bbbl67@ezrs.com> wrote:

>George Macdonald wrote:
>> There *were* multi-tasking environments available at the time. It's even
>> remotely possible that if dual cores had been available at a reasonable
>> price, DesqView, which did real pre-emptive multi-tasking for 386 Protected
>> Mode progs, would not have disappeared into oblivion. Then again.....:-)
>
>Desqview disappeared because nobody wanted to do DOS apps anymore, they
>wanted to do nice and easy GUIs from that point forward.

.... even if they didn't need them.:-) ISTR some talk of a hook-up with Gem
which never got anywhere but you're right, eventually Windows 3.11 killed
Desqview.

--
Rgds, George Macdonald
Anonymous
a b à CPUs
June 15, 2005 12:28:25 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Tony Hill wrote:
> The 486 weighed in at 1.2M transistors, the P5 had 3.1M transistors.
> I don't know the exact break-down of the transistor count, but it is
> certainly quite reasonable to assume you could build a dual-core 486
> for no more (and probably less than) a single-core P5.

Another big stumbling block is that the 486 had no concept of multiple
processors. The bus didn't support it. The cache didn't support it.
If you wanted multiple 486 cores you'd have to re-engineer the 486
pretty drastically. In this day of all CPUs designed to support MP,
people forget that. Multicore has the same requirements as
multiprocessor and 486 was never multiprocessor.

Alex
Anonymous
a b à CPUs
June 15, 2005 12:55:39 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

George Macdonald wrote:
>>Desqview disappeared because nobody wanted to do DOS apps anymore, they
>>wanted to do nice and easy GUIs from that point forward.
>
>
> ... even if they didn't need them.:-) ISTR some talk of a hook-up with Gem
> which never got anywhere but you're right, eventually Windows 3.11 killed
> Desqview.

Desqview could've survived if it could've done what's being done now by
programs like Vmware and Xen. That is if it could've been an OS virtualizer.

Quarterdeck did come up with the Desqview/X program, which was Desqview
with an X Windows interface. From what I can remember of it, it was
extremely pretty, but Quarterdeck didn't have the marketing muscle of
Microsoft (what else is new?) to compel developers to develop for their
environment.

Yousuf Khan
Anonymous
a b à CPUs
June 15, 2005 5:54:59 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.intel George Macdonald <fammacd=!SPAM^nothanks@tellurian.com> wrote:
> On Wed, 15 Jun 2005 00:53:33 -0400, Yousuf Khan <bbbl67@ezrs.com> wrote:
> >Desqview disappeared because nobody wanted to do DOS apps anymore, they
> >wanted to do nice and easy GUIs from that point forward.
>
> ... even if they didn't need them.:-) ISTR some talk of a hook-up with Gem
> which never got anywhere but you're right, eventually Windows 3.11 killed
> Desqview.

And of course they had their own GUI, Desqview/X, which implemented an X
Windows server.

--
Nate Edel http://www.cubiclehermit.com/

"This is not a humorous signature."
Anonymous
a b à CPUs
June 15, 2005 11:14:47 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Wed, 15 Jun 2005 08:55:39 -0400, Yousuf Khan <bbbl67@ezrs.com> wrote:

>George Macdonald wrote:
>>>Desqview disappeared because nobody wanted to do DOS apps anymore, they
>>>wanted to do nice and easy GUIs from that point forward.
>>
>>
>> ... even if they didn't need them.:-) ISTR some talk of a hook-up with Gem
>> which never got anywhere but you're right, eventually Windows 3.11 killed
>> Desqview.
>
>Desqview could've survived if it could've done what's being done now by
>programs like Vmware and Xen. That is if it could've been an OS virtualizer.

Back then virtualization was not that well known at the desktop level - I
don't see how that could have helped them that much. They also were making
money on QEMM386 because it took M$ 7-8 years to figure it out and they
never quite got there.

>Quarterdeck did come up with the Desqview/X program, which was Desqview
>with an X Windows interface. From what I can remember of it, it was
>extremely pretty, but Quarterdeck didn't have the marketing muscle of
>Microsoft (what else is new?) to compel developers to develop for their
>environment.

Ahead of their time.:-)

--
Rgds, George Macdonald
June 16, 2005 2:07:23 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Wed, 15 Jun 2005 19:14:47 -0400, George Macdonald wrote:

> On Wed, 15 Jun 2005 08:55:39 -0400, Yousuf Khan <bbbl67@ezrs.com> wrote:
>
>>George Macdonald wrote:
>>>>Desqview disappeared because nobody wanted to do DOS apps anymore, they
>>>>wanted to do nice and easy GUIs from that point forward.
>>>
>>>
>>> ... even if they didn't need them.:-) ISTR some talk of a hook-up with Gem
>>> which never got anywhere but you're right, eventually Windows 3.11 killed
>>> Desqview.
>>
>>Desqview could've survived if it could've done what's being done now by
>>programs like Vmware and Xen. That is if it could've been an OS virtualizer.
>
> Back then virtualization was not that well known at the desktop level - I
> don't see how that could have helped them that much.

Dunno. I know a few thousand people who knew all about virtualization
long before (VM/370). ...and while the processor wasn't on their desktop
the glass was. I'm quite tickled when I see all these "new revelations"
about virtualization and multi-tasking.

<snip>

--
Keith
June 16, 2005 2:09:16 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Wed, 15 Jun 2005 00:52:11 -0400, Yousuf Khan wrote:

> Alex Johnson wrote:
>> A dual core 486 would have performed no better than a 486 on any single
>> program. The paradigm of use in that era was a single process on a
>> single processor. Dual core would require two programs to be running.
>> Adding a second core would add no value to the customers. On the other
>> hand, adding additional decode and execution pipes makes the single
>> program go faster, something every customer was screaming at intel for.
>> The choice was obvious, and correct at the time.
>
> Also let's not forget that the majority of operating systems that could
> run on it at the time were single-processor oriented, such as Windows
> 3.x and Windows 95.

Not only single-processor, but single *task*. There was no concept of
preemption in 3x or Win95.

--
Keith
Anonymous
a b à CPUs
June 16, 2005 10:43:46 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

keith wrote:
> Not only single-processor, but single *task*. There was no concept of
> preemption in 3x or Win95.

Windows 95 was definitely pre-emptive, that was one of the big
improvements from Win3x to 95. And Windows 3.x was able to preempt DOS
boxes (Virtual-8086 DOS apps).

Yousuf Khan
Anonymous
a b à CPUs
June 16, 2005 11:35:59 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

George Macdonald wrote:
> >Desqview could've survived if it could've done what's being done now by
> >programs like Vmware and Xen. That is if it could've been an OS virtualizer.
>
> Back then virtualization was not that well known at the desktop level - I
> don't see how that could have helped them that much. They also were making
> money on QEMM386 because it took M$ 7-8 years to figure it out and they
> never quite got there.

Well, it could've helped them if they could've virtualized Windows
underneath a Desqview supervisor. They were able to do it, in a
severely restricted fashion: they could run Windows 3.x in "Standard"
mode (which was basically a 16-bit protected mode), but not in
"Enhanced" mode (which was a 32-bit protected mode). That was because
Microsoft never implemented the DPMI (DOS Protected Mode Interface)
standards properly -- strange considering it was Microsoft's own
standard -- DPMI apps should be able to act as both DPMI master or
slave if there is already another DPMI master present, Windows could
only be a master.

But Qemm could've been modified to become a hypervisor much like what
VMWare eventually did. Qemm had the ability to trap privileged
instructions and if instead of just shutting down an errant program, it
actually tried to accomodate it with emulated instructions, it would've
become a virtualizer.

Yousuf Khan
Anonymous
a b à CPUs
June 16, 2005 12:05:55 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Wed, 15 Jun 2005 22:07:23 -0400, keith <krw@att.bizzzz> wrote:

>On Wed, 15 Jun 2005 19:14:47 -0400, George Macdonald wrote:
>
>> On Wed, 15 Jun 2005 08:55:39 -0400, Yousuf Khan <bbbl67@ezrs.com> wrote:
>>
>>>George Macdonald wrote:
>>>>>Desqview disappeared because nobody wanted to do DOS apps anymore, they
>>>>>wanted to do nice and easy GUIs from that point forward.
>>>>
>>>>
>>>> ... even if they didn't need them.:-) ISTR some talk of a hook-up with Gem
>>>> which never got anywhere but you're right, eventually Windows 3.11 killed
>>>> Desqview.
>>>
>>>Desqview could've survived if it could've done what's being done now by
>>>programs like Vmware and Xen. That is if it could've been an OS virtualizer.
>>
>> Back then virtualization was not that well known at the desktop level - I
>> don't see how that could have helped them that much.
>
>Dunno. I know a few thousand people who knew all about virtualization
>long before (VM/370). ...and while the processor wasn't on their desktop
>the glass was. I'm quite tickled when I see all these "new revelations"
>about virtualization and multi-tasking.

Not on the desktop? Well not for everybody but there was VM/PC on an
AT/370 card... or was that just a name? I guess it didn't really do VM did
it? BTW any idea if there is still such a card as the AT/370 for a modern
machine and how one obtains one and at what cost?

--
Rgds, George Macdonald
Anonymous
a b à CPUs
June 18, 2005 12:56:16 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

keith wrote:
> On Thu, 16 Jun 2005 06:43:46 -0700, YKhan wrote:
> > Windows 95 was definitely pre-emptive, that was one of the big
> > improvements from Win3x to 95. And Windows 3.x was able to preempt DOS
> > boxes (Virtual-8086 DOS apps).
>
> NO it certainly wasn't. Win95 couldn't walk and chew gum at the same
> time. It was advertised as (cooperative) multi-tasking, which meant that
> it wasn't at all. Win95 was pretty much a shell over Win3.x. OS/2 would
> turn circles around Win95, simply because it *WAS* a preemptive
> multi-tasking system.

Windows 95 was definitely pre-emptively multitasked. Sure, the old
16-bit Windows apps continued to be multitasked cooperatively, but the
whole 16-bit Windows environment was put into its own virtual machine
and that virtual machine was preemptively multitasked in the bigger
32-bit context. All 32-bit apps were preemptively multitasked.

> Remember the CZ-1000 IDE controller? It worked
> fine on Win95 because it *couldn't* multi-task.

No, I don't remember it, but what's hardware gotta do with how programs
are multitasked?

Yousuf Khan
June 18, 2005 2:15:13 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Thu, 16 Jun 2005 08:05:55 -0400, George Macdonald wrote:

> On Wed, 15 Jun 2005 22:07:23 -0400, keith <krw@att.bizzzz> wrote:
>
>>On Wed, 15 Jun 2005 19:14:47 -0400, George Macdonald wrote:
>>
>>> On Wed, 15 Jun 2005 08:55:39 -0400, Yousuf Khan <bbbl67@ezrs.com> wrote:
>>>
>>>>George Macdonald wrote:
>>>>>>Desqview disappeared because nobody wanted to do DOS apps anymore, they
>>>>>>wanted to do nice and easy GUIs from that point forward.
>>>>>
>>>>>
>>>>> ... even if they didn't need them.:-) ISTR some talk of a hook-up with Gem
>>>>> which never got anywhere but you're right, eventually Windows 3.11 killed
>>>>> Desqview.
>>>>
>>>>Desqview could've survived if it could've done what's being done now by
>>>>programs like Vmware and Xen. That is if it could've been an OS virtualizer.
>>>
>>> Back then virtualization was not that well known at the desktop level - I
>>> don't see how that could have helped them that much.
>>
>>Dunno. I know a few thousand people who knew all about virtualization
>>long before (VM/370). ...and while the processor wasn't on their desktop
>>the glass was. I'm quite tickled when I see all these "new revelations"
>>about virtualization and multi-tasking.
>
> Not on the desktop? Well not for everybody but there was VM/PC on an
> AT/370 card... or was that just a name? I guess it didn't really do VM did
> it? BTW any idea if there is still such a card as the AT/370 for a modern
> machine and how one obtains one and at what cost?

I'm not sure I'd put these too far in the "virtual" bucket. They were
rather software and memory limited, not to mention single user.
(Small) point taken though.

--
Keith
June 18, 2005 2:20:10 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Thu, 16 Jun 2005 06:43:46 -0700, YKhan wrote:

> keith wrote:
>> Not only single-processor, but single *task*. There was no concept of
>> preemption in 3x or Win95.
>
> Windows 95 was definitely pre-emptive, that was one of the big
> improvements from Win3x to 95. And Windows 3.x was able to preempt DOS
> boxes (Virtual-8086 DOS apps).

NO it certainly wasn't. Win95 couldn't walk and chew gum at the same
time. It was advertised as (cooperative) multi-tasking, which meant that
it wasn't at all. Win95 was pretty much a shell over Win3.x. OS/2 would
turn circles around Win95, simply because it *WAS* a preemptive
multi-tasking system. Remember the CZ-1000 IDE controller? It worked
fine on Win95 because it *couldn't* multi-task.

--
Keith
Anonymous
a b à CPUs
June 19, 2005 9:39:17 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <1119066976.647079.274560@f14g2000cwb.googlegroups.com>,
yjkhan@gmail.com says...
> keith wrote:
> > On Thu, 16 Jun 2005 06:43:46 -0700, YKhan wrote:
> > > Windows 95 was definitely pre-emptive, that was one of the big
> > > improvements from Win3x to 95. And Windows 3.x was able to preempt DOS
> > > boxes (Virtual-8086 DOS apps).
> >
> > NO it certainly wasn't. Win95 couldn't walk and chew gum at the same
> > time. It was advertised as (cooperative) multi-tasking, which meant that
> > it wasn't at all. Win95 was pretty much a shell over Win3.x. OS/2 would
> > turn circles around Win95, simply because it *WAS* a preemptive
> > multi-tasking system.
>
> Windows 95 was definitely pre-emptively multitasked. Sure, the old
> 16-bit Windows apps continued to be multitasked cooperatively, but the
> whole 16-bit Windows environment was put into its own virtual machine
> and that virtual machine was preemptively multitasked in the bigger
> 32-bit context. All 32-bit apps were preemptively multitasked.
>
> > Remember the CZ-1000 IDE controller? It worked
> > fine on Win95 because it *couldn't* multi-task.
>
> No, I don't remember it, but what's hardware gotta do with how programs
> are multitasked?

Good grief, Yousuf. Don't you think the first place you'd see multi-
tasking is in the I/O? If there were two tasks issued to the
controller at the right (wrong) time, it decided to clip two bytes off
one of the buffers; the file just lost two bytes (can you say bit-
rot?). This problem *never* appeared in Win95 because two transactions
couldn't happen. Win95 was mostly a prettier DOS shell than Win3.1.

BTW, the CMD CZ-1000 (I think that was the number anyway
  • ) was a rip-
    off of one of the early Intel PCI IDE controllers, right down to this
    bug.

  • I'd look it up, but I have no internet access here.
    --
    Keith
    Anonymous
    a b à CPUs
    June 20, 2005 8:31:37 AM

    Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Keith R. Williams wrote:
    > > > Remember the CZ-1000 IDE controller? It worked
    > > > fine on Win95 because it *couldn't* multi-task.
    > >
    > > No, I don't remember it, but what's hardware gotta do with how programs
    > > are multitasked?
    >
    > Good grief, Yousuf. Don't you think the first place you'd see multi-
    > tasking is in the I/O? If there were two tasks issued to the
    > controller at the right (wrong) time, it decided to clip two bytes off
    > one of the buffers; the file just lost two bytes (can you say bit-
    > rot?). This problem *never* appeared in Win95 because two transactions
    > couldn't happen. Win95 was mostly a prettier DOS shell than Win3.1.

    Or more likely because they serialized access to the controller through
    the device driver by adding queueing buffers in memory.

    Yousuf Khan
    Anonymous
    a b à CPUs
    June 20, 2005 11:31:28 AM

    Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Sun, 19 Jun 2005 17:39:17 -0400, Keith R. Williams <krw@att.bizzzz>
    wrote:

    >In article <1119066976.647079.274560@f14g2000cwb.googlegroups.com>,
    >yjkhan@gmail.com says...
    >> keith wrote:
    >> > On Thu, 16 Jun 2005 06:43:46 -0700, YKhan wrote:
    >> > > Windows 95 was definitely pre-emptive, that was one of the big
    >> > > improvements from Win3x to 95. And Windows 3.x was able to preempt DOS
    >> > > boxes (Virtual-8086 DOS apps).
    >> >
    >> > NO it certainly wasn't. Win95 couldn't walk and chew gum at the same
    >> > time. It was advertised as (cooperative) multi-tasking, which meant that
    >> > it wasn't at all. Win95 was pretty much a shell over Win3.x. OS/2 would
    >> > turn circles around Win95, simply because it *WAS* a preemptive
    >> > multi-tasking system.
    >>
    >> Windows 95 was definitely pre-emptively multitasked. Sure, the old
    >> 16-bit Windows apps continued to be multitasked cooperatively, but the
    >> whole 16-bit Windows environment was put into its own virtual machine
    >> and that virtual machine was preemptively multitasked in the bigger
    >> 32-bit context. All 32-bit apps were preemptively multitasked.
    >>
    >> > Remember the CZ-1000 IDE controller? It worked
    >> > fine on Win95 because it *couldn't* multi-task.
    >>
    >> No, I don't remember it, but what's hardware gotta do with how programs
    >> are multitasked?
    >
    >Good grief, Yousuf. Don't you think the first place you'd see multi-
    >tasking is in the I/O? If there were two tasks issued to the
    >controller at the right (wrong) time, it decided to clip two bytes off
    >one of the buffers; the file just lost two bytes (can you say bit-
    >rot?). This problem *never* appeared in Win95 because two transactions
    >couldn't happen. Win95 was mostly a prettier DOS shell than Win3.1.

    The way I remember it was that that IDE controller, and some others, could
    only work in "serialized transaction" mode, which placed some restrictions
    on the IDE driver in PIO Mode and ruled out Bus Mastering mode completely.
    Win95(A) never had Bus Mastering driver support but Win95(B) (sort of)
    did... if you count the driver of the week comedy we went through with
    Intel et.al. at that time.

    The way I recall it, even from the start, Win95 *was* sold as having
    preemptive multitasking; OTOH anyone who used it could be excused for
    thinking that it didn't.:-) Again, it's hazy, but as I recall that was as
    much to do with the legacy 16-bit GUI compatibility and the infamous
    "Windows Resources" as anything else.

    >BTW, the CMD CZ-1000 (I think that was the number anyway
  • ) was a rip-
    >off of one of the early Intel PCI IDE controllers, right down to this
    >bug.

    Yep I definitely recall that sinking feeling every time I saw "CMD IDE
    Controller" in Device Manager of a new system.

    >
  • I'd look it up, but I have no internet access here.

    Oh, that's a good one - love it!;-)

    --
    Rgds, George Macdonald
    Anonymous
    a b à CPUs
    June 21, 2005 1:56:11 PM

    Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    keith wrote:
    > > Or more likely because they serialized access to the controller through
    > > the device driver by adding queueing buffers in memory.
    >
    > More likely because the I/O was 16bit DOS, as was most of the OS. Once in
    > 16bit, everything serialized.

    Doubtful, since the 32-bit disk device drivers first started appearing
    with Windows 3.1. I can recall there were tons of concern about this
    fact:

    "Microsoft is going to do what? They're going to replace the BIOS
    routines with 32-bit protected mode device drivers? Why? What's wrong
    with the BIOS? The BIOS has been handling disk i/o since the beginning
    of the PC, it's got the job nailed down tight. How could they possibly
    improve upon the BIOS? This is Microsoft, the first implementations of
    the drivers are bound to be flakey. So why not just use the BIOS? ",
    &c.

    Of course, we've never looked back, the BIOS is barely used to do
    anything other than create the initial disk drive maps which it then
    hands to the OS now.

    Yousuf Khan
    June 21, 2005 2:01:52 PM

    Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Mon, 20 Jun 2005 07:31:28 -0400, George Macdonald wrote:

    > On Sun, 19 Jun 2005 17:39:17 -0400, Keith R. Williams <krw@att.bizzzz>
    > wrote:
    >
    >>In article <1119066976.647079.274560@f14g2000cwb.googlegroups.com>,
    >>yjkhan@gmail.com says...
    >>> keith wrote:
    >>> > On Thu, 16 Jun 2005 06:43:46 -0700, YKhan wrote:
    >>> > > Windows 95 was definitely pre-emptive, that was one of the big
    >>> > > improvements from Win3x to 95. And Windows 3.x was able to preempt DOS
    >>> > > boxes (Virtual-8086 DOS apps).
    >>> >
    >>> > NO it certainly wasn't. Win95 couldn't walk and chew gum at the same
    >>> > time. It was advertised as (cooperative) multi-tasking, which meant that
    >>> > it wasn't at all. Win95 was pretty much a shell over Win3.x. OS/2 would
    >>> > turn circles around Win95, simply because it *WAS* a preemptive
    >>> > multi-tasking system.
    >>>
    >>> Windows 95 was definitely pre-emptively multitasked. Sure, the old
    >>> 16-bit Windows apps continued to be multitasked cooperatively, but the
    >>> whole 16-bit Windows environment was put into its own virtual machine
    >>> and that virtual machine was preemptively multitasked in the bigger
    >>> 32-bit context. All 32-bit apps were preemptively multitasked.
    >>>
    >>> > Remember the CZ-1000 IDE controller? It worked
    >>> > fine on Win95 because it *couldn't* multi-task.
    >>>
    >>> No, I don't remember it, but what's hardware gotta do with how programs
    >>> are multitasked?
    >>
    >>Good grief, Yousuf. Don't you think the first place you'd see multi-
    >>tasking is in the I/O? If there were two tasks issued to the
    >>controller at the right (wrong) time, it decided to clip two bytes off
    >>one of the buffers; the file just lost two bytes (can you say bit-
    >>rot?). This problem *never* appeared in Win95 because two transactions
    >>couldn't happen. Win95 was mostly a prettier DOS shell than Win3.1.
    >
    > The way I remember it was that that IDE controller, and some others, could
    > only work in "serialized transaction" mode, which placed some restrictions
    > on the IDE driver in PIO Mode and ruled out Bus Mastering mode completely.
    > Win95(A) never had Bus Mastering driver support but Win95(B) (sort of)
    > did... if you count the driver of the week comedy we went through with
    > Intel et.al. at that time.
    >
    > The way I recall it, even from the start, Win95 *was* sold as having
    > preemptive multitasking; OTOH anyone who used it could be excused for
    > thinking that it didn't.:-) Again, it's hazy, but as I recall that was as
    > much to do with the legacy 16-bit GUI compatibility and the infamous
    > "Windows Resources" as anything else.

    It may have been sold that way, but it didn't work in this reality.

    >>BTW, the CMD CZ-1000 (I think that was the number anyway
  • ) was a rip-
    >>off of one of the early Intel PCI IDE controllers, right down to this
    >>bug.
    >
    > Yep I definitely recall that sinking feeling every time I saw "CMD IDE
    > Controller" in Device Manager of a new system.
    >
    >>
  • I'd look it up, but I have no internet access here.
    >
    > Oh, that's a good one - love it!;-)

    You've never heard of off-line news-reading? ;-) I was in Maine for the
    weekend (anniversary) and there are no local dial-up POPs in the southern
    part of the state. To get access I had to go down the hill to the lobby,
    where they had an open WiFi warm-spot. "Here" was in our room.

    --
    Keith
    June 21, 2005 2:03:13 PM

    Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Mon, 20 Jun 2005 04:31:37 -0700, YKhan wrote:

    > Keith R. Williams wrote:
    >> > > Remember the CZ-1000 IDE controller? It worked
    >> > > fine on Win95 because it *couldn't* multi-task.
    >> >
    >> > No, I don't remember it, but what's hardware gotta do with how programs
    >> > are multitasked?
    >>
    >> Good grief, Yousuf. Don't you think the first place you'd see multi-
    >> tasking is in the I/O? If there were two tasks issued to the
    >> controller at the right (wrong) time, it decided to clip two bytes off
    >> one of the buffers; the file just lost two bytes (can you say bit-
    >> rot?). This problem *never* appeared in Win95 because two transactions
    >> couldn't happen. Win95 was mostly a prettier DOS shell than Win3.1.
    >
    > Or more likely because they serialized access to the controller through
    > the device driver by adding queueing buffers in memory.

    More likely because the I/O was 16bit DOS, as was most of the OS. Once in
    16bit, everything serialized.

    --
    Keith
    June 22, 2005 12:02:34 AM

    Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Tue, 21 Jun 2005 09:56:11 -0700, Yousuf Khan wrote:

    > keith wrote:
    >> > Or more likely because they serialized access to the controller through
    >> > the device driver by adding queueing buffers in memory.
    >>
    >> More likely because the I/O was 16bit DOS, as was most of the OS. Once in
    >> 16bit, everything serialized.
    >
    > Doubtful, since the 32-bit disk device drivers first started appearing
    > with Windows 3.1. I can recall there were tons of concern about this
    > fact:

    There is a lot more to the filesystem than device drivers.

    > "Microsoft is going to do what? They're going to replace the BIOS
    > routines with 32-bit protected mode device drivers? Why? What's wrong
    > with the BIOS? The BIOS has been handling disk i/o since the beginning
    > of the PC, it's got the job nailed down tight. How could they possibly
    > improve upon the BIOS? This is Microsoft, the first implementations of
    > the drivers are bound to be flakey. So why not just use the BIOS? ",
    > &c.
    >
    > Of course, we've never looked back, the BIOS is barely used to do
    > anything other than create the initial disk drive maps which it then
    > hands to the OS now.

    Oh, please tell me more (obvious stuff). Sheesh!

    --
    Keith
    !