Part 1/3: Order Matching Engine Requirements
Dev’s corner is a new section of BitShares News where developers involved with the BitShares project post technical related briefs and observations.
As an academic exercise, I wanted to take on building a order matching engine in C++. The purpose here is to iterate through the process of measuring and improving performance.
I imagine the initial requirements as naive, with later iterations including removal of floating point calculations, variable precision, 128-bit integers, “dust” handling (may be more of an implementation question than a performance one).
This order matching engine will be strictly single-threaded and purposeful. It is hoped that the input will be clean and optimized (which could be offloaded) to improve throughput.
Tooling will be sparse, on purpose. The idea here is not a discussion of the intricacies of the tools, but how tweaks to code affects speed.
The Idea
The engine will receive limit orders that specify the asset held, the asset to be bought, and the desired price. It will include a sequential ID, externally guaranteed to be unique (such a key could be analyzed later… we’ll see…).
Once received, the order is processed and if not immediately filled, what is left over is placed on the order book.
Simple, right? There are many details yet to be sorted out. So we will get started! Stay tuned!
For the first cut of the order book, see this GitHub commit.
Stay tuned for Part II: "Order matching and Container Types".
Posted from BitShares News using SteemPress, see: https://news.bitshares.org/order-matching-engine/
Join the community in our migration to Hive, a community built blockchain for the community. All Steem account holders will receive equivalent stake on the new Hive blockchain.
Please see this post on SteemPeak for more information.
hmmmm, these things bother me.
bitshares is not of such that you can use any single-threaded thinking or implementation. Yes, your implementation should probably run in a single thread, it just has to iterate over the order books. However, your implementation will run in several places at several times.
You can never count on clean inputs.
Thus you will clean and optimize inputs before handing it to your process.
If you build two modules, someone later can come and place something in between... thus you can never count on clean inputs.
Note that the beginning of the post was "academic exercise". This article is a repost from my website, where I was just walking through the thought process of designing an order book. So please do not assume this is the thought process for future iterations of BitShares. It is more like a technical article from a BitShares developer.
As for the "clean and optimized", that is why I put the "offloaded" comment in there. Such steps could be outside the matching engine code (separation of duties).
In this article, I wanted to make sure to narrow my focus on the matching engine and measuring for performance. It is a brief view for outsiders into the thinking process and experimentation of 1 developer. I gave my permission to repost articles from my blog, not thinking this would be one chosen. I hope this clears up any confusion