What other cases have you seen of denormals arising in real calculations?

Basically, you have to have out of order/speculative execution if you ultimately want the best performance on general/integer workloads. And once you have that, timing information is going to leak from one process into another, and that timing information can be used to infer the contents of memory. As far as I can see, there is no way to block this in software. No substitute for the CPU knowing 'that page should not be accessible to this process, activate timing leak mitigation'.

There is plenty of information on the technology of machines like the VAX, PDPs, 360 etc. Quite a bit also on how they were built. ('The Mythical Man-Month' and 'The Soul of a New Machine' are generally recognized as classics. A lesser-known favorite of mine: 'The Supermen'.) But not so much on how they were used, particularly at the 'coal face' level, so to speak.

This post was inspired by a comment on https://news.ycombinator.com/item?id=45818471

"... at the time I was working on an IBM 360, mostly doing Fortran for scientists running anemometer simulations. The center for this activity was the person in charge of the 360 who could dole out time on the computer.

The power dynamic was something I did not really notice, but in retrospect this was frustrating for the mathematicians/scientist trying to run simulations. They had to queue up and wait.

Then one day a mathematician brought in an Apple II running VisiCalc. His own personal computer. He ran his simulations on that."

One thing I found fascinating here: looking at the clock speeds of 1970s computers, by today's standards, you would expect 'the computer is too slow' to be a big limiting factor. But in the above account, it wasn't. The actual workload was such that an Apple II running VisiCalc was good enough to get the job done. The limiting factors were the actual availability of the 360 (presumably there genuinely was not enough machine time to go around), and the overhead of dealing with the politics of gaining access to it.

What were people's experiences with minicomputers and mainframes? What did they enable, that was more difficult or impossible than before? What were the actual bottlenecks and limiting factors? I'm interested in both direct firsthand accounts, and links to published material in any format.

Comments URL: https://news.ycombinator.com/item?id=45824655

Points: 2

# Comments: 2

If you don't have time to write a detailed refutation, that's entirely understandable! But if you do, I would love to read it.

I did appreciate your paragraph length comment on the matter elsewhere in this thread.

As far as I can see, you are indeed going to incur one extra memory access apart from the object itself, for any design other than just 'Temporarily flag the object deleted, sweep deleted objects in bulk later' (which would only be good if deleted objects are uncommon). It still matters how many extra memory accesses; deleting an object from a doubly linked list accesses two other objects.

It also matters somewhat how many cache lines each object takes up. I say 'somewhat' because even if an object is bulky, you might be able to arrange it so that the most commonly accessed fields fit in one or two cache lines at the beginning.

As to what would be better - this is also a reply to your sibling comments above - I don't have a single across-the-board solution; the equivalent of std::vector everywhere is fine for some kinds of application code, but not necessarily for system code. Instead, I would start by asking questions.

What kinds of entities are you dealing with, what kinds of collections, and, critically, how many entities along each dimension, to an order of magnitude, p50 and p99? What are your typical access patterns? What are your use cases, so that you can figure out what figures of merit to optimize for? How unpredictable will be the adding of more use cases in the future?

In most kinds of application code, it's okay to just go for big-O, but for performance critical system code, you also need to care about constant factors. As an intuition primer, how many bytes can you memcpy in the time it takes for one cache miss? If your intuition for performance was trained in the eighties and nineties, as mine initially was, the answer may be larger than you expect.

I'm aware of the reasons Linux uses doubly linked lists. I'm still of the opinion this design decision made a lot of sense in the 1990s, and would make less sense in a new project today. You may disagree, and that's fine! Engineering is constrained by hard truths, but within those constraints, is full of judgment calls.

I'm not a member of the evangelical Rust community. I'm not proclaiming 'thou shalt rewrite it all in Rust'. Maybe you have good reasons to use something else. That's fine.

But if you are considering Rust, and are concerned about its ability to handle cyclic data structures, there are ways to do it, that don't involve throwing out all the benefits the language offers.

Though yes, I do give it credit for going at least a little of the way - not far enough, but a little - in pushing back on the 'human error' scapegoating, in favor of asking questions about procedures and policies.

How many hours had the officer on watch in this case worked that week? How many hours of sleep did he have?

And why is no one except me asking those questions?