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 -
SharedArrayBuffers are another good option, but you have to build your own datatypes on top. I'm most excited for ZGC in Java actually, but if you're doing it right you're pre-allocating anyway...
1 reply 0 retweets 2 likes
ZGC is a life savior. In jdk-16 you have also parallel thread-stack scanning.
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.