Re: Alpha remembrance day

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

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.

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.

....

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.

....

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

At least when you were working for Sun one could, if one were charitable, consider your incompetent drivel to have been a form of competitive attack. For your current employer, however, it would seem likely nothing but an embarrassment with no compensating benefit: perhaps you should ask them how they feel about it before continuing to use their facilities (and time) to indulge your little Internet troll fetish.

- bill
.