Newest at the top
| 2024-09-21 22:16:58 +0200 | <tomsmeding> | I dunno, maybe. But if so, then what's the difference (to go) between a syscall and a libc function that wraps that syscall? |
| 2024-09-21 22:16:44 +0200 | <geekosaur> | similarly to what ghc's RTS does with `safe` calls |
| 2024-09-21 22:16:27 +0200 | <geekosaur> | right, I assume it offloads the actual call to a thread that isn't part of the scheduler so it can safely block |
| 2024-09-21 22:16:23 +0200 | <tomsmeding> | eventually there is some code in go's stdlib or RTS that does the actual syscall, be it directly or through libc |
| 2024-09-21 22:16:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 22:15:36 +0200 | <tomsmeding> | of course, but we're talking about how said go function is implemented |
| 2024-09-21 22:15:18 +0200 | <geekosaur> | right, but you're not supposed to do either, you use the go function which offloads the call (similarly to Haskell's `safe`) so it doesn't block the scheduler |
| 2024-09-21 22:14:49 +0200 | <tomsmeding> | (surely?) |
| 2024-09-21 22:14:36 +0200 | <tomsmeding> | well, some are, but then the libc call would also be |
| 2024-09-21 22:14:05 +0200 | <tomsmeding> | but a syscall is also uninterruptible |
| 2024-09-21 22:14:01 +0200 | <geekosaur> | blocking syscalls would be a problem, imagine that a go syscall is Haskell's `unsafe` |
| 2024-09-21 22:13:49 +0200 | <tomsmeding> | libc is just C code, which is just additional work that happens before and after the syscall -- which itself is just work that happens on a different privilege level |
| 2024-09-21 22:13:41 +0200 | <tuxpaint> | it becomes a task that is uninterruptable by the go runtime, since the syscall is happening outside of the runtime, it has to make the most conservative assumptions possible |
| 2024-09-21 22:13:18 +0200 | <tomsmeding> | tuxpaint: that sounds weird to me; libc surely doesn't lock up the runtime any more than a system call does. The only reason would be that libc has overhead -- which I can accept -- but that would still just be "doing syscalls directly is faster". |
| 2024-09-21 22:11:50 +0200 | <tomsmeding> | note that buffers are not flushed by the RTS upon exit(3) |
| 2024-09-21 22:11:37 +0200 | <tomsmeding> | https://paste.tomsmeding.com/WzVl8hRp |
| 2024-09-21 22:11:24 +0200 | <tuxpaint> | it's not about absolute speed, it locks up the runtime and would make the language unusable |
| 2024-09-21 22:11:03 +0200 | <geekosaur> | (more likely they watch the commits list very closely so they have the necessary library changes by the time it's released) |
| 2024-09-21 22:10:37 +0200 | <tomsmeding> | use the capi style though, for the reasons monochrom mentioned |
| 2024-09-21 22:10:33 +0200 | <tuxpaint> | if you do syscalls through libc you have to do calls which fuck with the go scheduler. |
| 2024-09-21 22:10:25 +0200 | <tuxpaint> | yep! |
| 2024-09-21 22:10:21 +0200 | <tomsmeding> | tuxpaint: seems we have a workaround? :p |
| 2024-09-21 22:10:12 +0200 | <EvanR> | move fast break things |
| 2024-09-21 22:09:58 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-09-21 22:09:41 +0200 | <geekosaur> | so they can't update a kernel without auditing the kernel/libc interface and updating their go libs, or they get random crashes |
| 2024-09-21 22:09:39 +0200 | <tomsmeding> | ah good, capi vs ccall import doesn't make a difference in timing |
| 2024-09-21 22:09:00 +0200 | <geekosaur> | no, they just want absolute speed and went the accursedUnutterablePerformIO route |
| 2024-09-21 22:08:22 +0200 | <tuxpaint> | and yeah, it's google. they probably need more jobs for the employees they already have :) |
| 2024-09-21 22:08:11 +0200 | <monochrom> | OK heh :) |
| 2024-09-21 22:08:07 +0200 | <tuxpaint> | EvanR: its somewhat required as part of design, since having non-go code, or linking to libc would remove the "fast compilation speed and compile everything from scratch" feature. |
| 2024-09-21 22:08:05 +0200 | <monochrom> | (The price is of course the compile time is longer.) |
| 2024-09-21 22:08:03 +0200 | <geekosaur> | ^ |
| 2024-09-21 22:08:02 +0200 | troojg | (~troojg@user/troojg) |
| 2024-09-21 22:08:02 +0200 | <tomsmeding> | monochrom: I know |
| 2024-09-21 22:07:46 +0200 | <monochrom> | If you s/ccall "exit"/capi "stdlib.h exit"/ it will be more portable over various platforms that may make "exit()" a function or a macro or a syscall or anything. |
| 2024-09-21 22:07:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 22:07:32 +0200 | <tomsmeding> | geekosaur: TIL |
| 2024-09-21 22:07:27 +0200 | <tomsmeding> | that seems within cpu speed variation |
| 2024-09-21 22:07:22 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 272 seconds) |
| 2024-09-21 22:06:59 +0200 | <tuxpaint> | yeah, i'm getting 1.1ms with exit() with hyperfine -N |
| 2024-09-21 22:06:47 +0200 | <tomsmeding> | seems almost _all_ of the time is spent in shutdown |
| 2024-09-21 22:06:42 +0200 | <geekosaur> | (this is not according to POSIX, iirc, threads are associated with a process and _exit() kills the entire process. thanks the old LinuxThreads disaster for this) |
| 2024-09-21 22:06:38 +0200 | <tomsmeding> | tuxpaint: seems those 6ms and 15ms numbers were including some shell overhead. I installed hyperfine, and `hyperfine -N ./pure` (i.e. not going via the shell) yields 13.8ms without exit(3), and 0.93ms with exit(3) |
| 2024-09-21 22:06:30 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-09-21 22:05:49 +0200 | <geekosaur> | (The raw _exit() system call terminates only the calling thread.) |
| 2024-09-21 22:05:49 +0200 | <geekosaur> | glibc 2.3, the wrapper function invokes exit_group(2), in order to terminate all of the threads in a process. |
| 2024-09-21 22:05:48 +0200 | <geekosaur> | In glibc up to version 2.3, the _exit() wrapper function invoked the kernel system call of the same name. Since |
| 2024-09-21 22:04:37 +0200 | <geekosaur> | it did, actually |
| 2024-09-21 22:04:27 +0200 | <tomsmeding> | I mean, exit(2) probably isn't going anywhere |
| 2024-09-21 22:04:20 +0200 | <EvanR> | constantly following changes in linux |