Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: ancient OS history, ARM is sort of channeling the IBM 360
Date: Sun, 30 Jun 2024 16:13:51 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <v5s07u$jf15$1@dont-email.me>
References: <s7r87j1c3u6mim0db3ccbdvknvtjr4anu3@4ax.com> <e4f7278a5ff4e0b488306ae43aac8135@www.novabbs.org> <v5nbfo$3hdrc$1@dont-email.me> <v5o6jr$37jie$1@dont-email.me> <v5pjcc$25j5$1@gal.iecc.com> <v5q6qm$5fhe$1@dont-email.me> <v5qn67$c1dr$1@dont-email.me> <v5r13f$dn62$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 30 Jun 2024 18:13:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="654a1831c01f9f66d69c6db8106c14a9";
	logging-data="637989"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+a+BM5jsDGvherZwGuyb2Yg47o3Mq6X38="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:+kEaCBG2NATnZNHIs6VxKILOpBU=
Bytes: 2773

Lawrence D'Oliveiro wrote:

> On Sun, 30 Jun 2024 04:33:11 -0000 (UTC), Stephen Fuld wrote:
> 
> > Lawrence D'Oliveiro wrote:
> > 
> >> By the 1970s, CPU/RAM speeds had improved to the
> >> point where copying records a few hundred bytes at a time between
> >> buffers was not the performance bottleneck; disk I/O was.
> > 
> > Yes, but given multiprogramming, even in the 1970s, you would
> > typically have several batch programs running at the same time, so
> > during waits for I/O, another program could use the CPU.  But using
> > the CPU to move records meant it couldn't be doing anything else at
> > the same time.
> 
> Scraping the bottom of the barrel, much?
> 
> Work out the numbers. The CPU time necessary to copy a single record
> is most likely a small fraction of the time it takes to service an
> I/O interrupt.
> 
> And this is not taking into account the fact that I/O interrupts run
> at a higher priority than user-level tasks like copying buffers,
> anyway.

The thing you are missing is that (in the common scenario I was talking
about) locate mode costs absolutely zero.  No overhead in the I/O
system, no changes to the source code, nothing.  And not using it has
no, i.e. zero, advantages.  So while the savings might be small, there
are no costs, so why no use it.

And BTW, not that it effects the calculation, but you only have one I/O
interrupt per physical block, not per logical record.



-- 
 - Stephen Fuld 
(e-mail address disguised to prevent spam)