This is quite curious. It appears to be a compiler bug. Here’s a very slightly
smaller test case:
#lang racket/base
(define count!
(let ([i 0])
(λ () (begin0
(set! i (add1 i))
(+ i)
(count!)
The fully-expanded program looks fine, so i
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
It seems to work ... i.e. returns # ... in Windows. I tried it in
7.6 and 7.7, both 32 and 64 bit versions. Not near my Linux machine
to try it there.
The expansion in all cases is the same and seems reasonable:
(module count racket
(#%module-begin
(module configure-runti
Thanks to all of you for your help.
I have tried some of your suggestions.
They are promising.
Meanwhile I have found out that I can do the following:
- Create an equation in Word
- Save it as a picture
- Convert it to gif
- Insert it with @image
Nevertheless I’ll look further into your suggestion
Sorry for the noise: it behaves as you say returning "!", "2", ...
Somehow I paths screwed up and was running CS when I thought I was
running regular (bytecode) Racket.
Sigh!
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To un
Yes, clearly a BC compiler bug --- and probably almost as old as
Racket. The bug was specific to `set!` on a locally bound variable as
the first subexpression of `begin0`.
I've pushed a repair.
Thanks!
At Wed, 17 Jun 2020 03:35:51 -0500, Alexis King wrote:
> This is quite curious. It appears to
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 w
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 w
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
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
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
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
Thank you all so much! I'm glad it wasn't a huge mystery in the end.
Original Message
On Jun 17, 2020, 9:13 AM, Matthew Flatt wrote:
> Yes, clearly a BC compiler bug --- and probably almost as old as
> Racket. The bug was specific to `set!` on a locally bound variable as
> the f
Compiler bugs have been so blessedly rare in Racket, maybe there should
be a page on the Web, honoring those who found a compiler bug?
I would nominate Sage and Alexis for this one.
And Matthew, though we'd have to make sure he's not mis-incentivized by
the glory of bug-finding, to start makin
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 distin
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
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
I take notes using short indented lines, so I wrote a #lang using Pythonic
indentation rules to interpret my notes as nodes in a mind map.
Source for the interested: https://github.com/zyrolasting/mind-map
With thanks to Hadi Moshayedi for racket-graphviz. I use that to render the
maps.
Time p
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
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
Perhaps my choice for the interval names is not ideal, so I will try to
explain it:
I am trying to fit a function which uses 3 parameters, so I need three data
points to solve for these parameters. The three points are drawn from
three intervals, and, rather than calling the intervals ivl1, iv
21 matches
Mail list logo
