What workstations should we get?

Philip Helsel Sun SE-San Antonio 512-4904786 phillip.helsel at texsun.central.sun.com
Wed Sep 18 10:59:19 EST 1991


Carl-Georg Meinhof & Phillip Curtiss:
I saw your note on the net.  I hope you don't mine my responding.

>|Subj:	What workstations should we get?
>|
>|Dear Netters,
>|             the problem we have and most probably share with
>|others is to decide what workstations we should buy.
>|
>|Our department of molecular genetics plans to buy 7 workstations
>|together with one server. We thought about buying SUN
>|SPARCstations because we were under the impression that these
>|machines are the most widespread in the field. 
This is true Sun has 38% of the over all work station market and has
gained market share every year since we started shipping.  If you just
look at the UNIX/RISC market Sun has between 65% to 78% of the market
depending on who's numbers you use.

>|In terms of
>|compatibility this is a very important argument because we will
>|depent largely on software which is freely available. 
>|
An that is a excellent reason to buy Suns ... I attached a list
of public domain molecular biology software, most have no hardware
requirment but those that do all list Sun workstations.

>|Now it seems that SUN is lagging behind in its technology while
>|other systems (IBM's RS6000, HP, NEXT) offer more bang for the
>|buck. Is there as much software for molecular biologists
>|developed for these machines as for SPARCstations?
See attached list ... Yes Sun is behind in pure CPU floating point
speed but that will all change when our next generation super scaler
SPARC arrives.  This business is characterized by each company leap
froging the other.  That is why looking at the whole picture is
important.  See the attached independent study by Chalmers University
of Technology in Gothenburg titled "SPARCSTATION IPX OUTPERFORMS HP
SNAKE AND RS6000".  An also note IBM & HP have both shown that if you
are willing to trash binary compatablity you can make significant
performance improvements.  We are taking a different (and harder)
approach and keeping binary compatability with our next generation
SPARC systems.

As for NeXT ... who knows will they be around in 2 years?  NeXT was
started in 1985, Sun in 1982.  Look at where Sun was 6 years into it
life and look where NeXT is.  Thats the trouble with going with a 
property system not based on standards.
>| How much do
>|they differ in terms of source code compatibility? Is it a big
>|disadvantage that SUN is not part of OSF? 
>|
I don't think so ... but only time will tell.  OSF is so much vapor
that its just hard to say what they really do that is so wonderful.
>|Thanks for any suggestions
>|
Your welcome and thanks for your time.
PeH

		o /		o /		o /		o /
-----Cut-here----X-----Snip------X---Cut-here----X-----Snip------X---Ouch !
		o \		o \		o \		o \

attached 1: 
INDEPENDENT STUDY CONFIRMS - SPARCSTATION IPX OUTPERFORMS HP SNAKE AND RS6000

The next issue of Swedish computer magazine UNIX/Open Systems, due
out on Sep 19th, will contain an interesting workstation evaluation carried
out by independent researchers at Chalmers University of Technology in
Gothenburg.
Unlike far too many industry benchmarks (Dhrystone, SPEC etc) that
typically measure single task compute performance, this is a study of
performance in real workstation-type jobs , (CPU and I/O dependance, 
as well as multitasking performance).

The overall conclusion is that SPARCstation IPX has equal or better
performance in most tasks that are I/O-bound or combined CPU and I/O
bound and that it OUTPERFORMS THE COMPETITION when it comes to
multi-tasking. 

I think the failure of RS6000 and DECstation5000/200 in particular but also
of HP700 in these tests is quite sensational, and confirms that UNIX 
implementation and workstation SYSTEM design is genuine craftsmanship in 
which our competitors still have a lot to learn.

The article proclaims SPARCstationIPX the unchallenged champion when
it comes to "user-relevant performance". I think it is a good term. 
A personal comment is that the SPECmark phenomenon so far has had
very negative impact on the industry, as it draws inappropriate
attention to everything except what matters. 

Below is a summary of the benchmarks. Check out the multitasking test
in particular; it certainly made my day.

rgds
	-- sven uthorn, sun sweden

-----


Summary of Chalmers Workstation User's Benchmark Suite
-all values in seconds, ie lower numbers are better
Comments are direct quotes from the UNIX/Open Systems magazine, Oct 1991

		DEC5000/200	HP720CRX	RS6000/320 	IPX
		16M, 2x1Gb SCSI	16M, 420+664M	16M, 2x320M 	16M;207+669M
		Ultrix4.1	HP-UX8.01	AIXv3 		SunOS4.1.1

1A. CPU tests with various degrees of I/O dependence.
	
	a) grep1 (search non-existent word in 1 Mb file)
		1.4		0.9		0.9		1.4
	b) grep2 (9-12 Mb file, unit is s/Mb)
		1.7		0.9		1.1		1.5
	c) cp 	(copy 1 Mb file)
		2.5		2.2		0.9		1.0
Comment: "IPX is twice as fast as HP"
	d) cc 	(c-compile and link 10 program, 75 % of which on disk,
		remainder in cache)
		23		19		28		13
Comment: " IPX is outstanding"

1B. More I/O dependent jobs

		DEC5000/200	HP720CRX	RS6000/320 	IPX

	e) read1 (read 1Mb file to main memory from cache)
		0.2		1.0		0.2		0.2
	f) read2 (larger files, not in cache; unit s/Mb)
		1.0		1.1		1.2		0.6
Comment: " IPX shows impressive read performance"
	g) write 
		2.5		0.1		0.8		0.5
	h) strcpy ( repeated copy of 256k strings in main memory; s/Mb)
		0.2		0.05		0.05		0.12
	i) echo (echo 500k characters to standard output)
		11.1		18.6		48.6		58
