Newest at the top
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 |
2024-09-21 22:04:20 +0200 | <geekosaur> | and glibc has massive amounts of code to look up and adapt to specific kernel versions' ABIs |
2024-09-21 22:04:06 +0200 | <EvanR> | sounds like golang likes job security |
2024-09-21 22:03:56 +0200 | <tomsmeding> | TIL |
2024-09-21 22:03:48 +0200 | <tomsmeding> | I know on macos the syscall interface is unstable |
2024-09-21 22:03:46 +0200 | <geekosaur> | yes, he did it by making a contract with the glibc maintainers |
2024-09-21 22:03:36 +0200 | <tuxpaint> | i am coming from golang world, where syscalls are implemented without any C. I know it is rather unique to go. |
2024-09-21 22:03:31 +0200 | <tomsmeding> | wasn't Linus' mantra "don't break userspace"? |
2024-09-21 22:03:24 +0200 | <geekosaur> | no, it is especially true on linux |
2024-09-21 22:03:14 +0200 | <tomsmeding> | geekosaur: surely that's false on linux? |
2024-09-21 22:03:13 +0200 | <EvanR> | or experts llvm |
2024-09-21 22:03:04 +0200 | <tuxpaint> | got it, makes sense |
2024-09-21 22:03:01 +0200 | <EvanR> | ghc generates its own code right |
2024-09-21 22:03:00 +0200 | <geekosaur> | the kernel's interface with glibc changes constantly. alternative libcs like musl need to keep up, and if something changed that they don't know about your program will crash |
2024-09-21 22:02:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |