IRC channel logs
2025-11-22.log
back to list of logs
<ArneBab>ecraven: this is close to the benchmarksgame graphs, though the script to create that relies on quite a bit of duct-tape (the statistics should be solid, though) <ArneBab>The PR contains an output graph created from your all.csv results file :-) <ArneBab>one interesting result is that Chez is still awesomly fast, Loko,Larcreny, and MIT have very unpredictable performance, and Guile is just on its way of following Larceny off the Cyclone/Bones/Chicken plateau. I’m still surprised that Kawa is so far away, even though it builds on the JVM. <ArneBab>(aside: that the uncertainty goes below 1 is an artefact of merging the std higher and lower than the geometric mean) <old>why Chez so fast wtf <old>Faster than Gambit that compiled down to C <identity>C compilers may be good at optimizing, but they are generally good at optimizing hand-written C and not Scheme-compiled-to-C <old>I guess it would be possible for Guile to get to that at some point <old>wonder if Chez has some limitation due to this compiler <old>I think my interogation is more on why Chez has such good optimization and other Scheme have not <identity>mostly because others are usually interpreters/bytecode VMs/compile-to-C, and do not have Cisco backing them <old>Chez is almost x4 faster than Guile and almost x2 faster than Stalin <old>I dont see Clang bein x2 slower than GCC <old>Oh so there is a private compagny putting money into Chez? <identity>yeah, Cisco bought Cadence Research Systems, the developer of Chez, in 2011 and open-sourced Chez in 2016 <dsmith>I suspect Chez was performant before Cisco got involved <mwette>Is the GC disabled during these tests? <old>So the gap between the two is a matter of resources <old>Also these are standard-benchmarks I suppose, so I would take this is a grain of salt <dsmith>Is it Chez that has cons pairs immutable? <identity>dsmith: would be interested in seeing benchmarks of Chez in 2010 <identity>dsmith: they are quasi-immutable in R6RS unless you import (rnrs mutable-pairs (6)), i guess, but not otherwise. Racket has proper immutable pairs <dsmith>AH, racket is what I was thinking of <old>is Chez compiling to native directly? <identity>yeah, Chez has a native AoT compiler, but Petite Chez is an interpreter <old>hm still wonder why something like GambitC is twice slower <dsmith>"The Development of Chez Scheme" But I can't find a copy any more <old>I get that it may be not optimital to translate high-level language to C so the resulting code is perhaps not optimal <dsmith>Something about the only optimiztions that went in had to make compile times faster (or no slower). <identity>dsmith: it seems that Chez has improved since late 2000s, but i am not sure whether that more strongly correlates with Cisco funding or just having ~18 more years to work on the compiler <rlb>...If you need to respect the C ABI (say across compilation units), that introduces a notable limitation, because that ABI is incompatible with optimizing recursion (TCO, etc.). iirc stalin gets around that by just insisting on "whole world optimization" (i.e. seeing all the code at once), and compiles it to more or less one giant main() with a huge switch/labele-goto/whatever in it representing the program. I think you can see that if <rlb>you compile a hello world and ask it to show you the C. <rlb>I think perhaps the pascal calling convention/abi -stdcall(?) avoids at least that issue, but is of course incompatible with "anything else". <ArneBab>mwette: GC is not disabled, as far as I know. <ArneBab>I just got feedback on Mastodon, that the reason that C is so fast in the benchmarksgame is that it’s (at least for some tasks) just thin wrappers around SIMD instructions. <ArneBab>identity: It looks to me like chez got faster, because 2007 Larceny was twice as fast in ack, but 2025 chez is 3x as fast as Larceny. Since Larceny didn’t seem to have seen that many changes since 2009 (this is just my uninformed impression from the website, though 2010 it was version 0.97 and 2017 it was 0.99 and now it is 1.3¹), it may be a good anchor. ¹ https://larcenists.org/benchmarks.html <ArneBab>The SIMD in C makes me wonder whether that’s also the reason why Rust is so fast there. <rlb>...iirc rust might have a better claim there, depending on what the programs are doing, because I think it might have language-level/standard simd support, where C doesn't (just per-compiler bits, or inline asm). <ArneBab>I found a tutorial about "learn SIMD in Rust": https://mcyoung.xyz/2023/11/27/simd-base64/ -- but that code looks a lot like C with added overhead and back-and-forth casting of variables. That said: the factor 2 speedup in the example is something I’d love to be able to do in Guile …. <mwette>rlb: C implementations have `#praga omp parallel' <rlb>i.e. still percolating I guess. <humm>there is no standard, is there? <mwette>You meant targeted to core. I thought there was something for that. <mwette>v4 of OpenMP supports SIMD from reading wikipedia page <ArneBab>I only remember OpenMP from when I worked with Fortran in 2012-2017. <identity>rlb: last time i was around Rust circles, simd was a thing you would do manually with intrinsics, and i do not think that the situation has changed significantly. Rust /is/ a more restricted language, though, which opens up opportunities for optimisations that would be risky otherwise <mwette>I believe gcc is supposed to have built-in support for risc-v vector ops. C code from demo I ran a while ago: vfloat64m1_t vec_a = __riscv_vle64_v_f64m1(ptr_a, vl); <rlb>yeah, though then you're benchmarking *gcc*, not C :) <rlb>Interesting question wrt say C vs rust vs ..., etc. <rlb>Say your whole benchmark submission is one bit inline asm block... <rlb>Guile could do that too. <rlb>Yes, if you're also allows to have a C compiler handy. <humm>I guess you could have a Guile program that writes a code blob to an mmapped executable page and jumps there <rlb>Wondered about that too. <rlb>(Offhand, I'd say that benchmarking-wise, perhaps inline asm should be disallowed, or a separate category.) <old>that must slow as hell to compile a huge C file <old>If Chez has its own ABI, it must loose in performance when communicating with the C world just like other runtime, e.g. Rust <ArneBab>I wonder whether there could be an ice-9 module that allowed to jit-compiled code with Guile, write that to a standard executable page and then access it via FFI. Kind of like programming a specialized tool that you’ll then use in a hot loop. <rlb>I'd imagine so -- I'm not sure, but I think jank (clojure variant) may be doing something similar via llvm lib, though I think it does full aot too.