previous: >>107929895#define __NR_readv 19https://man7.org/linux/man-pages/man2/readv.2.htmlyet another read clone, huh... they really went all out with adding a million different ways to perform the same fundamental operation. and i'm honestly really struggling to see the use case for this one. i'm sure it's out there, but god. is calling read in a loop really so terrible? at least iovec (https://man7.org/linux/man-pages/man3/iovec.3type.html) is a nice little blob container....... i guess it's nice that each iov operation is atomic? (<- grasping at straws)relevant resources: man manman syscallshttps://man7.org/linux/man-pages/https://linux.die.net/man/https://elixir.bootlin.com/linux/https://elixir.bootlin.com/musl/https://elixir.bootlin.com/glibc/
#define __NR_readv 19
man man
man syscalls
>>107939911I wish I had something to contribute to your autism thread
>>107939911>is calling read in a loop really so terrible?yes, non-vectored read/write should not even be a thing. there is literally no use case for such retardation.
>>107939911Is this also encumbered by IOV_MAX?
>>107939911I've never used readv but writev gave me nice speedups in /g/ pissing contests. Syscalls are expensive.readv is probably nice for reading into a circular buffer? But if you're using it to read many records then it's awkward that you need to know all the record lengths ahead of time.>>107940268WASI does this.>>107940414Yes.
>>107940485>/g/ pissing contestsIf you mean the sort thing I sped up mine a lot after the thread diedhttps://pastebin.com/Bt3FmAni6.5ms with gcc-14 and 6.1ms with clang-20
>>107940799nice UB
>>107940799I didn't use it for that one because the lines were too short to make it worth it but I used it in https://desuarchive.org/g/thread/85752414/#85758937 and maybe in some later advent of code threads.>https://pastebin.com/Bt3FmAniThis segfaults on GCC (Debian 14.2.0-19 x86_64) on all optimization levels, except when I use -fsanitize=address, in which case it gives nondeterministic output with the right number of bytes but the wrong number of lines. So something is wrong.But on clang it gives the right output and beats mine by 10-25%. Nice.
>>107941120coolthanks for testing it out
>>107941120>So something is wrong.Alignment issue. GCC assumes rsp is aligned to 16 bytes
>>107941366which is fair, because that's mandated by the SysV ABI
>>107939911i have linked list of strings and i want to write them to a file what is fasterjoin them together with newline as seperator in memory and normal write to the fileuse writev, put newline after each string in the vector a
>>107942571If the strings are e.g. 20 bytes long on average then since IOV_MAX = 1024 you'll write 20B * 1024 / 2 = ~10KB of data per syscall. That's not much so I'd expect joining them in your own buffer and doing larger writes to be faster. If they're e.g. 1000 bytes on average then I expect writev to win. You should measure it.If you can add the newlines to your strings in advance then you double the number of strings you can write per call.>linked listConsider using a growable array if you can, linked lists tend to be very slow on modern hardware.
>>107940025your presence is appreciated anyways. Thank you for being here anon
>>107942622i have my linked list nodes (and most likely the strings too) on the same arena so some problems are mitigated>IOV_MAXohh i didn't even see that i guess it makes sense to do hard caps in the kernel like that i guess you are right that ultimately i have to measure but i feel like it most likely doesn't matter
>>107942962My experience is that a large buffer gives predictably good performance while writev can be even better but harshly tanks performance if your strings are small or the system has a low IOV_MAX. So not a safe optimization.One way to think about it that maybe misses some crucial nuances is that the worst-case overhead of a buffer is 2x, from copying your strings twice (once by you into the buffer and once by the kernel into the file) instead of once, if copies are the bottleneck. While the worst-case overhead of writev might be 20x if you have to do 20x as many syscalls and syscalls are your bottleneck.
>>107939911this must be one of the best threads in this board simply because of how it motivates/invites people to learn something, and it's not even complicated to make, though it obviously requires some effort and dedication.thanks OP.this really says a lot about the state of this board, though.
>>107939911brat correction
>>107944467btw, I know some (most?) people use this board to complain/laugh about shit or to troll other people, but, seriously... we get the same shit over and over, and the only things that could improve the status of this board are of low quality. I'm not even sure why I come here...on the other hand, I could also contribute, but:1. whenever I tried, no one cared (I guess I could have been more pushy?), and2. honestly I fell for the "I don't want to train my competitors" mentality.3. you get called shill whenever you post something interesting from, say, youtube or whatever.I mean, if no one cares about stuff, why even do any effort?guess I went into a meta discussion here. sorry about that.
>>107940799>while (jobs[i].tid)shouldn't it be while(atomic_load(... ?
