A long overdue demise

On Tue, Apr 6, 2010 at 5:59 AM, Prokash Sinha wrote:
> Yep, you are right. RedHat has been ported to IA64. Also SPARC is under-nurished these days. AIX also supports some IA64, and kernel.org has a port for it too. I don’t know but I think novel’s suse also have a port.
>

AIX doesn’t support anything but IBM POWER. There was an early porting
effort to IA-64 circa 2000-2001, but was abandoned early. Just as
there was a SPARC porting effort for Windows that was abandoned in NT
4 days.

The only mainstream operating systems running on IA-64 this days are
HP-UX, OpenVMS, Linux and various BSDs. From this list, only HP-UX and
OpenVMS matter because you can’t run current versions on something
else.

IA-32 has become too expensive to replace. All the other platforms are
for some specific niche. I think this is caused partially by
Microsoft. UNIX/Linux vendors AND ISVs have adapted extremely fast
to architecture changes. It has never taken more then an year for any
historic transition to occur (including x86 -> x64) in UNIX/Linux
world.

In Windows, even a simple transition like x86 -> x64 takes forever,
Microsoft provides x64 software only for Windows and SQL-SERVER. What
about Office and Visual Studio? (I hear Office 2010 will run on x64).
Why does Visual Studio, when running on 64 bit windows and targets 64
bit binaries, use 32 bit cross compilers?

I also blame Intel for the slow 64 bit transition. When 64 bit SPARC
appeared, compiler could produce binaries that used new 64 bit
instructions and 32 bit pointers. This is important because a lot of
software doesn’t need 64 bit pointers (decreasing address bus pressure
and increasing memory throughput) and because new 64 bit plugins could
work with old 32 bit software!

/end rant.


Aram Hăvărneanu

>

On Tue, Apr 6, 2010 at 5:59 AM, Prokash Sinha
wrote:
> > Yep, you are right. RedHat has been ported to IA64. Also SPARC is
under-
> nurished these days. AIX also supports some IA64, and kernel.org has a
port
> for it too. I don’t know but I think novel’s suse also have a port.
> >
>
> AIX doesn’t support anything but IBM POWER. There was an early porting
> effort to IA-64 circa 2000-2001, but was abandoned early. Just as
> there was a SPARC porting effort for Windows that was abandoned in NT
> 4 days.
>
> The only mainstream operating systems running on IA-64 this days are
> HP-UX, OpenVMS, Linux and various BSDs. From this list, only HP-UX and
> OpenVMS matter because you can’t run current versions on something
> else.

FWIW (not much :), Xen also runs/ran on IA64. Someone asked if I could
look at porting my PV drivers to IA64. I looked, but it was a fairly big
change so it didn’t happen. I don’t feel so bad about it now :slight_smile:

> In Windows, even a simple transition like x86 -> x64 takes forever,
> Microsoft provides x64 software only for Windows and SQL-SERVER.

And Exchange (AMD64, not sure about IA64)

James

There’s so much nonsense in this I barely know where to start. I just HATE it when a post like this puts me in the position of having to defend and explain Microsoft to people who are so very obviously clueless.

FIRST of all, without Microsoft there probably would BE no x64 as we know it today. Seriously. If you’re not aware of this, you don’t know the history of the chip or how the chip was developed.

SECOND, *very* shortly after the AMD64’s (Hammer) release, Windows was RTM’ed with x64 support. I don’t call that “taking forever.” Further, you’ll note that when Windows-64 shipped with x64 support, it shipped with VERY good (not perfect, but VERY good) compatibility. Tons of down-level apps ran just fine as 32-bit apps. And those apps typically ran (and today do run) FASTER than they do on x86.

And, by the way, “even a simple transition like x86 -> x64”? Simple? Really? From an OS point of view, that’s SIMPLE? I don’t think so.

THIRD, *the* limiting problem for x64 has always been driver support. Linux systems don’t support one TENTH of the devices supported by Windows. MSFT had the OS support, the core driver stack support. It took the ISV’s *ages* to get their drivers 64-bit compliant. The only thing that caused 64-bit drivers to eventually be released was Microsoft’s (heavy handed, for my tastes, but unfortunately required) policy of REQUIRING x64 drivers to be provided when x86 drivers were logo’ed by WHQL. If it was up to ISVs and OEMs, there STILL wouldn’t be any 64-bit drivers.

