Re: Alpha remembrance day


Bill Todd wrote:
Andrew wrote:
Bill Todd wrote:
Andrew wrote:
Bill Todd wrote:
Michael Kraemer wrote:
In article <44E6087E.FA9BDDEC@xxxxxxxxxxxx>, JF Mezei
<jfmezei.spamnot@xxxxxxxxxxxx> writes:

Well, considering it was the first "mainstream" 64 bit architecture, I
wouldn't say that Alpha was late. If at all, it was early to the market.
even if it were true (Andrew corrected you on that one), so what ?
It is just now, more than a decade later that people start really looking
at 64 bit stuff.
Ah, you must be a PC weenie: that could explain a lot. Of course, even
PC weenies might have recognized what benefits a 64-bit architecture
could confer on systems configured with 4 GB or less of RAM (let alone
the 64 GB that IA32 servers have supported since 1996 - hmmm, I wonder
why Intel bothered with that?) if he were familiar with NT/2K/XP's
32-bit approach to its file system cache and how much *virtual* space it
can waste.

It would be nice if the benefits of 64bit are as clear as you think
they are
Actually, *most* things are rather close to what I think they are, since
(unlike you) I don't form firm opinions on negligible (and often
flat-out incorrect) data.

it would also be nice if your Windows filesystem cache example
was really a 32bit issue and not just an MS issue.
Since the context above was explicitly PC technology, moron, the two
aren't all that different. But I guess asking you to try to understand
what you've read before responding to it would be expecting far too much
of you.

So why did you introduce it ????????????????????????????

If you didn't understand why, then why on earth did you think that you
were even remotely qualified to respond to it?


This is a discussion about Tru64/OpenVMS and their competitors the fact
that example you introduced is only true for Windows doesn't increase
its relevance or did you think it did ?????

Hey, moron, it's not *my* job to deal with *your* confusion: if you
don't understand a conversation, stay the hell out of it.

...

The reality is that 64bit VLM support in Tru64 was of very limited
benefit because the AlphaServer platform was not configurable with a
usefull amount of memory, CPU's and I/O.
Given a choice between believing you and believing the Tru64 customer
base's opinions on this point, I'll take the latter any day.


Its not an opinion, just read the 8400 configuration guide.

Of course it's an opinion, idiot: an evaluation of *relative benefit to
the customer* (which you presumed to make, still right up there above)
is *always* an opinion (and, as I noted, one better advanced by the
customer in question than by some flack like you).

...

The reality was that the top of the Alphaserver range for most of the
90's was only really equivalent to a sun E4500/4000 (12 CPU's, 12GB RAM
redundant I/O).

The discussion (at least before you stuck your incompetent oar into it)
had nothing to do with Alpha vs. Sun or about the '90s: it was about
whether 64-bit support was of any significance before *now* (as you can
still ascertain - assuming that you are capable of extracting meaning
from simple text, though that fact is clearly not yet in evidence) by
returning to the start of this post and perusing the embedded quoted
material there).


Of course it was about Alpha vs the competition. If there had been no
competition then Alpha probably would have been a sucess. The fact that
there was and the reasons why Alpha wasn't competitive go back to the
core of this discussion.. What a bizarre suggestion.

Since the thread was about the demise of Alpha which clearly isn't
happening now, it has already happened your attempts to move the 64bit
discussion into the present entirely lack relevance. Perhaps you should
spend a bit more time reading the thread you are replying to.

As (yet again) I already observed, so listen up or shut up.

...

You don't need 64bit support to
have a single OS instance that adresses more than 4GB of RAM.

Since I already pointed out Pentium's support for 64 GB of RAM since
1996 (a feature also supported by NT, of course), I'm afraid that one
can't consider the above as anything resembling a new contribution to
this conversation.

http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

Sorry wrong again. The Pentium may well have supported 64GB of RAM in
1996 but but Windows NT Server 4 never did. Neither did Windows 2000,
in fact the first release of Windows that supported 64GB of RAM was
Windows 2003. So much for your contribution.

And why the ludicrous 8GB example later in your response ?????

At one point in the thread you demonstrate that you might know what you
are talking about and then later you demonstrate that you don't.

32bit
versions of Solaris, HP-UX, Dynix, AIX and Linux were all able to
support >4G. The Sun E10000 supported 64GB of RAM and one Solaris 2.x
instance could map all of that memory.

However indevidual processes couldn't address more than 4GB.

That, of course, being one of the advantages of a 64-bit architecture,
nitwit. Though of course a process in 32-bit NT/2K/XP *can* address
more than 4 GB of physical memory by explicitly mapping sections of its
32-bit virtual address space around the larger region.


Something
like Oracle consists of multiple processes but these processes need to
access the SGA which is where being able to support more than 4GB of
RAM for a single process becomes usefull.

Or, in the case of NT, instead uses a single process and maps around the
larger-than-4GB physical RAM that it's allowed to manage - an approach
often significantly more efficient than cobbling together multiple
separate processes in the Unix idiom (an idiom even more laughably
expressed in fumbling attempts to compensate for the lack of in-process
support for parallelism in the days before it had any support for
asynchrony or system-level process threading) but still not as efficient
as a 64-bit single-process approach.


This was impossible with NT because NT did not support more than 4GB of
physical memory. Of course 2003 is an NT derivative but it is also
64bit so your point lacks any relevance at all.

You also seem to have entirely missed the whole user level and kernel
level threads support which has been inherant in many UNIX's since the
early 1990's. Solaris 2.2 introduced in 1992 had kernel threads, with a
standard API which eventually became POSIX threads to let ISV's like
Oracle program for it.

Your point was out of date when Alpha was originally introduced.

...

In reality Oracle TPC-C platforms hit a wall at about 40-50K TPM where
4GB SGA's became a necessity. The problem was that the 8400 only ever managed about 50% of this. Sequent through the use of OPS in a box demonstrated how with multiple Oracle instances each with its own SGA you could defeat this limit on a 32bit platform.

It is hard not to conclude from your posts that you don't reallly have
a good grasp of the subject

Since you have so far not managed to draw any competent conclusions
during this discussion, I'd hardly expect you to begin now.


So provide some examples of the incompetent conclusions that you claim
I have or havn't drawn.
...

That 128 GB system, idiot, was a full 6 years ago (not that 64-bit
operation wasn't useful with as little as 8 or 16 GB of RAM, of course,
which takes us back a bit over 10 full years). Whereas the drivel to
which my earlier response was directed (as distinct from your own drivel
to which *this* response is directed) alleged that only *now* was 64-bit
support becoming interesting to customers.

You seem again to have compeletely missed the point.

No, you fucking idiot: the point (which once again you can see quoted
right up at the start of this post) was the ridiculous assertion that
64-bit support was only starting to become interesting *today*.


And your claim unless you had forgotten was that 64bit was interesting
a lot earlier than "today". Hence the discussion about how usefull
64bit was when Alpha was introduced. Or do you now want to select some
arbitrary point between 1992 and now to base your discussion of 64bit
relevance on ????

Regards
Andrew Harrison

.