RE: [racket-users] Re: trying to use futures for some calculations
In addition, some time ago I did use futures which did parallelization very well when using distinct parts of the same vector. I did not need unsafe for that. Jos -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5eea45fb.1c69fb81.a8487.089d%40mx.google.com.
RE: [racket-users] Re: trying to use futures for some calculations
It’s long ago, but I worked nicely with parallelization on a CDC 205 both in assembler and Fortran (CDC has expired shortly after). IIRC it did not protect against simultaneous updating the same memory location. But what I do recall is that it is very important that parallel processes use distinct parts of memory. So I wonder: give each future or place its own copies of the data they need and produce data in locations local within the place or future before returning them. Of course it may happen that a procedure is called for which Racket cannot know which parts of memory it will access. But for (very) primitive arithmetic functions this should be an avoidable problem, I think. Just my single one cent. Jos From: Robby Findler Sent: 17 June 2020 17:23 To: Brian Adkins Cc: Racket Users Subject: Re: [racket-users] Re: trying to use futures for some calculations On Wed, Jun 17, 2020 at 8:56 AM Brian Adkins wrote: On Wednesday, June 17, 2020 at 4:50:44 AM UTC-4, Alex Harsanyi wrote: I am trying to speed up an algorithm using futures, but I am getting some unexpected results (and no real speed improvements), and I was wondering if someone more experienced could have a look a the code and tell me what am I doing wrong. [...] I would *love* to be proven wrong on this, but I think it's rare to be able to get decent parallelization in practice using futures. You may have better results using places, but it will depend on how the amount of processing for a unit compares to the overhead of communicating with the places i.e. you may get better results with 2 places than with 8 due to place communication overhead. In your case, if it's easy for the places to input their own sets of parameters, then the place overhead may be small since I think each place would simply need to communicate its best value. While this may be true, it is also the case that the design of futures is such that incremental work on the primitives turns into incremental ability to parallelize programs. So while it is likely to be more work today, it may also be the case that people putting effort in to help their own programs will help us turn the corner here. Perhaps this is a place where an interested contributor can help us out a lot! Robby -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAL3TdOPnzjMdTEOU%2BdO34B8VAfXzORSVHfXYx6tV-8DVGZ7oXw%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5eea438f.1c69fb81.872f7.149c%40mx.google.com.
Re: [racket-users] Re: trying to use futures for some calculations
I've looked at it only briefly (it's the end of the semester and grading is due soon). > > > I would *love* to be proven wrong on this, but I think it's rare to > be able to get decent parallelization in practice using futures. You > may have better results using places, but it will depend on how the > amount of processing for a unit compares to the overhead of > communicating with the places i.e. you may get better results with 2 > places than with 8 due to place communication overhead. In your > case, if it's easy for the places to input their own sets of > parameters, then the place overhead may be small since I think each > place would simply need to communicate its best value. > This is not even remotely true, I am using futures to get 100% utilization on all cores available. The current situation is that it takes quite some effort to leverage futures to get there. A few generic remarks first. Arbitrary partitioning does not work well with futures. I always partition the work based on the processor-count with something like: (define futures-depth (make-parameter (inexact->exact (ceiling (log (processor-count) 2) (define-syntax (define-futurized stx) (syntax-case stx () ((_ (proc start end) body ...) #'(begin (define max-depth (futures-depth)) (define (proc start end (depth 0)) (cond ((fx< depth max-depth) (define mid (fx+ start (fxrshift (fx- end start) 1))) (let ((f (future (λ () (proc start mid (fx+ depth 1)) (proc mid end (fx+ depth 1)) (touch f))) (else body ...))) Of course all those fx+, fx- and fx< must be unsafe versions from racket/unsafe/ops. Second problem is the allocation of flonums. The inner part of the loop looks like even with flonums inlining it triggers the allocator more than often. With CS just forget about this before the inlined flonums are merged. In the meantime, you can drop the for/fold and use flvector to store and accumulate whatever you need. Using futures-vizualizer is a good start. I'll look into it later this week. But generally you need to stick to unsafe ops and avoid the allocator. > > > While this may be true, it is also the case that the design of futures > is such that incremental work on the primitives turns into incremental > ability to parallelize programs. So while it is likely to be more work > today, it may also be the case that people putting effort in to help > their own programs will help us turn the corner here. Perhaps this is a > place where an interested contributor can help us out a lot! It is on the list :) Dominik -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/16fc95cf-5e46-50b6-2d9d-0e336ff1be37%40trustica.cz.
Re: [racket-users] Re: trying to use futures for some calculations
On Wed, Jun 17, 2020 at 8:56 AM Brian Adkins wrote: > On Wednesday, June 17, 2020 at 4:50:44 AM UTC-4, Alex Harsanyi wrote: >> >> >> I am trying to speed up an algorithm using futures, but I am getting some >> unexpected results (and no real speed improvements), and I was wondering if >> someone more experienced could have a look a the code and tell me what am I >> doing wrong. >> [...] >> > > I would *love* to be proven wrong on this, but I think it's rare to be > able to get decent parallelization in practice using futures. You may have > better results using places, but it will depend on how the amount of > processing for a unit compares to the overhead of communicating with the > places i.e. you may get better results with 2 places than with 8 due to > place communication overhead. In your case, if it's easy for the places to > input their own sets of parameters, then the place overhead may be small > since I think each place would simply need to communicate its best value. > > > While this may be true, it is also the case that the design of futures is such that incremental work on the primitives turns into incremental ability to parallelize programs. So while it is likely to be more work today, it may also be the case that people putting effort in to help their own programs will help us turn the corner here. Perhaps this is a place where an interested contributor can help us out a lot! Robby -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAL3TdOPnzjMdTEOU%2BdO34B8VAfXzORSVHfXYx6tV-8DVGZ7oXw%40mail.gmail.com.
