Newest at the top
2024-09-21 22:22:00 +0200 | <geekosaur> | libc calls can therefore crash |
2024-09-21 22:21:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
2024-09-21 22:21:54 +0200 | <tuxpaint> | it makes it faster, but it's still very very slow |
2024-09-21 22:21:53 +0200 | <geekosaur> | libc *has a runtime*. go does not initialize that runtume |
2024-09-21 22:21:52 +0200 | <tomsmeding> | that's just `start()` at the start of the go _process_ |
2024-09-21 22:21:46 +0200 | <tuxpaint> | yes, you can set gomaxprocs to a very high number, and do one thread per syscall |
2024-09-21 22:21:36 +0200 | <geekosaur> | you still don't have loibc initialized |
2024-09-21 22:21:30 +0200 | <tomsmeding> | I still don't see what the difference is |
2024-09-21 22:21:23 +0200 | <tomsmeding> | okay, but if you're willing to start another thread for that syscall, why not run the libc call in that new thread too? |
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. |