AMD/Linux vs Intel/Microsoft

[E]

Hello

You can't help to notice the significant change in hardware and software at
the moment. A somewhat interesting scenerio is playing out.

AMD has its x86-64 architecture, which can run 32-bit applications rather
well, and promises to be able to run 64 bit applications, when they come
out, even better. They have forced Intel to play there hand, and now Intel
must follow AMD's lead.

Although Intel currently has there own IA-64 architecture, this is aimed at
the server market, and from what I have read, if Intel wants to go 64 bit,
Microsoft wants Intel to get a license to implement AMD x86-64
architecture. But Intel also has Hyperthreading in there Xeon and Pentium 4
lines, and will have a more improved version in the Prescott
core, which may help in multitasking. But like AMD's 64 bit solution, don't
individual applications need to be written and compiled with the new
optimizations in mind, in order to gain any benefit?

This is where it gets interesting. Why doesn't Microsoft have an x86-64
version ready of Windows XP? Will Linux companies pick up the slack, and
ban together with AMD to take some of the Windows and Intel market share?
There are already 64-bit Linux distributions ready. Will open source
applications be optimized for AMD x86-64? Will proprietary vendors of
multimedia and photo editing software, optimize there applications for AMD
x86-64 and port them to Linux? We can only hope.

E

 

[E]

Here is the MS/XP64bit site
http://www.microsoft.com/WindowsXP/64bit/default.asp
Its been available for almost a year to OEMs,via MSDN and usenet warez.

Thanks for the link, but isn't that the version of Windows XP written and
compiled for the Itanium. This shows that Microsoft has a 64 bit workstation
solution, but the workstation must have an Intel Itanium. This will not
install on x86-64.

Competition is good for all. It is good to see AMD pushing Intel harder
but
it is unlikely that any open source companies will ally with AMD. Why
limit their markets?

I agree the competition is good.

The way I worded my question may have seemed
to imply that I was asking if there would be an official alliance between
AMD and open source. I had in mind a de facto alliance, however temporary,
for both AMD and open source companies to market there products while Intel
and Microsoft got around to addressing x86-64. I read Intel may have an
x86-64 architecture CPU out in 2005, so any work done by open source
for x86-64 will not go to waste.

Adobe already tried a Solaris port of PhotoShop and it did not sell.at
all. Unlikely there will be a Linux build especially since PhotoShop runs
well under Wine.

Thats a shame. Maybe Adobe will give it another shot if they see Linux or
FreeBSD on AMD gaining momentum.

E

 

[E]

E wrote:

(snip)


There is a discussion in one of these newsgroups on the need for
64 bit at all. While I do know a few applications for them, they
are relatively rare.

Multimedia and games. If they are compiled for x86-64 and ported to Linux,
then we might have something. I don't think there is anything wrong with
running proprietary closed source applications on Linux or BSD.

Remember, though, when the 386 and 486 first came out, and they were
mostly used to run 16 bit DOS applications. Usually they were faster,
which was for some enough reason to buy one. Will x86-64 be enough
faster to buy it for 32 bit code?

Hyperthreading, like multiple processors, should benefit normal programs
when more than one are running at once, or when an OS program needs
to run. That is assuming that the OS supports it.

Yes, and I was wondering if individual applications like games and video
editing could some how benefit from a dual processor system or a
Hyperthreading CPU, if written and compiled to use Hypertreading.

 

[E]

why doesn't Intel and AMD adopt Linux and produce their own distros
optimized to their chips?

why do they have to deal with m$oft at all ?

why not certify Linux chips with optimized kernels?

I didn't really mean that open source companies would literally band
together with AMD, maybe just a temporary de facto alliance.

But I like your ideas better. Even with Intel, since Intel has there own
compiler, that is as far as I know, free to use with Linux for
non-commercial use. And who would know how to create a compiler for an
Intel chip better than Intel? Although I also read that it still has some
problems with Linux kernal compiles, it seems to be getting better.
Application compiled with the Intel compiler benchmark a bit higher in a
lot of areas according to what I have read. So far I guess this is just
for regular 32 bit x86.

AMD has teamed up with Portland and STMicroelectronics to create a compiler
for x86-64 and Linux...

http://www.amd.com/us-en/Processors
DevelopWithAMD/0,,30_2252_2272_7640,00.html

And there is this from a privately held company called Pathscale
http://www.pathscale.com/

 

[Kevin Lawton]

