This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (5)
- # architecture (1)
- # bangalore-clj (4)
- # beginners (45)
- # boot (4)
- # cider (19)
- # clojure (56)
- # clojure-austin (1)
- # clojure-canada (1)
- # clojure-finland (1)
- # clojure-russia (67)
- # clojure-uk (2)
- # clojurescript (57)
- # clojutre (1)
- # cursive (15)
- # datomic (3)
- # emacs (2)
- # figwheel-main (71)
- # fulcro (117)
- # hoplon (33)
- # java (5)
- # off-topic (52)
- # pedestal (7)
- # remote-jobs (1)
- # shadow-cljs (134)
- # slack-help (9)
- # specter (1)
- # tools-deps (17)
- # vim (2)
@benzap give it a look-see some time when you get a chance. It'd be cool to iron out the kinks.
I've been looking into it a bit, and .Net Core and just recently, the go-lang, have released wasm implementations
I think the standardized gc that is being proposed is just to reduce the amount of wasm sent, since languages like go and c# need to include the runtime in wasm. A lot of what is included in the runtime consists of the gc
It would be cool to see a WAST DSL in CLJS that could implement that algorithm from the maria.cloud gist
Yeah, I wonder what the shortest path is between getting wast compiled into a wasm module in the browser
in my head im unclear on how once we go into wasm territory (by whatever magic), how do we write our code to be callable from JS?
and do the tradeoffs from that (would their be any?) negate the performance gains from being on WASM
maybe this is a short path, for some exploration: https://webassembly.js.org/docs/example-add-wast.html
But either way, we can send messages in and call functions on SharedArrayBuffers that we have synchronous access to. So you can have the WASM side doing some major matrix operations on a matrix and just dereference it as often as you want from the js side, as long as you structure all reads as wait free.
I'm guessing that if the same alloc/free, swap/deref algo can be implemented in a cljs dsl on the wasm side, then the swap and deref functions can then be exposed to the wasm side code to interoperate with the structure safely.
Just looking at that hello world example, it seems like there is one fairly glaring issue for interop
ive seen examples of passing the size and start in the wasm buffer for a string then decoding that here
but generalizing something like that to maps is something I would need to pull out an expert for
and whether or not this kind of effort is neccisary is the kind of thing i would need to know more about the use cases of wasm for
You can stick an ffmpeg tool in there and just blast frames through a filter on the wasm side, while just derefing on the js side
It's mostly for doing fast, time-deterministic ops on large datasets that would be slow in js
if the LLVM compiler toolchain was compiled to wasm, maybe we could target wasm from ferret https://github.com/nakkaya/ferret lol
A corollary, what is wasm not for? https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/win2k.cfg&mem=192&graphic=1&w=1024&h=768
So we can have a typed fressian object pool on a SAB and persistent data structures can be special reference tries that allow for cheap immutable transformations within transactions on the SAB. Then different threads from different languages can interoperate on the same SAB if they adhere to the protocol, I'm thinking.
Any host holding a top level reference to a clj-persistent trie of references will have incremented a reference counter on each of those references when it obtained the top level reference. If a host does a transformation on that trie and any references are dissoced, their reference counters will be decremented and if they have reached 0, the reference will be freed from memory (by the thread completing the transformation).
It's kinda like a thread-safe append-only log, but it's insert instead of append, and where the log auto-collapses as it's being used. But in a thread-safe way, so that different hosts adhering to the protocol and the SAB model will always see a consistent view.
And this would essentially allow languages with different memory and gc models to operate over a shared data structure that handles its own allocation and gc
But top level reference containers in clojure, like atoms, are usually never designed to be disposable, commonly GCed things. We usually keep atoms around throughout the life of our program, letting our host environment collect ephemeral data that gets dissoced from the structures within those atoms anyway. So for some programs, you could get away with using a host environment that has no GC at all, and just be judicious with the top level references.