I think that the "Numbers every programmer should know" web page addresses a tremendously important concept thats widely ignored by software developers and SAs. That is "what is the normal or expected time to do X?"
I know a lot of programmers who are concerned with the performance of their systems and are hampered by not having any visceral physical sense of "what is slow? what is fast?" I have a favorite analogy about this: a developer walks into a grocery store to buy a pint of Haagen Daz ice-cream. The cashier rings it up and says "$56 please." Of course 99% of folk will balk at this and say that something is wrong. But if they are logged onto a modern linux host (Say Sandy Bridge to Kaby Lake) and they ping an adjacent host and see a ping time of 0.3ms many would not balk - because they don't know what it's "supposed" to be. If the same developers writes code that listens to a FIX message and then sends another message to a downstream host they might want to test/tune this application. What value for the hop across their app host should they expect to see? The only solutions that I have seen for this are either 1. rely on published benchmarks like this from Stac Research https://stacresearch.com/system/files/asset/files/STAC-T1.EMINI.v0.5_RLT121008_0.pdf 2. Test this themselves using tools like http://psy-lob-saw.blogspot.com/2013/07/a-java-ping-buffet.html I've found the second to be tremendously useful for measuring things like "whats the effect of enabling openonload in our environment?" For developers doing performance or low latency work, i think this understanding is just as crucial as knowing multiplication tables is for a middle-school student. Unfortunately CS programs and our industry don't do a great job of demystifying performance. On Monday, September 25, 2017 at 9:08:24 AM UTC-4, Rupert Smith wrote: > > In one of Martin Thompsons talks he gave an overview of the pyramid of > speed, working from CPU registers out to remote storage, showing how > storage classes along the way get progressively slower to access. He also > gave some approximate numbers to each storage class, but I can't find a > document online that contains this information, or the right section of one > of his talks on youtube to extract this from. Can anyone help me fill in > the Xs in the table below? Obviously it depends on the exact hardware, but > approximate figures will do, its just to illustrate a point and get a feel > for how this scale operates. Thanks. > > CPU Register - X nanoseconds > L1 Cache - X nanoseconds > L2 Cache - X nanoseconds > L3 Cache - X nanoseconds > RAM - X nanoseconds > Local Storage - X milliseconds > Remote Storage - X milliseconds > > > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
