4 ms·

My own perf comparison: when I switched from Fil-C running on my system’s libc (recent glibc) for yololand to my own build of musl, I got a 1-2% perf regression

My own perf comparison: when I switched from Fil-C running on my system’s libc (recent glibc) for yololand to my own build of musl, I got a 1-2% perf regression. My best guess is that it’s because glibc’s memcpy/memmove/memset are better. Couldn’t have been the allocator since Fil-C’s runtime has its own allocator.

abnercoimbre 1y ago
Interesting! Will you stick around with the musl build? And if so, why?
- pizlonator 1y ago
  Not sure but in likely to because right now I to use the same libc in userland (the Fil-C compiled part) and yololand (the part compiled by normal C that is below the runtime) and the userland libc is musl. Having them be the same means that if there is any libc function that is best implemented by having userland call a Fil-C runtime wrapper for the yololand implementation (say because what it’s doing requires platform specific assembly) then I can be sure that the yololand libc really implements that function the same way with all the same corner cases. But there aren’t many cases of that and they’re hacks that I might someday remove. So I probably won’t have this “libc sandwich” forever
LukeShu 1y ago
When I was working with Envoy Proxy, it was known that perf was worse with musl than with glibc. We went through silly hoops to have a glibc Envoy running in an Alpine (musl) container.
skissane 1y ago
What's Fil-C? Okay, found it myself, looks cool: https://github.com/pizlonator/llvm-project-deluge/ https://github.com/pizlonator/llvm-project-deluge/ What's yoyoland? All I can find is an amusement park in Bangkok, and some 1990s-era communication software for Classic Mac OS: https://www.macintoshrepository.org/39495-yoyo-2-1 https://www.macintoshrepository.org/39495-yoyo-2-1
- pizlonator 1y ago
  The Fil-C stack is composed of : - Userland: the place where you C code lives. Like the normal userland you're familiar with, but everything is compiled with Fil-C, so it's memory safe. - Yololand: the place where Fil-C's runtime lives. Fil-C's runtime is about 100,000 lines of C code (almost entirely written by me), which currently has libc as a dependency (because the runtime makes syscalls using the normal C functions for syscalls rather than using assembly directly; also the runtime relies on a handful of libc utility functions that aren't syscalls, like memcpy). So Fil-C has two libc's. The yololand libc (compiled with a normal C compiler, only there to support the runtime) and the userland libc (compiled with the Fil-C compiler like everything else in Fil-C userland, and this is what your C code calls into).
  - skissane 1y ago
    Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy? On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does. Doesn’t work on some other operating systems (e.g. Solaris/Illumos, OpenBSD, macOS, Windows) where the system call interface is private to the system shared libraries
    - pizlonator 1y ago
      > Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy? Unless you do special things, the compiler turns __builtin_memcpy into a call to memcpy. :-) There is __builtin_memcpy_inline, but then you're at the compiler's whims. I don't think I want that. A faithful implementation of what you're proposing would have the Fil-C runtime provide a memcpy function so that whenever the compiler wants to call memcpy, it will call that function. > On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does. I could do that. I just don't, right now. You're totally right that I could remove the yolo libc. This is one of like 1,000 reasons why Fil-C is slower than it needs to be right now. It's a young project so it has lots of this kind of "expedient engineering".
    - imcritic 1y ago
pjmlp 1y ago
Are you sure they were being used at all? GCC replaces memcpy/memmove/memset with its own intrisics, if compiling in high optimization levels.
- pizlonator 1y ago
  Yes they were being used.

abnercoimbre 1y ago

Interesting! Will you stick around with the musl build? And if so, why?

pizlonator 1y ago
Not sure but in likely to because right now I to use the same libc in userland (the Fil-C compiled part) and yololand (the part compiled by normal C that is below the runtime) and the userland libc is musl. Having them be the same means that if there is any libc function that is best implemented by having userland call a Fil-C runtime wrapper for the yololand implementation (say because what it’s doing requires platform specific assembly) then I can be sure that the yololand libc really implements that function the same way with all the same corner cases. But there aren’t many cases of that and they’re hacks that I might someday remove. So I probably won’t have this “libc sandwich” forever

LukeShu 1y ago

When I was working with Envoy Proxy, it was known that perf was worse with musl than with glibc. We went through silly hoops to have a glibc Envoy running in an Alpine (musl) container.

skissane 1y ago

What's Fil-C? Okay, found it myself, looks cool: https://github.com/pizlonator/llvm-project-deluge/ https://github.com/pizlonator/llvm-project-deluge/ What's yoyoland? All I can find is an amusement park in Bangkok, and some 1990s-era communication software for Classic Mac OS: https://www.macintoshrepository.org/39495-yoyo-2-1 https://www.macintoshrepository.org/39495-yoyo-2-1

pizlonator 1y ago
The Fil-C stack is composed of : - Userland: the place where you C code lives. Like the normal userland you're familiar with, but everything is compiled with Fil-C, so it's memory safe. - Yololand: the place where Fil-C's runtime lives. Fil-C's runtime is about 100,000 lines of C code (almost entirely written by me), which currently has libc as a dependency (because the runtime makes syscalls using the normal C functions for syscalls rather than using assembly directly; also the runtime relies on a handful of libc utility functions that aren't syscalls, like memcpy). So Fil-C has two libc's. The yololand libc (compiled with a normal C compiler, only there to support the runtime) and the userland libc (compiled with the Fil-C compiler like everything else in Fil-C userland, and this is what your C code calls into).
- skissane 1y ago
  Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy? On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does. Doesn’t work on some other operating systems (e.g. Solaris/Illumos, OpenBSD, macOS, Windows) where the system call interface is private to the system shared libraries
  - pizlonator 1y ago
    > Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy? Unless you do special things, the compiler turns __builtin_memcpy into a call to memcpy. :-) There is __builtin_memcpy_inline, but then you're at the compiler's whims. I don't think I want that. A faithful implementation of what you're proposing would have the Fil-C runtime provide a memcpy function so that whenever the compiler wants to call memcpy, it will call that function. > On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does. I could do that. I just don't, right now. You're totally right that I could remove the yolo libc. This is one of like 1,000 reasons why Fil-C is slower than it needs to be right now. It's a young project so it has lots of this kind of "expedient engineering".
  - imcritic 1y ago

pjmlp 1y ago

Are you sure they were being used at all? GCC replaces memcpy/memmove/memset with its own intrisics, if compiling in high optimization levels.

pizlonator 1y ago
Yes they were being used.