0.1 + 0.2 = 0.30000000000000004
-
-
-
-
Replying to @paoloardoino @cryp7obi
That said, it's not a JS thing. It's a floating-point thing. If you use floats instead of decimal types for financial math you're gonna have a bad time.
1 reply 0 retweets 7 likes -
Yup. Ruby etc same thing. Just floating-point math, first thing everyone should learn. Still JS (ie. nodejs) would not be a smart move for a matching engine IMHO. Multi-threading is quite needed in order to reach large scale.
1 reply 0 retweets 2 likes -
Replying to @paoloardoino @cryp7obi
And while it has threads now - JS is never the right choice for a matching engine. Performance is too unpredictable, deopt still happens for seemingly random reasons, GC leaves a lot to be desired. Still beats python though for speed and convenience for most apps imo.
1 reply 0 retweets 2 likes -
Indeed. Worker threads are quite slow. They don't allow 0-copy memory passing AFAIK. It's basically serialize/deserialize. Eventually I'll be curious to test this stuff. https://www.graalvm.org/reference-manual/js/Multithreading/ …
1 reply 0 retweets 0 likes -
Replying to @paoloardoino @cryp7obi
They do transfer actually - we've used it in a few places. But it's *super* tricky. The data basically leaves the Buffer and it throws errors if you try to reuse it. Doesn't jive well with a lot of existing http and ws libs.
2 replies 0 retweets 1 like
Ah right. SharedArrayBuffers, we used for compress/decompress in gateway workers. But not super versatile.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.