Hi Dominic,
Thanks for taking the time to look into this. For most of your suggestions
I already suspected this to be the case, as I attempted to use futures
several times in the past, but it is good to know that other people are of
the same opinion.
I looked at some other suggestions in thi
Hi Alex,
I finally got to investigate the issue in depth. And there are two major
problems blocking your implementation from running the futures in parallel.
1) Allocations of boxed flonums. I tried to get rid of those by
allocating "scratchpad" flvectors and mapping everything onto them. The
fut
I tried this out, by adding 1.0 as the third argument in `in-range` in
all cases. The performance in Racket BC increased, but there's still
no parallelism. In Racket CS, it appears to have made things slower,
so I need to investigate more.
Sam
On Wed, Jun 17, 2020 at 10:36 AM Matthew Flatt wrote
At Wed, 17 Jun 2020 10:24:37 -0400, Sam Tobin-Hochstadt wrote:
> - on Racket BC, operations like `+` do indeed block
... which mixing, say, fixnum and flonum arguments, but not when
operating on all fixnums or all flonums.
In this case, it may be the `in-range` with flonum bounds that results
in
I have not yet done much investigating on this, but:
- on Racket BC, operations like `+` do indeed block, and effectively
you need to replace them with lower-level operations that don't (such
as `unsafe-fl+`). Typed Racket can help with this, or you can do it
all by hand. As you note, that makes t
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 put up the code in this repository:
https://github.c
6 matches
Mail list logo
