@mflatt @massung

The conclusion we came to was that flomat uses malloc correctly.

For very large chunks of memory it might be a good idea to throw in (collect-garbage) explicitly to regain memory as early as possible. Also, using debugging in DrRacket makes it more difficult to figure out what is going on.

Finally, we found out that malloc is much slower on >8.3 [cs] than on the old 7.5.

soegaard@mbp2 tmp % racket --version Welcome to Racket v7.5. racket matloop.rkt 3.01s user 0.84s system 95% cpu 4.036 total /Applications/Racket\ v8.3.0.6/bin/racket matloop.rkt 65.70s user 27.59s system 98% cpu 1:34.44 total The benchmark program: #lang racket (require ffi/unsafe) (let loop ([n 0]) (unless (> n 10000) (when (zero? (remainder n 1000)) (displayln n)) (malloc 100000000 _double 'atomic) (loop (+ n 1)))) This is on an Intel mac.

so there was actually no memory leak?

Something bad did happen. But it wasn’t because of malloc.

There’s definitely a Racket CS problem in the way that it ends up keeping 10s or 100s of GB of memory allocated at once (but not necessarily touched, since the memory isn’t initialized). Fixing that problem makes it much slower, though, because a major GC is triggered every iteration. I need to investigate more to see whether BC’s GC heuristics — which work well here by using minor collections — can make sense for CS.

Not sure if anyone has done this in DrRacket, but if it has been (or is possible in general), I’d appreciate a quick pointer:

Basically, I’m now starting in on things that can take quite a while to run (training AI models) and I’d like to get a little better output/progress over println. For example, if I could “print” a progress bar in the expression area and slowly fill it in that’d be fantastic. If I could simultaneously provide a sibling label to show a little debug output, again that’d be fantastic.

I know DrRacket can do all sorts of things in the expression area (like input boxes), but I’m not sure if the above is easily doable. Anyone have any pointers/docs I can look at if so?

Look into snips and their dc%. You could also have a gui separated from drracket, and use a simple slider

With a GUI you can even run it outside DrRacket, which I’d recommend for memory/speed hungry apps

(you can still develop within DrRacket though, just run things outside)