IRC channel logs

2013-11-01.log

back to list of logs

<dsmith-work>(srfi-1.go ....)
<dsmith-work>language/tree-il.go
*ijp rakes around the popcorn bag
***fangism is now known as fangism-ghost
<kurohin>newbie question, when a calling a function in guile and I get two results, like $5 = <list that I expected> and $6 = #<vhash ...... 8 pairs> does is it somehow telling me about side effects that has happend, or what is it?
<kurohin>found the page about multiple return values :-)
<dsmith>Hey hey
<dsmith>Well, I've got guile installed. (libgc and guile both pass make check)
<dsmith>unknown_lamer, Now building bobot++
<dsmith>Not happy. I don't remember the fix offhand.
<dsmith>Interp.C:187:3: error: invalid conversion from ‘SCMFunc {aka scm_unused_struct* (*)()}’ to ‘scm_t_subr {aka void*}’ [-fpermissive]
<dsmith>/usr/local/include/guile/2.0/libguile/gsubr.h:68:13: error: initializing argument 5 of ‘scm_unused_struct* scm_c_define_gsubr(const char*, int, int, int, scm_t_subr)’ [-fpermissive]
<cky>What does line 187 of Interp.C look like?
<mark_weaver>dsmith: just cast the procedure pointer to (void *)
<dsmith>Ah
<mark_weaver>well, casting to (scm_t_subr) might be a little nicer
<dsmith>Yeah, I remember doing that now.
<cky>But in C++, you probably have to use reinterpret_cast.
<cky>e.g., reinterpret_cast<scm_t_subr>(func)
<cky>(As a long-time C++ programmer, I've grown to have a strong distaste for C-style casts.)
<dsmith>sneek2, botsnack
<dsmith>sneek, botsnack
<dsmith>sneek, botsnack
<dsmith>sneek, botsnack
<dsmith>sneek, botsnack
<dsmith>sneek, botsnack
*gzg` wonders if guile-wm is any factor of usable.
<dsmith>sneek, botsnack
<sneek>:)
<dsmith>sneek, seen rlb?
<sneek>rlb was here Aug 10 at 01:17 am UTC, saying: mark_weaver: ok, right -- I'll hold off for further discussion, and then we can either change the topic or the approach. Thanks..
<dsmith>yey
<cky>Yay for sneek.
<cky>sneek: later tell davexunit Prefer to use (srfi srfi-41) rather than (ice-9 streams). (Disclaimer: I ported SRFI 41 to Guile, but a number of others strongly encouraged me to complete the work and get it shipped, so this wasn't just my barrow to push.)
<sneek>Got it.
<cky>Since I never seem to be online at the same time as davexunit....
<dsmith>And now the reboot test...
<dsmith>Hmm.
<dsmith>Yey
<mark_weaver>sneek: later tell davexunit I agree with cky: srfi-41 is definitely much nicer than (ice-9 streams).
<sneek>Got it.
<mark_weaver>sneek: botsnack
<sneek>:)
<wingo>moin
<anddam>is there a libtool specific channel or should I look at #gnu / libtool ml?
<wingo>i haven't looked at libtool recently, but it used to be really quiet
<wingo>the libtool mailing list is probably best
<anddam>thanks
<anddam>I just subscribed
<anddam>I don't like much the ml subscribe/confirm mechanism so I try to find a different source of information
<wingo>yeah i know what you mean
<TaylanUB>Where can I find the code that handles a set! form like (set! (@ foo) bar) ?
<mark_weaver>ice-9/psyntax.scm
<TaylanUB>Thanks.
<mark_weaver>np :)
<wingo>woo, i have the rtl compiler doing a topological sort before emitting code
<wingo>results in much nicer block orders
<wingo>a simple count-up loop now does 140M iterations per second in the interpreter
<wingo>some compiler optimizations could double that
<wingo>and at that point we would only be about 10 times slower than optimal
<wingo>assuming about one instruction per cycle throughput on a loop
<wingo>maybe optimal is faster than that though
<wingo>i hear i7's can do 4 IPC at times
<wingo>the interpreter only does around 1M iterations per second on a count-up loop though, alack
<wingo>still, that's more than 3 times as fast as 2.0's evaluator (!)
<wingo>heya civodul
<civodul>Hello Guilers!
<civodul>right in time for the good news :-)
<civodul>wingo: 3 times as fast for a loop?
<wingo>civodul: that's for ,time (primitive-eval '(let lp ((n 0)) (when (< n 1000000) (lp (1+ n)))))
<wingo>so it's really testing the evaluator
<civodul>aah
<civodul>well that's interesting too
<civodul>that means possibly faster Guile compile times
<wingo>well, the compiler itself is bigger and slower
<wingo>but there are many things remaining to do, speed-wise
<wingo>for (lambda () (let lp ((n 0)) (when (< n 1000000000) (lp (1+ n)))))
<wingo>which is 1e9, as an exact integer
<wingo>compiled
<wingo>my branch (wip-rtl-halloween) does it in 9 seconds, and 2.0 does it in 30 seconds
<wingo>that's in a debugging VM, with hooks
<wingo>the 2.0 loop looks like:
<wingo> 0 (assert-nargs-ee/locals 8) ;; 0 args, 1 local
<wingo> 2 (br :L490) ;; -> 33
<wingo> 6 (local-ref 0) ;; `n'
<wingo> 8 (make-uint64 0 0 0 0 59 154 202 0);; 1000000000
<wingo> 17 (lt?)
<wingo> 18 (br-if-not :L491) ;; -> 31
<wingo> 22 (local-ref 0) ;; `n'
<wingo> 24 (add1)
<wingo> 25 (local-set 0) ;; `n'
<wingo> 27 (br :L492) ;; -> 6
<wingo> 31 (void)
<wingo> 32 (return)
<wingo> 33 (make-int8:0) ;; 0
<wingo> 34 (local-set 0)
<wingo> 36 (br :L492) ;; -> 6
<wingo>and RTL is
<wingo> 0 (assert-nargs-ee/locals 1 2) ;; 0 args, 2 locals
<wingo> 1 (make-short-immediate 1 2) ;; 0
<wingo>L1:
<wingo> 2 (make-long-immediate 2 4000000002);; 1000000000
<wingo> 4 (br-if-< 1 2 #t 4) ;; -> L2
<wingo> 6 (add1 1 1)
<wingo> 7 (br -5) ;; -> L1
<wingo>L2:
<wingo> 8 (make-short-immediate 1 2052) ;; #<unspecified>
<wingo> 9 (reset-frame 2)
<wingo> 10 (return-values)
<civodul>much shorter
<wingo>so a much shorter path length, although it's actually more bytes (44 bytes versus 40 bytes)
<civodul>yes, but fewer dispatches
<wingo>yep
<civodul>and as anticipated, that does help :-)
<civodul>the #<unspecified> above looks bogus, no?
<wingo>and if we hoist the constant load, and then rotate the loop around so the branch is at the end, we'd be optimal
<wingo>civodul: it's the return value
<wingo>also the return sequence should be shorter -- just (return 2) instead of doing the reset-frame / return-values thing
<wingo>but that doesn't matter for the loop itself
<civodul>right
<wingo>anyway, everything builds except (language elisp boot); I haven't investigated that
<wingo>and i haven't really run the test suite either
<wingo>and i haven't really looked at optimizing the compiler; I'm sure many things could be algorithmically better
<dsmith-work>Happy Friday, Guilers!!
<wingo>the compiler uses an unfortunate amount of memory right now (max of 100s of MB); I'd like to figure out why and fix
<wingo>heya dsmith-work :)
<wingo>i think using more memory to compile than 2.0 is practically a given, unfortunately, but we should do better than what is there
<civodul>yeah
<wingo>wow, peval inlines "return" in all locations in (language elisp lexer)'s "lex" function
<wingo>even though it's a closure
<wingo>but i think bipt assumed the let expressions would be evaluated in order; tsk tsk
***araujo_ is now known as araujo
***araujo is now known as Guest54701
***Guest54701 is now known as araujo
<civodul>wingo: isn't it a bad idea to inline it every time?
<wingo>depends
<wingo>you can't really know is the thing
<wingo>perhaps inlining it enables specialization and overall code size decreases
<civodul>sure, but it's quite large, and there are like 5 call sites
<civodul>i don't see what could be specialized here
<civodul>there's no conditional in 'return'
<wingo>yeah, dunno
<wingo>hum, indeed it isn't inlined
<wingo>it appears to be contified (!)
<wingo>even though it's a closure
<wingo>could be my algorithm is broken for contifying let-bound functions
<wingo>will know soon, anyway...
<civodul>so there are now both peval and the contification pass that can end up inlining procedures
<civodul>it'll be interesting to see how it plays together in such cases
<wingo>well contification doesn't inline
<wingo>inlining is copying
<wingo>contification never copies
<wingo>inlining can be very beneficial but it can explode on you
<wingo>contification always makes things bette
<wingo>*better
<wingo>unless of course it doesn't do its job right, as in this case I'm investigating :)
<civodul>oh, ok
<civodul>but what if it contifies a procedure that has several call sites?
<civodul>as seems to be the case here
<wingo>indeed, if I had been running the verify-cps thing i would have caught that it was contifying in the wrong scope
<wingo>civodul: they all have to return to the same continuation
<wingo>which is the case in lex -- they are all in tail position
<civodul>ok
<civodul>but that's equivalent to inlining at all these call sites, no?
<wingo>no
<wingo>instead of copying the code into the call sites
<wingo>at each call site instead of calling the function it shuffles the arguments into the appropriate slot then jumps to the body of "return"
<civodul>aah ok, so no copying at all
<wingo>and the body of "return", instead of returning at the end, returns to the common continuation
<wingo>right
<civodul>ok
<wingo>it just hard-wires procedure calls
<civodul>i need to re-read the paper, i suppose ;-)
<civodul>i see
<wingo>"contification using dominators" has a nice clear introduction
<ijp>(display (random-farm-animal-sound))
<anddam>bye
***sneek_ is now known as sneek
***fangism-ghost is now known as fangism
<wingo>woo, fixed the elisp lexer contification
<wingo>just had a fresh bootstrap succeed all the way through
<mark_weaver>that's great news!
<tupi>wouah, fantastic
<ijp>cool
<wingo>it actually contifies closures, i didn't know it would do that
<civodul>:-)
<dsmith-work>Woo
<ZombieChicken>Can guile compile Scheme into a binary?
<ijp>not yet
<civodul>well, .go files are binaries
<civodul>but what they contain is not native code
<ZombieChicken>bytecode?
<civodul>yes
<ZombieChicken>Thanks
<wingo>shockingly it passes most tests
<wingo>even control.test...
<dsmith-work>sneek: benchmarks?
<sneek>Someone once said benchmarks is http://ossau.homelinux.net/~neil/
<wingo>boo, r5rs_pitfall failures
<wingo>i hate that thing ;)
<lloda>although the tests are shallow in many places
<ijp>r5rs_pitfalls? Or just in general?
<wingo>in general
<ijp>I figured, but I had a particular answer for the first
<wingo>you can still give it :)
<ijp>no, now it makes no sense
<ZombieChicken>Is there a way to have guile output the code that has been typed into it into a seperate file?
<fangism>ZombieChicken: like | tee guile.log? :)
<ZombieChicken>fangism: More like if I type, say, (display "Hello, World!") into guile and wanted to save that to a file
<ijp>if you use readline it will put it in a history file
<ZombieChicken>Okay. Thanks
<ZombieChicken>ah
<ZombieChicken>where might said history file be?
<ijp>ah, rotty *isn't* dead
<ijp>ZombieChicken: I forget the name exactly, it'll be somethign like .guile_history
<ZombieChicken>nada
<ijp>ZombieChicken: did you enable readline?
<ijp>if so, how?
<ZombieChicken>$cat .guile
<ZombieChicken>; Load and use readline
<ZombieChicken>(use-modules (ice-9 readline))
<ZombieChicken>(activate-readline)
<ijp>okay, and have you used guile since adding that?
<ZombieChicken>I'm running it right now
<ijp>I don't think it will be created until after you close it
<ZombieChicken>ah, ok
<ZombieChicken>Nope. I just closed it out and there is the file
<ZombieChicken>thanks
<wingo>i wonder what the speed impact will be of going down from two RAs to one
<fangism>btw, wingo, fixing gc seems to have cured the segfaults I was seeing
<wingo>fangism: great
<ijp>RA?
<fangism>(guile-2.0.9, x86_64-darwin11)
<mark_weaver>ijp: return address
<ijp>ah, right
<mark_weaver>as in: going from separate return addresses for multiple-values/one-value to a single one.
<mark_weaver>fangism: that's good!
<mark_weaver>thanks for letting us know
<mark_weaver>I suspect that one RA is the right thing to do in native code, or else multivalued returns will get heavily penalized.
<mark_weaver>but I guess it depends on how much one is willing to penalize multivalued returns in order to microoptimize single-valued returns.
<wingo>yeah, dunno
<wingo>the current thought is one RA -- now that i have a fully rtl system i can remove the old vm and remove the separate ra -- but i have to bang the test suite into shape first...
<mark_weaver>sounds good to me
<mark_weaver>fwiw, when I was fiddling with the assembly bits for fast math in the VM, I tried various tricks to reduce the number of conditional branches, and it only ended up making things slower (for my admittedly simplistic unrolled-loop benchmarks)
<mark_weaver>for example, I tried ANDing together two numeric arguments so that I could check to see if they were both fixnums in a single test. (fixnums are the only SCM values with 1 in the second-to-lowest bit)
<mark_weaver>and that turned out to be slower than the naive test-each-argument approach.
<wingo>funny
<cky>davexunit: Say something so sneek will play your messages. :-)
<davexunit>hey
<sneek>Welcome back davexunit, you have 2 messages.
<sneek>davexunit, cky says: Prefer to use (srfi srfi-41) rather than (ice-9 streams). (Disclaimer: I ported SRFI 41 to Guile, but a number of others strongly encouraged me to complete the work and get it shipped, so this wasn't just my barrow to push.)
<sneek>davexunit, mark_weaver says: I agree with cky: srfi-41 is definitely much nicer than (ice-9 streams).
<davexunit>I'm about to go into a meeting.
<davexunit>cky: thanks.
<ijp>okay, but first just let me say, DIE ICE-9 STREAMS DIE
<cky>:-D
<mark_weaver>ijp++
*dsmith-work contemplates a stream of ice-9
<cky>dsmith-work: Here, have an ice-9 Icee®.
<fangism>also noted bug#15750 is fixed (should be closed)
<mark_weaver>fangism: thanks, I'll close the bug.
<TaylanUB>Am I the only one finding the graphs at http://ossau.homelinux.net/~neil/ somewhat unreadable ? :P
<dsmith>They get denser as commits happen
<civodul>dje42: is there a public repo with your GDB work?