AMD/Linux vs Intel/Microsoft

On Thu, 08 Jan 2004 17:05:04 +0100, Bernd Paysan wrote:

chrisv wrote:
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

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.

"Nick Maclaren" wrote in message
...

In article ,
(Tim Shoppa) writes:
| E 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" wrote in message
...
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

E writes:
[...]
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.

--
David Magda dmagda at ee.ryerson.ca, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

Tony Hill wrote:

On Thu, 08 Jan 2004 00:13:13 -0500, E
wrote:

snip


Although Intel currently has there own IA-64 architecture, this is aimed
at the server market,

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?


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

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.


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?

Not exactly. The program needs to be multithreaded. Simply
recompiling a program will not make it multithreaded, a
single-threaded program would need to be partially re-written to take
advantage of it.

However, that being said, any program that is designed to work on a
multiprocessor machine is already going to be multithreaded (or use
multiple processes). Basically any server application worth it's salt
is already written with multiple processors in mind, so SMT (or
hyperthreading in Intel's word book) is supported right out of the box
(though perhaps not in an ideal fashion). Hyperthreading is like a
poor-mans dual-processor setup in one chip.

There are a few pitfalls to this. SMT doesn't give you a full second
processor, just an emulation of one. You still need to share lots of
resources. In particular, if a program is designed to be split among
processors to optimize the use of cache in a dual-processor box it can
easily end up running slower with hyperthreading (each thread keeps
bumping the other's data out of cache). So, in this sense modifying
the code and recompiling can provide additional benefits for SMT.

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

It's in the works but not ready yet. The main issue is market demand,
or lack there of. Unfortunately AMD64 (aka x86-64) is basically a
negligible feature in the grand scheme of things at the moment. AMD
has sold, at most, a million AMD64 capable chips so far. For
comparison, Intel sells a million chips every three or four days.

What this means is that there isn't much incentive for Microsoft to
invest a lot of time and money into supporting an AMD64 port of WinXP
entirely on it's own. Supporting a separate architecture is
expensive, especially for a company like Microsoft that has LOTS of
different products that need to work together. To minimize costs,
Microsoft has wisely chosen to try and keep their AMD64 and their IA32
ports as close together as possible.

Unfortunately for AMD this means that WinXP for AMD64 won't be
released until Microsoft can synch up the releases of the two. That
isn't going to happen until this summer with the release of WinXP SP2.
If Microsoft were to release WinXP for AMD64 now it would be sort of
halfway in between SP1 and SP2 and would require extra cost to support
independently.

Will Linux companies pick up the slack, and
ban together with AMD to take some of the Windows and Intel market share?

Possibly, but not in huge numbers. In Q3 of 2003 AMD managed to sell
something like 10,000 servers. In that same time frame Intel sold
~500,000 Xeon servers. Even if every single one of those servers sold
went to Linux instead of Windows Microsoft is still not losing much in
the way of sales. However, the numbers will grow and if MS delays the
release of their operating system for AMD64 for too much longer it
might start costing them some real money.

There are already 64-bit Linux distributions ready. Will open source
applications be optimized for AMD x86-64?

Probably yes. Actually they just need to be recompiled to take
advantage of most of the new features of AMD64.

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.

Probably not. Porting a Windows application to Linux is a pretty big
undertaking for a commercial software vendor. It's a very different
environment from Windows and requires a lot of software changes as
well as increased support costs. If the application is already ported
to Linux, then porting to AMD64 is an easy option (case-in-point,
IBM's DB2, which apparently took all of 2 days to port from IA-32 to
AMD64 under Linux). However, porting a commercial application JUST
because AMD64 is supported under Linux now and won't be supported
under WinXP for 6 months makes absolutely no sense.

-------------
Tony Hill
hilla underscore 20 at yahoo dot ca

"Kevin Lawton" writes:

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.

--
David Magda dmagda at ee.ryerson.ca, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

"GreyCloud" wrote in message
...
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

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

(Tim Shoppa) writes:

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).

--
David Magda dmagda at ee.ryerson.ca, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

David Magda wrote:

(Tim Shoppa) writes:

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
--
Hardware, n.:
The parts of a computer system that can be kicked.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08 Jan 2004 17:09:22 -0500,
David Magda wrote:
E writes:
[...]
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 use gcc 3.x (whatever is the latest in Sid at the time I compile it)
and you can supposedly use icc (the intel compiler) to compile (for
intel cpu's only) Additionally, icc is supposed to have better
optimizations for intel cpus, probably at least in part, because they
don't have to support so many other architectures.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQE//e+nd90bcYOAWPYRAiBDAJ4jh8jSf+uQD+VJK+nAd5b1aMzh1gC goLb/
bOJSs0CVQo8wTXqyeVNxQ0w=
=i1xj
-----END PGP SIGNATURE-----

--
Jim Richardson http://www.eskimo.com/~warlock
"If guns cause crime, mine must be defective." -Ted Nugent