I/O is no longer the bottleneck? (2022)
stoppels.ch
I/O is no longer the bottleneck? (2022)
1–10 of 133 posts
Re: I/O is no longer the bottleneck? (2022)
#2Previous related discussion: https://news.ycombinator.com/item?id=33751266
Re: I/O is no longer the bottleneck? (2022)
#3The author recently posted an addendum that describes a clever trick to go even faster, which I highly recommend reading: https://news.ycombinator.com/item?id=46503612
Re: I/O is no longer the bottleneck? (2022)
#4Previous related discussion: https://news.ycombinator.com/item?id=33751266
I/O is no longer the bottleneck - https://news.ycombinator.com/item?id=33751266 - Nov 2022 (326 comments)
Re: I/O is no longer the bottleneck? (2022)
#5Previous related discussion: https://news.ycombinator.com/item?id=33751266
I/O is no longer the bottleneck - https://news.ycombinator.com/item?id=33751266 - Nov 2022 (326 comments)
That's not actually this post (that post is by this OP.. confusingly) Harmen/@stabbles just chose the same title. What's here is a retort to that post from a week later (still from back in 2022).
Edit: Ah, I saw @wmf has edited their comment to include "related"
Re: I/O is no longer the bottleneck? (2022)
#6But I/O being the bottleneck never was about sequential reads, was it? I get the point of the article, though.
Re: I/O is no longer the bottleneck? (2022)
#7Increasingly the performance limit for modern CPUs is the amount of data you can feed through a single core: basically memcpy() speed. On most x86 cores the limit is around 6 GB/s and about 20 GB/s for Apple M chips.
When you see advertised numbers like '200 GB/s' that is total memory bandwidth, or all cores combined. For individual cores, the limit will still be around 6 GB/s.
This means even if you write a perfect parser, you cannot go faster. This limit also applies to (de)serializing data like JSON and Protobuf, because those formats must typically be fully parsed before a single field can be read.
If however you use a zero-copy format, the CPU can skip data that it doesn't care about, so you can 'exceed' the 6 GB/s limit.
The Lite³ serialization format I am working on aims to exploit exactly this, and is able to outperform simdjson by 120x in some benchmarks as a result: https://github.com/fastserial/lite3
Re: I/O is no longer the bottleneck? (2022)
#8Increasingly the performance limit for modern CPUs is the amount of data you can feed through a single core: basically memcpy() speed. On most x86 cores the limit is around 6 GB/s and about 20 GB/s for Apple M chips. When you see advertised numbers like '200 GB/s' that is total memory bandwidth, or all cores combined. For individual cores, the limit will still be around 6 GB/s. This means even if you write a perfect…
> 6 GB/s
Samsung is selling NVMe SSDs claiming 14 GB/s sequential read speed.
Re: I/O is no longer the bottleneck? (2022)
#9Increasingly the performance limit for modern CPUs is the amount of data you can feed through a single core: basically memcpy() speed. On most x86 cores the limit is around 6 GB/s and about 20 GB/s for Apple M chips. When you see advertised numbers like '200 GB/s' that is total memory bandwidth, or all cores combined. For individual cores, the limit will still be around 6 GB/s. This means even if you write a perfect…
What is the nature of the architectural limit here? The bus between an individual core and the caches and/or memory controller?
Re: I/O is no longer the bottleneck? (2022)
#10But I/O being the bottleneck never was about sequential reads, was it? I get the point of the article, though.
With modern CXL/PCIe, I guess it's not going to be that stupid to claim that RAM/memory controller is slowly becoming I/O on its own.