# Is there plans for improving the performance of the generated code from the racket compiler? **URL:** \ **Category:** Internals\ **Tags:** question\ **Created:** [December 11, 2023, 11:50pm UTC](https://racket.discourse.group/t/is-there-plans-for-improving-the-performance-of-the-generated-code-from-the-racket-compiler/2593 "2023-12-11T23:50:46Z")\ **Posts on this page:** 1\ **Showing post:** 17
**Author:** ![LiberalArtist](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/liberalartist/32/151_2.png) [@LiberalArtist](https://racket.discourse.group/u/LiberalArtist)\ **Post date:** [May 28, 2024, 7:59pm UTC](https://racket.discourse.group/t/is-there-plans-for-improving-the-performance-of-the-generated-code-from-the-racket-compiler/2593/17 "2024-05-28T19:59:42Z")
> [@dstorrs](#): > > based on what I've read about futures it feels like they basically aren't worth using because they overly restrict the operations you can use and it's hard to predict if you will invalidate the future. > [@samth](#): > > Futures are certainly somewhat limited but I wouldn't say they're not worth using; it just requires somewhat more care to use them well. I found Matthew's talk [Incremental Parallelization of Dynamic Languages | Air Mozilla | Mozilla, in Video](https://web.archive.org/web/20161014095622/https://air.mozilla.org/incremental-parallelization-of-dynamic-languages/) useful context for futures. Unfortunately, it looks like Mozilla Air moved to a new CMS and didn't import old videos, and the Internet Archive page I linked to doesn't seem to have archived the actual video: maybe someone can find another source? With respect to discussions about the limitations of futures one might read in various places, a big change came with the move to Racket CS, and I think we are (certainly I am) still gaining experience with what is now possible. Racket BC was originally single-threaded, and most operations ended up blocking futures from running in parallel. (This was explained well in the Mozilla talk. I particularly remember a picture of a bike covered with an extreme number of locks.) What worked in Racket BC was primarily carefully written numeric code. In Racket CS, _most_ primitives are now future-safe (by virtue of Chez Scheme's support for OS-level threads), basically the opposite of the Racket BC situation! I found the diff from [guide: update discussion on futures for Racket CS · racket/racket@4fcecee · GitHub](https://github.com/racket/racket/commit/4fcecee53c61e44687696a1116137c3a7c12f368) an interesting view into what changed. That said, there is certainly also room for improvement, e.g. (as @samth wrote [here](https://racket.discourse.group/t/what-is-the-racket-roadmap/2204/28)) finding a way to make IO operations "synchronized" rather than "blocking". > [@robby](#): > > There is a mode where you can run places will run in separate processes, but in most environments, they are in the same OS process, I believe. Are you thinking of the `--processes` mode for e.g. `raco setup`? IIUC, places always use OS threads in the same OS process when they are able to run in parallel, and that mode exists to enable process parallelism when parallel places aren't supported (as was the case on non-x86{,\_64} with Racket BC), but has to be implemented explicitly in `raco setup`. I don't think ordinary places ever run in separate OS processes. (I say "normal places" because [`loci`](https://docs.racket-lang.org/loci/index.html) by Paulo Matos and [`racket/place/distributed`](https://docs.racket-lang.org/distributed-places/index.html) exist, and [`prop:place-location`](https://docs.racket-lang.org/reference/places.html#%28def._%28%28lib._racket%2Fplace..rkt%29._prop~3aplace-location%29%29) provides some extensibility.) (Tangentially, I wonder if the bottleneck from the OS page table described in [docs: describe some limits of place scaling · racket/racket@b223ce4 · GitHub](https://github.com/racket/racket/commit/b223ce471ec38c61f37e0a458d54fabf525324cb) and [this thread](https://groups.google.com/g/racket-users/c/oE72JfIKDO4/m/IYggL09WBAAJ) also applies with Racket CS. I don't have any machines with more than 16 cores to check.) > [@louis771](#): > > Since the link in the original post no longer works, here are the two implementations (Racket and SBCL): > > [Racket performance measurements (Benchmarks Game)](https://benchmarksgame-team.pages.debian.net/benchmarksgame/measurements/racket.html) > [@samth](#): > > Certainly Racket has performance issues that it would be good to fix, but I don't think the benchmarks game is a good guide to them. I agree with @samth on this, but, if someone wants to spend time making the benchmarks look faster, adding [`(#%declare #:unsafe)`](https://docs.racket-lang.org/reference/module.html#%28idx._%28gentag._104._%28lib._scribblings%2Freference%2Freference..scrbl%29%29%29) would probably give at least some benefit without requiring deep thought. (Unlike using `(#%declare #:unsafe)` in real life!) --- _[View the full topic](https://racket.discourse.group/t/is-there-plans-for-improving-the-performance-of-the-generated-code-from-the-racket-compiler/2593)._