FINALLY, you entirely miss the point about x64 on Windows when you ask “What about Office and Visual Studio?” – What ABOUT office and VS?? While I have no doubt that everything will eventually be native 64-bit (because 32-bit Windows will in time be deprecated)… in the mean time who gives a rat’s ass if Office runs in 32-bit mode or 64-bit mode? Again, let me repeat, the 32-bit version runs faster on 64-bit Windows than on 32-bit Windows. We tend not to port things to different architectures here in the Windows world just for the sake of doing it, like they do on Linux.

Now, I return you to the discussion of the IA64… Is that “Nearer My God To Thee” I hear playing in the background?

Peter
OSR

Intel and HP should have paid me $10,000,000 to explain to them why the
Multiflow design failed and why they were going to fail too. They could have
saved x billiions and I would have the FU money to stop doing this crap.

Mark Roddy

On Mon, Apr 5, 2010 at 1:06 PM, Don Burn wrote:

> For those who have not seen it, the Windows Server Division said Windows
> Server 2008 R2 and Visual Studio 2010 are the last to support Itanium.
> See
> http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server
> -2008-r2-to-phase-out-itanium.aspx Finally the Itanic is sinking under
> the waves.
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Ironically years ago I did a research paper for a major Intel partner
that basically proved that the performance for anything other than
specialized highly parallel applications was not there. I know the
paper was forwarded to Intel. Years later I was interviewing at the
same company and they were excited about the great benchmarks of IA64
(though the chip was not release yet). I was having lunch with the head
of advanced research and asked “Which benchmark towers of Hanoi or
Stanford loops?” Ended up I sent them the paper again and their
enthusiasm wained.

Multiflow was truly a scam, they claimed great performance including
having hardware (albeit running at slowed down clock speeds). When the
company shutdown interestingly the hardware did not work, and no one
could repo their performance numbers, of course all the major players
moved on to positions at HP and Intel promising even better performance
“on all applications” which of course never happened.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

From: xxxxx@gmail.com [mailto:xxxxx@gmail.com] On Behalf
Of Mark Roddy
Posted At: Tuesday, April 06, 2010 10:19 AM
Posted To: ntdev
Conversation: A long overdue demise
Subject: Re: A long overdue demise

 Intel and HP should have paid me $10,000,000 to explain to them why the
Multiflow design failed and why they were going to fail too. They could
have saved x billiions and I would have the FU money to stop doing this
crap.
 
 
Mark Roddy

On Mon, Apr 5, 2010 at 1:06 PM, Don Burn wrote:
For those who have not seen it, the Windows Server Division said Windows
Server 2008 R2 and Visual Studio 2010 are the last to support Itanium.
See
http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server
-2008-r2-to-phase-out-itanium.aspx Finally the Itanic is sinking under
the waves.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Information from ESET Smart Security, version of virus
signature database 5004 (20100406)


The message was checked by ESET Smart Security.

http://www.eset.com

I hereby nominate Mr. Roddy’s post, above, for the highly sought-after Post Of The Week award (play trumpet sound here), with all the rights and privileges appurtenant thereto.

Peter
OSR

On Tue, Apr 6, 2010 at 5:14 PM, wrote:
> FIRST of all, without Microsoft there probably would BE no x64 as we know it today. Seriously. If you’re not aware of this, you don’t know the history of the chip or how the chip was developed.

Oh, I am well aware of that fact. In fact, there’s more to it! If it
were not Microsoft, IA-32(e) as a whole not be as we know it today. I
would be the same toy architecture it was 20 years ago when RISC ruled
the market. But I think that if the mainstream arch people use today
would be one of those kind of architectures, the world would be a
better place.

So yes, I thank Microsoft for making x64 as a better x86, but I don’t
like that the reason there was a need for x64 in the first place was
the Microsoft ecosystem (not the company, but the whole ISV pool with
their little apps).

> SECOND, very shortly after the AMD64’s (Hammer) release, Windows was RTM’ed with x64 support.

So did NetBSD and Linux. In fact, the NetBSD port appeared before
the silicon was out. It was developed on the Virtutech Simics
Emulator. Just like Windows.

> I don’t call that “taking forever.”

But it does take forever. It is still not done. You think I was
referring to Windows when in fact I am referring to the whole Windows
ecosystem, with all ISVs doing their small apps and whatnot. When I
did say “UNIX arch transitions happen quickly”, I did not mean OS
(kernel + support utilities) transition, as you might have assumed,
but the transition of the whole ECOSYSTEM. Of COURSE every sane OS
could be ported to whatever arch in about the same time, provided the
complexity is about the same, but a couple of MONTHS after AMD64 got
out, 99%, THOUSANDS of Linux application were running in 64 mode on
it. Right now, my FreeBSD system reports over 17,000 64 bit ports of
random UNIX applications. Compare that to Windows ecosystem, where
only few vendors deliver 64 bit apps.