Comment: "IPX is not very good on screen updates, which confirm
	previous tests...)

	j) emacs prim (coldstart of emacs, executable 4.5 Mb)
		3		4		3		3
Comment: "In summary, the I/O race ends in a tie between IPX and HP,
that compete in a class of their own"

3. Multitasking
   In these tests, an editing session is simulated, in which emacs is
   started on a 50 page document, a minor change is made and the file is
   saved). This is done with increasing background loads.

		DEC5000/200	HP720CRX	RS6000/320 	IPX

	Level1 (zero background load, "preheated" cache)
		1.1		0.6		0		0.4	
	Load2	(3 small compute jobs in the background)
		2.8		3.3		0.1		0.3
	Load3 ( additional background compilation)
		5.9		5.1		0.7		1.3	
	Load4 ( additional disk read/write)
		>130		8.1		>200		1.1
	Load5 (additional extensive screen updates)
		-		25.6		-		1.1	

Comment: "Only HP720 and IPX make it to the goal, HP is however much
more tired. This matters to a user, who intends to use his workstation
for more than one application. Waiting 8 seconds for an editor,
compared to 1.7 for IPX is of course frustrating"

4. "Real application" = Framemaker

		DEC5000/200	HP720CRX*	RS6000/320 	IPX

	k) Frame1 (start the application)
		5,1		-		7.2		7.6
	l) Frame2 (open 40 page document, bitmapped and PS graphics)	
		7.8		-		12.2		10.9
	m) Frame3 (search and replace)
		41		-		60		44
Comment: HP could not be tested,as their tapeformat was incompatible
	with previous models.
5. Specmarks
		18.5		40		32.8		24.2

----

Additional comments:

... about IBM:

	"After compiling the test suite without problems, and running
	one of the testprograms to check that everything was OK, we
	got an interesting message: FATAL ERROR (20). Remember that
	our little c program has been executed on 15 different
	architectures from 7 vendors without problems. Such an error
	message is what you could expect from a calculator, BUT IN A
	UNIX IMPLEMENTATION WE HAVE NEVER SEEN ANYTHING LIKE IT"

	"(The editing session with background loads) ends in a complete
	disaster at level 4, ie with disk and main memory under
	attack. This situtation is quite comparable to a heavy database
	update, while doing some foreground administration,"

... about DEC:
	" What appeared outstanding two years ago, today seems pretty
	mediocre"


		o /		o /		o /		o /
-----Cut-here----X-----Snip------X---Cut-here----X-----Snip------X---Ouch !
		o \		o \		o \		o \

attached 2:

 UNIX Molecular Biology Software on EMBL File Server
 --------------------------------------------------

 Molecular biological software for the UNIX operating system is available from
 the EMBL File Server. Though all programs are tested we can make no  warranty
 on the functionality of these programs nor shall be  liable  for  any  damage
 resulting from their usage.

 Most programs on the File Server are freeware,  but that does not imply  that
 there are no rights reserved by the authors. Some programs are shareware. You
 may freely copy and distribute these programs, but if you like  to  use  them
 after a trial period you are asked to send the author a small fee. Please see
 the accompanying documentation files or  manuals  for  details  of  copyright
 status.

 To get any file from the EMBL File Server  use  normal  E-mail  addressed  to
 NETSERV at EMBL-Heidelberg.DE. The body of the mail message should  contain  one
 server command per line.

 Getting started
 ---------------

 UNIX software  on  the  EMBL  File  Server  is  distributed in a form that is
 first   compressed  and  then  converted  from   binary  to  printable  ASCII  
 ("uuencoded"). The standard extension for uuencoded files is ".uue". You will
 first need to install the decoding program UUD on your  machine.  Get  the  C
 source code from the EMBL File Server using the command:
                           GET UNIX_SOFTWARE:UUD.C
 and compile it:
                           % cc -o uud uud.c

 SUN users should get the file SunUUD.C instead of UUD.C, because  the  SUN  C 
 compiler does not support the ANSI C standard (SUN  users  may  alternatively
 use the GNU C compiler to compile uud.c).

 The programs that are used for data compression are the standard UNIX tar and
 compress programs.


 How to access files
 -------------------

 All software for UNIX on the  EMBL  File  Server is  in  a  directory  called
 UNIX_SOFTWARE, and a directory listing can be acquired with  the  file server
 command:
                           DIR UNIX_SOFTWARE

 To get any specific file use the command:
                           GET UNIX_SOFTWARE:filename.ext

 For decoding a uuencoded file run uud and specify the source file name:
                           % uud filename.uue

 Files larger than 100k are split into parts. The  first  part  is  designated
 "filename.uaa", the second part "filename.uab" and  so  forth.  If you send a
 request for "filename.uaa", you will automatically receive  all  parts  of  a
 package. The Subject line will tell you the part number of each part and  how
 many parts were sent in total. To decode split files follow this procedure:

 Extract all files from your mail reader to your disk. Call part 1 of a package
 "filename.uaa", part 2 "filename.uab", and so on. Make sure that all belonging
 parts are in one directory and type:
                           % uud filename.uaa

 The name of the resulting file after UUDecoding is stored within the ".uaa" or
 ".uue" file; it will be placed in your current directory. In most  cases,  the
 file name will end with .tar.Z
 
 Now use the UNIX uncompress program to expand these files:
                           % uncompress filename.tar.Z
 which will result in a file named filename.tar in your current directory.
 
 Finally, use tar to extract all files from these archives:
                           % tar -xvf filename.tar

 This will extract all files  contained  in  the  arc


More information about the Comp-bio mailing list