From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: comp.arch
Subject: Re: Will Prescott work on Win64?
Message-ID: <bpo38q$h93$1@build.pdx.osdl.net>
Date: Sat, 22 Nov 2003 16:40:02 GMT

glen herrmannsfeldt wrote:
>
> It was discussed in some newsgroup, maybe this one, that only a very
> small fraction of code needs 64 bits.  You only need 64 bit addressing
> for really large programs (there is always PAE if you need it).

That really doesn't matter.

It's not a question of "most people don't need it".

It's a question of having advantages of a mass market. If AMD continues to
produce 32-bit versions of the Athlon chip (regardless of whether they base
it on the old K7 architecture or just a cut-down K8) they automatically
kill off interest in their 64-bit architecture.

This is the same problem Intel has with Itanium: it's not going to be a
successful architecture as long as the 32-bit chips compete with it. You'd
have to be *CRAZY* to buy an Itanium box when you can buy Xeon's that
perform better for 99% of all workloads for a third of the price.

(Yeah, some people care about that 1% where 64-bit matters, but it's not
enough to maintain an interesting market).

To maintain an interesting market, AMD needs to stop producing the 32-bit
versions, and needs to be able to say that every x86 CPU they ship (with
the exception of specialized markets like embedded) is 64-bit capable.
That's the only way they can get enough of the chips on the market that
anybody will bother buying them.

Remember: the reason the Alpha died was not technology. The reason the alpha
died is that you can't afford to push an architecture that doesn't have a
wide appeal.

This is why AMD64 and the Power architectures are interesting, and why
Itanium eventually _will_ die unless Intel starts seriously changing their
approach to it. AMD64 and Power - in Opteron and the 970 respectively -
both have 64-bit architectures with a very real wide appeal, which helps
widen the market for them without fragmenting it.