| Alucard wrote:
<snip>
|| Adobe already tried a Solaris port of PhotoShop and it did not
|| sell.at all. Unlikely there will be a Linux build especially since
|| PhotoShop runs well under Wine.
|
| Thats a shame. Maybe Adobe will give it another shot if they see
| Linux or FreeBSD on AMD gaining momentum.

The problem might be that most users of open source Op Systems, like Linux
and FreeBSD, are used to getting their application software under a similar
arrangement. There might not be much money to be made from commercial
applications competing head-on with open-source equivalents like The Gimp.
Would Microsoft ever do a Linux version of office to face Sun's Star Office
? Probably not !
API bridges, like WINE, enable you to run well written Windoze
applications under Linux so there's even less incentive.
Drivers and utility programs are a different matter, though. Quite a
number of hardware namufacturers are drivers for Linux, BeOS and FreeBSD as
well as different versions of Windoze. If they didn't, they'd run the risk
of losing out on a growing market share.
I don't think there is much profit made out of drivers, though.
Kevin.

 

[Tim Shoppa]

This is where it gets interesting. Why doesn't Microsoft have an x86-64
version ready of Windows XP?

Set your wayback machine to the early-mid-90's and remember that Microsoft
sold Windows NT for a 64-bit platform (Alpha) before. Rumors have it that
other RISC platforms were targets back then too. Clearly they have (or
had) some internal experience with multiple target platforms, even though
it's not nearly as extensive as the Linux experience.

Back then the big gotcha was binary-only driver distributions that weren't
cross-compatible. Microsoft invested a lot of time and money into some
mitigation schemes, some of which were clever or stupid depending who you
ask (virtualized 386 on an Alpha handling driver stuff!) but all that
may have to be re-done... AGAIN. Linux doesn't suffer nearly so much
from this stupidity (but it does, to some extent, as many manufacturers
distribute binary-only drivers for Linux. That's not the fault of Linux,
although many regard binary-only drivers as pure evil.)

Tim.

 

[Nick Maclaren]

|>
|> > This is where it gets interesting. Why doesn't Microsoft have an x86-64
|> > version ready of Windows XP?
|>
|> Set your wayback machine to the early-mid-90's and remember that Microsoft
|> sold Windows NT for a 64-bit platform (Alpha) before. Rumors have it that
|> other RISC platforms were targets back then too. Clearly they have (or
|> had) some internal experience with multiple target platforms, even though
|> it's not nearly as extensive as the Linux experience.

Rumours also have it that most of the porting was done by DEC people,
that little of the coding has been preserved, that none of the other
projects got off the drawing board (within Microsoft) and that most of
the Microsoft people who did work on the Alpha have left.

The real issue is whether the Itanium port has been done competently,
or by simply spawning off another completely unportable code stream.
I have not heard any reliable rumours either way.


Regards,
Nick Maclaren.

 

[chrisv]

Linux doesn't suffer nearly so much
from this stupidity (but it does, to some extent, as many manufacturers
distribute binary-only drivers for Linux. That's not the fault of
Linux, although many regard binary-only drivers as pure evil.)

I'll take them. Either that, or have REALLY good, simple, step-by-step,
never-fail instructions. Since that's usually too difficult for them to
get right, hell, just compile me the binaries.

You can't tell me it would take all THAT much manpower for a company
like ATI to compile their drivers for the half-dozen or so leading Linux
distributions. If they want their cards to be purchased by Linux users,
they should be doing it.

 

[Bernd Paysan]

You can't tell me it would take all THAT much manpower for a company
like ATI to compile their drivers for the half-dozen or so leading Linux
distributions. If they want their cards to be purchased by Linux users,
they should be doing it.

