Futures in 8.4 cs and 8.4 bc

Questions & Answers
1

Hi

I have a program using futures.
It runs very well with DrRacket 8.4 cs.
With DrRacket 8.4 bc it seems to use one processor only.
Is this a known problem?
If not I can send the source code (about 500 lines)

Details: debugging off, Windows 10.

Best wishes, Jos Koot

1 Like
2

One of the advantages of Racket CS is that more operations are future-safe. See the discussion in racket/racket/src/thread/README.txt for more information.

1 Like
3

Thanks Ryan,
That may explain things, although I don't see any unsafe operations in my code
(proper lists and exact integers only)
(no mutable objects, no hashes, no mpairs, no vectors, no boxes, no semaphores, no etc)
Jos

4

Have you tried using the futures visualizer to see what operations your futures are blocking on?

5

I’ll try that,

Jos

DC369554041A4649A528B20B10730B39.png
DC369554041A4649A528B20B10730B39.png708×1 76 Bytes

6

BC:

9842F364F723414C916F2E049DB5D6CD.png

CS

C0D8CA652B0C4BA188EEE279BF48D6AE.png

Is it the garbage collector that is blocking?

Thanks, Jos

DC369554041A4649A528B20B10730B39.png
DC369554041A4649A528B20B10730B39.png708×1 76 Bytes

7

It means it's blocking on the + operation. IIUC, in Racket BC + is only future-safe if it is inlined by the JIT and if only the fast (fixnum-only) path is executed.

In my experiments, using + in a higher-order way caused the future to block; for example: (foldl + 0 xs). When I rewrote that to (foldl (lambda (a b) (+ a b)) 0 xs) then the future did not block. I had hoped that the compiler would inline foldl and put + in a direct-call position so the JIT can inline it, but it didn't. (Tested on Racket BC 8.1.)

5 Likes
8

Hi Ryan,

Thanks for your clear explanation.

I tried some modifications to enhance inlining, but without luck.

I’ll use CS.

Thanks again, Jos

A05275C433EC4658AD04B6A7586C7F72.png

1 Like