[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Poor Sun timings, as competition...
Date: Fri, 27 Jul 90 11:20:44 PDT
From: jrs@atc.boeing.com (Ross Stenstrom)
There is a posting from the sun-spots mailing list that describes
an experiment on the current Suns. It concludes that when executables
exceed 16M (probably bytes) their performance becomes markedly
poorer. It draws a reasoned conclusion based upon a bunch of nitty
gritty Sun details about why and it is a true hardware limitation.
Now my question or comment, we are periodically asked why we don't just
run Lucid on a Sun or KCL which is FREE. Obviously this treats Suns
as a free resource which has its own implications (there are also Sun
managers who don't/won't/can't do Symbolic's who would seem to have an
interest in dropping the Symbolics, particularly where I used to work...).
Has anyone (else) read this study? Does anyone with deep Sun knowledge
support the conclusions? Can we use this as a major refutation of the
"just use a Sun, they're faster and cheaper anyway" mentality?
I'm too timid to post someone else's writing to the net. The study is
available by anonymous ftp from titan.rice.edu, doing a cd to sun-spots
and a get of v9n257 (presumably an edition number of "sun-spots").
Interestingly enough, the study was really about large executables and
suggested that large lisp systems with (intrinsic?) poor locality of
reference might be most affected.
If you can't ftp I'll try to send you a copy by mail, there may be an
automatic mechanism at sun-spots.
Ross Stenstrom
Boeing High Technology Center
Bellevue, WA
jrs@atc.boeing.com
I saw the report, but don't understand enough about UNIX kernel
architecture to figure out what's really going on there; I'm not sure
that theoretical exercise has much effect in practice (but maybe during
garbage collection?). I do know about the Ivory virtual memory system,
though, which was designed to degrade much more gracefully in such
situations. Below is the Genera equivalent of the C test program, which
runs with roughly the expected performance on an XL1200.
Some of the relevant architectural differences in Ivory:
- it uses an inverted page table to describe the mapping of every
page in main memory
- there is a 64 entry fully associative cache of those mappings
on chip
- the refill of this cache (a hash table lookup) is highly optimized,
and takes less than one microsecond
- the page size is smaller (256 words), because that uses main
memory more efficiently for large object-oriented programs
- the architecture supports a single address space for all processes
Primarily because of this last feature, the example program is not much
of a challenge to the virtual memory system, so I added a provision to
increase the data set.
;;; -*- Mode:LISP; Syntax:Common-Lisp; Package:USER; Base:10 -*-
(defun test-virtual-memory-system (&key (processes 2)
(megabytes 2)
(iterations 5000)
(context-switch-rate 100))
(stack-let* ((bytes (* megabytes (expt 2 20)))
(array (make-array bytes :element-type '(unsigned-byte 8))))
(let ((start-time (get-internal-real-time))
(active-processes 0))
(loop repeat processes do
(process-run-function "Virtual Memory Test"
(lambda ()
(loop repeat iterations
for i from 0 below bytes by (* sys:page-size 4)
do
(assert (= (aref array i) 0)))
(process:atomic-decf active-processes)))
(process:atomic-incf active-processes))
(loop while (> active-processes 0) do
(sleep (/ 1.0 context-switch-rate)))
(float (/ (- (get-internal-real-time) start-time) internal-time-units-per-second)))))
(cp:define-command (com-test-virtual-memory-system :command-table "user")
()
(loop for size in '(2 4 8 16) do
(formatting-table ()
(formatting-column-headings () "Megabytes" "Processes" "Seconds")
(loop for processes in '(2 4 8 16 32) do
(formatting-row ()
(formatting-cell ()
(write size))
(formatting-cell ()
(write processes))
(formatting-cell ()
(format t "~3$" (test-virtual-memory-system :processes processes
:megabytes size))))))
(terpri)))
#|
;;; Trials on an 8 megaword (aka 32 megabyte) Symbolics XL1200
Test Virtual Memory System
;;; This run is the equivalent of the Sun trials
Megabytes Processes Seconds
2 2 0.041 ;4 megabytes referenced
2 4 0.085 ;8 megabytes referenced
2 8 0.182 ;16 megabytes referenced
2 16 0.350 ;32 megabytes referenced
2 32 0.677 ;64 megabytes referenced
Megabytes Processes Seconds
4 2 0.090
4 4 0.168
4 8 0.323
4 16 0.673
4 32 1.330
Megabytes Processes Seconds
8 2 0.103
8 4 0.204
8 8 0.420
8 16 0.822
8 32 1.653
Megabytes Processes Seconds
16 2 0.102
16 4 0.203
16 8 0.424
16 16 0.828
16 32 1.614
|#