IRC channel logs
2026-05-07.log
back to list of logs
<cow_2001>duno if it's reasonable. just writing a separate matching procedure does the same thing <cow_2001>but you have to write everything yourself for every rule <cow_2001>otherwise the tree descent wouldn't be complete <cow_2001>it has some addition(s?) to the PEGy grammar <rlb>Pushed preliminary rdelim (*read-delimited*, etc.) overhaul to utf8; will probably review/revise it a bit more and add additional tests later. <rlb>I *think* that may have been our last remaining, notable string-set!. <lloda>miss a mode arg to call-with-output-file <JohnCowan>someone should look at the pessimization just reported in r/scheme by <probie>that actually causes guile to segfault on my machine <probie>well, it causes guile 3.0.1 to segfault, and on 3.0.9 I seem to never get the "optimised" path <old>I don't quite see what the problem is here <old>it's slow also in O0 when you execute it <old>and ofc it's slow at O1 and not O0. O1 enable peval with will compute the value ahead for you <old>inlining the result in the resulting code. If the REPL optimization level is 1 or more, than ofc it will be slow <old>I don't see any faster program in O0 here <old>> This could be proven by disassembling, but that's beyond the point <old>no that's exactly what you want to look for if you try to debunk a performance issue <probie>Still, it shouldn't actually take long <old>really? 2^16777216 should be fast to compute? <identity>i mean, it is only 16777215 bigint multiplications, how long could that take? <ekaitz>python doesn't even compute it: ValueError: Exceeds the limit (4300 digits) for integer string conversion; use sys.set_int_max_str_digits() to increase the limit <old>It depends I guess. is it with minigmp or no <ekaitz>that's when you try to print in the repl lol <probie>old: definitely; the bottleneck should be (by far) converting it to a string to display <old>well in pure C I get the answer under .6 second using gmp <old>well it seems to be that's indeed the problem here <probie>identity: it reduces to squaring a value 24 times <old>the problem is that optimize want to print the result on the REPL <old>that's the bottleneck <old>scheme@(guile-user)> ,optimize (define (foo) (let ((x (expt 2 (* 4096 4096)))) (if (> x 3) 1 0))) <old>$1 = (define (foo) 1) <old>scheme@(guile-user)> ,optimize (define (foo) (let ((x (expt 2 (* 4096 4096)))) (if (> x 3) x 0))) <old>#2 0x00007f951e040458 in scm_bigprint () <old>so it's actually very fast to compute. not printing like ekaitz mentionned :-) <probie>So I guess the issue is that guile's number->string is a bit slow. Haskell does the stringification for me in about 0.6 seconds <old>90.34% guile libguile-3.0.so.1.7.1 [.] mpn_div_qr_1_preinv.lto_priv.0 ◆ <old>8.84% guile libguile-3.0.so.1.7.1 [.] mpn_lshift ▒ <old>ah that's mini-gmp for you <rlb>what are those percentages? <old>90% of the spent time is in X <probie>I wonder what GHC is doing that allows it to stringify big numbers so rapidly that Guile and Python don't <rlb>ahh, ok --- I still need to learn more about perf. <old>I can't read haskell <old>I've tried. but I can't. I found bash and even perl more readable <old>happy to review some C PR tho <probie>I'll give it a shot at some point on Friday <old>wonder if it's faster without mini-gmp <rlb>(I saw a bit of the mini-gmp discussion; iirc debian has always used full gmp, but I think I do vaguely recall maybe having to deal with some issues a good while back...) <old>nope it is also slow with full gmp <old>but .. the perf record is very much spread <old>oh actually not really <old>it's much faster with full gmp <old>I guess I profile the wrong thing here <old>so I guess mini-gmp is at fault here <rlb>Alongside string-concatenate-vectors-reverse, I'm also tentatively adding string-concatenate-utf8-vectors-reverse. Both mirror srfi-152 string-concatenate-reverse, but just work on vectors of chars, and bytevectors of utf-8 respectively. They're well suited, for the utf-8 world, to replace previous use of string fragments with mutable char or utf-8 fragments when building a result (e.g. read-string, read-c-string, sxml parsing, <rlb>etc.). Neither have been made public yet.