3 ms·

Your comment kind of support notion "I/O is slow" you seemingly oppose - the I/O that is needed by real world programs may be different from I/O that is fast in

by thesz 4y ago

Your comment kind of support notion "I/O is slow" you seemingly oppose - the I/O that is needed by real world programs may be different from I/O that is fast in benchmarks. E.g., B-tree reads need pretty much random access after many non-sequential data insertions. And we are talking about read-optimized data structures here.

nine_k 4y ago
I/O hardware is fact. The algorithms did not adapt, so I/O in software is slow. Exactly what the author complaints about. BTW network is also fast; your typical server has at least a 10G interface, sometimes 40G or even 100G. Transfers within the same rack may be faster than your NVMe, and within the same DC, comparable.
- 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 ago
    To 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.

by thesz 4y ago

nine_k 4y ago

I/O hardware is fact. The algorithms did not adapt, so I/O in software is slow. Exactly what the author complaints about. BTW network is also fast; your typical server has at least a 10G interface, sometimes 40G or even 100G. Transfers within the same rack may be faster than your NVMe, and within the same DC, comparable.

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 ago
  To 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.