4 ms·
Oh, those pesky algorithms, they did not adapt to the good, good hardware that is so fast. I do not like that stance at all. Consider CPUs, out-of-order ones.
by thesz 4y ago
Oh, those pesky algorithms, they did not adapt to the good, good hardware that is so fast.
I do not like that stance at all.
Consider CPUs, out-of-order ones. They can adapt to the algorithms being thrown at them and most of the time algorithm author is not even aware it can be done. Improvements in this area are steady, about two-to-five of percents per year. Apple's M1 is able to schedule almost 8 instructions per cycle, for example, in quite latency-sensitive task [1].
[1] https://lemire.me/blog/2021/03/24/counting-cycles-and-instructions-on-the-apple-m1-processor/ https://lemire.me/blog/2021/03/24/counting-cycles-and-instru...
Storage systems development is unable to produce something that is similar to OoO CPUs. You can't throw algorithm at storage so that it'll adapt. Algorithms should be adapted to hardware.
Circling back to CPUs, situation with storage hardware is very much like situation with the IBM's Cell BE architecture: hardware is fast, but nobody knows how to make concrete algorithms fast on that hardware.
In my opinion, Cell BE is slow, just like contemporary storage systems are slow. They are fast only in benchmarks.
- nine_k 4y agoTo their credit, storage systems try as hard as they can to speed things up for algorithms oblivious to their real functuoning. NVMe devices introduce caches made with fast SLC flash and even banks of battery-backed RAM. They expose the familiar disk-like intetface while keeping a log-based structure internally. They expose contiguous space and mostly hide the latency due to the internal reallocation of faulty cells. They queue and reorder operations sent to them (OoO executuon). But sometimes divining the user intent is impossible, and they expose stuff like the truncation command.