Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: Emulating vintage computers Date: Sat, 28 Sep 2024 13:02:48 -1000 Organization: Wheeler&Wheeler Lines: 57 Message-ID: <87v7yf1iw7.fsf@localhost> References: <87tte2s1hu.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sun, 29 Sep 2024 01:02:50 +0200 (CEST) Injection-Info: dont-email.me; posting-host="2e0f1dff49e9949eda1a035847a5d7c4"; logging-data="1519825"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX189YUMtTH5qT90DHjhicWo1iDPtowED2gE=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:JDm0PcjF00wUPHfBImgTpXm6lsI= sha1:IFEcKNDwJA7f1CBQeTrpqDovRlU= Xref: csiph.com alt.folklore.computers:227171 antispam@fricas.org (Waldek Hebisch) writes: > I wonder how you get those numbers? Basicaly processor speed is clock > frequency times with of processor time utilization of that. from original post: (benchmarks are number of program iterations compared to reference platform, not actual instruction count) ... industry standard MIPS benchmark had been number of program iterations compared to one of the reference platforms (370/158-3 assumed to be one MIPS) ... not actual instruction count ... sort of normalizes across large number of different architectures. consideration has been increasing processor rates w/o corresponding improvement in memory latency. For instance IBM documentation claimed that half of the per processor throughput increase going from z10 to z196 was the introduction of some out-of-order execution (attempting some compensation for cache miss and memory latency, features that have been in other platforms for decades). z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008 z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010 aka half of the 469MIPS/proc to 625MIPS/proc ... (625-469)/2; aka 78MIPS per processor from Z10 to z196 due to some out-of-order execution. There have been some pubs about recent memory latency when measured in terms of processor clock cycles is similar to 60s disk latency when measured in terms of 60s processor clock cycles. trivia: early 80s, I wrote a tome that disk relative system throughput had declined by an order of magnitude since mid-60 (i.e. disks got 3-5 faster while systems got 40-50 times faster). Disk division executive took exception and assigned the performance group to refute the claims. After a few weeks they came back and effectively said I had slightly understated the problem. They then respun the analysis to configuring disks to increase system throughput (16Aug1984, SHARE 63, B874). trivia2: a litle over decade ago, I was asked to track down the decision to add virtual memory to all IBM 370s. I found staff member to executive making the decision. Basically MVT storage management was so bad that region sizes had to be specified four times larger than used. As a result a typical 1mbyte, 370/165 only ran four concurrent regions at a time, insufficient to keep 165 busy and justified. Going to MVT in 16mbyte virtual memory (VS2/SVS) allowed increasing the number of regsions by factor of four times (caped at 15 because of 4bit storage protect keys) with little or no paging ... similar to running MVT in a CP67 16mbyte virtual machine (aka increasing overlapped execution while waiting on disk I/O, and our-of-order execution increasing overlapped execution while waiting on memory). -- virtualization experience starting Jan1968, online at home since Mar1970