IRC channel logs
2024-10-16.log
back to list of logs
<dthompson>cpli: a scheme(ish) -> wgsl compiler is something that's on my todo list so... interesting! <sneek>Welcome back dthompson, you have 1 message! <sneek>dthompson, ArneBab says: sadly I don’t know enough about lightening to review patches to it. <dthompson>generally speaking, a procedure (or lower level bytecode object) may have a pointer to a source location, but the source will not be attached <dthompson>I'm unsure of the utility, anyhow, as the things that a shader can do are greatly limited compared to what scheme can do <ArneBab>Is it intentional that '(1 2 3) is immutable, but `(1 2 ,3)) is not? ⇒ (list-set! `(1 2 3) 1 'a) => ERROR, but (list-set! `(1 2 ,3) 1 'a) => success. <dpk>see the report specification for quasiquote <old>I'm actually suprise that this allocates anything and the compiler does optimize it to a literal <dthompson>`(1 2 ,3) is shorthand for (list 1 2 3) which is not a literal <dpk>i wasn’t aware that Guile enforces the immutability of literals. in what circumstances? <dpk>it doesn’t appear to at the REPL <mwette>The right test would be to see if `(,1 2 3) is immutable; at the repl ,optimize `(,1 2 3) gives (cons 1 '(2 3)) <mwette>optimize `(1 2 ,3) gives (list 1 2 3) <ArneBab>I’ve been bothered by the abysmal ctak performance of Guile for years. I just found out the reason: the initial heap size of Guile is so small that it spends almost all time in GC. Just pushing the initial heap size from 1MiB to 8MiB reduces the runtime from 27s to 12s (when forced to a single core with taskset -c 5). <ArneBab>When not constraining the cores, the real time doesn’t change much, but the user time with Initial HEAP 1MiB is 1m49s and with initial HEAP 8MiB it is 23s. <ArneBab>Are we sure that 1MiB initial heap is still the right size for todays typical workload? <ArneBab>dthompson: guile would be allowed to turn this into a literal by r7rs; do we specify that we don’t or is that an implementation detail? <ArneBab>The current 1MiB limit will already exhaust L2 caches (especially when core-specific), but L3 caches are 3MiB to 20MiB these days, so going to 4MiB should reduce pressure on the gc for short-running processes. <shawnw>String and vector literals are also immutable. <ArneBab>(I know that just going by a microbenchmark is questionable: it needs to be checked with real applications, i.e. guix and lilypond) <ane>I wonder how hard would it be to create something like edebug in Emacs for Guile using Geiser... not impossible I guess, macroexpand and put #break everywhere <ArneBab>I do not see a difference for guix, not even with hyperfine; I wonder whether my impure environment variables even reached inside guix ☺ <ane>no wait, #break doesn't exist in guile, that was in clojure and cider <ArneBab>To test: guix shell hyperfine -- hyperfine -i "guix search grep" "GC_INITIAL_HEAP_SIZE=8000000 guix search grep" <ArneBab>dthompson: do you have a practical performance critical project that we could benchmark? <mwette>ArneBab: I tried a big compile-ffi run. What takes 6:22 w/ default heap takes 5:50 w/ 8 MB heap (and also w/ 32 MB heap). <ArneBab>mwette: can you try that with hyperfine to get the uncertainty of the values? <ArneBab>With 1GiB memory that would be 16 MiB. <ArneBab>(but Java is known as being memory hungry and not good for commandline tools) <dthompson>ArneBab: are you sure that's correct re: r7rs turning `(1 2 ,3) into a literal? do you know the section in the spec? <ArneBab>dthompson: yes, r7rs explicitly allows either literal or object: A quasiquote expression may return either newly allocated, mutable objects or literal structure for any structure that is constructed at run time during the evaluation of the expression. <dthompson>regarding initial heap sizes: wingo is doing lots of analysis over this sort of thing for whippet so I expect he'll have a strong opinion about whether or not the initial heap size should be changed <dthompson>ArneBab: ah okay, yeah I guess there's an option. idk what previous standards specify here because guile has to be compatible with them, too <ArneBab>dthompson: my point is: whatever Guile is doing is correct, but I cannot count on that staying the same. <dthompson>idk maybe I missed something earlier, I'm not sure what you're getting at <ArneBab>dthompson: that means if I want my code to be compatible, I should treat quasiquoted structures as immutable. Except if we clearly state that quasiquoted will stay mutable. <ArneBab>(I still remember how much of my code broke when Guile started enforcing immutability for quoted lists) <dthompson>this begs the question of why you'd mutate a list in the first place :) <dthompson>but yeah, since quasiquote doesn't guarantee you a mutable list then I wouldn't use it if you need mutability <ArneBab>Sometimes mutation of a list is the best representation of a task. <dthompson>I struggle to think of a time where mutable pairs were what I needed vs. a vector, hash table, struct, etc. <ArneBab>The list is usually much easier to build and has the nicest source-level representation. <ArneBab>⇒ (cons 1 '()) vs. make-something <param1> <param2> ... <ArneBab>And you can always fold over a list. <mwette>ArneBab: get nyacc (latest is in dev-2.01 branch); cd examples; . env.sh ; time guild compile-ffi ffi/gtk2.ffi <ArneBab>mwette: do I do something else to make it recognize /home/arne/.guix-profile/include/linux/stddef.h <mwette>you can update ffi file: #:inc-dirs '("/home/.../include/linux") <mwette>it uses pkg-config cflags and gcc builtin inc's by default <ArneBab>mwette: I don’t get that working right now … do you have a chance to try it with hyperfine? <ArneBab>hyperfine "guild compile-ffi ffi/gtk2.ffi" "GC_INITIAL_HEAP_SIZE=8000000 guild compile-ffi ffi/gtk2.ffi" <mwette>OK. So, guix does not grok pkg-config. What's the replacement?