5 ms·

According to Apple's MacBook Pro marketing page [0], their SSD supports sequential read speeds of up to 3.2GB/s. So this isn't as far-fetched as you imply, even

According to Apple's MacBook Pro marketing page [0], their SSD supports sequential read speeds of up to 3.2GB/s. So this isn't as far-fetched as you imply, even if we're discounting other factors like the filesystem cache. [0] https://www.apple.com/macbook-pro/ https://www.apple.com/macbook-pro/

maxxxxx 8y ago
Yes, I see these specs all the time but I never see them materialize in the real world. Agree about the cache but that's also an easy way to fool yourself when you are measuring performance.
- dspillett 8y ago
  > easy way to fool yourself when you are measuring performance In this case isn't the "already in RAM" test a more accurate reflection of performance anyway, as we are talking about the performance of grep and not the IO subsystem? There are many cases where grep's performance won't be bottlenecked by IO, or at least not impacted directly by a bottleneck there. Anywhere when the input is coming from another program, essentially, and even if that task is IO bound it might be sending output to grep much faster than it is consuming input (perhaps gunzip <file | grep searchtext). And in the case of searching a log file interactively, it is common that you won't just run grep of the file just once in a short space of time, instead doing it a couple of times as you refine your search, so for most of the runs it will be in cache (assuming the file is not to large).
  - Rapzid 8y ago
    The data could also be in the VFS cache/buffers for a number of reasons depending on the system setup and access pattern; including being written.
- kllrnohj 8y ago
  This usage is literally ideal for pretty much any file I/O - it's a straight sequential read. Even spinning rust will achieve >400MB/s on this type of load. Take a look at the sequential burst speeds at QD1, first chart: https://www.anandtech.com/show/13761/the-samsung-970-evo-plus-ssd-review/7 https://www.anandtech.com/show/13761/the-samsung-970-evo-plu... Nearly ever SSD listed achieves well over 1GB/s in an actual benchmark, not just on a spec sheet. And these are just boring old off the shelf consumer drives. Nothing crazy.
  - BeeOnRope 8y ago
    HDDs almost never sustain 400 MB/s unless you are talking about something pretty exotic. 5200 RPM drives are generally in the 100-130 MB/s range and 7200 proportionally faster but still usually under 200 MB/s.
    - kllrnohj 8y ago
      https://www.tomshardware.com/reviews/wd-red-10tb-8tb-nas-hdd,5277-2.html https://www.tomshardware.com/reviews/wd-red-10tb-8tb-nas-hdd... So yeah maybe not over 400MB/s, but all of them are over 200MB/s. Sequential speeds really spiked as densities kept increasing.
- the8472 8y ago
  Definitely seeing GB/s IO spikes on my samsung NVMe drives. E.g. when persisting application state into sqlite. Note that you're not going to get this with SATA SSDs, you need NVMe, it's a 5x difference in throughput and IOPS.

maxxxxx 8y ago

Yes, I see these specs all the time but I never see them materialize in the real world. Agree about the cache but that's also an easy way to fool yourself when you are measuring performance.

dspillett 8y ago
> easy way to fool yourself when you are measuring performance In this case isn't the "already in RAM" test a more accurate reflection of performance anyway, as we are talking about the performance of grep and not the IO subsystem? There are many cases where grep's performance won't be bottlenecked by IO, or at least not impacted directly by a bottleneck there. Anywhere when the input is coming from another program, essentially, and even if that task is IO bound it might be sending output to grep much faster than it is consuming input (perhaps gunzip <file | grep searchtext). And in the case of searching a log file interactively, it is common that you won't just run grep of the file just once in a short space of time, instead doing it a couple of times as you refine your search, so for most of the runs it will be in cache (assuming the file is not to large).
- Rapzid 8y ago
  The data could also be in the VFS cache/buffers for a number of reasons depending on the system setup and access pattern; including being written.
kllrnohj 8y ago
This usage is literally ideal for pretty much any file I/O - it's a straight sequential read. Even spinning rust will achieve >400MB/s on this type of load. Take a look at the sequential burst speeds at QD1, first chart: https://www.anandtech.com/show/13761/the-samsung-970-evo-plus-ssd-review/7 https://www.anandtech.com/show/13761/the-samsung-970-evo-plu... Nearly ever SSD listed achieves well over 1GB/s in an actual benchmark, not just on a spec sheet. And these are just boring old off the shelf consumer drives. Nothing crazy.
- BeeOnRope 8y ago
  HDDs almost never sustain 400 MB/s unless you are talking about something pretty exotic. 5200 RPM drives are generally in the 100-130 MB/s range and 7200 proportionally faster but still usually under 200 MB/s.
  - kllrnohj 8y ago
    https://www.tomshardware.com/reviews/wd-red-10tb-8tb-nas-hdd,5277-2.html https://www.tomshardware.com/reviews/wd-red-10tb-8tb-nas-hdd... So yeah maybe not over 400MB/s, but all of them are over 200MB/s. Sequential speeds really spiked as densities kept increasing.
the8472 8y ago
Definitely seeing GB/s IO spikes on my samsung NVMe drives. E.g. when persisting application state into sqlite. Note that you're not going to get this with SATA SSDs, you need NVMe, it's a 5x difference in throughput and IOPS.