Re: Alpha remembrance day

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 it would also be nice if your Windows filesystem cache example
was really a 32bit issue and not just an MS issue.

However as is usual neither is the case.

Most vendors who support dual 64/32 bit architectures such as SPARC,
POWER and x86-64 try to ensure that people only port applications that
will benefit from being 64bit to being a native 64bit application. This
is not just because the effort involved would be wasted but also
because in some cases the 64bit ports will be slower than their 32bit
counterparts. OSnews and other online publications are peppered with
tests illustrating the negative impact of native 64bit applications for
some commonly used tools and applications. Performance hits can be up
to 20% with other issues such as larger executables on disk, bigger
memory footprint and higher cache useage. Most vendors identify
applications that can use more than 4GB of memory, with other benefits
after that which have lower returns.

Your point about 32bit filesystem caching may be valid for Windows
however other 32bit OS's such as Solaris did not have this problem, the
Solaris 2.x UFS buffer cache could be larger than 4GB despite the OS
only being 32bit. Sun even had a marketing name of SuperCaching for
this.

So much for your claims for the universal understanding of the 64bit
benefit.

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. Having to trade I/O/CPU and
memory slots in configurations ment that having a decent I/O
infrastructure of decent number of CPU's severely limitted the number
of slots available for CPU's.

The hype arround VLM created by Digital caused some customers to buy
TurboLasers to host 64bit versions of Oracle, it quickly became clear
to most of them that the other limitations of the platform limitted the
benefits they might have acheived.

The TurboLaser held the TPC OLTP performance crown between 1995 and
1996 but was overtaken by HP, Sun and IBM. Alpha boxes never featured
in the TPC OLTP stakes again except by using multi-node clusters.

The issues configuring the TurboLaser to make best use of its large
memory support is well illustrated by the TPC-C results posted by
Digital. Despite supporting 14 CPU's no 8400 results exist for more
than 10 CPU's and most are for 8, this is mainly because in order to
get enough memory to support the benchmark and enough I/O Digital had
to drop CPU's from the config.



The more serious part of the industry has of course been 'really looking
at 64 bit stuff' for considerably longer - it having been one
significant reason, for example, why Tru64 enjoyed the level of success
it did despite its owner's earlier Unix missteps, and why the rest of
the RISC brigade tried to catch up with Alpha and MIPS in that regard
sooner rather than later.


Again you are mistaken, Sun spent a great deal of time worrying about
losing business to Alpha because of its 64bit support. However after
the initial flurry of purchases many customers discovered that you
couldn't really benefit from having a 64bit platform at least not with
Alpha and so Sun stopped worrying.

Regards
Andrew Harrison

.

Relevant Pages

  • Re: How to figure out what machine it came from?
    ... The memory controller on all the DECstation 5000/2x0 systems supports ... mixed memory configurations and the REX console will happily support them ... Ultrix I am told can only support contiguous memory ...
    (comp.sys.dec)
  • Re: Time to produce EV79s!
    ... any CPU variant newer than McKinley ... Supported memory configurations range from 512 MB to 64 GB. ... V8.2-1 also adds support for some mid-range and high-end server ...
    (comp.os.vms)
  • Re: Alpha remembrance day
    ... wouldn't say that Alpha was late. ... that example you introduced is only true for Windows doesn't increase ... You don't need 64bit support to ... Since I already pointed out Pentium's support for 64 GB of RAM since ...
    (comp.os.vms)
  • Re: Code density and performance?
    ... Heck, IPF memory requirements make ... It wasn't when the Alpha was designed. ... |> You mean the "POSIX" documentation, ... |>> You may regard breaking standards without even documenting the ...
    (comp.arch)
  • Re: Alpha remembrance day
    ... losing business to Alpha because of its 64bit support. ... Alpha and so Sun stopped worrying. ... Yeah, I heard similar from various Sun folks, too. ... And by the time AlphaServers did support configurations that made 64bit ...
    (comp.os.vms)