> Further, you’ll note that when Windows-64 shipped with x64 support, it shipped with VERY good (not perfect, but VERY good) compatibility. Tons of down-level apps ran just fine as 32-bit apps.

Depends on what you are comparing it with. Compared to Linux? Sure,
but we all know Linux sucks, right (at least I do). Linux has no
notion of backward/forward compatibility in the first place.

Windows compatibility is pretty good, but behind Solaris
compatibility. I don’t know much about AIX and HP-UX, I only speak of
what I know. At least Solaris doesn’t have 32 bit binaries in SysWOW64
and 64 bit binaries in System32…

> And, by the way, “even a simple transition like x86 -> x64”? Simple? Really? From an OS point of view, that’s SIMPLE? I don’t think so.

It is simple compared to a transition like PPC -> IA-32 or ALPHA ->
Itanium or PA-RISC -> Intanium. Mac OS X switched from PPC to IA-32, a
rather hard thing to do, and nobody noticed.

> THIRD, the limiting problem for x64 has always been driver support. Linux systems don’t support one TENTH of the devices supported by Windows. MSFT had the OS support, the core driver stack support. It took the ISV’s ages to get their drivers 64-bit compliant. The only thing that caused 64-bit drivers to eventually be released was Microsoft’s (heavy handed, for my tastes, but unfortunately required) policy of REQUIRING x64 drivers to be provided when x86 drivers were logo’ed by WHQL. If it was up to ISVs and OEMs, there STILL wouldn’t be any 64-bit drivers.

But that is absolutely EXACTLY the same thing I am saying. The problem
is because I typed “Microsoft” in my previous post, you ASSUME I was
referring to the COMPANY, when in fact I was referring to the
ECOSYSTEM. It may be my fault that I was not specific enough.

And although I don’t like Linux on any level (philosophy, code etc)
and would not recommend it to any sane person, I must object to your
statement regarding 10% of supported Windows devices. That is a gross
overexageration, and in the server world I’d say (unfortunately!) that
Linux supports pretty much the same hardware as Windows does.

> FINALLY, you entirely miss the point about x64 on Windows when you ask “What about Office and Visual Studio?” – What ABOUT office and VS?? While I have no doubt that everything will eventually be native 64-bit (because 32-bit Windows will in time be deprecated)… in the mean time who gives a rat’s ass if Office runs in 32-bit mode or 64-bit mode? Again, let me repeat, the 32-bit version runs faster on 64-bit Windows than on 32-bit Windows. We tend not to port things to different architectures here in the Windows world just for the sake of doing it, like they do on Linux.

Porting things to different architectures is always a very good thing
to do. It means that the code quality will be higher and you’ll catch
more bugs.

The thing goes like this. ISVs look at other ISVs and see that they
are doing 32 bit only, therefore they decide that they shouldn’t
bother with 64 bit because others are not doing it. At least
companies/people that I worked with think that way. And then nobody
does 64 bit. And then Microsoft has to support 32 bit forever with all
kind of ugly hacks like the SysWOW64 thing because ISVs can’t be
bothered to write correct code. IMHO, complete transition to 64 bit
will happen only when Microsoft will FORCE people to do it.


Aram Hăvărneanu

I don’t recall whether it was Ed Dekker or I who made this statement, but it
was one of us, after we saw the announcement of the IA-64

“Itanium is the 432 of the 90s”

Does anyone remember the Intel 432 chip? Late1970s. A truly fascinating
architecture, well ahead of its day, completely and utterly
non-cost-effective, far too slow to be usable.

The whole point of the IA-64 architecture was that you would not have to
devote acres of silicon to producing the illusion of a synchronous CISC
architecture on top of an asynchronous RISC architecture. I knew it was
doomed the moment I read the statement that “the compiler will optimize the
concurrency”. I had a student, back when I was University faculty, who
worked on optimizing horizontal microcode to maximize concurrency.
Essentially, what you get is the NP-hard “bin packing problem”. What saved
him was that he was working with very small microstores (256 horizontal
microinstructions, max) and had some heuristics that gave pretty good
answers without wandering into NP-hard computations. So the idea that you
could build a compiler which would solve an NP-hard problem, optimally, on
every compilation, for large programs, seemed foolish (it sounded like some
hardware geek figuring “we can do anything we want, and The Software Will
Solve All Remaining Problems” Or, as I call it, the inevitable consequence
of software illiteracy in hardware people, which I don’t have to explain to
THIS group!). Friends who are compiler experts have told me (I have not
looked myself) that the code [for those who don’t know: the IA64 can
nominally pack three instructions into a 64-bit quadword, and control bits
determine which instructions run concurrent with which other instructions
within the quadword] that they see from IA-64 compilers producing output
that “consists of one instruction and two NOPs per quadword” and a computer
architecture expert once told me that “there is no way you can beat a
pipelined superscalar architecture with an IA-64-style architecture” (he was
the designer of several major RISC computer systems, which still sell to
this day). Ultimately, everyone who ever saw the architecture predicted it
was doomed, and it has merely taken a very long time to have Intel realize
that. It took them years to see the 432 was doomed, also.