I don't know what problems you'll have with ATI cards and Linux (up to now,
I've mainly use nVidia cards, and a Matrox card), but if you go to http:/
www.ati.com/support/faq/linux.html, you'll see that ATI does support Linux,
and does provide proprietary binary drivers on http://mirror.ati.com
support/driver.html. ATI also does provide informations to the Linux
developer community (the DRI project), at least up to the Radeon 9200 (not
the high-end ones - there, only the binary drivers are available). The
binary drivers support only the i386 architecture, i.e. those people who
want a real high-end graphic workstation with an Athlon 64 (or two
Opterons) will not be able to make use of a high-end ATI card. nVidia on
the other hand does support AMD64. Since Radeon 9x00 excel at DirectX 9
benchmarks, while GeForce 5x00 is better at OpenGL benchmarks, it's
probably better for a Linux user to use nVidia cards, anyway.

 

[Tim Shoppa]

The real issue is whether the Itanium port has been done competently,
or by simply spawning off another completely unportable code stream.

Historically Microsoft *seems* to have always chosen to "spawn off
an incompatible branch". All their products have to have a unique
set of features, the concept of having identical functionality across
different platforms is always broken. (They do seem to have
some grasp of "core" vs "extra" functionality.)

I happen to believe that these decisions are usually driven by marketing,
and not by any technical inability inside Microsoft, although I could be
wrong. Clearly the lack of uniformity has great costs inside Microsft's
development and support organizations; I can only assume that somehow
this is made up for in extra sales. Probably in the same way that
each toothpaste company now has twenty different variations ("shelf
space").

Tim.

 

[chrisv]

I don't know what problems you'll have with ATI cards and Linux (up to
now, I've mainly use nVidia cards, and a Matrox card), but if you go to
http:/ www.ati.com/support/faq/linux.html, you'll see that ATI does
support Linux, and does provide proprietary binary drivers on
http://mirror.ati.com support/driver.html

Well, I had already tried that on MD9.2, and I was required to compile
kernel modules. That's not a binary driver in my book.

 

[GreyCloud]

|> E <75475,[email protected]> wrote in message

|>
|> > This is where it gets interesting. Why doesn't Microsoft have an x86-64
|> > version ready of Windows XP?
|>
|> Set your wayback machine to the early-mid-90's and remember that Microsoft
|> sold Windows NT for a 64-bit platform (Alpha) before. Rumors have it that
|> other RISC platforms were targets back then too. Clearly they have (or
|> had) some internal experience with multiple target platforms, even though
|> it's not nearly as extensive as the Linux experience.

Rumours also have it that most of the porting was done by DEC people,
that little of the coding has been preserved, that none of the other
projects got off the drawing board (within Microsoft) and that most of
the Microsoft people who did work on the Alpha have left.

The porting was by DEC. DEC had to pay for the whole port. Trouble was, NT
couldn't compete against OpenVMS and TRU64 UNIX on the Alpha. Not enough
features and pretty rough around the edges. DEC dropped developement for
M$.
M$ let the other vendors do the port of NT to their perspective platforms.
When the vendors finally woke up, they dropped NT.

The real issue is whether the Itanium port has been done competently,
or by simply spawning off another completely unportable code stream.
I have not heard any reliable rumours either way.

OpenVMS has been ported successfully to the Itanium2 processor as well as
TRU-64 UNIX. Whether HP keeps tru-64 unix is another question tho.
When M$ has ported XP to the Itanium2 isn't known here nor have I seen any
ads on M$ website about it.

 

[Nick Maclaren]

The porting was by DEC. DEC had to pay for the whole port. Trouble was, NT
couldn't compete against OpenVMS and TRU64 UNIX on the Alpha. Not enough
features and pretty rough around the edges. DEC dropped developement for
M$.

That is what I heard, but I didn't hear whether Microsoft got the rights
to the updated source or not, nor did I hear whether Microsoft employees
were actively involved in the port (whether paid for by DEC or not).

M$ let the other vendors do the port of NT to their perspective platforms.
When the vendors finally woke up, they dropped NT.

I heard that few of them got further than an evaluation, too ....

OpenVMS has been ported successfully to the Itanium2 processor as well as
TRU-64 UNIX. Whether HP keeps tru-64 unix is another question tho.

Yes. The official answer to the latter is it won't, of course.

When M$ has ported XP to the Itanium2 isn't known here nor have I seen any
ads on M$ website about it.

Yes. I should have used a different tense! The question remains
relevant, unless Microsoft have cancelled the project, in which case
I think that Intel's screams would have leaked out


Regards,
Nick Maclaren.

 

[Del Cecchi]

snip

Yes. I should have used a different tense! The question remains
relevant, unless Microsoft have cancelled the project, in which case
I think that Intel's screams would have leaked out


Regards,
Nick Maclaren.

When I look at the brochure for the x450 and x455, it says "Supports
Microsoft Windows Server 2003, Enterprise Edition "
These are IA64 boxes. Is that XP?

del cecchi

 

[David Magda]

But I like your ideas better. Even with Intel, since Intel has
there own compiler, that is as far as I know, free to use with
Linux for non-commercial use. And who would know how to create a
compiler for an Intel chip better than Intel? Although I also read

[...]

Part of the issue is that the code in the Linux kernel has a lot of
"GCC-isms" in it. Quirks and way of coding things to make things work
correctly.

In the past the Linux kernel even had code which worked around known
bugs in earlier version(s?) of the GCC compiler. Even with the newest
2.6 kernel series I think (correct if wrong) that you still need to
use GCC 2.95.x to compile the kernel. Many distributions have one
compiler for the kernel and another for the userland.

I know that FreeBSD had to go through a lot of code and fix it up
when they imported GCC 3.{1,2,3} into their 'base' system. Though as
it stands the default compiler (kernel and userland) is GCC
3.3. Installing other compilers (e.g., ICC, TenDRA) is possible but
not support for building the 'base' system.

 

[E]

Intel is still holding out for IA-64 across the board. Their original
plan had IA-64 dominating the server world by 2000 and starting to
take over the workstation market at that time. Then, by 2002 and 2003
IA-64 was supposed to be replacing IA-32 on the desktop and in all
except the low-end and mobile chips.

Obviously things haven't played out quite how Intel had hoped! Still,
they've put too much time and effort into IA-64 to abandoned it just
yet. Announcing a 64-bit extension to x86 for the Xeon would pretty
much kill off the Itanium line.

Thats interesting, so Intel might one day have an IA-64 and an AMD x86-64
aimed at desktop PCs?

Rumor has it that Microsoft has told Intel that they've already played
their 64-bit hand with the Itanium. That was their one and only shot.
If they want another 64-bit architecture, it'll have to be one that MS
already supports, ie AMD64.

Yes, I read this same rumor. But I don't understand why if Microsoft already
has a version of XP for the Itanium, they would drop support for it in
favor of a version of Windows for x86-64, and tell Intel to follow suite
with there desktop CPU line. I guess its the built in 32 bit compatiblity
of the AMD x86-64.

 

[David Magda]

The problem might be that most users of open source Op Systems,
like Linux and FreeBSD, are used to getting their application
software under a similar arrangement. There might not be much money
to be made from commercial applications competing head-on with
open-source equivalents like The Gimp. Would Microsoft ever do a
Linux version of office to face Sun's Star Office ? Probably not !

Commercial apps may have features that are not available in
OSS. GIMP does not have CMYK (?) support which is a must in the
graphics business. (Supposedly this will be rectified in GIMP 2.0.)

Drivers and utility programs are a different matter, though. Quite

[...]

Actually there are projects for both Linux and FreeBSD to be able to
use NDIS Windows drivers. Looks quite promising.

I don't think there is much profit made out of drivers, though.

All the hardware manufacturers have to do is release the
specifications. I'm sure someone will create a driver for it.

 

[Stephen Sprunk]

The porting was by DEC. DEC had to pay for the whole port. Trouble
was, NT couldn't compete against OpenVMS and TRU64 UNIX on the
Alpha. Not enough features and pretty rough around the edges.
DEC dropped developement for M$. M$ let the other vendors do the
port of NT to their perspective platforms. When the vendors finally woke
up, they dropped NT.

Were there any platforms besides i386, Alpha, and MIPS?

OpenVMS has been ported successfully to the Itanium2 processor as well as
TRU-64 UNIX. Whether HP keeps tru-64 unix is another question tho.

I don't see why HP would continue supporting Tru64 if they've already got a
commitment to HP-UX on IA64. Also, HP appears to be putting some level of
support into Linux and GCC -- at least on IA64. How many different unix
flavors can a single vendor realistically ship and support?

When M$ has ported XP to the Itanium2 isn't known here nor have I
seen any ads on M$ website about it.

Windows Server 2003 has been ported to IA64. Whether XP was ported or not
is now moot.

S

 

[David Magda]

Set your wayback machine to the early-mid-90's and remember that
Microsoft sold Windows NT for a 64-bit platform (Alpha) before.
Rumors have it that other RISC platforms were targets back then

[...]

Actually it ran on PowerPC and MIPS as well, if I remember
correctly. This was NT 3.5(1) and maybe 4.0. It's one of the reasons
why NT has/had a hardware abstraction layer (HAL).

 

[Peter =?ISO-8859-15?Q?K=F6hlmann?=]

Set your wayback machine to the early-mid-90's and remember that
Microsoft sold Windows NT for a 64-bit platform (Alpha) before.
Rumors have it that other RISC platforms were targets back then

[...]

Actually it ran on PowerPC and MIPS as well, if I remember
correctly. This was NT 3.5(1) and maybe 4.0. It's one of the reasons
why NT has/had a hardware abstraction layer (HAL).

It did not run under NT4.
And the Alpha-version ran in 32-bit mode