Is Itanium the first 64-bit casualty?

Stephen Sprunk wrote:

[SNIP]

The distinction I've always used is that a workstation is a high-performance
server platform that was later scaled down to single-user performance,
whereas a desktop was designed originally with single user in mind and might
be later scaled up to make mid-range servers (often requiring extensive
kludges).

Seems like a better way of drawing the line.

Despite the different definition it still places Alphas in the
workstation slot and PCs in the desktop slot.

Mac IIs were schziophrenic by that definition, they could run
MacOS or A/UX.

Given the price and the spec I'd still the Mac II a workstation
because they were too pricey to find their way onto every desk
in an office. I'm making it sound like the universal truth, but
it's what I saw in practice. :/

The guys doing the heavy work (+PHB) would get a Mac II and the
rest would get something more modest like a Mac SE... At least
that is how it panned out at the few Mac sites I visited.

I've also heard the term "workstation" applied to x86 Linux boxes, so some
people seem to associate the term with running a real multiuser OS as
opposed to a consumer OS, not the hardware that is in use.

I think it's a fair cop in that regard.

Cheers,
Rupert

Scott Moore wrote:
Rupert Pigott wrote:

I think we should play the Marketoids at their own game : Let's start
referring to IA-64 as "Legacy" now that we have a dual-sourced 64bit
architecture in the x86 world.


It didn't get widespread enough to be a legacy.

I think it's old enough and dead enough and has had enough money thrown
at it to be called legacy though.

Cheers,
Rupert

In article ,
Rupert Pigott writes:
Dan Pop wrote:
In Rupert Pigott writes:


Worth noting that DEC did initially point Alpha at Embedded and low
end workstation space, and they continued their spasmodic efforts to
push it at the desktop for a long time.


Care to elaborate on the difference between "low end workstation" and
"desktop"? Since 1994, all low end Alpha workstations have actually been

Marketing and the perceptions of PHBs with the chequebooks.

PCs with an Alpha processor instead of an Intel processor. What can be
more "desktop" than such a system?

Not my call. Reminds me a little of the thread about some Intel dude
calling SPARC "proprietry".

I think we should play the Marketoids at their own game : Let's start
referring to IA-64 as "Legacy" now that we have a dual-sourced 64bit
architecture in the x86 world.

Easier to stick to absolute truths, and highlight just how proprietary
IA-64 is. (all the third-party IP holding, etc)

Dale Pontius

"Tony Hill" wrote in message
news
On Wed, 30 Jun 2004 14:42:01 -0600, "Judd"
wrote:
"Tony Hill" wrote in message
.. .

That's the last of 'em then. It looks like EVERY major Linux
distribution has managed to beat Microsoft to market with a usable
AMD64/x86-64 operating system (at least as long as you don't count
Slackware as a "major distribution", which most people don't these
days). SuSE, RedHat, Mandrake, Gentoo, Turbolinux and now Debian are
all out there now. Debian's distribution is still in the "unstable"
stream, but those who know Debian should know that Debian "unstable"
is roughly equivalent to pre-SP1 release of Windows rather than a beta
version.

Ohh, and FreeBSD and OpenBSD also have full support for AMD64 as well.
Kind of makes you wonder just what the heck is taking MS so long?!

What is taking them so long? Answer = Intel! If 64-bit was such a big
deal
for consumers, we would be looking at Itanium Workstations. 64-bit = not
big deal = why MS hasn't pushed it very hard. Wait for Intel's 80+
percent
market share to join in and then release something for OEM's to sell
their
i64 and AMD64 systems. It's a very smart business move.

Smart business move for who?!? For Intel maybe, but how exactly does
it help MS' cause? It's not like they're selling more by not having a
product now and I can't see any way that it would help them long-term.
Not releasing the product until the end of this year or early next
year (it looks like 64-bit Windows is being delayed *again*) is only
going to hurt Microsoft relative to Linux.


It isn't hurting them at all. Development costs $$$... In today's world,
you don't develop unless the $$$ is there. The $$$ isn't there until Intel
is OEM'ing large quantities of 64-bit hardware. Linux isn't gaining
anything at all from this.

Tony Hill wrote:
On Wed, 30 Jun 2004 14:42:01 -0600, "Judd"
wrote:
What is taking them so long? Answer = Intel! If 64-bit was such a
big deal for consumers, we would be looking at Itanium Workstations.
64-bit = not big deal = why MS hasn't pushed it very hard. Wait for
Intel's 80+ percent market share to join in and then release
something for OEM's to sell their i64 and AMD64 systems. It's a
very smart business move.