joe

Well, I’ll allow myself the luxury of one additional reply and – if there’s any more to be said about this – it needs to go to NTTalk.

Well, we disagree. I think I was being generous to Linux, frankly. OK, maybe you could convince me that Linux supports 20% of the devices that Windows support… but I think that’s seriously pushing it. Now… I’m not talking about servers. I’m talking about devices supported AS A WHOLE. You’re the one who mentioned Office and Visual Studio, neither of which typically run on servers.

Huh? Beyond the implicitly contained comment “a line by line code review is always a good thing to do, and will result in higher code quality and you’ll catch bugs” I don’t understand how this can be. Adding MORE CODE, or changing existing code so it works in a different environment but still works in the environment in which it was originally intended to run, results in FEWER bugs? Well, that’s the first time anybody tried to tell me THAT. Sorry, I’m not buying it.

It’s correct as 32-bit code. There’s no NEED to update it.

The x64 runs 32-bit code natively. There’s no translation involved. The convergence layer in the OS is very thin, and comprises thunking from 32-bit to 64-bit, basically. 64-bit Windows runs 32-bit applications FASTER than those applications run on 32-bit Windows. Lacking the need for a larger virtual address space, there is absolutely no compelling need to re-write 32-bit application code to become 64-bit application code at this point. Will it EVENTUALLY happen? Sure. But this isn’t like the 16-bit to 32-bit transition where almost EVERYONE needed the extra address space. Or the (cursed) x86 to IA64 move, where you have to upgrade or the performance of your app sucks due to translation and unaligned access issues. No. Because 64-bit Windows on the x64 is DESIGNED to allow 32-bit apps to happily co-exist.

In terms of “ugly hacks”… in whose eyes? I’m sure Mom and Dad don’t know – or care – what the SysWow32 directory is, or that there are 64-bit executables in the System32 directory. I bet they don’t even know that there ARE 64-bit executables or what the “32” in System32 refers to. To them, and in fact to any sane user, System32 is the system after System31 and the one before System33. In fact, *I* don’t even care. Why should I?

Insert program, run program, program works… user gets work accomplished without annoyance. Done. Full stop.

Ahhhh… different strokes, I guess.

Peter
OSR

Joseph M. Newcomer wrote:

The whole point of the IA-64 architecture was that you would not have
to devote acres of silicon to producing the illusion of a synchronous
CISC architecture on top of an asynchronous RISC architecture. I knew
it was doomed the moment I read the statement that “the compiler will
optimize the concurrency”. I had a student, back when I was
University faculty, who worked on optimizing horizontal microcode to
maximize concurrency. Essentially, what you get is the NP-hard “bin
packing problem”.

It’s true that this is a hard problem, but that doesn’t necessarily
“doom” a processor. The Philips/NXP/Trident Trimedia, for example, is a
VLIW processor with 5 slots per instruction, in which you can schedule a
dozen functional units. The compiler manages all of the latencies and
knows all of the dependencies. It takes a pretty freakin’ smart
compiler to handle that, but once you have a team that understands what
they’re doing, you can do amazing things. memcpy, for example, compiles
to two instructions.

Now, I’ll grant that the Trimedia has so far survived only in a niche
(although a large niche – odds are the set top box from your satellite
or cable company has a Trimedia in it), so maybe your assessment is not
so far off.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> I think I was being generous to Linux, frankly. OK, maybe you could convince me that Linux

supports 20% of the devices that Windows support… but I think that’s seriously pushing it.
Now… I’m not talking about servers. I’m talking about devices supported AS A WHOLE…

First of all, let’s decide what “Linux” and “Windows” are in this context. I would propose that “Linux” is the latest source tree available from kernel.org, and “Windows” is the latest RTM version. At this point we will be able to quantify things - we will be able to compare vendor/device ID in Linux sources and in .inf files on the Windows CD. Are you ready for that or you would prefer to make ridiculous statements without any backup whatsoever…

Anton Bassov

Anton,

Which part of

was unclear to you?

