IRC channel logs
2026-05-08.log
back to list of logs
<probie>So I tried a naive implementation of GHC's string printing in Guile itself. It works fine if auto-compile is turned off, but if it's left on, it takes a very long time to load my stringifying function <probie>Something about including the expression `(* BASE BASE)` given `(define BASE 1000000000000000000)` causes guile to choke for several minutes (which is strange, since when not compiling guile can stringify that in under a second) <probie>s/GHC's string printing/GHC's printing of large integers/ (without context I realised that what I said might not make any sense) <old>are you with mini-gmp our full gmp ? <probie>old: how to check that? I'm just using whatever `guix shell guile` gives me <old>that's mini-gmp if from Guix I believe <old>how did you implemented the printing algorithm? <old>I thought you modified core guile in C for that <probie>I haven't gotten that far yet. My plan was to first implement it in Guile Scheme so I'd have something I could point to. However, I got blocked on this, and since it never directly tries to stringify anything larger than a machine word, I wasn't expecting an issue, especially just from compilation <old>you say guile can stringify this when not compiling. I assume here you mean you are loading a file that has this expressiion <old>if you are not compiling, Guile does not need to print the result back I suppose <probie>Well, I haven't actually finished it; the code for numbers larger than a single machine word is just a stub. <probie>It works on small numbers (both compiled and not), since it just calls `number->string` right now on those, but when this code is "compiled", it takes several minutes and I actually have no idea why <probie>to clarify, several minutes to compile, not to run <old>that's because the interpreted code does not need to print the result of (* BASE BASE) <old>the compiler has a partial evaluation phase where it will do the computation of (* BASE BASE), but it will also probably need to print it in tree-il <old>and this will use the current code in Guile, in mini-gmp <old>which is the original problem <old>try: guix shell guile guile:debug perf -- perf guile --auto-compile ./test.scm <old>kill the process after a few seconds <old>then: guix shell perf -- perf report <old>you should see the same hot path I had in mini-gmp <probie>but printing `(* BASE BASE)` should not be that expensive, even for `mini-gmp`. It should only involve about 36 division operations, hardly something that should take seconds (let alone minutes) on a slightly less than 128 bit number <probie>a few hundred bits is the area where mini-gmp aims to work at 10% the speed of GMP, but this is less than 0.1% the speed <probie>I'll take a proper look at this over the weekend, but I'm pretty sure there's an actual bug in guile causing this to blow up <old>hmm true I can optimize quickly the result here <old>do you have a full stand alone reproducer file? <mwette>I tried (define base 100...) (define x (* base base)) (display base) and it took 0.1s (using guile 3.0.11). <probie>What I just shared on pastebin should take a few minutes to compile on guile 3.0.9 with mono-gmp. If you want some code, just add something like `(display (integer->string 42))` to the end (which will just call `number->string` without running anything else) <old>any idea where I could find some good benchmark? <mwette>old: ArneBab runs lots of guile benchmarks <rlb>old: I don't know call-with-allocation in detail (#181), but strings will likely have the same problem, particularly wrt intermediate states (i.e. collecting all the parts of a string and then making the final result happens in multiple places, and easily ends up with 2x+ the size temporarily). <rlb>I'd guess the only way we could really get that right is with broader changes, e.g. explicit support for optional allocation limits on the C side too. <rlb>(one way or another) <mwette>rlb: Does your utf-8 update work with (ice-9 regex) for the non-ascii case? <rlb>Well, it passes all the tests (if there are any), but I don't remember (it's been over years) if I've explicitly tested that along the way.