Agner Fog

> Go ahead and cite the absolute best example you can come up from this incredible list of yours. The very top of your list will suffice to evaluate your whole list. I'll wait.

This could really do without the "incredible list of yours" and "I'll wait" snark. You don't need to be so condescending, but for the sake of helping others who are actually curious about the subject:

https://www.agner.org/optimize/ is a great place to start that I link to frequently.

It has significantly more breadth than the small collection of techniques in the paper linked in this post. It doesn't have the "HFT" buzzword attached, but then again the techniques in the linked paper above aren't unique to HFT either.

There are also several books on the subject, but given that the above link is a good place to start and the resources are freely available, that's where I'd recommend you look.

Agner speaks about memory renaming back on Zen 2:

https://www.agner.org/forum/viewtopic.php?t=41

Intel Alderlake has performance events for tracking it:

https://github.com/intel/perfmon/blob/974c69919b2a9dfd8278cfe3384d2ae8ede477e9/ADL/events/alderlake_gracemont_core.json#L2126

But even before this you had store to load forwarding on x86. I'm not saying you have, but before inventing a performance problem it is worth spending time trying to diagnose it with thorough profiling (e.g. [1]). The Fedora frame pointer patch did a thorough performance analysis and performance will be revisited again. Unfortunately there are a lot of arm chair performance experts who haven't spent time looking into the details.

[1] https://perf.wiki.kernel.org/index.php/Top-Down_Analysis

While this is a pretty decent overview, it is not very precise, and even a bit misleading in certain cases. Depending on where certain instructions are in the execution pipeline, you can. R limited in what can be issued and executed, and the latencies are not deterministic. This is one of the biggest difficulties in optimizing scheduling in a complex architecture such as x86, and gets even worse (determinism wise) when you throw in cache misses and branch prediction.

For a more exhaustive instruction latency listing over a variety of micro architectures, check out [0]. [1] is also a great resource for memory latencies for a variety of processors.

[0]: http://www.agner.org/optimize/instruction_tables.pdf

[1]: http://www.7-cpu.com

It's great for hardware implementations, because it's simple and you get good/excellent accuracy. I wouldn't be surprised if that's still how modern x86-64 CPUs compute sin, cos, etc.

That said, last time I had to do that in software, I used Taylor series. Might not have been an optimal solution.

EDIT:

AMD's Zen 4 takes 50-200 cycles (latency) to compute sine. I think that strongly suggests AMD uses CORDIC. https://www.agner.org/optimize/instruction_tables.pdf page 130.

Same for Intel, Tiger Lake (Intel gen 11) has 60-120 cycles of latency. Page 353.

I'd guess usually ~50 cycles for Zen 4 (and ~60 for Intel) for float32, float64/float80 datatype. Denormals might also cost more cycles.

(as you might be able to tell) this is of great interest to me so if you have any reading recommendations I'd appreciate them (thanks).

some of the people (other than Scott) who influenced my thinking on this would be:

Berger: https://en.wikipedia.org/wiki/Peter_L._Berger (especially http://perflensburg.se/Berger%20social-construction-of-reality.pdf)

Jacques Ellul https://archive.org/details/JacquesEllulTheTechnologicalSociety (also Propaganda)

and Nassim Taleb (e.g. his view on Switzerland) ...

also I'm admittedly thin on anthropological reading (still have Agner Fog's book on my list since ages: https://www.agner.org/cultsel/warlike_peaceful.pdf)

There are a lot of instances in a design, both macro and micro, where you can trade off greater performance at the expense of something else - either area or power or both.

Then these tradeoffs tend to multiply each other. If you have a design which is fast on branch-predicted and slow on branch-mispredicted, and you build a big branch predictor, it works well. But you're committed to powering all that.

I mean, compare http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/CHDHCFBC.html (few sentences) with http://www.agner.org/optimize/microarchitecture.pdf (admittedly a lot more detail, but it's clearly a more complicated system too)