Re: Cycles per ASM instruction

Steve Myers <noone@[EMAIL PROTECTED]
> writes:
> Something wrong here.  No way a /67 could do .98 MIPs.  Nor could a
> /67MP do almost 2 MIPs - the shared memory really slowed that class of
> machine down.  /67s with the DAT turned off were roughly the same as a
> /65; the DAT took about 20% off that.  /67MPs were about 1.75 times
> the UP.

as per pervious post
http://www.garlic.com/~lynn/2007d.html#62
Cycles per ASM instruction

it wasn't that shared memory slowd the 67MP down ... it was that the
67-2 had multi-****ted memory delay ... even when you are only talking
about a single processor (half-duplex) 67-2. The delay of the
multi-****ted memory (compared to 65 or 67-1) mitigated memory
contention ... both when there was heavy i/o and/or multiprocessor
operation. two-processor 67-2 might actually have twice the aggregate
effective MIP rate of single 67-1 in heavy i/o workloads.

multiprocessor 370 cache machines were slightly different. For two
processor operations the cache machine cycle was slowed down by ten
percent (to allow for cross-cache chatter) ... making each processor
effectively .9 processing rate of a single processor machine (two
processors were 1.8 of a single processor machine).

The processing of actual cross-cache chatter, for things like
cache-line invalidates, would slow the running hardware down even
further ... then there is the overhead of kernel multiprocessor
software ... resulted in two-processor 370s thruput being rated at
1.4-1.5 times that of single processor 370.

However, I did some fiddling in some early vm370 multiprocessor
sup****t that effectively provided for some cache affinity. For some
workloads on a two processor 158-3 ... the aggregate mip rate of the
two processors were sometimes slightly better than same workload on a
single processor operation; aka some games being able to take
advantage of two caches and improvement cache hit ratio running the
workload ... could more than make up for the degraded processor cycle
(and other MP overhead).

for some real topic drift ... posting of the old MIP Envy article
http://www.garlic.com/~lynn/2007d.html#17
Jim Gray Is Missing

in the early 80s (during the 3081 product cycle), both MVS and VM
kernels had work to optimize kernel storage allocation to minimize
cross-cache tra****ng ... kernel storage was reworked to be aligned on
cache-line boundaries ... and be in units of cache-lines. The
resulting reduction in cross-cache thra****ng supposedly increased
overall system thruput between 5-10 percent.

a couple recent posts mentioning cache hit ratios and/or cross-cache
chatter
http://www.garlic.com/~lynn/2007.html#44
vm/sp1
http://www.garlic.com/~lynn/2007c.html#47
SVCs