Earlier quoted context omitted.
> 6 GB/s Samsung is selling NVMe SSDs claiming 14 GB/s sequential read speed.
Any code that's reading/writing to SSD needs to use multiple cores. The SSD is faster than a single CPU core.
I/O is no longer the bottleneck? (2022)
101–110 of 133 posts
Re: I/O is no longer the bottleneck? (2022)
#102Increasingly 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…
Quite easy to outperform a parsing library when you're not actually doing any parsing work and just memory-mapping pre-parsed data... That being said storing trees as serializable flat buffers is definitely useful, if only because you can release them very cheaply.
Re: I/O is no longer the bottleneck? (2022)
#103Author here. There is a part 2 to this: https://stoppels.ch/2022/11/30/io-is-no-longer-the-bottlenec...
Some other participants said that they measured 0 difference in runtime between pshufb+eq and eqx3+orx2, but i think your problem has more classes of whitespace, and for the histogram problem, considerations about how to hash all the words in a chunk of the input dominate considerations about how to obtain the bitmasks of word-start or word-end positions.
Re: I/O is no longer the bottleneck? (2022)
#104Earlier quoted context omitted.
> 6 GB/s Samsung is selling NVMe SSDs claiming 14 GB/s sequential read speed.
> 14 GB/s Yes, those numbers are real but only in very short bursts of strictly sequential reads, sustained speeds will be closer to 8-10 GB/s. And real workloads will be lower than that, because they contain random access. Most NVMe drivers on Linux actually DMA the pages directly into host memory over the PCIe link, so it is not actually the CPU that is moving the data. Whenever the CPU is involved in any data move…
In Linux you can use direct IO or RWF_UNCACHED to avoid paying extra for unwanted readahead.
Re: I/O is no longer the bottleneck? (2022)
#105Increasingly 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…
Which file formats allow partial parsing?
Re: I/O is no longer the bottleneck? (2022)
#106Earlier quoted context omitted.
Quite easy to outperform a parsing library when you're not actually doing any parsing work and just memory-mapping pre-parsed data... That being said storing trees as serializable flat buffers is definitely useful, if only because you can release them very cheaply.
Imagine if you measured the speed of beer delivery by the rate at which beer cans can be packed/unpacked from truck pallets. But then somebody shows up with a tanker truck and starts pumping beer directly in and out. You might argue this is 'unfair' because the tanker is not doing any packing or unpacking. But then you realize it was never about packing speed in the first place. It was about delivering beer.
Re: I/O is no longer the bottleneck? (2022)
#107Earlier quoted context omitted.
Being schemaless is deliberate design decision as it eliminates the need for managing and building schema files. By not requiring schema, messages are always readable to arbitrary consumers. If you want schema, it must be done by the application through runtime type checking. All messages contain type information. Though I do see the value of adding pydantic-like schema checking in the future. EDIT: Regarding message…
The thing about schemaless is that it's great for usability and I like it with JSON but as with JSON when we develop applications in reality at the end of the day you always have some kind of schema, whether it's written down or not. Like you alluded with pydantic, the application is going to rely on the data being in some sort of shape, even if it's very defensively written and practically everything is optional, yo…
Re: I/O is no longer the bottleneck? (2022)
#108Author here. There is a part 2 to this: https://stoppels.ch/2022/11/30/io-is-no-longer-the-bottlenec...
Hello, a couple years ago I participated in a contest to count word frequencies and generate a sorted histogram. There's a cool post about it featuring a video discussing the tricks used by some participants. https://easyperf.net/blog/2022/05/28/Performance-analysis-an... Some other participants said that they measured 0 difference in runtime between pshufb+eq and eqx3+orx2, but i think your problem has more classes…
Re: I/O is no longer the bottleneck? (2022)
#109Not a new idea, but it's intriguing to think about an architecture that's just: CPU caches nonvolatile storage What if you could take it for granted that mmap()ing a file has the exact same performance characteristics as malloc(), aside from the data not going away when you free the address space? What if arbitrary program memory could be given a filename and casually handed off to the OS to make persistent? A lot of…
> A lot of basic software design assumptions are still based on the constraints of the spinning rust era... fsync() is still slow, and you need that for real persistence. It's not just about spinning rust, there's very good reasons for wanting a different treatment of clearly ephemeral/scratchpad storage.