IRC channel logs


back to list of logs

<paroneayea>I am suddenly in want of a database
<paroneayea>I guess I should look at guile-dbi
<nalaginrut>mark_weaver: what's the best way to parse a bytevector? there's a boundary in string, but if I use bytevector->string, there must be an allocation. Can I parse bytevector directly?
<nalaginrut>maybe I should convert boundary to bytevector and use fast string searching in integers (unicode of the char)
<nalaginrut>well, maybe yes, it's similar to C...
<dsmith-work>Wednesday Greetings, Guilers
<paroneayea>hi everyone
<b4283>i'm bumping into a problem where using futures actually made my program a lot slower than the single-threaded version
<b4283>is this usual or i'm using wrong ?
<b4283>i know context switch could take some resources but it's like 100 times slower
<ijp>we couldn't say without more information
<ArneBab_>b4283: how big are the functions you run in futuresp
<b4283>it's a recursive function
<b4283>so i'd say pretty big
<b4283>i put the permutation of a list into a future, cons the future on to a "future list", and then (map touch futures)
<b4283>would you like to see the source code ?
<b4283>hmm, i discovered some interesting results
<b4283>maybe there were too many threads fighting for resources
<taylanub>probably. seems I can reproduce:
<taylanub>b4283: you might want to use `par-map', though IIRC there was recently a bug in it...
<please_help>b4283 if you have too many threads, context switching will slow down your program dramatically
<taylanub>actually, shouldn't futures be smart and only start as many threads as the machine has cores? in the ideal case at least...
<b4283>please_help: i'm reading the manual and it says guile implements it with a thread pool so that shouldn't happen, or am i thinking wrong ?
<please_help>I don't know how it's implemented in guile, the chicken implementation I saw uses 1 thread per future instead of a thread pool.
<please_help>you're right, b4283
<b4283>taylanub: the manual has stated that "Guile’s futures are implemented on top of POSIX threads (*note Threads::). Internally, a fixed-size pool of threads is used to evaluate futures, such that offloading the evaluation of an expression to another thread doesn’t incur thread creation costs."
<b4283>i'm imagining what happened is that (touch) initiates the thread forcefully
<b4283>if the future has been waiting
<b4283>and mapping over it is like opening a can of worms
<ArneBab_>b4283: so you create a future in the function with the value of the recursive call?
<ijp>that seems like a bad idea
<b4283>100 millions calls
<ArneBab_>b4283: then just the thread switching overhead will kill it
<ArneBab_>s/will/does/ ☺
<ArneBab_>(that’s likely what you see)
<ArneBab_>these are real threads, and thread switching has some constant time per switch
<ArneBab_>b4283: I’ll try to estimate the overhead
<civodul>ArneBab_: by default there's one thread per core, so no switching for a compute-bound application
<b4283>ArneBab_: using futures only on the first level of recursion actually helped !
<ArneBab_>civodul: if the result from one thread has to be passed to the next I’d think that it will hurt
<b4283>about 25% execution time improvement
***karswell` is now known as karswell
<ajnirp>shouldn't in the guile manual mention unsigned-short?
<ajnirp>i just checked and guile does have it, so maybe the "platform-dependent types" section should mention it...
<zacts>hi guilers
<dsmith-work>df -h
<ajnirp>civodul: is it ok to assume that the dhcp client will be running on a system with getifaddrs() present?
<ajnirp>apparently it's not in POSIX but instead it's part of GNU/Linux
<dsmith-work>ajnirp: I would think the two would be completely unrelated
<dsmith-work>dhcp client and getifaddrs()
<dsmith-work>ajnirp: Sorry, I read that the other way around.
<ajnirp>agreed, the client doesn't need getifaddrs() per se. but getifaddrs() abstracts away a lot of the work in finding out the network interfaces on a system... which is needed by the dhcp module, which is needed by the client
<ajnirp>so i was wondering if i really needed to do it the POSIX way or if i could just take advantage of getifaddrs() (i have some working FFI code)
<dsmith-work>ajnirp: I somehow read that getifaddrs() would only be available when running a dhcp client. oops.
<ajnirp>ah ok
*dsmith-work shuts up and goes back to work
<ajnirp>if the client is to run only on GuixSD i don't think there should be a problem, since GuixSD uses GNU/Linux-libre
*ajnirp dreads the thought of writing low-level socket code
<civodul>ajnirp: that should be achieval using the FFI
<civodul>fun stuff! :-)
<civodul>or maybe /proc
<civodul>some of the procedures in there are going to be useful for the dhcp client, i guess
<davexunit>civodul: very cool stuff
<edw>If I eval `(procedure-documentation foo)' on a procedure I defined via `SCM_DEFINE', I don't get the docstring (while the procedure itself is defined). Anyone have any thoughts?
<ajnirp>civodul: this looks very useful, thanks!
<paroneayea>hey hey :D
<paroneayea>activitystreams guile library is coming along
<dsmith-work>sneek: later tell edw You need to run the C doc snarfer, however that's not installed. I think you can look at guile-cairo for an example of how to do it
<sneek>Will do.