IRC channel logs
2025-04-17.log
back to list of logs
<mwette>lechner: I used to use a ~-prefix for boxed values, but I don't like that too much. Suggestions are welcome. <dthompson>I took a look at how logcount is implemented today and was a little surprised to see it's not (very) optimized. <dthompson>scm_integer_logcount_i is implemented as a clever loop but it seems like we're missing an opportunity to use the relevant hardware instruction for population count. <dthompson>(unless gcc is somehow optimizing this??? idk I've been surprised before) <dthompson>and there are no bytecode instructions for logcount :( <old>mwette: I use the ~ prefix/suffix for anything lazy related <old>for box, how about #? <mwette>dthompson: lightening has none of those (including the count of leading / trailing zeros) so may be an issue <dthompson>mwette: would be nice to add support at some point. performance of logcount greatly influences performance of data structures like hash array mapped tries. <mwette>agree, l'g would need to detect support at compile. I'm not familiar how that is done. <old>I suspect that the guile version is indeed slower due to memory access that odly is not optimized <old>oh well surprise, the guile version is faster <old>I just did a micro-benchmark <old>Guile version is x 1.14 faster than GCC builtin popcount <old>hmm this is suprising <old>GCC do a call to __popocountdi2 <old>seems like I'm missing the instruction for popcount on x86 <dthompson>ah if there's no popcount instruction available on your cpu that would do it <old>oh sorry that was not true <old>I inverse my division .. so really it's 4 time faster <old>with gcc, it's 1.25 faster <dthompson>I wrote my own emulated version in scheme that mimicks what's in integers.c, but the benefits of unboxed math does not beat the call out to C even though it has to do type checking <dthompson>so logcount needs to join logand and friends and get a ulogcount optimization for the unboxed s64 case <old>I think it would be trivial to add if the builtin is available <old>GCC and clang support it <old>don't know for other C compilers <old>and this will not work with bignum ofc <dthompson>the builtin is orthogonal to the additional instruction <old>If # were not used by the reader one could do: #mybox# <old>but you could do: /mybox/ ? <old>really a shame that [] acts like () <lechner>old / both sides look pretty, especially <boxed> or |boxed| but it's too visual for me <old>lechner: <> is used for types as a convention <old>(define-record-type <my-record> ...) <old>(define-class <my-class> ...) <old>|| is comment I think <old>I always though that || were special <lechner>but i'm not a super graphical person and find the visual stimulus too much. <lechner>i also like boxed$ but that is semantically the opposite of ~ <old>Right. It does help sometime and editor often can add syntax-coloring also to help for that <old>like for me <type> are all green <lechner>old / operandi doesn't do much in terms of color locally compared to leuven. do you have a lot of color in scheme-mode overall? <lechner>beautiful theme, though, especially with the intense setting <old>lechner: not much color but good contrast <old>I don't like having too much color <old>I don't like the contrast of leuven-dark <old>comments are a little too light for me with leuven-light <meaty>(eqv? 0+3/2i (/ 3 0+2i)) => #f ???? order of operations <meaty>(eqv? 0+3/2i (/ 0+3i 2)) => #t <meaty>artefact of being able to start symbols with numbers ig, so 3i alone and therefore 3i/2 are symbols not numbers... but -i is a number <old>meaty: what's seems to be the problem? <old>(/ 3 2i) is indeed -1.5i <old>and 3i/2 is 1.5i. I'm not understanding what is your point? <meaty>nvm, I was reading 3/2i as 3/(2i)