3 ms·

Your snarkiness is not appreciated and I never said you should do constant switching. It's not required. > If you ask the OS to read 4k from 10k files simultan

Your snarkiness is not appreciated and I never said you should do constant switching. It's not required. > If you ask the OS to read 4k from 10k files simultaneously There is a difference between between copying inbound data from 10k handles simultaneously (which does require as many buffers) on the one hand, and on the other hand being open to read from any M-sized subset of 10k handles at once, which requires only M buffers. I also never said to have only 4k of (combined) buffer data for 10k handles. "4k should be a reasonable read buffer size" means 4k per buffer. I don't think I've been unclear, but with a tiny bit of good will you could have figured out what I meant anyway.

magicalhippo 8y ago
FWIW I'm not trying to be snarky. > I never said you should do constant switching. It's not required. I didn't see any other way to interpret your "It should let me choose which buffer I want to use next". Though perhaps what you meant was that you want to be able to tell the OS "yo, here's a bunch of buffers, use these to complete my reads"? > [...] and on the other hand being open to read from any M-sized subset of 10k handles at once, which requires only M buffers. I interpret that as saying "yo OS, I want to read 4k each from these 10k files, but only use these M 4k buffers when doing so", where M << 10k. If a request is slow to be fulfilled won't it hog a buffer, reducing the maximum throughput of the fast requests? Why would this be a performance win?
- jstimpfle 8y ago
  > Though perhaps what you meant was that you want to be able to tell the OS "yo, here's a bunch of buffers, use these to complete my reads"? Thank you for clarifying, and yes, that would be the best way to do it I think. > If a request is slow to be fulfilled won't it hog a buffer, reducing the maximum throughput of the fast requests? Why would this be a performance win? So someone else here said that with IOCP the kernel doesn't have its own read buffers but writes directly to userspace memory (in cases where this is possible, anyway). So there might be a possiblity for buffer hogging, I don't know. On the other hand, when the request really is slow to be fulfilled, the OS could just call it a partial write and notify the program of a (partial) completion. In which case the buffer is free for other uses again.
  - magicalhippo 8y ago
    Thanks for the follow-up. Would be interesting to see if it made much difference in the end, guess we'll have to wait a bit longer for all of Windows to be open sourced :P
magicalhippo 8y ago
> I also never said to have only 4k of (combined) buffer data for 10k handles. "4k should be a reasonable read buffer size" means 4k per buffer. I never thought the former, only the latter.
- jstimpfle 8y ago
  Oh I see, it was the other commenter saying "less than 1 byte per buffer" and you only said "by doing 1 byte reads". It seems I really was a little unclear and should try to hold my horses.
  - magicalhippo 8y ago
    No harm done :) My idea was to exploit the caching mechanism in the OS. Though clearly it wouldn't be as efficient as providing a set of buffers for the OS to use.

magicalhippo 8y ago

FWIW I'm not trying to be snarky. > I never said you should do constant switching. It's not required. I didn't see any other way to interpret your "It should let me choose which buffer I want to use next". Though perhaps what you meant was that you want to be able to tell the OS "yo, here's a bunch of buffers, use these to complete my reads"? > [...] and on the other hand being open to read from any M-sized subset of 10k handles at once, which requires only M buffers. I interpret that as saying "yo OS, I want to read 4k each from these 10k files, but only use these M 4k buffers when doing so", where M << 10k. If a request is slow to be fulfilled won't it hog a buffer, reducing the maximum throughput of the fast requests? Why would this be a performance win?

jstimpfle 8y ago
> Though perhaps what you meant was that you want to be able to tell the OS "yo, here's a bunch of buffers, use these to complete my reads"? Thank you for clarifying, and yes, that would be the best way to do it I think. > If a request is slow to be fulfilled won't it hog a buffer, reducing the maximum throughput of the fast requests? Why would this be a performance win? So someone else here said that with IOCP the kernel doesn't have its own read buffers but writes directly to userspace memory (in cases where this is possible, anyway). So there might be a possiblity for buffer hogging, I don't know. On the other hand, when the request really is slow to be fulfilled, the OS could just call it a partial write and notify the program of a (partial) completion. In which case the buffer is free for other uses again.
- magicalhippo 8y ago
  Thanks for the follow-up. Would be interesting to see if it made much difference in the end, guess we'll have to wait a bit longer for all of Windows to be open sourced :P

magicalhippo 8y ago

> I also never said to have only 4k of (combined) buffer data for 10k handles. "4k should be a reasonable read buffer size" means 4k per buffer. I never thought the former, only the latter.

jstimpfle 8y ago
Oh I see, it was the other commenter saying "less than 1 byte per buffer" and you only said "by doing 1 byte reads". It seems I really was a little unclear and should try to hold my horses.
- magicalhippo 8y ago
  No harm done :) My idea was to exploit the caching mechanism in the OS. Though clearly it wouldn't be as efficient as providing a set of buffers for the OS to use.