Re: [racket-users] trying to use futures for some calculations

[Dominik Pantůček]

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
future scheduling started to look different, however there are many
allocations because of your loops in functions cp3-futures and
evaluate-cost.

I didn't finish the work though, because I noticed another strange
thing. The Typed Racket code in the lambda function returned by spline
(your mmax-fn argument) blocks almost entirely the parallel execution on
... type checks.

2) All those =, < and friends just block it.

So how to fix this? Well, it is relatively easy albeit quite a lot of
manual work.

(I am looking only at the cp3-futures function when talking about
possible improvements).

* Change the all the for loops for let loop forms and use preallocated
flvectors to hold all the values.
* Switch to racket/unsafe/ops for everything inside futures (this is not
necessary, but takes away a few possible surprises)
* Restructuralize the way you split the work into 30 futures and just
use a binary tree of futures as suggested earlier.
* Use racket/unsafe/ops from regular racket to implement the spline
interpolation. I would also move the coefficients into one huge flvector
and forgot about lists at all. This is very specific workload.

And do not worry about GCs. Once you get rid of all allocations inside
futures, the GCs will disappear.

Also bear in mind that my suggestions are rather low level. By following
them you will get the algorithm to scale over multiple cores if you
really need it. Just remember it will be at a huge cost to readability.
You can slightly mitigate this by some refactoring and custom syntax,
but that is even more work and I would really consider whether you need
the parallelism for a computation that takes a few seconds anyway.

Of course, if you plan to use your algorithm for much bigger data set,
this is the way to go (including the custom syntax).


Cheers,
Dominik

On 17. 06. 20 10:50, 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 put up the code in this repository:
> https://github.com/alex-hhh/cp3-exeriments, unfortunately it is the
> simplest meaningful example that I can come up with.  Most of the
> functions, however are just support functions and there are six
> implementation of the same algorithm.
> 
> Basically, the problem I am trying to solve is to fit a model to
> existing data and this is done by evaluating 2.5 million combinations of
> parameters.  My best, non-futures based, algorithm can do this in about
> 3 seconds (8 seconds in DrRacket).
> 
> Given that each of this 2.5 million combination is completely
> independent from the others, they could all be done in parallel.  Given
> this, I "sliced" the combinations into 30 groups and tried to perform
> each "slice" in its own future and select the best among the 30 results
> produced by these futures.
> 
> Unfortunately, while the futures versions of the algorithm produce the
> correct result, the algorithm runs at the same speed as the non-futures
> version.  My `processor-count` returns 8, so I would expect at least
> some level of parallelism.
> 
> As a first step, I tried using `would-be-future`, to see if it reported
> any operations which might block, but nothing was printed out.
> 
> I also tried using the futures visualized, and I found the following:
> 
> * the code appears to be blocking on primitive operations, such as +, -,
> < etc.
> * I suspect these operations are inside the code generated by the `for`
> loops, so I am not sure how to remove them without making the code even
> more difficult to read.
> * there seems to be a lot more time spent in the garbage collector when
> running the futures visualizer than without it (DrRacket runs with
> unlimited memory)
> 
> So I am wondering if someone who is more familiar with futures can look
> at the code and provide some hints about what can be done to make this
> code run in parallel (or if it cannot, I would like to understand why).
> 
> This is already a long message, so I will not add further details here,
> but the repository at https://github.com/alex-hhh/cp3-exeriments has an
> explanation of what every function does, and I am happy to provide
> further clarifications if needed.
> 
> Thanks,
> Alex.
> 
> -- 
> 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

[racket-users] New package: mind-map

[Sage Gerard]

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 permitting, the next feature is HTML+SVG output to enable hyperlinks on 
nodes. Currently I use single lines for vertex labels, but am considering 
sexprs or at-exprs for richer rendering.

~slg

-- 
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/jcxRJ45tYM_Fdy5uPs-idEvlfPeTbNA_UD3RavJ_x-q9FWnpPC_KmOQBH9tg07QfBqrHOnK5eBsQmsZrLHXl5rs1m0n9eGYF3Sr3scLO4j8%3D%40sagegerard.com.

Re: [racket-users] trying to use futures for some calculations

[Sam Tobin-Hochstadt]

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 `+` with fixnum 1 and a flonum.
>

-- 
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/CAK%3DHD%2BYoCf8O2aO90peZSSVFYybehgKg-iLqgtQcZBA0DU3WWw%40mail.gmail.com.

RE: [racket-users] Re: trying to use futures for some calculations

[Jos Koot]

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

[Jos Koot]

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] Why does this counter behave differently in different runtimes?

