Re: Cycles per ASM instruction

Sparky Spartacus <Sparky@[EMAIL PROTECTED]
> writes:
> Thus taking an enormous hit for using ISAM, a true hog.

ISAM sprang out of the same philosiphy as the design of VTOC and PDS
.... which used multi-track search to find members; basically I/O
resources were traded off to compensate for real memory
resource constraint ...  a serious issue in the 60s.

The trade-off of using I/O resources to compensate for constrained
real memory continued for VTOC/PDS long after the trade-off had
****fted by at least the mid-70s.

Basically the index for "finding" what you wanted was stored on the
disk ... and channel programs were built that could scan the on-disk
structures looking for target information. ISAM had structures that
were more complex that the simple linear search used for VTOC/PDS
.... being able to fetch information from disk that would change the
channel (i/o) program "on the fly" (somewhat the equivalent of
self-modifying instruction streams ... which were frequently done in
the same period ... compensate for constrained real storage).

In the case of VTOC/PDS implementation ... the proflicate "burning" of
i/o resources continued long after primary system bottleneck had
****fted from being real storage constrained to being I/O resource
constrained ... and frequently could represent an enormorse system
bottleneck ... collected past posts mentioning CKD and VTOC/PDS
implementation representing a serious system system thruput bottleneck
(as system configurations changed from being primarily real storage
constrained to being primarily i/o constrained)
http://www.garlic.com/~lynn/subtopic.html#dasd

in the early 80s i got into a little trouble with the disk development
organization ... in the late 70s ... I started making statements about
system configurations ****fting from being memory constrained to being
disk constrained. Part of this was noting that disk relative system
thruput had declined by better than an order of magnitude over a
period of years (cpu & memory got 50 times bigger/faster, while disks
only got 3-5 times faster) ... as a result there was a significant
requirement to change implementation paradigms to use memory to
compensate for disk thruput (caching and other paradigm changes).  the
disk division assigned their performance organization to refute my
statements. However after several weeks, the group came back and noted
that I had actually somewhat understated the situation. a few
past posts mentioning the subject:
http://www.garlic.com/~lynn/93.html#31
Big I/O or Kicking the Mainframe
out the Door
http://www.garlic.com/~lynn/94.html#43
Bloat, elegance, simplicity and
other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55
How Do the Old Mainframes Compare
to Today's Micros?
http://www.garlic.com/~lynn/95.html#10
Virtual Memory (A return to the
past?)
http://www.garlic.com/~lynn/98.html#46
The god old days(???)
http://www.garlic.com/~lynn/99.html#4
IBM S/360
http://www.garlic.com/~lynn/2001d.html#66
Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62
any 70's era supercomputers that
ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68
Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40
MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61
MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23
Smallest Storage Capacity Hard
Disk?
http://www.garlic.com/~lynn/2002.html#5
index searching
http://www.garlic.com/~lynn/2002b.html#11
Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20
index searching
http://www.garlic.com/~lynn/2002e.html#8
What are some impressive page
rates?
http://www.garlic.com/~lynn/2002e.html#9
What are some impressive page
rates?
http://www.garlic.com/~lynn/2002i.html#16
AS/400 and MVS - clarification
please
http://www.garlic.com/~lynn/2004p.html#39
100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#13
Today's mainframe--anything to
new?
http://www.garlic.com/~lynn/2005k.html#53
Performance and Capacity
Planning
http://www.garlic.com/~lynn/2006m.html#32
Old Ha****ng Routine
http://www.garlic.com/~lynn/2006o.html#27
oops
http://www.garlic.com/~lynn/2006x.html#13
The Future of CPUs: What's After
Multi-Core?

For a slightly different drift ... some number of posts mentioning
the original relational/sql implementation, System/R
http://www.garlic.com/~lynn/subtopic.html#systemr

in the system/r time-frame there was some number of arguments about
benefits/trade-offs between the IMS people in STL and the System/R
people in SJR. IMS used direct record pointers embedded as part of the
information. System/R used a index structure built "under the covers"
to abstract away direct record pointers from explicit representation
as part of the data. IMS pointed out that the System/R index structure
typically doubled the physical disk requirements ... and significantly
increased the number of disk I/Os (as part of processing the index).
System/R people pointed out the enormous manual costs maintaining the
exposed record pointers. effectively in the 80s, with ever increasing
real storage availability, it was possible to cache the majority of
the RDBMS index ... eliminating the costly disk I/O overhead
processing the index ... and the significant increase in disk
capacities and significant increase in disk price/mbyte ... somewhat
made the issue of the size of the on-disk index structure mute. This
changed the trade-off of increased System/R computing resource
requirements vis-a-vis the significant manual resource requirements
for IMS ... making RDBMS implementations a lot more attractive for
many people (although there are claims that still today there may be
more mbytes stored in IMS databases than RDBMS databases).

misc. past posts mentioning the the IMS/RDBMS discussions
http://www.garlic.com/~lynn/2004e.html#22
Pre-relational, post-relational,
1968 CODASYL "Survey of Data  Base Systems"
http://www.garlic.com/~lynn/2004o.html#67
Relational vs network vs
hierarchic databases
http://www.garlic.com/~lynn/2004q.html#23
1GB  Tables as Cl*****, or
Tables as Types, and all that
http://www.garlic.com/~lynn/2004q.html#79
Athlon cache question
http://www.garlic.com/~lynn/2005b.html#1
Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2006m.html#32
Old Ha****ng Routine
http://www.garlic.com/~lynn/2006w.html#27
Generalised approach to storing
address details

for other drift, a couple other posts about that period
http://www.garlic.com/~lynn/2007.html#1
"The Elements of Programming
Style"
http://www.garlic.com/~lynn/2007d.html#17
Jim Gray Is Missing

for other drift ... recent thread on self-modifying instruction streams
http://www.garlic.com/~lynn/2007d.html#1
Has anyone ever used
self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#3
Has anyone ever used
self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#7
Has anyone ever used
self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#9
Has anyone ever used
self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#46
Has anyone ever used
self-modifying microcode? Would it even be useful?