Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler Newsgroups: comp.arch Subject: Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Date: Wed, 21 May 2025 07:06:26 -1000 Organization: Wheeler&Wheeler Lines: 53 Message-ID: <87v7ptopv1.fsf@localhost> References: <27492f8028a0d40eff5071e85214fc36@www.novabbs.com> <100gj7t$1sbnn$11@dont-email.me> <100iher$2b7vi$2@dont-email.me> <100jata$2g8o9$3@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Wed, 21 May 2025 19:06:30 +0200 (CEST) Injection-Info: dont-email.me; posting-host="430801cc2a2d3bee3c2e3eabbda887fb"; logging-data="3085017"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+g5Vw4friXX8huowS4foIYO6rRnejkU6o=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:QbgFQI/9dkYeR40oxyJIjTJQ4jk= sha1:RQvpHy0ebrpQBs885TDrC0iOxU8= Xref: csiph.com comp.arch:111719 "Chris M. Thomasson" writes: > Only if the cores and/or "hardware threads" do not interfere with one > another? Fwiw, an example of an embarrassingly parallel algorithm is > computing the Mandelbrot set. Actually, this reminds me of the "alias" > problem with Intel hyper threading in the past. shortly after graduating and joining IBM, I got roped into helping with hyperthreading the 370/195. It had pipelined, out-of-order execution, but conditional branches drained the pipeline and most code only ran system had half rated throughput. Two hardware i-streams ... each running at half throughput would (might) keep system full throughput. hardware hyperthreading mentioned in this about Amdahl winning the battle to make ACS, 360 compatible (folklore it was shutdown because IBM was concerned that it would advance the state-of-the-art too fast and IBM would loose control of the market, and Amdahl leaves IBM). https://people.computing.clemson.edu/~mark/acs_end.html Then decision was made to add virtual memory to all 370s, and it was decided it would be too difficult to add it to 370/195 and all new 195 activity was shutdown (note operating system for 195 was MVT and its shared memory multiprocessor support on 360/65MP was only getting 1.2-1.5 throughput of single processor, so running 195 with simulated multiprocessor with two i-streams ... would only be more like .6 times fully rated throughput (all hardware might be running at 100%, but the SMP overhead would limit productive throughput); trivia the multiprocessor overhead continues up throught MVS. also after joining IBM, one of my hobbies was enhanced production operating systems for internal datacenters and the online sales&marketing support HONE systems were early (& long time) customer. Then with decision to add virtual memory to all 370s, there was also decision to do VM370 and in the morph of CP67->VM370 a lot of things were simplified and/or dropped (including multiprocessor support). I then start adding stuff back into VM370 and initially do multiprocessor support for the HONE 168s so they can add 2nd processor to all their systems (and managed to get twice single processor throughput with some cache affinity hacks and other stuff). In the mid-70s, after Future Systems implodes, http://www.jfsowa.com/computer/memo125.htm https://en.wikipedia.org/wiki/IBM_Future_Systems_project https://people.computing.clemson.edu/~mark/fs.html I get roped into helping with a 370 16-CPU multiprocessor design. It was going fine until somebody tells head of POK (high end 370 processors) that it could be decades before POK's favorite son operating system (now "MVS") had ("effective") 16-cpu support (POK doesn't ship a 16-CPU system until after the turn of the century) ... and some of us are invited to never visit POK again. -- virtualization experience starting Jan1968, online at home since Mar1970