[Neil Van Dyke]

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 making bugs. :)


--
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/68d508ac-b702-10b8-1d04-e6afa79e0248%40neilvandyke.org.

Re: [racket-users] Why does this counter behave differently in different runtimes?

[Sage Gerard]

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 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 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 it isn’t the expander’s fault:
>>
>> (module counter racket/base
>> (#%module-begin
>> (module configure-runtime '#%kernel
>> (#%module-begin (#%require racket/runtime-config) (#%app configure
>> '#f)))
>> (define-values
>> (count!)
>> (let-values (((i) '0))
>> (lambda () (begin0 (set! i (#%app add1 i)) (#%app + i)
>> (#%app call-with-values (lambda () (#%app count!)) print-values)))
>>
>> But `raco decompile` reveals that begin0 has been mysteriously replaced with
>> begin in the compiled program:
>>
>> (module counter 
>> (require (lib "racket/base.rkt"))
>> (provide)
>> (define-values
>> (count!)
>> (let ((local54 '0))
>> (begin
>> (set! local54 (#%box local54))
>> (lambda ()
>> '#(count! # 4 4 53 63 #f)
>> '(flags: preserves-marks single-result)
>> '(captures: (val/ref local54))
>> (begin
>> (#%set-boxes! (local54) (add1 (#%unbox local54)))
>> (+ (#%unbox local54)))
>> (#%apply-values print-values (count!))
>> (void)
>> (module (counter configure-runtime) 
>> (require '#%kernel (lib "racket/runtime-config.rkt"))
>> (provide)
>> (print-as-expression '#t)
>> (void)))
>>
>> It seems perhaps an optimization has gone awry. The bug appears to be quite
>> old: I can reproduce it as far back as 6.1.1. (I didn’t test any versions
>> earlier than that.) Unsurprisingly, the issue does not occur on Racket CS,
>> which is consistent with the hypothesis that this is a compiler bug.
>>
>> Alexis
>>
>> > On Jun 17, 2020, at 02:04, Sage Gerard  wrote:
>> >
>> > I attached a video demonstrating what I'm seeing. In case it does not load
>> or is not available, I'll summarize here. Forgive any typos; it's been a late
>> night of coding.
>> >
>> > Here's a module with an incorrect counter. It's incorrect because it uses
>> begin0, and is therefore expected to return void instead of an incrementing
>> integer.
>> >
>> > #lang racket
>> > (provide count!)
>> > (define count!
>> > (let ([i 0])
>> > (λ () (begin0
>> > (set! i (add1 i))
>> > (~v i)
>> >
>> > Notice that I added the ~v to format the return value. If I launch Racket
>> v7.7.0.5 using racket -it prog.rkt, (count!) returns the formatted value. But
>> if I remove the ~v, it behaves as written (returning void).
>> >
>> > The video shows the behavior with and without ~v, both in DrRacket and
>> racket. DrRacket is the only environment that consistently runs the code
>> correctly.
>> >
>> > ~slg
>>
>> --
>> 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/781BE0E5-E6E5-4F0B-8B46-5227FDFB
>> 8835%40gmail.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/20200617071306.bc%40sirmail.smtp.cs.utah.edu.

-- 
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/IH8l5cBwN3MPSWGHBWcbvDTEMikj3_ZDa5UWVtZ36bEabxTUzD8qamaPRE42q8U6mYRKYGKWit9Zh6cGYc7J7ibz2DmCeJ3dt0_4zJU5Vyc%3D%40sagegerard.com.

Re: [racket-users] Re: trying to use futures for some calculations

[Dominik Pantůček]

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

[Robby Findler]

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.

Re: [racket-users] trying to use futures for some calculations

[Matthew Flatt]

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 `+` with fixnum 1 and a flonum.

-- 
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/20200617083640.285%40sirmail.smtp.cs.utah.edu.

Re: [racket-users] trying to use futures for some calculations

[Sam Tobin-Hochstadt]

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 the code more painful to read.
- on Racket CS, operations like `+` do not block, and I see much
better speedup. I changed the third range to 720-800 to get answers
quicker, and I got numbers like:

[samth@homer:/tmp/cp3-exeriments (master) plt] racketcs main.rkt
cp3-baseline:
cpu time: 1947 real time: 1947 gc time: 10
cp3-precomputed:
cpu time: 399 real time: 399 gc time: 4
cp3-precomputed-more:
cpu time: 475 real time: 475 gc time: 3
cp3-futures:
cpu time: 4285 real time: 740 gc time: 11
cp3-precomputed-futures:
cpu time: 785 real time: 138 gc time: 3
cp3-precomputed-more-futures:
cpu time: 876 real time: 153 gc time: 4

So a more than 2x increase in cpu time, but a more than 2x decrease in
wall-clock time.

Certainly more investigation is needed to figure out why things take
so much longer total, but this seems like a promising speedup.

- The futures-visualizer uses logging and a functional graphics
library, both of which will allocate a lot more. You can use
`trace-futures` and `show-visualizer` to separate out the gui display
from execution, which might help.

Sam

On Wed, Jun 17, 2020 at 4:50 AM 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 put up the code in this repository: 
> https://github.com/alex-hhh/cp3-exeriments, unfortunately it is the simplest 
> meaningful example that I can come up with.  Most of the functions, however 
> are just support functions and there are six implementation of the same 
> algorithm.
>
> Basically, the problem I am trying to solve is to fit a model to existing 
> data and this is done by evaluating 2.5 million combinations of parameters.  
> My best, non-futures based, algorithm can do this in about 3 seconds (8 
> seconds in DrRacket).
>
> Given that each of this 2.5 million combination is completely independent 
> from the others, they could all be done in parallel.  Given this, I "sliced" 
> the combinations into 30 groups and tried to perform each "slice" in its own 
> future and select the best among the 30 results produced by these futures.
>
> Unfortunately, while the futures versions of the algorithm produce the 
> correct result, the algorithm runs at the same speed as the non-futures 
> version.  My `processor-count` returns 8, so I would expect at least some 
> level of parallelism.
>
> As a first step, I tried using `would-be-future`, to see if it reported any 
> operations which might block, but nothing was printed out.
>
> I also tried using the futures visualized, and I found the following:
>
> * the code appears to be blocking on primitive operations, such as +, -, < 
> etc.
> * I suspect these operations are inside the code generated by the `for` 
> loops, so I am not sure how to remove them without making the code even more 
> difficult to read.
> * there seems to be a lot more time spent in the garbage collector when 
> running the futures visualizer than without it (DrRacket runs with unlimited 
> memory)
>
> So I am wondering if someone who is more familiar with futures can look at 
> the code and provide some hints about what can be done to make this code run 
> in parallel (or if it cannot, I would like to understand why).
>
> This is already a long message, so I will not add further details here, but 
> the repository at https://github.com/alex-hhh/cp3-exeriments has an 
> explanation of what every function does, and I am happy to provide further 
> clarifications if needed.
>
> Thanks,
> Alex.
>
> --
> 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/8bf6f7c4-3b2f-4b86-9a8a-be68e82d09cfo%40googlegroups.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/CAK%3DHD%2BaKpxBhaRs64yfmats3j_V5kF7KTe3Mb4OsgUpaDvk_WQ%40mail.gmail.com.

[racket-users] Re: trying to use futures for some calculations

[Brian Adkins]

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 put up the code in this repository: 
> https://github.com/alex-hhh/cp3-exeriments, unfortunately it is the 
> simplest meaningful example that I can come up with.  Most of the 
> functions, however are just support functions and there are six 
> implementation of the same algorithm.
> [...]
>

This is entirely unrelated to your question, but I'm curious about your 
ranges. Andy Coggan defines the following:

Neuromuscular:  < 30 seconds
Anaerobic:  30 seconds to 3 minutes
VO2max:  3 minutes to 8 minutes
Lactate Threshold: 8 to 30 minutes
Tempo:  60 to 180 minutes
Endurance:  60 to 300 minutes

I'm curious about you using 2 to 5 minutes for anaerobic. In particular, 
because I'm targeting 5 minutes as an important benchmark, and I've 
considered that as high level aerobic w/ a strong anaerobic contribution.

-- 
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/3a54dd48-96f7-4d1e-81e2-f192bf9320e2o%40googlegroups.com.

[racket-users] Re: trying to use futures for some calculations

[Brian Adkins]

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.

-- 
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/633393c0-319c-4d7a-a587-cee2d6ab3eb4o%40googlegroups.com.

Re: [racket-users] Why does this counter behave differently in different runtimes?

[Matthew Flatt]

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 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 it isn’t the expander’s fault:
> 
> (module counter racket/base
>   (#%module-begin
>(module configure-runtime '#%kernel
>  (#%module-begin (#%require racket/runtime-config) (#%app configure 
> '#f)))
>(define-values
> (count!)
> (let-values (((i) '0))
>   (lambda () (begin0 (set! i (#%app add1 i)) (#%app + i)
>(#%app call-with-values (lambda () (#%app count!)) print-values)))
> 
> But `raco decompile` reveals that begin0 has been mysteriously replaced with 
> begin in the compiled program:
> 
> (module counter 
>   (require (lib "racket/base.rkt"))
>   (provide)
>   (define-values
>(count!)
>(let ((local54 '0))
>  (begin
>(set! local54 (#%box local54))
>(lambda ()
>  '#(count! # 4 4 53 63 #f)
>  '(flags: preserves-marks single-result)
>  '(captures: (val/ref local54))
>  (begin
>(#%set-boxes! (local54) (add1 (#%unbox local54)))
>(+ (#%unbox local54)))
>   (#%apply-values print-values (count!))
>   (void)
>   (module (counter configure-runtime) 
> (require '#%kernel (lib "racket/runtime-config.rkt"))
> (provide)
> (print-as-expression '#t)
> (void)))
> 
> It seems perhaps an optimization has gone awry. The bug appears to be quite 
> old: I can reproduce it as far back as 6.1.1. (I didn’t test any versions 
> earlier than that.) Unsurprisingly, the issue does not occur on Racket CS, 
> which is consistent with the hypothesis that this is a compiler bug.
> 
> Alexis
> 
> > On Jun 17, 2020, at 02:04, Sage Gerard  wrote:
> > 
> > I attached a video demonstrating what I'm seeing. In case it does not load 
> or is not available, I'll summarize here. Forgive any typos; it's been a late 
> night of coding.
> > 
> > Here's a module with an incorrect counter. It's incorrect because it uses 
> begin0, and is therefore expected to return void instead of an incrementing 
> integer.
> > 
> > #lang racket
> > (provide count!)
> > (define count!
> >   (let ([i 0])
> > (λ () (begin0
> > (set! i (add1 i))
> > (~v i)
> > 
> > Notice that I added the ~v to format the return value. If I launch Racket 
> v7.7.0.5 using racket -it prog.rkt, (count!) returns the formatted value. But 
> if I remove the ~v, it behaves as written (returning void).
> > 
> > The video shows the behavior with and without ~v, both in DrRacket and 
> racket. DrRacket is the only environment that consistently runs the code 
> correctly.
> > 
> > ~slg
> 
> -- 
> 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/781BE0E5-E6E5-4F0B-8B46-5227FDFB
> 8835%40gmail.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/20200617071306.bc%40sirmail.smtp.cs.utah.edu.

Re: [racket-users] Why does this counter behave differently in different runtimes?

[George Neuner]

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 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/abbcdae5-f88e-8a4c-f48b-c6f4fb6be38c%40comcast.net.

[racket-users] scribble: how to put a bar above text?

[Jos Koot]

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 suggestions.
Thanks, 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/5ee9fe05.1c69fb81.f0c4e.da9a%40mx.google.com.

Re: [racket-users] Why does this counter behave differently in different runtimes?

[George Neuner]

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-runtime '#%kernel
 (#%module-begin (#%require racket/runtime-config) (#%app
   configure '#f)))
   (#%provide count!)
   (define-values
    (lifted/2)
    (begin
  (with-continuation-mark
   contract-continuation-mark-key
   (#%app cons idB12 'no-negative-party)
   (let-values ()
 (#%app
  idX9
  (#%app
   module-name-fixup
   (#%app
    variable-reference->module-source/submod
    (#%variable-reference))
   (#%app list)))
   (define-values
    (count!)
    (let-values (((i) '0))
  (lambda () (begin0 (set! i (#%app add1 i)) (#%app lifted/2
   i)))



Btw:  my Racket installations report only  "7.7", not  "7.7.0.5". Are 
you running a snapshot build?


George


On 6/17/2020 3:04 AM, Sage Gerard wrote:
I attached a video demonstrating what I'm seeing. In case it does not 
load or is not available, I'll summarize here. Forgive any typos; it's 
been a late night of coding.


Here's a module with an incorrect counter. It's incorrect because it 
uses begin0, and is therefore expected to return void instead of an 
incrementing integer.


#lang racket
(provide count!)
(define count!
  (let ([i 0])
    (λ () (begin0
    (set! i (add1 i))
    (~v i)

Notice that I added the ~v to format the return value. If I launch 
Racket v7.7.0.5 using racket -it prog.rkt, (count!) returns the 
formatted value. But if I remove the ~v, it behaves as written 
(returning void).


The video shows the behavior with and without ~v, both in DrRacket and 
racket. DrRacket is the only environment that consistently runs the 
code correctly.




--
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/626cee23-fa67-c17f-781c-44554a50cf2e%40comcast.net.

[racket-users] trying to use futures for some calculations

[Alex Harsanyi]

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.com/alex-hhh/cp3-exeriments, unfortunately it is the 
simplest meaningful example that I can come up with.  Most of the 
functions, however are just support functions and there are six 
implementation of the same algorithm.

Basically, the problem I am trying to solve is to fit a model to existing 
data and this is done by evaluating 2.5 million combinations of 
parameters.  My best, non-futures based, algorithm can do this in about 3 
seconds (8 seconds in DrRacket).

Given that each of this 2.5 million combination is completely independent 
from the others, they could all be done in parallel.  Given this, I 
"sliced" the combinations into 30 groups and tried to perform each "slice" 
in its own future and select the best among the 30 results produced by 
these futures.

Unfortunately, while the futures versions of the algorithm produce the 
correct result, the algorithm runs at the same speed as the non-futures 
version.  My `processor-count` returns 8, so I would expect at least some 
level of parallelism.

As a first step, I tried using `would-be-future`, to see if it reported any 
operations which might block, but nothing was printed out.

I also tried using the futures visualized, and I found the following:

* the code appears to be blocking on primitive operations, such as +, -, < 
etc.
* I suspect these operations are inside the code generated by the `for` 
loops, so I am not sure how to remove them without making the code even 
more difficult to read.
* there seems to be a lot more time spent in the garbage collector when 
running the futures visualizer than without it (DrRacket runs with 
unlimited memory)

So I am wondering if someone who is more familiar with futures can look at 
the code and provide some hints about what can be done to make this code 
run in parallel (or if it cannot, I would like to understand why).

This is already a long message, so I will not add further details here, but 
the repository at https://github.com/alex-hhh/cp3-exeriments has an 
explanation of what every function does, and I am happy to provide further 
clarifications if needed.

Thanks,
Alex.

-- 
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/8bf6f7c4-3b2f-4b86-9a8a-be68e82d09cfo%40googlegroups.com.

Re: [racket-users] Why does this counter behave differently in different runtimes?

[Alexis King]

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 it isn’t the expander’s fault:

(module counter racket/base
  (#%module-begin
   (module configure-runtime '#%kernel
 (#%module-begin (#%require racket/runtime-config) (#%app configure 
'#f)))
   (define-values
(count!)
(let-values (((i) '0))
  (lambda () (begin0 (set! i (#%app add1 i)) (#%app + i)
   (#%app call-with-values (lambda () (#%app count!)) print-values)))

But `raco decompile` reveals that begin0 has been mysteriously replaced with 
begin in the compiled program:

(module counter 
  (require (lib "racket/base.rkt"))
  (provide)
  (define-values
   (count!)
   (let ((local54 '0))
 (begin
   (set! local54 (#%box local54))
   (lambda ()
 '#(count! # 4 4 53 63 #f)
 '(flags: preserves-marks single-result)
 '(captures: (val/ref local54))
 (begin
   (#%set-boxes! (local54) (add1 (#%unbox local54)))
   (+ (#%unbox local54)))
  (#%apply-values print-values (count!))
  (void)
  (module (counter configure-runtime) 
(require '#%kernel (lib "racket/runtime-config.rkt"))
(provide)
(print-as-expression '#t)
(void)))

It seems perhaps an optimization has gone awry. The bug appears to be quite 
old: I can reproduce it as far back as 6.1.1. (I didn’t test any versions 
earlier than that.) Unsurprisingly, the issue does not occur on Racket CS, 
which is consistent with the hypothesis that this is a compiler bug.

Alexis

> On Jun 17, 2020, at 02:04, Sage Gerard  wrote:
> 
> I attached a video demonstrating what I'm seeing. In case it does not load or 
> is not available, I'll summarize here. Forgive any typos; it's been a late 
> night of coding.
> 
> Here's a module with an incorrect counter. It's incorrect because it uses 
> begin0, and is therefore expected to return void instead of an incrementing 
> integer.
> 
> #lang racket
> (provide count!)
> (define count!
>   (let ([i 0])
> (λ () (begin0
> (set! i (add1 i))
> (~v i)
> 
> Notice that I added the ~v to format the return value. If I launch Racket 
> v7.7.0.5 using racket -it prog.rkt, (count!) returns the formatted value. But 
> if I remove the ~v, it behaves as written (returning void).
> 
> The video shows the behavior with and without ~v, both in DrRacket and 
> racket. DrRacket is the only environment that consistently runs the code 
> correctly.
> 
> ~slg

-- 
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/781BE0E5-E6E5-4F0B-8B46-5227FDFB8835%40gmail.com.