IRC channel logs

2026-06-18.log

back to list of logs

<stabbles>fast has the advantage that more people are likely to verify
<xentrac>yeah. also it enables experimentation
<matrix_bridge><Andrius Štikonas> Yeah, but final 3 stage build of GCC 15 actually takes non trivial amount if time in live-bootstrap
<matrix_bridge><Andrius Štikonas> Definitely more than hex0 to GCC 4 even including mes
<stabbles>Yeah, that's slow, but at least it has more parallelism. Apparently there's still low-hanging fruit optimizing that: https://gcc.gnu.org/pipermail/gcc-patches/2026-June/719831.html
<stabbles>And this critique of autotools project structure applies three decades later https://aegis.sourceforge.net/auug97.pdf
<stabbles>I expect you could speed up the full featured GCC build a lot by flattening the sanitizer related makefiles. There's a lot of unnecessary serialization there. Don't know if it has been attempted before.
<stabbles>I tried flattening the sanitizer makefile by eliminating the `for dir in dirs; $(MAKE)` loop. Not as spectacular, but it does go from 85.5s -> 58.7s and the load goes from 2.3 to 3.7 (so still many idle cores sadly). When it comes to GCC it seems to me there's a lot of low-hanging fruit to speed it up just by fiddling with the build system.
<stabbles>Is GitHub the right place to submit patches to mescc-tools? I'm trying to upstream some of my changes: https://github.com/oriansj/mescc-tools/pull/58
<siraben>WIP... still removing Perl parts here. https://github.com/siraben/nixpkgs-darwin-bootstrap
<siraben>porting the entire hex0 chain to macOS
<siraben>stabbles: nice I'm seeing https://github.com/haampie/shpack for the first time
<siraben>very cool!
<siraben> https://github.com/oriansj/mescc-tools/pull/53 this PR should be reviewed as well, whoever is around
<matrix_bridge><Jeremiah Orians> siraben: if no output file is specified, then the correct output is stdout
<siraben>Jeremiah Orians: fixed and forcepushsed
<siraben> https://github.com/oriansj/M2libc/pull/125
<siraben>new pr
<siraben>running some tests
<mihi>siraben, re that PR: That was how I originally implemented I/O buffering in M2-Planet's libc (this predates M2libc) in https://github.com/oriansj/M2-Planet/pull/9
<mihi>oriansj preferred to read the file fully instead, see https://logs.guix.gnu.org/bootstrappable/2020-12-22.log#035445
<mihi>(I just noticed that you participated in the discussion as well :D)
<mihi>But I have to agree, since M2libc is a lot less messy nowadays, your commit looks a lot cleaner in the diff :D
<matrix_bridge><Jeremiah Orians> Well if you read the whole file at once and never do lseeks for writing; then the kernel implementation can be simpler.
<superstar64>siraben, Hello, I that you working on bootstrapping via simple Haskell. Well, I happen to making a Haskell compiler(https://github.com/Superstar64/Hazy) and I'd figure I'd throw Hazy at HCC just for fun.
<superstar64>Unfortunately, I don't support Haskell's FFI because I'm compiling to Javascript. `Hcc/HccSystem.hs:23:1 error: expected end of file but found "foreign"`
<siraben>superstar64: I think you should be able to do without the FFI, it's there to make input/output buffered and more efficient
<siraben>man I shouldn't have used ix.io as my paste service back then, now all the pastes in that log are gone lol
<superstar64>I should say that even if it didn't use the FFI. I still have placeholders (I.E. no implementation yet) for actually doing the IO, but that something I'm going to fix soon.
<siraben>I see. My Haskell implementation is pretty much just patched https://github.com/blynn/compiler , which you should check out too
<superstar64>Yes, I've heard of blynn's compiler. It's very neat.
<superstar64>I should ask, what exactly does Blynn's precisely dialect support? I'm not aware of any documentation for it.
<siraben>superstar64: i don't have an exact list, but it's mostly just standard GHC features
<superstar64>Like, does it support type classes? deriving? infix operators?
<siraben>infix, type classes, some deriving i tihnk
<siraben>if you look at hcc that should give you a sense of wwhat precisely supports
<superstar64>Okay, so I managed to get Hazy to type check all of HCC and I can generate a blob of Javascript from it, but it doesn't work. I didn't implement the functions that I moved to Hazy's FFI and my runtime still has placeholders that Hcc will probably run into anyway.
<superstar64>Still pretty neat I guess.