<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) <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>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>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. <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 <ArneBab_>b4283: then just the thread switching overhead will kill it <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>i just checked and guile does have it, so maybe the "platform-dependent types" section should mention it... <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 <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. *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>some of the procedures in there are going to be useful for the dhcp client, i guess <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! <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