[KMag]

The really interesting stuff is the metallurgy necessary to have an oxidizer-rich pre-burner run the turbopumps without having the hot oxidizer burn through the engine. Western engineers thought it was pure fiction when they first heard about it.

[jacquesm]

The Soviets royally sucked in the computation department but were absolute masters at the materials sciences. To some extent this is still the case today.

[lkozma]

> The Soviets royally sucked in the computation department

To add more nuance, there is an essay [1] telling the history of early maximum flow algorithms and includes this small anecdote:

[An] American asked: ".. how were you able to perform such an enormous amount of computing with your weak computers" to which the Russian responded: "we used better algorithms".

There is some truth to that, besides maximum flow, similar stories can be told about linear programming, data structures (e.g. AVL-trees), numerical computing, etc. The hardware may have been sloppy, but the algorithms-research was top notch.

[1] http://www.cs.bgu.ac.il/~dinitz/Papers/Dinitz_alg.pdf

[jacquesm]

This is true, and one of the reasons why I feel that we have come too far too fast in the hardware department, the degree to which Moore's law has enabled sloppy and wasteful programming should not be underestimated.

[HPsquared]

Is there any kind of index of software inefficiency? Something like "number of operations required by the software stack to display a sentence on screen", with a trend over time.

[handrous]

Input latency's one potential convenient proxy for this, once you adjust for display latency. "How long does it take the computer to do pretty much the most basic operation an interactive computer system performs?"

Considering an IBM 8088 did way better on that than modern computers, with like 1/5,000 of the processing power (figure ass-pulled but probably not far off), indicates to me that the trend is really damn bad.

[jacquesm]

That is a good one! And pretty easy to measure as well.

[jacquesm]

This is very much application dependent, so you'd have to take a 1980's application, say Visicalc and extrapolate to today, say Office 365 or Google Sheets.

This you can then do for different application domains, and both in absolute terms (# cycles wasted) as well as relative terms (%age of cycles wasted).

[p_l]

While not unknown in the west in the past, "better algorithms" are in a way a dying breed in aerospace - these days a student will easily have a CFD package brute force through the problem overnight and be done.

My father, upon taking over his promotor's office in Warsaw Institute of Technology, found among other things a book in Russian that described analytical, symbolic methods allowing "good enough" approximated results for many airfoil/wing design tasks that are now exclusively done through CFD.

As described, in 30 minutes with pen & paper you had maybe a more coarse, but valid and in desired precision result that takes overnight run in ANSYS CFX.

[orbital-decay]

CFD only looks like brute force when compared to purely analytical methods. In practice, you can't brute force a chaotic system as you quickly hit the wall. Anything complex pretty much requires you to get clever with simulation just like it did before computers with analytical approach, and/or rely on experimentation. It's especially true for rocket engine design; there's a reason why nobody made a practical RDE yet.

[p_l]

True, but for a large class of problems in aviation, the analytical methods can provide faster iteration before going into CFD for deep optimization, at least that's my understanding (I'm the computer science person in the family, not aerodynamic physicist :) )

[jacquesm]

Past a certain minimum grid size it certainly looks like brute force to me, am I missing something?

[p_l]

Sometimes you can't get that grid size ;)