Show HN: Binance Orderbooks Consumer in C++(github.com)
github.com
Show HN: Binance Orderbooks Consumer in C++
https://github.com/xreptoid/viperfish
39 comments
Using doubles for crypto prices instead of fixed point seems like a disaster waiting to happen?
Minor disaster with the probability of becoming something worse, you never know where these values will end up being used/stored and it's likely that somewhere else in your code some weird form of equality will start appearing at some point (value1-value2<1E-04, lol).
There are a lot of alternatives, use them.
Never use floats for prices and rates.
There are a lot of alternatives, use them.
Never use floats for prices and rates.
> Using doubles for crypto prices instead of fixed point seems like a disaster waiting to happen?
TDLR; nope.
That depends what you use the incoming data for. Bookkeeping, yeah. And that's about it.
This doesn't look like it was meant for that. Some sort of trading where you track a bunch of indicators over a day (not HFT at their timings at the moment but along those lines): you absolutely want to avoid fixed point because of the speed penalty. See also [1].
[1] https://news.ycombinator.com/item?id=15808316
TDLR; nope.
That depends what you use the incoming data for. Bookkeeping, yeah. And that's about it.
This doesn't look like it was meant for that. Some sort of trading where you track a bunch of indicators over a day (not HFT at their timings at the moment but along those lines): you absolutely want to avoid fixed point because of the speed penalty. See also [1].
[1] https://news.ycombinator.com/item?id=15808316
Indeed. Although I don't know what precisions are required in crypto products, in traditional trading an 8 byte double is quite enough - the price submitted will have to be rounded to the instrument's precision anyway (e.g. most spot FX products are rounded to 5 decimal places).
With a caveat here, after a very quick look at the code: The price here is defined as long double, which can be different among platforms... My Mac/clang says that long double is still 8 bytes, Linux on that same arm64 machine says it's 16 bytes (and I'm not sure what that's mapped to these days - 80bit FPU instructions, or some Float128 representation)
With a caveat here, after a very quick look at the code: The price here is defined as long double, which can be different among platforms... My Mac/clang says that long double is still 8 bytes, Linux on that same arm64 machine says it's 16 bytes (and I'm not sure what that's mapped to these days - 80bit FPU instructions, or some Float128 representation)
The orderbook class uses original strings received from the exchange as keys. However, in some places, numbers are compared with a precision of 1e-12 as long doubles. I plan to modify this to use the symbols' price step from exchangeInfo.
That's long double with 64 bit mantissa. I think they'll be all right.
No. You're overthinking it.
It's not a good practice, but no disaster will happen either for this particular purpose - a trading API.
It's not a good practice, but no disaster will happen either for this particular purpose - a trading API.
How can you say that so confidently?
Floating point is terrible for decimals, as any number not consisting of only 0's and 5's after the decimal point does not have a precise representation.
What if you're counting ratios or differences? Those values are no longer precise. What if you're comparing those ratios or differences? That comparison cannot be trusted.
What if you have a NaN? Now all your comparisons return false and any values you calculate from the NaN will also be NaN.
There is no way you can confidently claim these issues won't show up in a production system without doing fuzzing and formal verification. Just use big integers, 64 bit integers can represent 18 quintillion (short scale) values, which if you're trading in fractions of cents should be enough of a range for the foreseeable future. 128 bit integers will always be enough.
What if you have a NaN? Now all your comparisons return false and any values you calculate from the NaN will also be NaN.
There is no way you can confidently claim these issues won't show up in a production system without doing fuzzing and formal verification. Just use big integers, 64 bit integers can represent 18 quintillion (short scale) values, which if you're trading in fractions of cents should be enough of a range for the foreseeable future. 128 bit integers will always be enough.
As someone who works on trading systems, this is stupid.
You can compute floats all you want, but crypto APIs have a finite number of decimals the accept, other wise, you get a precision error.
I think it's down the list among several dozen other issues for accurate crypto pricing on binance
You say realtime feed, but at the same time use the websocket feed that updates every 100ms as your source. Am I missing something?
You are correct. When I referred to 'real-time', I meant it in the sense that it is as efficient as consuming data directly from the exchange's WebSocket because, during the consumption stage, data is directly consumed from the exchange, not an intermediate server.
Since Binance only provides 100ms diffs, there isn’t 'real-time' in the sense of receiving each atomic orderbook change. Thank you for your feedback, I changed the description.
Since Binance only provides 100ms diffs, there isn’t 'real-time' in the sense of receiving each atomic orderbook change. Thank you for your feedback, I changed the description.
`bookTicker` is realtime but the caveat is you will only get bbo (best bid and ask)
Whew! 100ms??
Ancient history.
Ancient history.
Isn't binance going away? Feels like they're going under heavy pressure and are getting restricted everywhere.
Why bother? The FPGAs HFTs connected directly to fiber will trade the sh*t out of you.
There aren't any. The fastest access you can get to Binance is in apne1 (az depends on which products you are trading). There are also a lot of systematic strategies worth automating that aren't really latency sensitive.
In traditional finance where machines are colocated, yes. That's not the case for crypto
There are exchanges which offer that in crypto too - Deribit has colocation in Equinix LD4.
Rigged markets as a service!
The crypto/cloud equivalent is letting market makers connect directly to the exchange front end servers via AWS VPC peer or equivalent rather than going via the public load balancers.
We have the VPC thing for Gate but it's slower than the public thing.
And even in non-crypto it's not only about who is the fastest.
No such thing as colo for most crypto exchanges, at least not officially. But your general point still stands. This is a cute project that's likely useless for anything serious. People go to great lengths to shave a bunch of ms off these feeds.
lots of programmatic strategies are not latency sensitive, most even
and the crypto market, despite its volatility, does not move that fast, it just has 24 hour trading, in comparison of 6-8 for equities, in a single day
so the 3x greater trading sessions create the eternity
and the crypto market, despite its volatility, does not move that fast, it just has 24 hour trading, in comparison of 6-8 for equities, in a single day
so the 3x greater trading sessions create the eternity
Windows support soon?
It's cmake based, you can download cmake and the other dependencies and just compile it.
Edit: actually no, the networking bits have some platform specific #ifdefs. The code looks not too difficult to rewrite into a WinHTTP based client, though.
Edit: actually no, the networking bits have some platform specific #ifdefs. The code looks not too difficult to rewrite into a WinHTTP based client, though.
Is there any reason you couldn't use WSL for something like this?
Better yet - Linux. Why would someone want windows to snoop on their trading? Let alone the poor performance of that OS.
or windows update
Right? Windows should never even come into your mind. Always think Linux.
Loads of quant and HFT funds run their trading software on Windows.
Can you name some, I'm curious. I assume you mean the actual trading software not just the UIs?
Loads of people do silly things :-) In all seriousness use the best tool for the task at hand, but Linux is easier to fine tune for demanding loads.
WSL is linux. HyperV runs windows and linux as guests.
It’s only slower if you trigger many world switches.
It’s only slower if you trigger many world switches.
Windows will be supported. Not sure when, but likely in a month or two.