***jonsger1 is now known as jonsger
<daviid>sneek: later tell tohoyn it is invoked in (g-golf hl-api function) gi-import-function <daviid> sneek: later tell tohoyn not exactly 'invoked' but used to substitute the GI function ... look at %i-func and %o-func ... again, for info ... you should write your own mechanism, knowing that these overridden funcs are being overridden becaus they expect a g-value and *-get-* should ignore that arg, *-set-* should receive the value to be set to, not a g-value ... <daviid>sneek: later tell tohoyn you should write your own mechanism and _not_ depend on g-golf's internals, especially not the overriding mechanism I should say, because chances that I'll need to improve or change it are rlatively high ... <anadon>xelxebar: Just because I'm new and trying to figure stuff out :P <anadon>How do I achieve the effect of `(hash-ref initial_state "heads")` when using `(hash-ref initial_state (heads))` when `heads` is defined as the string "heads"? ***wxie1 is now known as wxie
<sneek>tohoyn, you have 3 messages! <sneek>tohoyn, daviid says: it is invoked in (g-golf hl-api function) gi-import-function <sneek>tohoyn, daviid says: not exactly 'invoked' but used to substitute the GI function ... look at %i-func and %o-func ... again, for info ... you should write your own mechanism, knowing that these overridden funcs are being overridden becaus they expect a g-value and *-get-* should ignore that arg, *-set-* should receive the value to be set to, not a g-value ... <sneek>tohoyn, daviid says: you should write your own mechanism and _not_ depend on g-golf's internals, especially not the overriding mechanism I should say, because chances that I'll need to improve or change it are rlatively high ... ***apteryx is now known as Guest53265
***apteryx_ is now known as apteryx
***matijja``` is now known as matijja
<d4ryus>hi, is (resolve-module '(fibers) #f #f #:ensure #f) a good way to test if a module has been loaded? <leoprikler>d4ryus: code like that is used in Guix with the comment "this hack allows us to [...]", so I'd guess yes <ArneBab>wingo: this could be interesting to your fibers experiment: http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html — especially "a virtual thread can be pinned in two situations: when there is a native frame on the stack — when Java code calls into native code (JNI) that then calls back into Java — and when inside a synchronized block or method. In those cases, blocking the virtual thread will block the physical thread that carries <ArneBab>this loses all the unsafe operations in racket and some performance <ArneBab>racket: time racket nbody/nbody.racket-2.racket 100000 # real 0m0,190s <ArneBab>guile: time guile time guile nbody/nbody.guile.guile 100000 # real 0m5,243s <ArneBab>^ this could be a good candidate for a game of golfing down the runtime <wingo>you will get better perf if you use an f64vector as the backing store and compile with -O3 <wingo>you pass it to "guild compile" <ArneBab>I don’t see a difference with an f64vector <wingo>should also switch to normal * - and so on <ArneBab>O3: down to 377ms; only factor 2 to racket <ArneBab>guild compile -O3 nbody/nbody.guile.guile ; time guile nbody/nbody.guile.guile 100000; time guile --fresh-auto-compile nbody/nbody.guile.guile 100000 <ArneBab>wingo: that was already a factor 10! <ArneBab>O2 is similarly fast — I thought O2 would be default … <ArneBab>so with minimal optimization and without unsafe math, Guile is half as fast as the optimized racket program (in this case). <ArneBab>current version would be 2 minutes on that page. <ArneBab>with 50000000 as setting racket gets better — it’s now 14s racket vs. 83s guile <ArneBab>guild compile -O3 nbody/nbody.guile.guile ; time guile nbody/nbody.guile.guile 50000000; time racket nbody/nbody.racket-2.racket 50000000 <ArneBab>50000000 is the setting recommended on the benchmarksgame page <wingo>yes those need replacing with = and + and so on <roelj>I'd like to cite/refer to Guile. Is there a preferred way to do this (and perhaps a BibTeX entry? :D) <ArneBab>roelj: in my bibtex I only have the guile reference manual <ArneBab>are these still exact when replaced? (result must not change) <ArneBab>result did not change, speed went up by factor 4 <ArneBab>"we made the code simpler and now it is 10x as fast" <roelj>ArneBab: What did you use as "authors <leoprikler>I personally have " author = {Galassi, Mark and Blandy, Jim and Jerram, Neil and Vollmer, Marius and Grabm\"{u}eller, Martin and Court\`{e}s, Ludovic and Wingo, Andy},", but that renders as Galassi et al. which may or may not be accurate <lloda>That's what always happens with multiple authors <leoprikler>I think, there's a setting for that, but 7 is more than 3. <wingo>ArneBab: you could replace the map with a for-each also; perhaps that is a transformation guile should make, dunno <wingo>i.e. if a map result is unused, don't cons <wingo>or replace with a loop up to N instead of iota <roelj>ArneBab: I'm using publisher={The Guile Developers} now, but I wonder whether this can be improved. :) <lloda>that code looks translated from something else <ArneBab>lloda: it’s taken from racket which likely took it from the java reference version as advised on the benchmarksgame page. <ArneBab>--fresh-auto-compile takes 4 minutes, O2 takes 24 seconds. <ArneBab>switching to named let loop got down to 22s ***janneke_ is now known as janneke
<leoprikler>and instead of your vector loop, do vector-map! of vector-for-each <ArneBab>leoprikler: I don’t see an effect of the tail recursion <ArneBab>(but I don’t want to deviate too far from the racket, if it does not yield performance gains) <leoprikler>Well, my idea was that you could call (advance N) instead of looping advance calls <ArneBab>I tried that, but yes, did not make a difference. Named let is fast :-) <wingo>i don't know why fresh-auto-compile would take longer than O2 <wingo>unless compilation takes a while, but that's a small program <wingo>afaiu fresh-auto-compile uses O2 <lloda>i wish I could chain maps and get the same perf <d4ryus>Is redefinition guaranteed to work? e.g. when i redefine a function foo via (set! foo (lambda ...)), is it guaranteed to be picked up in all places on the next call of foo? <lloda>question isn't clear to me d4ryus <lloda>what are all places? the next call is just one place <lloda>but Scheme variables are just names for values, they aren't places where you keep values <lloda>so anywhere you grabbed foo's value won't see that foo now names something else <lloda>or that's how I see it at least <wingo>i think that's not quite right tho <d4ryus>lloda: sorry. i meant if module x exports foo which is used by module y. if i load x and y and then redefine foo from module x. Will module y then use the new value of foo? <wingo>d4ryus: module y will use the new value of foo <d4ryus>well, i know it does. but is it guaranteed? <d4ryus>wingo: Ahh, interesting. that is exactly the information i was looking for :) <lloda>well I was waiting for wingo's correction ;-) <heisenberg-25>Why is (get-bytevector-n (response-body-port res #:keep-alive? #f) len) giving an "Throw to key `bad-response' with args `("EOF while reading response body: ~a bytes of ~a" (0 237))'." while reading from a response object res, with content-length len using guile web module? <ArneBab>wingo: I don’t know either why --fresh-auto-compile is slower — should I file a bug report? <ArneBab>wingo: this is really easy to reproduce <wingo>if you could look into it that would be great <wingo>use guile from master tho if you can <ArneBab>I have the strange effect that the time does not match any optimization level. It is faster than O1 but slower than O2 <ArneBab>wingo: is it possible that switching from interpreter to compiled does not work as it should? <ArneBab>Here’s complete reproduction in one shell command: wget -O nbody.guile https://paste.debian.net/download/1151386; time guile nbody.guile 500000; time guild compile -O2 nbody.guile ; time guile nbody.guile 500000; time guile --fresh-auto-compile nbody.guile 500000; time guile nbody.guile 500000 <ArneBab>calling guild compile gives a massive speedup that is lost when forcing a recompile from guile <ArneBab>but if you switch from -O2 to -O1, the explicitly compiled code is slower than when using auto-compile <ArneBab>All these are toplevel forms and the code to run is a let at toplevel. Could that be the issue? <ArneBab>defining a toplevel procedure and running that explicitly does not change this. <leoprikler>I think using "time" to time the algorithm is perhaps the wrong approach <leoprikler>If you do fresh-auto-compile, you get the compilation overhead once and normal performance otherwise <leoprikler>or no, fresh-auto-compile always recompiles, my bad <leoprikler>but still you have compilation + execution vs. just compilation vs. just execution <ArneBab>leoprikler: the second call uses the code created by fresh-auto-compile, and it is also slower <ArneBab>so the command-line above tests all three cases: not compiled (real auto-compile), explicit guild compile, fresh-auto-compile, using the fresh-auto-compile <ArneBab>only the call after explicit guild compile is fast <leoprikler>okay, I looked it up and %auto-compilation-options only sets up warnings, but no optimizations <leoprikler>so in theory it should be as good as guild compile -W... <ArneBab>I’m trying to create a minimal working example, but my examples don’t reproduce the problem … <leoprikler>can you try "guild compile -O2" vs "guild compile" <manumanumanu>ArneBab: could you post the code? Next week I am up for som micro-optimizations :D <manumanumanu>it just checks that the args are fixnums and that the results are fixnumns <ArneBab>manumanumanu: that might no lonegr be needed, yes