The part that included “any more to be said” in which I meant “said” as a sort of analogy, and didn’t mean it to actual pertain only to SPEECH, but rather intended to convent that my comment applied to any additional follow-ups of any type (via forum, email, or NNTP)…

the part about “this” meaning that my request applied to the discussion about x64 versus x86…

or the part about “it needs to go to NTTALK”, where once again I didn’t mean the actual POST should – of its own power – move to the other news group, but rather I intended this to imply that further replies should be posted to a different group, and not this one.

Peter
OSR

That would be the box that, on the order of once per week, performs the
belly button stare followed by manual power intervention?

I agree that within the confines of a restricted programming environment
some smart people might get the compiler right. All bets are off on a
general purpose system.

Mark Roddy

On Tue, Apr 6, 2010 at 5:38 PM, Tim Roberts wrote:

>
> Now, I’ll grant that the Trimedia has so far survived only in a niche
> (although a large niche – odds are the set top box from your satellite
> or cable company has a Trimedia in it), so maybe your assessment is not
> so far off.

Plus I should read the other messages before violating edicts. Sorry, over
and out.

Mark Roddy

On Wed, Apr 7, 2010 at 9:28 AM, Mark Roddy wrote:

> That would be the box that, on the order of once per week, performs the
> belly button stare followed by manual power intervention?
>
> I agree that within the confines of a restricted programming environment
> some smart people might get the compiler right. All bets are off on a
> general purpose system.
>
> Mark Roddy
>
>
> On Tue, Apr 6, 2010 at 5:38 PM, Tim Roberts wrote:
>
>>
>> Now, I’ll grant that the Trimedia has so far survived only in a niche
>> (although a large niche – odds are the set top box from your satellite
>> or cable company has a Trimedia in it), so maybe your assessment is not
>> so far off.
>
>
>

On Tue, Apr 06, 2010 at 10:14:15AM -0400, xxxxx@osr.com wrote:

THIRD, *the* limiting problem for x64 has always been driver support.
Linux systems don’t support one TENTH of the devices supported by
Windows.

Just a small note to correct this inaccurate statement. Linux actually
supports more devices than any other operating system, including
Windows. It has been this way for quite a number of years, and this
fact has been independantly verified by Microsoft itself (off-the-record
of course.)

thanks,

greg k-h

Great note Greg :),

Aram, I like the level of abstraction that the linux kernel has and I like the stability that FreeBSD has.

Only if you count TiVo and mass spectrometers and other similar instruments.

But next time I try to get my multi-monitor Nvidia system, or my laptop with a wifi card, doing something useful… I’ll certainly think of how great the device support is on Linux.

Clearly, we’ll just have to agree to disagree on this one…

Peter
OSR

Well, just one data point…If you read and follow the instructions
exactly, getting dual monitors to work (very well) under Ubuntu Linux on my
quad-core was a piece of cake for me and I am NOT a Linux guru by any
stretch. I also had no problems with ALL of the hardware (WiFi, touch
buttons, etc) on my HP dv6120 with plain vanilla ubuntu. It wasn’t until
Windows 7 did that work without a ton of special drivers from HP. My
ExpressCard eSATA adapter worked out of the box with Ubuntu and I had to go
get special drivers for Windows 7 from the manufacture’s web site.

Having used and abused both, my experience is that Linux supports mainstream
hardware far better than Windows.

Greg (not the same one)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, April 12, 2010 9:13 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] A long overdue demise

Only if you count TiVo and mass spectrometers and other similar instruments.

But next time I try to get my multi-monitor Nvidia system, or my laptop with
a wifi card, doing something useful… I’ll certainly think of how great the
device support is on Linux.

Clearly, we’ll just have to agree to disagree on this one…

Peter
OSR


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Guys,

Actually, we are already discussing it with Peter and few other participants on NTTALK - you can check our argumentation there…

Anton Bassov

On Mon, Apr 12, 2010 at 10:12:30AM -0400, xxxxx@osr.com wrote:

Only if you count TiVo and mass spectrometers and other similar instruments.

I’m curious as to why you would not consider those valid devices? Are
they not valid platforms to support?

But next time I try to get my multi-monitor Nvidia system, or my
laptop with a wifi card, doing something useful… I’ll certainly
think of how great the device support is on Linux.

I have multi-monitor systems working as well as every wifi device
currently known, working just fine “out of the box” today.

Seriously, the “there is no drivers for Linux” myth was disproven a long
time ago, please don’t perpetuate it.

Clearly, we’ll just have to agree to disagree on this one…

Clearly :slight_smile:

thanks,

greg k-h