Newest at the top
| 2024-09-21 22:27:14 +0200 | <tomsmeding> | and I claim that these (hypothetical) libc calls are written by go developers in the go stdlib, so there's no good reason to have to go through all the usual hoops |
| 2024-09-21 22:27:03 +0200 | <tuxpaint> | i think the go team felt that was just as much effort as doing it themselves |
| 2024-09-21 22:26:56 +0200 | <tuxpaint> | i guess you could make your own special wrappers with safety guarantees around each libc, yes |
| 2024-09-21 22:26:50 +0200 | <tomsmeding> | that is exactly what I'm asking |
| 2024-09-21 22:26:40 +0200 | <tuxpaint> | there's no special things to handle libc safely, if that is what you are asking? |
| 2024-09-21 22:26:32 +0200 | <tuxpaint> | the only way to use libc in go is through CGO, it's treated as any other c library |
| 2024-09-21 22:26:27 +0200 | <tomsmeding> | sorry for the outburst |
| 2024-09-21 22:26:13 +0200 | <tomsmeding> | I fucking KNOW, you two :') |
| 2024-09-21 22:25:58 +0200 | <tomsmeding> | but you were saying that there's _more_ and I still haven't gotten clear what that is :p |
| 2024-09-21 22:25:50 +0200 | <geekosaur> | libc does extra runtime checks, it randomly wraps syscalls with extra goop that updates libc internal data, etc, |
| 2024-09-21 22:25:49 +0200 | <tomsmeding> | I get that 1. linking with libc means that the compiler has to do more, and that 2. going via libc takes longer than just doing the syscall, and 3. initialising libc takes time |
| 2024-09-21 22:25:26 +0200 | <tomsmeding> | I get that! |
| 2024-09-21 22:25:18 +0200 | <tomsmeding> | as far as I understand, the gomaxprocs story is all irrelevant |
| 2024-09-21 22:25:17 +0200 | <tuxpaint> | and its to have the fast compile times, and to compile the entire project from source every compile |
| 2024-09-21 22:25:17 +0200 | <geekosaur> | but I'm bailing since I'm apparently talking to a wall |
| 2024-09-21 22:25:06 +0200 | <geekosaur> | and I told you part of what that runtime cost was |
| 2024-09-21 22:25:04 +0200 | <tomsmeding> | and I have been trying to reason that there is no such cost, apart from libc being somewhat slower, which is what geekosaur has been saying all the time already |
| 2024-09-21 22:24:53 +0200 | <tuxpaint> | there is no libc at all, that is one of the goals |
| 2024-09-21 22:24:35 +0200 | <tomsmeding> | _apart_ from initialisation at the start of the process |
| 2024-09-21 22:24:29 +0200 | <geekosaur> | that's the whole point of this, libc is replaced by go's RTS |
| 2024-09-21 22:24:24 +0200 | <tomsmeding> | because previously you were claiming, repeatedly, that there is a real runtime cost |
| 2024-09-21 22:24:22 +0200 | <tuxpaint> | imo yes. and it's a major language feature of go |
| 2024-09-21 22:24:12 +0200 | <tomsmeding> | tuxpaint: is that linking/rebuilding/static binaries reason the only reason to not want to link libc? |
| 2024-09-21 22:24:10 +0200 | <geekosaur> | tomsmeding, in the go world you do _not_ call it. at all. |
| 2024-09-21 22:24:01 +0200 | <tuxpaint> | for such static binaries |
| 2024-09-21 22:23:49 +0200 | <tuxpaint> | which defeats the goal of having portable static binaries, and very fast build times |
| 2024-09-21 22:23:47 +0200 | <tomsmeding> | geekosaur: right, but you just do that once, right? |
| 2024-09-21 22:23:40 +0200 | <tuxpaint> | so you either need to link it, or rebuild it every time |
| 2024-09-21 22:23:33 +0200 | <geekosaur> | …right, never mind |
| 2024-09-21 22:23:32 +0200 | <tuxpaint> | well now you are calling libc right? |
| 2024-09-21 22:23:31 +0200 | <tomsmeding> | and anyway, freeing up a worker is lying to yourself, because the time that you spend in kernel mode is also cpu time |
| 2024-09-21 22:23:07 +0200 | <tomsmeding> | this libc call is written by go developers in the go standard library, it's not a random go programmer that goes through the cgo interface |
| 2024-09-21 22:22:57 +0200 | <geekosaur> | (glibc's RTS startup actually does quite a lot, if you strace a program you'll see a _lot_ of activity before main() is called) |
| 2024-09-21 22:22:47 +0200 | <tomsmeding> | tuxpaint: why could the runtime not spawn up a new system thread, that is _not_ registered as a go worker, to run the libc call in? |
| 2024-09-21 22:22:19 +0200 | <tuxpaint> | as in, unusably slow for many disk operations (think database) |
| 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 |