* Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) [not found] ` <87y5d8rclr.fsf@gnu.org> @ 2013-03-28 2:55 ` Nala Ginrut 2013-03-28 5:05 ` Mark H Weaver 0 siblings, 1 reply; 15+ messages in thread From: Nala Ginrut @ 2013-03-28 2:55 UTC (permalink / raw To: Ludovic Courtès, guile-devel; +Cc: 13188-done On Wed, 2013-03-27 at 18:12 +0100, Ludovic Courtès wrote: > Hi, > > Nala Ginrut <nalaginrut@gmail.com> skribis: > > > scheme@(guile-user)> (par-map 1+ (iota 10000)) > > While executing meta-command: > > ERROR: Throw to key `vm-error' with args `(vm-run "VM: Stack > > overflow" ())'. > > Commit 8a177d3 fixes this. I added a paragraph in the documentation > that explains what happens: delimited continuations to the rescue once > again! ;-) > > Comments welcome. > oh~I love delimited continuations! But I'm still puzzled with the performance of par-map: --------------------cut------------------- scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota 10000))) ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) (iota 10000))) ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. --------------------end------------------- So my question is, what's the proper scenario to use par-map? > Ludo’. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) 2013-03-28 2:55 ` Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) Nala Ginrut @ 2013-03-28 5:05 ` Mark H Weaver 2013-03-28 13:44 ` Ludovic Courtès 2013-03-29 2:36 ` Nala Ginrut 0 siblings, 2 replies; 15+ messages in thread From: Mark H Weaver @ 2013-03-28 5:05 UTC (permalink / raw To: Nala Ginrut; +Cc: Ludovic Courtès, 13188-done, guile-devel Nala Ginrut <nalaginrut@gmail.com> writes: > But I'm still puzzled with the performance of par-map: > --------------------cut------------------- > scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota > 10000))) > ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. > scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) > (iota 10000))) > ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. > --------------------end------------------- > > So my question is, what's the proper scenario to use par-map? It only makes sense to use 'par-map' when the procedure is fairly expensive to compute. There is inevitably a lot of overhead in creating and joining the threads. Granted, we should be able to do much better than we're doing now, but it would *never* make sense to use 'par-map' when each computation is as simple as (expt x 5). Regards, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) 2013-03-28 5:05 ` Mark H Weaver @ 2013-03-28 13:44 ` Ludovic Courtès 2013-03-28 18:00 ` Mark H Weaver 2013-03-29 2:36 ` Nala Ginrut 1 sibling, 1 reply; 15+ messages in thread From: Ludovic Courtès @ 2013-03-28 13:44 UTC (permalink / raw To: Mark H Weaver; +Cc: 13188-done, guile-devel Mark H Weaver <mhw@netris.org> skribis: > Nala Ginrut <nalaginrut@gmail.com> writes: > >> But I'm still puzzled with the performance of par-map: >> --------------------cut------------------- >> scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota >> 10000))) >> ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. >> scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) >> (iota 10000))) >> ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. >> --------------------end------------------- >> >> So my question is, what's the proper scenario to use par-map? > > It only makes sense to use 'par-map' when the procedure is fairly > expensive to compute. Indeed. > There is inevitably a lot of overhead in creating and joining the > threads. We use a thread pool, so there’s no such cost. But there are other costs. When delimited continuations are used, we’re on the slow path. Also, Guile’s fat mutexes & co. are terribly inefficient. And finally, there may be contention on the futexes mutex (esp. when the computations is too small.) So yes, there’s room for improvement. Yet, it should be fruitful, provided you use it for reasonably long computations, as Mark outlines. Ludo’. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) 2013-03-28 13:44 ` Ludovic Courtès @ 2013-03-28 18:00 ` Mark H Weaver 2013-03-28 20:07 ` Ludovic Courtès 0 siblings, 1 reply; 15+ messages in thread From: Mark H Weaver @ 2013-03-28 18:00 UTC (permalink / raw To: Ludovic Courtès; +Cc: 13188-done, guile-devel Hi Ludovic, ludo@gnu.org (Ludovic Courtès) writes: > Mark H Weaver <mhw@netris.org> skribis: > >> It only makes sense to use 'par-map' when the procedure is fairly >> expensive to compute. > > Indeed. > >> There is inevitably a lot of overhead in creating and joining the >> threads. > > We use a thread pool, so there’s no such cost. Sorry, I was using the term 'threads' not in the sense of OS-level threads, but in a more general sense. I should have been more clear. What I meant is that from the user's perspective, threads are being created and joined, and even if you build those using a pool of OS-level threads, this inevitably involves thread synchronization, which is very expensive on modern architectures. So I maintain that there _is_ such a cost, and it can't be avoided. The point I was really trying to make here, in the simplest possible terms, is that it will *never* make sense to replace all uses of 'map' with 'par-map' wherever it is safe to do so. > But there are other costs. When delimited continuations are used, we’re > on the slow path. Also, Guile’s fat mutexes & co. are terribly > inefficient. And finally, there may be contention on the futexes mutex > (esp. when the computations is too small.) Indeed, I wouldn't be surprised if we could improve this by an order of magnitude. More items for my TODO list :) > So yes, there’s room for improvement. Yet, it should be fruitful, > provided you use it for reasonably long computations, as Mark outlines. Regards, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) 2013-03-28 18:00 ` Mark H Weaver @ 2013-03-28 20:07 ` Ludovic Courtès 0 siblings, 0 replies; 15+ messages in thread From: Ludovic Courtès @ 2013-03-28 20:07 UTC (permalink / raw To: Mark H Weaver; +Cc: 13188-done, guile-devel Mark H Weaver <mhw@netris.org> skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <mhw@netris.org> skribis: >> >>> It only makes sense to use 'par-map' when the procedure is fairly >>> expensive to compute. >> >> Indeed. >> >>> There is inevitably a lot of overhead in creating and joining the >>> threads. >> >> We use a thread pool, so there’s no such cost. > > Sorry, I was using the term 'threads' not in the sense of OS-level > threads, but in a more general sense. I should have been more clear. > > What I meant is that from the user's perspective, threads are being > created and joined, and even if you build those using a pool of OS-level > threads, this inevitably involves thread synchronization, which is very > expensive on modern architectures. So I maintain that there _is_ such a > cost, and it can't be avoided. Ah yes, OK. > The point I was really trying to make here, in the simplest possible > terms, is that it will *never* make sense to replace all uses of 'map' > with 'par-map' wherever it is safe to do so. Indeed! Ludo’. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) 2013-03-28 5:05 ` Mark H Weaver 2013-03-28 13:44 ` Ludovic Courtès @ 2013-03-29 2:36 ` Nala Ginrut 2013-03-29 5:49 ` Mark H Weaver 2013-03-29 9:52 ` Ludovic Courtès 1 sibling, 2 replies; 15+ messages in thread From: Nala Ginrut @ 2013-03-29 2:36 UTC (permalink / raw To: Mark H Weaver; +Cc: Ludovic Courtès, 13188-done, guile-devel On Thu, 2013-03-28 at 01:05 -0400, Mark H Weaver wrote: > Nala Ginrut <nalaginrut@gmail.com> writes: > > > But I'm still puzzled with the performance of par-map: > > --------------------cut------------------- > > scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota > > 10000))) > > ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. > > scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) > > (iota 10000))) > > ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. > > --------------------end------------------- > > > > So my question is, what's the proper scenario to use par-map? > > It only makes sense to use 'par-map' when the procedure is fairly > expensive to compute. There is inevitably a lot of overhead in creating > and joining the threads. Granted, we should be able to do much better > than we're doing now, but it would *never* make sense to use 'par-map' > when each computation is as simple as (expt x 5). > Well, is there any example? And there're two possible applications: 1. handle the requests in a server 2. read files from disk (but how big file is proper for par-map) Are these ways heavy enough for par-map? Potentially, I inclined to use the lovely delimited-continuation to handle the requests, but seems ludo think this way is slower? Or there's improvement room? > Regards, > Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) 2013-03-29 2:36 ` Nala Ginrut @ 2013-03-29 5:49 ` Mark H Weaver 2013-03-29 6:00 ` Extremely high overhead of 'par-map' Mark H Weaver ` (2 more replies) 2013-03-29 9:52 ` Ludovic Courtès 1 sibling, 3 replies; 15+ messages in thread From: Mark H Weaver @ 2013-03-29 5:49 UTC (permalink / raw To: Nala Ginrut; +Cc: guile-devel Nala Ginrut <nalaginrut@gmail.com> writes: > --------------------cut------------------- > scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota > 10000))) > ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. > scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) > (iota 10000))) > ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. > --------------------end------------------- [...] > Well, is there any example? The timings above suggest that, on your machine, the overhead of 'par-map' is in the neighborhood of 660 microseconds per thread (that's the total run time divided by 10000 iterations). So if the procedure takes significantly longer than that to run, the overhead will not be so bad. For example, if the procedure takes 10 milliseconds to run, then the 'par-map' overhead would be about 6.6% (660/10000). If the procedure takes 100 milliseconds to run, then the overhead would be about 0.6% (660/100000). That's the way I'd suggest to think about it. Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Extremely high overhead of 'par-map' 2013-03-29 5:49 ` Mark H Weaver @ 2013-03-29 6:00 ` Mark H Weaver 2013-03-29 20:24 ` Noah Lavine 2013-03-30 23:37 ` Ludovic Courtès 2013-03-29 16:45 ` Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) Mark H Weaver 2013-04-01 19:10 ` Andy Wingo 2 siblings, 2 replies; 15+ messages in thread From: Mark H Weaver @ 2013-03-29 6:00 UTC (permalink / raw To: guile-devel I wrote: > Nala Ginrut <nalaginrut@gmail.com> writes: >> --------------------cut------------------- >> scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota >> 10000))) >> ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. >> scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) >> (iota 10000))) >> ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. >> --------------------end------------------- > [...] >> Well, is there any example? > > The timings above suggest that, on your machine, the overhead of > 'par-map' is in the neighborhood of 660 microseconds per thread (that's > the total run time divided by 10000 iterations). I must say that 'par-map' has shockingly poor performance. We really ought to try to improve this. Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Extremely high overhead of 'par-map' 2013-03-29 6:00 ` Extremely high overhead of 'par-map' Mark H Weaver @ 2013-03-29 20:24 ` Noah Lavine 2013-03-29 20:27 ` Noah Lavine 2013-03-30 23:37 ` Ludovic Courtès 1 sibling, 1 reply; 15+ messages in thread From: Noah Lavine @ 2013-03-29 20:24 UTC (permalink / raw To: Mark H Weaver; +Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 1098 bytes --] I agree. Do you have any idea what's causing the overhead? I tried to benchmark it, but got a segmentation fault. I think we have plenty of work to do here. :-) Noah On Fri, Mar 29, 2013 at 2:00 AM, Mark H Weaver <mhw@netris.org> wrote: > I wrote: > > > Nala Ginrut <nalaginrut@gmail.com> writes: > >> --------------------cut------------------- > >> scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota > >> 10000))) > >> ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. > >> scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) > >> (iota 10000))) > >> ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. > >> --------------------end------------------- > > [...] > >> Well, is there any example? > > > > The timings above suggest that, on your machine, the overhead of > > 'par-map' is in the neighborhood of 660 microseconds per thread (that's > > the total run time divided by 10000 iterations). > > I must say that 'par-map' has shockingly poor performance. > We really ought to try to improve this. > > Mark > > [-- Attachment #2: Type: text/html, Size: 1703 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Extremely high overhead of 'par-map' 2013-03-29 20:24 ` Noah Lavine @ 2013-03-29 20:27 ` Noah Lavine 2013-03-29 23:18 ` Mark H Weaver 0 siblings, 1 reply; 15+ messages in thread From: Noah Lavine @ 2013-03-29 20:27 UTC (permalink / raw To: Noah Lavine; +Cc: Mark H Weaver, guile-devel [-- Attachment #1: Type: text/plain, Size: 1748 bytes --] Oh, sorry to email twice so soon, but I have an idea for making par-map usable in more cases: add a keyword argument called "block-size". Its value should be a positive integer, and the meaning is to have each thread do block-size iterations. That should make it easier to use par-map for cases like this where the cost of each function is very small. I realize it's not a great solution because you still have to iterate through the list to get to the later elements. A hypothetical "vector-par-map" would solve that. Noah On Fri, Mar 29, 2013 at 4:24 PM, Noah Lavine <noah.b.lavine@gmail.com>wrote: > I agree. Do you have any idea what's causing the overhead? > > I tried to benchmark it, but got a segmentation fault. I think we have > plenty of work to do here. :-) > > Noah > > > On Fri, Mar 29, 2013 at 2:00 AM, Mark H Weaver <mhw@netris.org> wrote: > >> I wrote: >> >> > Nala Ginrut <nalaginrut@gmail.com> writes: >> >> --------------------cut------------------- >> >> scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) >> (iota >> >> 10000))) >> >> ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. >> >> scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) >> >> (iota 10000))) >> >> ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. >> >> --------------------end------------------- >> > [...] >> >> Well, is there any example? >> > >> > The timings above suggest that, on your machine, the overhead of >> > 'par-map' is in the neighborhood of 660 microseconds per thread (that's >> > the total run time divided by 10000 iterations). >> >> I must say that 'par-map' has shockingly poor performance. >> We really ought to try to improve this. >> >> Mark >> >> > [-- Attachment #2: Type: text/html, Size: 2784 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Extremely high overhead of 'par-map' 2013-03-29 20:27 ` Noah Lavine @ 2013-03-29 23:18 ` Mark H Weaver 0 siblings, 0 replies; 15+ messages in thread From: Mark H Weaver @ 2013-03-29 23:18 UTC (permalink / raw To: Noah Lavine; +Cc: guile-devel Hi Noah, Noah Lavine <noah.b.lavine@gmail.com> writes: > Oh, sorry to email twice so soon, but I have an idea for making > par-map usable in more cases: add a keyword argument called > "block-size". Its value should be a positive integer, and the meaning > is to have each thread do block-size iterations. IMO, we should avoid adding anything like this. It would be hard for callers to know what value to pass. I think it should be possible to make 'par-map' act sensibly and efficiently without this kind of help. > I tried to benchmark it, but got a segmentation fault. I think we > have plenty of work to do here. :-) Ouch. Can you please file a bug report with the full details? Regards, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Extremely high overhead of 'par-map' 2013-03-29 6:00 ` Extremely high overhead of 'par-map' Mark H Weaver 2013-03-29 20:24 ` Noah Lavine @ 2013-03-30 23:37 ` Ludovic Courtès 1 sibling, 0 replies; 15+ messages in thread From: Ludovic Courtès @ 2013-03-30 23:37 UTC (permalink / raw To: guile-devel Mark H Weaver <mhw@netris.org> skribis: > I must say that 'par-map' has shockingly poor performance. > We really ought to try to improve this. IMO we must improve futures, not necessarily ‘par-map’ itself, because lists are not a good data structure for parallel processing anyway (“get rid of cons” said Steele ;-)). Ludo’. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) 2013-03-29 5:49 ` Mark H Weaver 2013-03-29 6:00 ` Extremely high overhead of 'par-map' Mark H Weaver @ 2013-03-29 16:45 ` Mark H Weaver 2013-04-01 19:10 ` Andy Wingo 2 siblings, 0 replies; 15+ messages in thread From: Mark H Weaver @ 2013-03-29 16:45 UTC (permalink / raw To: Nala Ginrut; +Cc: guile-devel I wrote: > Nala Ginrut <nalaginrut@gmail.com> writes: >> --------------------cut------------------- >> scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota >> 10000))) >> ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. >> scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) >> (iota 10000))) >> ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. >> --------------------end------------------- > [...] >> Well, is there any example? > > The timings above suggest that, on your machine, the overhead of > 'par-map' is in the neighborhood of 660 microseconds per thread (that's > the total run time divided by 10000 iterations). BTW, I notice that the overhead of 'par-map' is much less for shorter lists. It's about 9 times faster for lists of length 1000, and about 20 times faster for lists of length 100. --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) (iota 10000))) ;; 8.293139s real time, 8.281802s run time. 1.310634s spent in GC. scheme@(guile-user)> ,time (define a (for-each (lambda (k) (par-map (lambda (x) (expt x 5)) (iota 1000))) (iota 10))) ;; 0.908630s real time, 0.916819s run time. 0.070018s spent in GC. scheme@(guile-user)> ,time (define a (for-each (lambda (k) (par-map (lambda (x) (expt x 5)) (iota 100))) (iota 100))) ;; 0.330130s real time, 0.418148s run time. 0.045255s spent in GC. --8<---------------cut here---------------end--------------->8--- Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) 2013-03-29 5:49 ` Mark H Weaver 2013-03-29 6:00 ` Extremely high overhead of 'par-map' Mark H Weaver 2013-03-29 16:45 ` Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) Mark H Weaver @ 2013-04-01 19:10 ` Andy Wingo 2 siblings, 0 replies; 15+ messages in thread From: Andy Wingo @ 2013-04-01 19:10 UTC (permalink / raw To: Mark H Weaver; +Cc: guile-devel On Fri 29 Mar 2013 06:49, Mark H Weaver <mhw@netris.org> writes: >> scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota >> 10000))) >> ;; 0.008019s real time, 0.007979s run time. 0.000000s spent in GC. >> scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5)) >> (iota 10000))) >> ;; 6.596471s real time, 6.579375s run time. 1.513880s spent in GC. > > The timings above suggest that, on your machine, the overhead of > 'par-map' is in the neighborhood of 660 microseconds per thread (that's > the total run time divided by 10000 iterations). Per item, you mean? Anyway this seems like a really high overhead, and we shouldn't make too many excuses for it ;) Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) 2013-03-29 2:36 ` Nala Ginrut 2013-03-29 5:49 ` Mark H Weaver @ 2013-03-29 9:52 ` Ludovic Courtès 1 sibling, 0 replies; 15+ messages in thread From: Ludovic Courtès @ 2013-03-29 9:52 UTC (permalink / raw To: Nala Ginrut; +Cc: Mark H Weaver, 13188-done, guile-devel Nala Ginrut <nalaginrut@gmail.com> skribis: > And there're two possible applications: > 1. handle the requests in a server > 2. read files from disk (but how big file is proper for par-map) Quoting the fine manual: Note that futures are intended for the evaluation of purely functional expressions. Expressions that have side-effects or rely on I/O may require additional care, such as explicit synchronization (*note Mutexes and Condition Variables::). IOW, think twice before you use it for something not purely computational. :-) Ludo’. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-04-01 19:10 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <1355559152.27310.5.camel@Renee-desktop.suse> [not found] ` <87y5d8rclr.fsf@gnu.org> 2013-03-28 2:55 ` Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) Nala Ginrut 2013-03-28 5:05 ` Mark H Weaver 2013-03-28 13:44 ` Ludovic Courtès 2013-03-28 18:00 ` Mark H Weaver 2013-03-28 20:07 ` Ludovic Courtès 2013-03-29 2:36 ` Nala Ginrut 2013-03-29 5:49 ` Mark H Weaver 2013-03-29 6:00 ` Extremely high overhead of 'par-map' Mark H Weaver 2013-03-29 20:24 ` Noah Lavine 2013-03-29 20:27 ` Noah Lavine 2013-03-29 23:18 ` Mark H Weaver 2013-03-30 23:37 ` Ludovic Courtès 2013-03-29 16:45 ` Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) Mark H Weaver 2013-04-01 19:10 ` Andy Wingo 2013-03-29 9:52 ` Ludovic Courtès
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).