@niklas has joined the channel
@pavpanchekha threads are very useful for network tasks. Places are too fat for that.
If anyone is interested, I just published a scheme request for implementation with transducers. They are trivial to port to racket.
They are quite different than the ones Jack made (eager vs lazy), but also a lot more like the clojure ones. They possibly have less overhead due to the protocol of rebellion’s transducers (which has other benefits, i’m sure).
Here ya go: https://srfi.schemers.org/srfi-171/ https://www.reddit.com/r/Racket/comments/dybh3q/racket_news_issue_20_racket_75_is_almost_here/f81bmu1/?utm_source=share&utm_medium=ios_app&utm_name=iossmf
@notjack Maybe keyword arguments or maybe it’s better though to get the architectural gist from C#/Java code and then switch the mindset to data and functions on them when “porting”. [I’m really tired of OOP]
Big thanks to @jaz for gregor - fantastic package that has saved me a ton of time!
thanks @badkins!
On the subject of places, what is the base memory footprint for each one created in a program?
@anything has joined the channel
@m.gregg has joined the channel
The memory footprint is similar to that of the regular racket VM by itself — think of places as cloning the VM
On Win 10, my command console consumes 7.3mb. Goes to 72mb running racket exe. Initial DrRacket consumes 520mb. So I guess a place, assuming it’s not pulling in masses of data, would typically grow to 100–250mb.
Here are the numbers I got for various tests (I was looking into this in conversation with @pavpanchekha recently): [samth@huor:~/sw/plt/extra-pkgs/racket-lang-org (master) plt] r /home/samth/sw/plt/extra-pkgs/herbie/tmp.rkt
'startup
19867984
'base
#t
55376128
'racket
#t
91006376
'typed/racket
#t
136819072
#t
'plot
229841508
'(#<place> #<place> #<place> #<place>)
so at startup were using about 20MB, loading a new place with racket/base in it 55 MB, loading another place with racket 91 MB, and so on
Are OS threads completely off the table for the foreseeable future?
What do you mean by “OS threads” — places use OS threads.
changing thread to use a new OS thread is very unlikely
A thread which can run on any CPU core within the same VM is what I mean.
Here’s the current situation: there are 3 relevant constructs for concurrency & paralleism in Racket: future, place, and thread. thread is green threads — lightweight, concurrent, but not parallel. future is fairly lightweight, but limited because if it would do something involving interaction with the runtime such as IO or many other things, it has to block and wait for the spawning thread to do the work. This works for computation-heavy workloads but is currently limited and not widely used. place is heavyweight but flexible — it’s shared-nothing concurrency with message-passing, a la Erlang, but because of the architecture of Racket (for example, module instances can point to mutable data) lots of things have to be duplicated per-place leading to high memory use and so you can’t have a very large number of them. Places and futures both use multiple CPU cores; threads do not. The most likely paths forward for improving things here are (1) making places less heavyweight and (2) making futures work in parallel efficiently with more runtime-sensitive operations. Changing thread to use multiple OS threads is very unlikely. (There’s also an unsafe os-thread library that only works on the Chez backend.)
Sam, is an OS thread library unsafe in the presence of immutable data structures and STM?
FWIW as of right now these channels claim the following numbers 24 reddit/r/racket 9 racket discord
Obviously this is apples and oranges, and is probably dwarfed by racket-users
Current active users?
I’m not entirely sure what those numbers mean. Is that supposed to be 93 for slack?
I think the slack number is wrong
I see Member List 926