Experiences using the Internet Alpha System
>From Users of the Internet Demo System axposf.pa.dec.com
===========================================================================
Name:Francis Hsu
Organization/Company:MIT Computer Connection
Title:Consultant
axposf Username:francis
I used the DEC C and C++ compilers.
We already sell your Alpha AXP systems to MIT affiliated people (along
with having already bought ourselves a 3000/300L to demo). Most of our
AXP sales are the low-end (300 and 300L). We are interested in taking
a better look at the mid and higher end Alpha machines and your demo
machine, thankfully, provides us with an opportunity to do so. The main
concern of most of our customers is that the Alpha machines are relatively
new (and thus, untested in their eyes.. they KNOW the Alpha provides
great performance speedwise, but they are otherwise ignorant). They will
at least be partly relieved when I tell them that porting and developing
applications on the Alpha will be easier than some of the platforms they
already have experience with. My personal experience with your demo
machine leads me to hope that the Alpha will gain a greater presence at
our institution (actually, I already know it will since there are already
people working on porting Athena to it). But for now, I just want to get
our own Alpha demo machine's operating system updated to 1.3!!
Name: Peter Muessig
Organization/Company: University of Karlruhe, Inst. for Photogrammetry
and Remote Sensing
Title: Dipl.-Ing.
I'm using the Alpha AXP system for porting and increasing the
stability of our image processing software DIDIX.
Name: Sam Helwig
Organization/Company: Carnegie Mellon University
Title: Undergraduate
I ran several suites of benchmarks to demonstrait to myself (and
others) how powerful an Alpha system is compaired to all the other
hardware we have (including Dec's MIPS line, Sun Sparcs, 486 systems,
etc).
The AXP system is a _very_ powerful machine and has superior
performance to most other systems I have used. It blows away your
average workstation. The interactive performance in axposf.pa.dec.com
is sometimes rather pitiful, but I assume that is net lag combined with
having many interactive users (probably all running benchmarks, not
doubt). I would like to be able to purchase an Alpha. However, funding
for our current project has not yet been determined. For sure, an Alpha
will be high on my recommendation list, if the money is available.
Name: Larry Drebes
Organization/Company: Myca Inc.
Via your public access system, we ported our product (as of this point
unreleased on any platform) which is 90% C++, rest C, and a couple lines
of asm. We've chatted about the alpha and it's unique integer/pointer
size diff for quite some time (a year maybe more). Anyway, I took our
sun source try and got it up on your system over a weekend, yes
I had to change/add some code here and there. In spots there were a
couple of problems on our side, the rest was really header stuff. We
really didn't stress things, but it did work, and i've since compiled
more recent tree's to make me feel good.
Name: Adrian Wong
Organization/Company: Molecular Science Research Center
Batelle Pacific Northwest Laboratories
Title: Research Assistant
Ported and benchmarked a suite of computational chemistry
software. These programs compute the energy and wavefunction
of a given molecular from the basic physical laws. The software
is extremely CPU and I/O intensive.
I found the AXP4000 to be the fastest scalar machine
that I have come across. The user and system times (with the
times for the HP755 for comparison). [data deleted at respondent's
request].
Disappointingly, the I/O throughput was not commensurate
with the increased CPU speed. This appears to be current trend
in fast workstations. Indeed, when compared to slower and older
workstations (e.g. Apollo 10000, IBM RS/6000 550) the I/O speed does
not even seem noteworthy. [EDITOR'S NOTE: I/O speed is directly
related to disk speed, therefore will rarely differ between
systems]
I am not in a position to directly influence the purchasing
of workstations. However, the parties involved have been informed
of these benchmarks and the ease of porting existing code to
the AXP machines has been noted. I was very impressed by the
FUSE software (albeit a little slow over the network)
+++ +++ +++ NOTE: I've no idea of my employer's opinions +++ +++ +++
Name: James Clark
Organization/Company: James Clark
Title:
[Application Ported:] It's an SGML (ISO 8879) parser.
I was mainly interested in evaluating the C++ compiler.
It's good that DEC has chosen to produce a quality native C++ compiler
which implements the ARM completely. It seems to work quite reliably,
but the debugger seems to have some problems. On the whole it seems
to be a better compiler than anything available for Suns. C++
compilations seem to go about twice as fast as my current machine
(SPARCstation 10/41). If there was a tool like purify or Testcenter
available, it would be a first class C++ development platform.
I might well buy a single, small system to evaluate it further.
Name: Lee Brintle
Organization/Company: Project Panda, Inc.
Title: Director
The Panda Information Environment is one client and a series of servers that
provide Gopher, FTP, NNTP, SMTP, Raccoon, and Aardvark functionality. It is
designed to be one client that accesses all common information resources on
the Internet. I used the public-access Alpha to port the curses (vt100)
version of the client.
The Alpha was a fast machine, although the C++ compiler was too strict compared
to other compilers (cfront, g++, xlc, borland, symantic). As a result, there
were some porting problems, but those were resolved fairly easily. The
compiles were rapid, and ignoring the net lag the machine responded very well.
Although this was the first 64-bit machine we used for porting, I ran into
no problems moving from 32-bit to 64-bit machines (although we did plan for
this during the coding of the client).
[CAN QUOTE, BUT] please do not use the phone number listed above. If a phone
number is required for some reason, please contact me for a more appropriate
number. [CONTACT GAIL GRANT IF YOU NEED PHONE #]
Name: Richard H. Broberg
Org: Boston University
3. Based on your usage of the system, what is your evaluation of Alpha
AXP systems and how has this influenced your organizations plans for
purchase of Alpha AXP systems(please include number/type of systems
to be purchased, if applicable)?
I was happy enough to buy 6 3000/500s
Name:Ismail Haritaoglu
Organization/Company: Bilkent University
Title:
Our research area requires too CPU-intensive programs.
we are working on placement and routing algorithm on VLSI and also
new mapping heuristics.
We use alot of benchmark circuit and graphs .
It is realy too fast. We have SUN SPARCS 490 in our university and running
our programs takes too long time but using ALPHA AXP we get the result very
fast. We are planing to purchase an ALPHA AXP if we find a support. We will
apply to goverment for support to purchase it. Waiting too long time to get a
result is boring espacially if a faster machine exists. We will get some
results on your ALPHA and we apply to support with these result.
Name: david whittemore
Organization/Company: usda, ars, national soil erosion laboratory
Title: software engineer
checking portability of large ascii/graphical user interface
and fortran soil-erosion modelling code to the AXP machine.
too early to commit to a system for myself, but i am impressed.
thank you for the opportunity.
Name:Thomas J. Scott, Ph.D.
Organization/Company:Western Illinois University
Title:Associate Professor of Computer Science
I have been running a Harmonic Series convergence on the Alpha to
see how it compares to other cpus. My job finished in .35 sec on
the alpha, compared to 1.85 on our Sun, 13 seconds on an IBM 4341,
and 8 Seconds on a 486-33 Intel processor.
... I certainly appreciate getting to use the alpha in the
manner you allowed me to use it.
Name: Brent Townshend
Organization/Company: Townshend Computer Tools
Title: President
I am porting our software used to drive out digital audio interface
that is being used by customers on Alpha machines.
I rate them [Alphas] highly, the response is much faster than Sun, Dec,
or
SGI machines I have used, and the compiler, though a stickler for
details, seems quite good.
Name: Chris Pugmire
Organization/Company: Hort Research
Title: System Manager
CGLE, Graphics Language Editor, a public domain scientific graphing and
drawing package.
The port was much easier than expected, a couple of global
search and replace operations fixed 99% of the problems.
Access to this system has been extremely useful, we greatly
appreciate DEC making it available in this way.
We are currently considering a purchase of an OSF or NT based
alpha. This experience has given us some confidence in our
ability to port applications onto an alpha from our current
SUN platforms.
Name: Lawrence Smith
Org: University of Wisconsin - Madison
Database Administrator
Evaluation/Simulation of High voltage circuits, use of Spice for
circuit testing. Fractals and Strange attractor equations.
The ability to access the Alphas and port some of our in-house
software has greatly helped our evaluation of the system, and definetly
influenced us towards purchase of Alpha systems. There is still a need for
more software yet, but the speed of the system is excellent.
The majority of our code is in VAX-Fortran, with several applications
using REAL*16 floats, if the new f77 compiler supported these, we would have
a better chance to evaluate the Alpha and it's potential speed, and advantage
to us.
Name: Sebastian Hammer
Organization/Company: State Library Services, Denmark
Title: Programmer
We're developing a new bibliographic search engine for the Danish libraries'
Union catalog, and wished to test the performance of the system on the
AXP. Basically, the system performs lookups in large, file-based tables,
and matches the retieved keys against certain search constraints.
The benchmark was quick and dirty - with a transatlantic link between
us and the machine, it had to be. Nevertheless, we were pleased with the
results - the software, developed on a DECStation 5000, ported easily,
and performance was good, even though the machine were bogged down with
other benchmarkers. We (as software developers and heavy Internet users)
are extremely impressed with the service you're providing with the PA
machine. By the recent extensions to the service, you've gone a long way
towards answering the needs of your guests and benchmarkers.
[...]
You may use my answers, but note that I do *not* speak on behalf of
the Danish Library services (not to mention the Danish state :). I'm
just a tech underdog.
Name: Bernard Gunther
Organization/Company: University of Tasmania, Hobart, Australia
Title:
Primarily, my usage of axposf has involved porting a custom-designed
simulator of a 64-bit multithreaded microprocessor and evaluating its
performance - both as a simulation and as an experimental architecture.
The purpose of this was to assess the ease with which migration to a
genuine 64-bit environment could be made, and to compare the
performance of the AXP system against that of our local Sun and IBM
servers.
The simulator is written entirely in C; support software (optimizing
macro assembler, linker, librarian, trace tools) are a mixture of C,
yacc, and lex. The simulator uses no floating-point operations (IEEE
754 emulated in software for portability to VAX) and was designed to be
readily portable to *32-bit* architectures, making a 64-bit port
particularly interesting. The simulator, written at almost register
transfer level of detail, loads an executable binary and simulates its
execution, while recording detailed statistics on the behaviour of the
processor architecture. Although only 10k lines long, the simulator
has proven very difficult to optimize, as it shows poor locality in
many respects: vary large variable working set, frequent subroutine
calls, and execution activity spread almost uniformly across the
entire program for every simulation cycle. Simulations are virtually
CPU-bound processes, often executing for several hours when using the
full data set.
The AXP system proved to be an easy target for porting my software, and
it provides an environment that is relatively familiar to a UNIX user.
I was pleased by the performance, particularly on integer code....
Name: Steve Chappelow
Organization/Company: UNH
Title: System Programmer
I have been porting the UNH C* (a DataParallel language) compiler system
to OSF/1. Effort has been a success
Very speedy and responsive. Fastest plattform I use. Good modern
porting environment. OSF/1 has been robust and full featured and
quite painless. We are getting two AXP 3000/300L's.
Name: Thomas Looney
Organization/Company: Institute of Computer Based Learning,
Queens University, Belfast, Northern Ireland.
Title: Systems Programmer
I am part of a team developing Computer Based learning Tools.
Our s/w is required to work on multiple platforms,eg pc's, macs and
unix boxes. Our s/w is written using an in house class library system.
I am responsible for the unix end of the project. I was using the Alpha
to see if out application will compile , run. Basically to see what
difficulties if any there would be in porting our material to the alpha.
The Alpha is a very capable machine. I enjoyed using it. I did
not encounter any major difficulties using the Alpha. Being so far away
I/O performance was slow, But the Alpha CPU Performance is stunning. I
am looking forward to having one under my desk....
Name: Brian K. Holman
Organization/Company: Brigham Young University--Library Automations
Title: Programmer/Analyst
We current do our main dataprocessing in MVS on an IBM 3090.
We are discontinuing our work in that environment and will be
doing all our local development in OSF/1 on Alphas. Within three
year we will be completely downsized to Alphas.
We have made this for two reasons:
(1) The superior design of the Alpha chip
(2) The compatibility work in OSF/1 to bridge the UNIX flavors gap.
(3) The supplier of our main software system (NOTIS) has committed
to develop their next general software on DEC Alphas.
Name: THE NEXT QUOTE IS ANONYMOUS, AT RESPONDENT'S REQUEST:
I am a theoretical chemist and my research is in computational
quantum chemistry. I have been trying to get the molecular integral
program, "Molecule", running on the internet machine. This program is the
first in a series of programs that allows one to calculate
fundamental properties of atoms and molecules. These codes currently
run on a Cray C90 computer.
I am impressed with the speed of the Alpha AXP. I have not yet entirely
completed the conversion of this code to the Alpha AXP because of
some quirks in the original fortran. The lack of access to a Fortran
manual over the internet has also slowed the conversion.
However, preliminary timings show
that the Alpha AXP runs this code within a factor of two of the time
needed on a Cray C90. This is remarkably fast. At this time, I am
planning to purchase an Alpha AXP before the end of 1993.
Name: Christophe BRUNIAU
Organization/Company: Cap Gemini Sogeti
Title: Project leader
The ported application is an Ada simulation software kit that didn't compile
with SunAda.
Nor did it on DEC-Ada, but the compiler was able to explain why, so
it became possible to correct it.
The association OSF + DEC-Ada + DEC-Fuse seems realy positive to me.
This has not changed my organization's plans of purchase for the moment
but it may have influenced the minds in order to do so in the future.
Name: John Peck
Organization/Company: UCLA
Title: Phd program Graduate Student in Computer Architecture.
CAD Research
I have performed two benchmarking runs of a multiway logic
partitioner that implements a variation of a bi-way logic partitioning
algorithm due to Fidducia & Matheyess (sp?). The variation was
developed by John Peck and Steven Novak at UCLA in Spring 1993. I am
preparing a running time versus benchmark plot including the RS/6000
Alpha, and Sparc.
The alpha performs well on my application in terms of the CPU
time required to arrive at solutions. Qualitatively, the alpha is
faster running my program than an RS/6000 (config unknown).
Name:Joachim Wienbeck
Organization/Company:Forschungszentrum Juelich (KFA)
Title:Dipl. Phys.
The Alpha AXP did exactly what I expected it to do, and this quite fast.
I tried to avoid interactive applications, since the communication via
internet is not always very fast - for that reason I can hardly give a
balanced evaluation.
The organisation where I work (plasma physics institute) is right now in
the progress of buying several Alpha AXPs; my testing of the
axposf.pa.dec.com
did not influence the decision to buy these systems (they were in fact
ordered before I discovered the internet testing site).
Name: Raul de la Fuente Marcos
Organization/Company: Universidad Complutense of Madrid
Title: ?????
I am a spanish doctorate student. Although I belong to Universidad
Complutense of Madrid my Ph.D. advisor is Dr. S.J.Aarseth (I.O.A,
University of Cambridge, UK). I am doing my Ph.D. thesis using Aarseth's
code NBODY5, a standard code in the field of star cluster simulations.
I am using your machine for running the code.
NBODY5 is a FORTRAN code developed by S.J. Aarseth at Institute of
Astronomy in Cambridge, UK. His code for many years has been the basic code
for all serious research in star cluster dynamics by N-body simulation,
not only in the UK but also in the USA and Japan.
NBODY5 is allowing the study of gravitational systems by N-body
simulations. It use direct solutions in the sense that the total
acceleration acting on a given particle is calculated as a sum over
all the mutual interactions. Although this approach is relatively
time-consuming the increased speed of current computers (like yours)
permit quite realistic systems to be studied over significant times.
The characteristic membership of NBODY5 is 100-10000.
I have checked the performance of your workstation for NBODY5.
It is about twice faster than your mainframe VAX9210, for the same
initial data set.
My Ph.D. adviser (Dr. Aarseth) is so satisfied that he is going
to buy a DEC Alpha AXP for the HARP project ( a scientific program
on high performance computing in Globular star clusters evolution).
Name: Roman Baranowski
Organization/Company: Memorial University of Newfounland
Title: Ph.D. student
Currently I am working on a theoretical description of the poly-
mer brushes and adsorption of the diblock-copolymers onto the
surface . The theory is based on the path-integral method. The
main idea of the calculation is based on the solutions of diffu-
sion equations (2 are needed) modified by the 'potentials' which
strongly depend on the solutions. Hence, the problem has to be
solved in a self-consistent way.
The fortran code I was running on the Alpha-AXP machine is based
on the Crank-Nicholson Scheme. Since the solutions of the diffu-
sion equations have to be known at every time step at least two
2-dimensional arrays are required to store the data. Other arrays
are one dimensional and store the density of all components
present in the system as well as the spatial dimensions of the
system and the length of the polymer molecule (described in terms
of 'time' coordinate), but these two-dimensional arrays are the
most important factors.
The Alpha-AXP machine is a very good and powerful system. I had
no problems with the system (somtimes the disk was full, but this
is quite different problem). The only thing which was what was
lacking, was a diagnosis of how much memory and the cpu-time my
process was using (somthing which corresponds to 'top' command on
IRIX system). I am very pleased with the speed of the machine.
The cpu-time needed to complete the job was about 50% of the time
on IRIX Release 4.0.5F System V with:
50 MHZ IP17 Processor
FPU: MIPS R4010 Floating Point Chip Revision: 0.0
CPU: MIPS R4000 Processor Chip Revision: 2.
The Department of Physics Memorial University of Newfoundland has
bought Alpha-AXP machine.
Name: Jim Meyering
Organization/Company: Free Software Foundation
Note: I am a salaried employee of Computational Mechanics Co. Inc.
(COMCO) of Austin, TX, but I am the maintainer for the GNU fileutils,
shellutils, and textutils on a volunteer basis for the Free Software
Foundation.
Title: N.A.
I have been using this system to ensure the portability (esp. to systems
where sizeof(int) != sizeof(void*)) of the packages named GNU fileutils,
GNU shellutils, and GNU textutils for the Free Software Foundation.
Overall integer performance is higher than I'm accustomed to (I do most
of my development on an Iris Indigo R3000). Since most of my performance
experience with this system has been with the C compiler, I can't comment
on floating point performance. Apart from the C compiler bug I reported,
I have experienced no problems with the system software.
Name: Raja Amrutha Valli
Organization/Company: Memorial University of Newfoundland
Title: M.Sc. Student
I am working on the abinitio calculations using the first principle methods
to study the physical, chemical properties, geometries, energies etc. of
the molecules.
Density Functional Theory (DFT), containing 'correlation effet' is
utilized for calculating these properties. The theory is based on the
Hartre-Fock approximation. The Hartre-Fock equation is nonlinear and
must be solved iteratively. The calculation is based on the solutions
of the Hartre-Fock equations modified by the 'potentials' which depend
on the solutions. Hence the problem has to be solved in a self-consistent
way.
I am using deMon fortran code on Alpha-AXP for these calculations.
Major thing in my calculations is the handling of large number of
two-electron
integrals which are of the order of (K^4)/8, where K is the number of
Basis functions. So, deMon jobs require storage for the temporary,
scratch files that are generated during the run. These files may be large
(10-20 MB). The files can be disposed of quickly after the job is
completed.
The Alpha AXP system is a very powerful system. I am very much pleased
with the speed of the system. My code is twice as fast as on IRIX (our
department mechice). I had no problems with the system.
IRIX has
1 50 MHZ IP17 Processor
FPU: MIPS R4010 Floating Point Chip Revision: 0.0
CPU: MIPS R4000 Processor Chip Revision: 2.
Name: David Warren
Org: Dept of Atmospheric Sciences, AK-40
University of Washington
DECUS E-PUBS Library Committee representative
SeaLUG DECUS Chair
We can not yet port our application as NCAR Graphics is not yet
ported to OSF/1, but we did manage to convert it using mxr. Even
in this mode it is very fast. The application is a scientific
visualization program for atmospheric scientists. It reads up
to 4D data sets, slices and displays them in various formats. The
only part we haven't tested yet is the ability to dynamically
load user writen data transforms into the running program. I do
not expect this to work. When we do the real port, I will use
shared libraries instead.
It is fast and looks alot like ULTRIX and SUNOS4.1.3. I can find
things on it, unlike under SOLARIS 2. Porting of most things has
been easy. Most problems come from bad programming practices. When
we have found bugs, we got quick responses from the development team,
and they were fixed quickly. (We had a field test unit here as well).
We have 9 desktop units on order currently, and one other one
here already.
Name: Dan Cross
Org: Integrated Intelligence Systems
I hope to be able to aford a DEC 3000 model 800 workstation within the
next 6 months. The use of the Internet alpha running DEC OSF/1 was a
major part of this decsision. I am interested in performing a few more
porting tests, but there's always time for that.
I will be using the Alpha to develop radar simulation and control
software. It will not be networked, with perhaps the exception of
networking it with an 800S server, which I hope that I will have enough
money to purchase seperately. Please note that one these systems I will
run DEC OSF/1.
Purchase time is dependednt on the completion of my first project, a
monopulse simulation, which I am hoping will be completed in 6 months.
The exact systems and configurations will vary as to what is in the product
line, etc, at that time.
Initial impressions of DEC OSF/1 and the AXP system:
- Put wheels on it, and it would blow away a formula one race car.
- The software is solid, and I was impressed with the level of
compatibility and performance that it offered. Please note that
part of this observation came from Jon "maddog" Hall, and the
presentation he gives on DEC OSF/1.
- The development tools are superior in quality, fast, and conform
to standards. I like that.
- The hardware is quality, providing the floating point performance
that I need. The speed is perfect for the kind of real-time
performance that I need, and the operating system will support
the real-time applications I need, as well as the time-sharing
user interface. I like the idea of being able to control the
radar in real-time, while having the operator do analysis and
communication on the same machine.
Overall, the DEC Alpha appears to be the only machine that will support the
applications that I need, while still doing the real-time work that I need
it to, on the same machine. This provides for lower hardware AND software
costs for my customers, while still providing the functionality to get the
job done. I REALLY like that. Keep up the good work.
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) =====
% Received: by us1rmc.bb.dec.com; id AA25443; Wed, 1 Dec 93 13:29:08 -0500
% Received: by wrl.pa.dec.com; id AA29297; Wed, 1 Dec 93 10:28:58 -0800
% Received: by glg.pa.dec.com; id AA10857; Wed, 1 Dec 93 10:28:55 -0800
% Message-Id: <9312011828.AA10857@xxxxxxxxxxxxxx>
% To: cobra-usage@xxxxxxxxxx, human::supnik, memit::kim
% Subject: Publishable Quotes from the Internet Alpha System
% Date: Wed, 01 Dec 93 10:28:54 PST
% From: grant@xxxxxxxxxx
