Newest at the top
| 2024-09-21 22:21:02 +0200 | <tuxpaint> | gomaxprocs does not determine the max amount of system threads |
| 2024-09-21 22:21:01 +0200 | <tomsmeding> | it's not like that `syscall` instruction can magically go off and run asynchronously |
| 2024-09-21 22:20:55 +0200 | <tuxpaint> | you can launch another thread and do work, you are not frozen |
| 2024-09-21 22:20:55 +0200 | <geekosaur> | no? it fires off completely separate threads for that |
| 2024-09-21 22:20:39 +0200 | <tomsmeding> | fine, but you still have a thread less for "normal" go code! |
| 2024-09-21 22:20:26 +0200 | <geekosaur> | the IO manager manages them separately from standard threads |
| 2024-09-21 22:20:12 +0200 | <tomsmeding> | ... okay, but the thread is still blocked and can't do anything else |
| 2024-09-21 22:20:03 +0200 | <geekosaur> | like ghc's IO manager threads |
| 2024-09-21 22:19:58 +0200 | <geekosaur> | right |
| 2024-09-21 22:19:51 +0200 | <tuxpaint> | the runtime does not see that thread as a thread that is "working" |
| 2024-09-21 22:19:45 +0200 | <tomsmeding> | so something is contradictory here |
| 2024-09-21 22:19:39 +0200 | <geekosaur> | (ghc ensures the C RTS is set up, but go's pure-go approach means it probably isn't and going through libc will therefore be dangerous) |
| 2024-09-21 22:19:31 +0200 | <tomsmeding> | tuxpaint: if you perform a syscall, your thread is blocked |
| 2024-09-21 22:19:26 +0200 | <tuxpaint> | and it doesn't take up when waiting, one of your gomaxprocs slots |
| 2024-09-21 22:19:11 +0200 | <tuxpaint> | while the pure-go syscall, they can unblock the worker and do something else while the syscall is waiting |
| 2024-09-21 22:19:00 +0200 | <geekosaur> | other things that come up are C-style global constructors/destructors and things that look like syscalls but aren't directly and may use services like malloc which could well fail with the go runtime because the C runtime isn't initialized |
| 2024-09-21 22:18:21 +0200 | <tuxpaint> | in go there is gomaxprocs, so each blocking thread takes a slot from gomaxprocs. say you have 20 slots, a cgo call will take one of those 20 slots when invoked, and cannot unblock the worker. |
| 2024-09-21 22:17:57 +0200 | <geekosaur> | I assume go's stdlib is wired to a particular kernel ABI and doesn't need the runtime checks |
| 2024-09-21 22:17:50 +0200 | <tomsmeding> | sure, but tuxpaint is claiming that there is more than just speed |
| 2024-09-21 22:17:31 +0200 | <geekosaur> | speed. did you notice earlier when I mentioned the extra code to check kernel ABI versions? |
| 2024-09-21 22:17:11 +0200 | <tomsmeding> | (apart from the latter possibly being a little slower) |
| 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 :) |