Intel engineer discusses their dualcore design 2162

however, kernel smp overhead has been notorious for adding 15-30% overhead ... which can result in a wash.

from 30+ years ago ... there was a project to add a second i-stream to 370-195. the issue was that 195 drained the pipeline on branches and most codes ran at around half pipeline and half peak thruput. the hope was that 2nd i-stream could get close to double hardware thruput (for wide-range of codes) ... more than enuf to compensate for any incremental kernel overhead going to smp kernel.

it was never produced. originally 370-195 was targeted at national labs. and numerical intensive supercomputer type stuff. however, it started to see some uptake in the TPF market (transaction processing facility ... the renamed ACP ... airline control program ... which in addition to be being used in large airline res. systems ... was starting to see some deployment in large financial transaction networks, therefor its name change). the codes in this market segment was much more commercial oriented ... so a 2nd thread-i-stream might benefit the customers workload.

the high-end TPF financial transaction market was seeing some uptake of 195 as growth from 370-168 (195 even running commercial codes at half peak could still be around twice thruput of 168). a big stumbling block was that TPF (operating system) didn't have SMP support and didn't get SMP until after 3081 time-frame in the 80s (the 3081 product was smp only ... but eventually they were forced to produce a reduced priced, single-cpu 3083 for the TPF market).

the other issue was that 3033 eventually showed up on the scene which was nearly the thruput of half-peak 195 (about even on commercial codes).

for some folklore drift sjr was still running 370-195 and made it available to internal shops for numerical intensive operations. however, the batch backlog could be extremely long. Somebody at PASC claimed that they were getting 3month turn-arounds (they eventually setup a background and checkpoint process on their own 370-145 that would absorbe spare cycles offshift ... and started getting slightly better than 3 month turn-around for the same job).

one of the applications being run by the disk division on research's 195 was air-bearing simulation ... working out the details for floating disk heads. they were also getting relatively poor turn around.

the product test lab across the street in bldg. 15 got an early 3033 engineering machine for use in disk-processor-channel product test.

the disk engineering labs (bldg 14) and the product test labs (bldg 15) had been running all their testing "stand-alone" ... scheduled machine time for a single 'testcell" at a time. the problem was that standard operating system tended to quickly fail in an environment with a lot of engineering devices being tested (MVS had a MTBF of 15 minutes in this environment).

I had undertaken to rewrite the i-o supervisor making operating system bullet proof so that they could concurrently test multiple testcells w-o requiring dedicated, scheduled stand-alone machine time (and w-o failing)

when the 3033 went into bldg. 15, this operating system was up and running and heavy concurrent product test was consuming something under 4-5 percent of the processor. so we setup an environment to make use of these spare cpu cycles. one of the applications we setup to provide thousands of cpu hrs processing was air-bearing simulation (in support of working out details for floating disk heads).

--