Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

io_uring is faster than mmap

bitflux.ai

Post reply on HN
Print view View original

11–20 of 143 posts

Re: io_uring is faster than mmap

#11

Post by jared_hulbert »

inetknght wrote: post #7
jared_hulbert wrote: post #4

Earlier quoted context omitted.

Oh man... I'd have look into that. Off the top of my head I don't know how you'd make that happen. Way back when I'd have said no. Now with all the folio updates to the Linux kernel memory handling I'm not sure. I think you'd have to take care to make sure the data gets into to page cache as huge pages. If not then when you tried to madvise() or whatever the buffer to use huge pages it would likely just ignore you. I…

> I'd have look into that. Off the top of my head I don't know how you'd make that happen. Pass these flags to your mmap call: (MAP_HUGETLB | MAP_HUGE_1GB)

Would this actually create huge page page cache entries?

Re: io_uring is faster than mmap

#12

Post by titanomachy »

Very interesting article, thanks for publishing these tests!

Is the manual loop unrolling really necessary to get vectorized machine code? I would have guessed that the highest optimization levels in LLVM would be able to figure it out from the basic code. That's a very uneducated guess, though.

Also, curious if you tried using the MAP_POPULATE option with mmap. Could that improve the bandwidth of the naive in-memory solution?

> humanity doesn't have the silicon fabs or the power plants to support this for every moron vibe coder out there making an app.

lol. I bet if someone took the time to make a high-quality well-documented fast-IO library based on your io_uring solution, it would get use.

Re: io_uring is faster than mmap

#14

Post by inetknght »

jared_hulbert wrote: post #11
inetknght wrote: post #7

Earlier quoted context omitted.

> I'd have look into that. Off the top of my head I don't know how you'd make that happen. Pass these flags to your mmap call: (MAP_HUGETLB | MAP_HUGE_1GB)

Would this actually create huge page page cache entries?

It's right in the documentation for mmap() [0]! And, from my experience, using it with an 800GB file provided a significant speed-up, so I do believe the documentation is correct ;)

And, you can poke around in the linux kernel's source code to determine how it works. I had a related issue that I ended up digging around to find the answer to: what happens if you use mremap() to expand the mapping and it fails; is the old mapping still valid or not? Answer: it's still valid. I found that it was actually fairly easy to read linux kernel C code, compared to a lot (!) of other C libraries I've tried to understand.

[0]: https://www.man7.org/linux/man-pages/man2/mmap.2.html

Re: io_uring is faster than mmap

#15

Post by jared_hulbert »

nchmy wrote: post #9
jared_hulbert wrote: post #2

Cool. Original author here. AMA.

I just saw this post so am starting with Part 1. Could you replace the charts with ones on some sort of log scale? It makes it look like nothing happened til 2010, but I'd wager its just an optical illusion... And, even better, put all the lines on the same chart, or at least with the same y axis scale (perhaps make them all relative to their base on the left), so that we can the relative rate of growth?

I tried with the log scale before. They failed to express the exponential hockey stick growth unless you really spend the time with the charts and know what log scale is. I'll work on incorporating log scale due to popular demand. They do show the progress has been nice and exponential over time.

When I put the lines on the same chart it made the y axis impossible to understand. The units are so different. Maybe I'll revisit that.

Yeah around 2000-2010 the doubling is noticeable. Interestingly it's also when alot of factors started to stagnate.

Re: io_uring is faster than mmap

#17

Post by bawolff »

Shouldn't you also compare to mmap with huge page option? My understanding is its presicely meant for this circumstance. I don't think its a fair comparison without it.

Respectfully, the title feels a little clickbaity to me. Both methods are still ultimately reading out of memory, they are just using different i/o methods.

Re: io_uring is faster than mmap

#18

Post by jared_hulbert »

john-h-k wrote: post #13
jared_hulbert wrote: post #2

Cool. Original author here. AMA.

You mention modern server CPUs have capability to “read direct to L3, skipping memory”. Can you elaborate on this?

https://www.intel.com/content/www/us/en/io/data-direct-i-o-t...

AMD has something similar.

The PCIe bus and memory bus both originate from the processor or IO die of the "CPU" when you use an NVMe drive you are really just sending it a bunch of structured DMA requests. Normally you are telling the drive to DMA to an address that maps to the memory, so you can direct it cache and bypass sending it out on the DRAM bus.

In theory... the specifics of what is supported exactly? I can't vouch for that.

Re: io_uring is faster than mmap

#20

Post by jared_hulbert »

bawolff wrote: post #17

Shouldn't you also compare to mmap with huge page option? My understanding is its presicely meant for this circumstance. I don't think its a fair comparison without it. Respectfully, the title feels a little clickbaity to me. Both methods are still ultimately reading out of memory, they are just using different i/o methods.

The original blog post title is intentionally clickbaity. You know, to bait people into clicking. Also I do want to challenge people to really think here.

Seeing if the cached file data can be accessed quickly is the point of the experiment. I can't get mmap() to open a file with huge pages.

void* buffer = mmap(NULL, size_bytes, PROT_READ, (MAP_HUGETLB | MAP_HUGE_1GB), fd, 0); doesn't work.

You can can see my code here https://github.com/bitflux-ai/blog_notes. Any ideas?

Post reply on HN