Smart business move for who?!? For Intel maybe, but how exactly does
it help MS' cause? It's not like they're selling more by not having a
product now and I can't see any way that it would help them long-term.
Not releasing the product until the end of this year or early next
year (it looks like 64-bit Windows is being delayed *again*) is only
going to hurt Microsoft relative to Linux.

I wonder if Intel's lack of IOMMU support beyond 4GB is going to result in
device drivers having to be revalidated under 64-bit Windows? If
manufacturers were using Opteron and A64 hardware to do device driver
validation, this incompatibility by Intel might require them to redo their
drivers to take into account the Intel discrepancy. I know that MS is now
having to redo its 64-bit beta just for the EM64T, since it breaks
compatibility in this way. Hopefully, the Windows code will have to bear the
brunt of taking care of Intel's oversight, and not the device drivers.

As it turns out Intel's 64-bit doesn't even support DMA beyond 32-bit memory
address boundary.

http://www.theinquirer.net/?article=16879

Yousuf Khan

Stephen Sprunk wrote:
I've never run across a desktop app that needs more than 2GB of
address space; for that matter my 512MB machine (with no VM) handles
anything I throw at it, though I'm sure it'd be a bit faster if the
motherboard accepted more than that.

Many news readers are running into the file size limitation when downloading
from binary newsgroups.

Yousuf Khan

Zalman Stern wrote:
I suggested using Boyer-Moore-Gosper (BMG) since the search string is
applied to a very large amount of text. A fairly straight forward BMG
implementation (including case insensitivity) in C is ~3 times faster
than strstr on PowerPC and SPARC for the test cases they use. On PIII
class hardware it is faster than strstr by maybe 50%. On a P4 it is a
little slower than strstr.

Typical story, the P4 seems to fall down anytime there is non-linear data
thrown at it.

AMD64 is a well executed piece of practical computer architecture
work. Much more in touch with market issues than IPF ever has been or
ever will be.

Even without the extra registers, AMD64 is achieving big performance gains
just with bog-standard unoptimized 386 code. Mostly due to the integrated
memory controller, I would gather, but also possibly due slightly to the
Hypertransport i/o.

Yousuf Khan

Stephen Sprunk wrote:
There was a year or so when an Alpha running x86 binaries on FX!32 did
indeed outpace the fastest x86 machines available, though by less
than a 50% margin. I believe it was right before the P6 core came
out.

As far as I recall, FX32 came out a long time after the P6 core introduced.
P6's first generation, PPro, was already obsolete, and they were already
into the second generation, PII. PPro was introduced in late 1995. I don't
think FX32 came out till sometime in 1997.

I'm sure FX32 could smoke an x86 core a couple of generations old, but it
never came close to any of the modern x86 cores it was competing against at
the time.

Yousuf Khan

Some ancient software (Premiere v4 IIRC) could happily write AVI files
beyound 2 GB, but such files were unusable.

Now, ODML AVI files are virtually unlimited in size.

There is no need to memmap a file to work on it. And it actually may be
slower than using explicit read.

"Rupert Pigott" wrote in
message ...
RusH wrote:
Tony Hill wrote :


thats FAT limitations

Not this time (though it could be in other situations). FAT32 has
a limit on file sizes of 4GB (unsigned 32-bit int)


ha, i was thinking about disk and thats where this FAT idea came, but
now I remember, its AVI file format limitation 2GB no more, there is
a new wersion of this format now supporting larger files

AVI was his *output* format, not the *input* format. What's more he had
verified that the input files were OK. I think he had the same idea that
perhaps they were junk after the 2GB mark.

Cheers,
Rupert

Yousuf Khan wrote:

I wonder if Intel's lack of IOMMU support beyond 4GB is going to result in
device drivers having to be revalidated under 64-bit Windows? If
manufacturers were using Opteron and A64 hardware to do device driver
validation, this incompatibility by Intel might require them to redo their
drivers to take into account the Intel discrepancy.

It seems the IOMMU is broken for Linux on some chipsets. If it is broken
hard on those, 64 bit windows should know how to work around that already.

I know that MS is now
having to redo its 64-bit beta just for the EM64T, since it breaks
compatibility in this way. Hopefully, the Windows code will have to bear the
brunt of taking care of Intel's oversight, and not the device drivers.

Probably also quite some assumptions in that code (no support for
certain support chips for example).

As it turns out Intel's 64-bit doesn't even support DMA beyond 32-bit memory
address boundary.

That would be very strange as it is supported (using 64 bit PCI
addressing) on older Xeons. But stranger things have happened... hmm...
switch CPU to 32 bit mode, do your 64 bit DMA, then switch back? Hehe...


Thomas