Secure design 1564

at the time, mostly kernel stuff in buttembler. but i may have been somewhat atypical. There was some jokes, that when i was coding, whatever language I was using tended to become my natural language (aka the analogy observation about indication that you are becoming proficient in a natural language is when you start dreaming in it).

at the science center

besides vs-repack ... detailed memory reference tracing and fortran program that implemented cluster analysis for semi-automated program re-arrgangement and APL for performance, configuration, workload modeling ... described for selecting automated benchmarking for validating resource manager

and performance predictor (sales & marketing support tool) on world-wide hone system

there was also a couple people that had implemented an event-driven system model in PLI. I used to joke with them that I would invent some new variation on performance algorithm ... and could then code it in buttembler, regression test, and deploy in production operation faster than they could write the PLI code for their model.

One variation on their model could take detailed memory traces (ala vs-repack) and simulate various kinds of page replacement algorithms ... clock global LRU (approximates exact LRU), true, exact global LRU (not very practical in real life, keeping exact order of all pages with respect to reference), various of others (like some of the stuff Belady had published from YKT ... like OPT).

So most of the LRU approximations were judged on how well they came to "true" LRU. There was ACM paper by one of the Multics paper showing numbers, using 1, 2, 3, & 4 "history" bits, improving ... but 4bits didn't improve much more than 3bits. The PLI model could also do exact LRU (kept exact reference ordering of all pages) ... something like the graph shown here:

so i came up with this slight of hand variation on clock. In real life, it should to be better than standard clock and in the PLI model tended to be slightly better than true LRU ... rather than slightly worse than true LRU. various past postings on page replacement algorithms:

as mentioned before, i had essentially done the original clock as undergraduate in the 60s. and then had done the slight of hand variation on clock after joining the science center.

something like 10 plus years after doing the original clock, there was the big fuss over granting a stanford PHD on clock, This was basicaly over clock being a global-LRU approximation rather than local-LRU approximation. I got to somewhat help resolve the issue because grenoble science center had published a paper in ACM on performance numbers for a local LRU approximation implementation ... done effectively on the same hardware and operating system being run at the cambridge science center (except grenoble machine had more real memory which should have given them advantage in paging tests). The cambridge machine performance (with clock, global LRU) had much better performance than the published grenoble numbers (even tho grenoble machine had 50 percent more real memory for paging).

--