IRC channel logs
2022-02-13.log
back to list of logs
<stis>that was tricky, to get a assembler macro working <stis>Now at 60 Millon operations per second!! 20M operations per second for guile that's 35-40X performance increase with pausable continuations <stis>python takes 0.5s and I am at 0.3s <stis>usual delimited continuation version takes more than 7s <ArneBab>is what you’re doing a fast-path in Python? <stis>general speed no fast path. I found that the overhead using delimited continuation is abit underwhlming (15X) <stis>actually python-on-guiles generators has really really poor performance <stis>So there the speed up might be better <lilyp>is that because python-on-guile generators could technically mutate state or what's the problem? <stis>delimited continuations store and resore the stack, I avoid this step iwith the pausing continuations <stis>so what we do is store the address and some registers and jump <stis>also there are some cruft of fluids and other stuff that causes lost cpu cyckiles <stis>I got this to work with the jit engine as well that is a nice little hack <lilyp>do fluids still work correctly after your patch? <stis>currently just a proof of concept, not sure how to handle fluids, maybe we need to unwind and wind the dynamic winds and then it will work <stis>This is actuallyy a quite complex patch <stis>I got it tobe safe towards memory amd handles growing stacks, but ordinary continuations does not work yet, fluids, exceptions needs work as well as stack schrinkage and stack traces <abcdw>Hi guile, we have unquote for lists `(,symbol-value-will-be-here) Is there something similar for vector? Something like #(,symbol-val-instead-of-symbol-itself-here) <pinoaffe>as in (let ((four 4)) `#(1 2 3 ,four 5)) is equal to #(1 2 3 4 5) <lilyp>abcdw: I think that's just a feature of quasiquote <lilyp>i.e. the vector syntax is still the same, but it gets expanded to (quasiquote (vector 1 2 3 (unquote four) 5)) <lilyp>which is then turned into (vector 1 2 3 4 5) <pinoaffe>lilyp: yeah afaik it's just the quasiquote syntax, though i guess it only works because '#(1 2 3 4 5) is equal to #(1 2 3 4 5) <pinoaffe>though I agree with abcdw that documenting these types of things might be useful <abcdw>Yep, I was looking for it in manual/ddg/google/so a few times during the last year and only now decided to ask in a chat. Would be really nice to have it in a section with vectors read syntax or vector creation. <abcdw>Actually, this is one feature (absence of my knowledge about it) that originally stopped me from using vectors for some usecases, where they fits well. <pinoaffe>abcdw: oh and you could also write (vector 1 2 3 four 5) <dsmith>Note that there is a difference btween #() and (vector). <dsmith>scheme@(guile-user)> (eq? #(1 2 3) #(1 2 3)) <dsmith>scheme@(guile-user)> (eq? (vector 1 2 3) (vector 1 2 3)) <abcdw>pinoaffe: yep, I'm aware of (vector ...) from manual, but it doesn't work well for my usecase) but thank you for mentioning it, and big thank you for the `#() one more time! :) <dsmith>#() forms are constant. And so are not mutable. <abcdw>dsmith: Thank you for the notes, will keep it in mind. It's the same for '() vs (list) <jpoiret>wow, didn't know about the '() (list) distinction <pinoaffe>dsmith: oh wow, I didn't know that the reader syntax generates constant/immutable vectors <abcdw>jpoiret: I didn't know it either before message from dsmith, maybe I'll take a deeper look at implementation of reader macros one day. *mwette not having success with applying my load-lang patch to 3.0.8 tarball so starting with a git-repo based local branch (wip-load-lang). Hope it goes better. <mwette>anyone have ref to the patch for test-out-of-memory failure? <mwette>I think I have load-lang ported to 3.0.8, though needs review. I will post soon.