In contrast, Intel is _consciously_ trying to fragment the market, which may
be in their own business interests ("gotta keep those high ASP's for those
high-end CPU's..") but it's against the interest of the consumers. And the
thing is, when you start doing things that are against the interest of your
marketplace, you are well on your way to disaster.

So if you see AMD actively pushing their 32-bit offerings next year, you'll
know that the Athlon64 is in deep trouble.

                        Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: comp.arch
Subject: Re: Will Prescott work on Win64?
Message-ID: <bpo7jh$jk2$1@build.pdx.osdl.net>
Date: Sat, 22 Nov 2003 17:50:02 GMT

Nick Maclaren wrote:
> In article <bpo38q$h93$1@build.pdx.osdl.net>,
> Linus Torvalds  <torvalds@osdl.org> wrote:
>>
>>It's not a question of "most people don't need it".
>>
>>It's a question of having advantages of a mass market. If AMD continues to
>>produce 32-bit versions of the Athlon chip (regardless of whether they
>>base it on the old K7 architecture or just a cut-down K8) they
>>automatically kill off interest in their 64-bit architecture.
>
> "Kill off"?  Oh, come, now!  "Cut down".

No, I mean "kill off".

Yes, it will obviously "cut down" too. But the thing is, if you continue to
cut down, you'll eventually have nothing left.

Introducing new architectural features is an uphill battle every time. It's
hard if you're a market leader, and it's doubly worse if you're already the
underdog in the market.  See what happened to 3dnow etc.

AMD already has Intel trying to undercut their market from them (P4EE etc).
They sure as hell don't need to do it themselves.

The K8 has a huge leg up thanks to backwards compatibility. That makes it
possible to sell it in the first place. But if you actually expect the new
architecture to matter and make a difference, it has to become common
enough that people will care.

And the only way it becomes common is by always including support for
64-bit. If you have a low-end 32-bit version, most people will just look at
the price difference and say "the 64-bit stuff doesn't buy me anything
today, so I'll just wait until there are applications taking advantage of
it".

And they'll wait literally forever, because it's a circular argument...

So AMD needs to drop the 32-bit versions to break the circle.

                Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: comp.arch
Subject: Re: Will Prescott work on Win64?
Message-ID: <bpoqtc$uoq$1@build.pdx.osdl.net>
Date: Sat, 22 Nov 2003 23:20:02 GMT

glen herrmannsfeldt wrote:
>
> Yes, and convincing people that they need something that they really
> don't.   Those people reading mail, or word processing, but like the
> idea of having a 64 bit processor so they can read mail faster, or
> process words faster.
>
> What would we do without marketing departments.

Hey, far be it from me to speak up for marketing, but the fact is, 64-bit
architectures _do_ help even people who only read mail and do word
processing.

Sure, the mail app or word processor may not need it, but the 64-bit stuff
does help other parts of the system, notably the infrastructure that helps
the mail reader/word processor do its job.

32-bit is getting quite cramped for operating systems when even normal
desktop (and laptop) machines have a gigabyte of RAM. PAE made us jump
through hoops, and it's getting worse.

512MB and 1GB machines are _normal_ today. And the virtual address space is
supposed to be noticeably *larger* than physical memory to be useful for a
number of things.

You can believe Intel marketing all you want ("the desktop doesn't need more
than 4GB of RAM in the next few years"), but that's a *lie*. Exactly
because the 32-bit virtual limit is _not_ at 4GB, but hits us much before
that (ie it hits at about 1GB of RAM - that's when the OS starts having
trouble mapping all of physical memory _and_ user space at the same time
without starting to have problems.

It's "highmem.sys" time all over again. And take it from me: that isn't five
years down the road - it's been that way for a couple of years already.
Every time I see a report on the 'net quoting some Intel person saying they
don't need to worry about it for a few years, I just cringe. They are
either incompetent or actively dishonest.

(Don't get me wrong, btw. I actually _like_ Intel. The x86 is my favourite
architecture simply because it beats everybody else hands down when it
comes to choice and bang-for-buck. I just can't stand the public
posturing).

Anyway: even if the mail reader doesn't need any more than 32-bit VM, other
parts of the system definitely would be improved by it.

And AMD64 actually gets this right - you can continue to happily use your
32-bit apps that don't need the bigger address space, without any
performance downsides. While the (much smaller) part of the installation
that actually can take advantage of 64-bit addressing can do so.

                Linus

From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: Will Prescott work on Win64?
Date: Sun, 23 Nov 2003 12:14:01 +0100
Message-ID: <bpq4pq$593$1@osl016lin.hda.hydro.com>

Linus Torvalds wrote:

> glen herrmannsfeldt wrote:
>
>>Yes, and convincing people that they need something that they really
>>don't.   Those people reading mail, or word processing, but like the
>>idea of having a 64 bit processor so they can read mail faster, or
>>process words faster.
>>
>>What would we do without marketing departments.
>
>
> Hey, far be it from me to speak up for marketing, but the fact is, 64-bit
> architectures _do_ help even people who only read mail and do word
> processing.
>
> Sure, the mail app or word processor may not need it, but the 64-bit stuff
> does help other parts of the system, notably the infrastructure that helps
> the mail reader/word processor do its job.
>
> 32-bit is getting quite cramped for operating systems when even normal
> desktop (and laptop) machines have a gigabyte of RAM. PAE made us jump
> through hoops, and it's getting worse.
>
> 512MB and 1GB machines are _normal_ today. And the virtual address space is
> supposed to be noticeably *larger* than physical memory to be useful for a
> number of things.

OTOH, with the increasing gap between memory and disk in
latency/bandwidth, the maximum sustainable overcommitment factor have
been dropping like a stone, from (say) 2 to 4 X around the time virtual
memory was invented, to 0.95 to 1.5 x these days, at least with a
Microsoft OS and 'jump all over the memory map' object-oriented programming.

> You can believe Intel marketing all you want ("the desktop doesn't need more
> than 4GB of RAM in the next few years"), but that's a *lie*. Exactly
> because the 32-bit virtual limit is _not_ at 4GB, but hits us much before
> that (ie it hits at about 1GB of RAM - that's when the OS starts having
> trouble mapping all of physical memory _and_ user space at the same time
> without starting to have problems.

These days my dual Xeon workstation has 2 GB RAM, and my three year old
laptop has 512 MB (because that was the maximum for a laptop at the time).

I'm replacing the laptop, mostly so I can get at least 2 GB there as
well (disk, graphics and cpu are all more or less still fast enough for
what I do, while RAM is really critical), while the next workstation
replacement will almost certainly have 4 to 8 GB with a 64-bit OS.

> It's "highmem.sys" time all over again. And take it from me: that isn't five
> years down the road - it's been that way for a couple of years already.
> Every time I see a report on the 'net quoting some Intel person saying they
> don't need to worry about it for a few years, I just cringe. They are
> either incompetent or actively dishonest.

"The difference between a computer vendor and a used car salesman is
that the used car dealer knows when he's lying."

I.e. I've been in many vendor announcements/presentations where the
presenter have been simply wrong, but almost certainly didn't know better.

>
> (Don't get me wrong, btw. I actually _like_ Intel. The x86 is my favourite
> architecture simply because it beats everybody else hands down when it
> comes to choice and bang-for-buck. I just can't stand the public
> posturing).
>
> Anyway: even if the mail reader doesn't need any more than 32-bit VM, other
> parts of the system definitely would be improved by it.
>
> And AMD64 actually gets this right - you can continue to happily use your
> 32-bit apps that don't need the bigger address space, without any
> performance downsides. While the (much smaller) part of the installation
> that actually can take advantage of 64-bit addressing can do so.

Which is why I'm sure that Dell will have to reconsider/renegotiate
their current 'Intel ONLY Inside' policy.

Either that, or Intel will have to bite the 64-bit x86 bullet within not
more than 2 years.

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: increasing addressable memory via paged memory?
Date: Thu, 20 Jan 2005 08:12:01 +0100
Message-ID: <csnlk1$2cd$1@osl016lin.hda.hydro.com>

John Dallman wrote:

> In article <m14ku0lfiiaf3tdivda8ii8opqt8mdpain@4ax.com>,
> gneuner2/@comcast.net (George Neuner) wrote:
>
>
>>Intel long ago deprecated use of segmenting and did not include
>>it at all in their 64 bit designs.
>
> It's there, I think. People on comp.arch have referred to it. Nobody uses
> it at at present, because there's little need with 64-bit addressing
> within segments, but it does allow for more than 64-bit address space per
> process.

No, it isn't (more or less):

AMD have specifically disallowed/disabled segment registers in 64-bit
mode, with a single exception: FS & GS are still sort of working to make
it easier to support Windows which use these for some kind of
process-private data store.

My guess would be that this is specifically to allow a 64-bit windows to
have 32-bit clients, without forcing the OS to switch in&out of 32-bit
mode to be able to setup these memory areas.

I would be _very_ surprised if they support anything but the 32-bit
maximum address range for these segments though, even in 64-bit mode.

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"