3 ms·

I'm building an open source matching engine. I would love to pair up the two systems for a stress test. I'll keep tracking your project and ping you again when

I'm building an open source matching engine. I would love to pair up the two systems for a stress test. I'll keep tracking your project and ping you again when I have a system up a running if you're interested. https://github.com/fmstephe/matching_engine https://github.com/fmstephe/matching_engine

zygomega 14y ago
We have some plans on the drawing board for market maker simulators that could do with some fast matching so I'll keep an ear open for that ping.
- fmstephe 14y ago
  What sort of performance baselines would you require?
  - zygomega 14y ago
    I have no idea yet. I see you're geeking out in go and there's been a lot of advocacy coming through to look at go as an alternative.
    - fmstephe 14y ago
      Yeah, Go is a great language. However, I am trying to develop some low level queues that should be faster, and less generic, than the ones that Go provides. But I am having some difficulty putting memory fences into my code. But if I can get a reasonable level of performance out of the standard Go queues then I will just use those in the meantime.
ycombobreaker 14y ago
I see a comment about ITCH in there... Are you modeling your interface after NASDAQ's ITCH/OUCH interfaces? If so, I think it would be interesting to look at the protocol specifications for all of the other major US equity exchanges. I think they are all freely-downloadable.
- fmstephe 14y ago
  I was using ITCH data to try to test the matching algorithm. However, I found that the number of hidden trades made it fairly poor for validation, which was what I was most interested in. I _was_ using the ITCH format for messages and switched away from it. I may revisit that decision in the future. I agree that it would be really interesting to look at the messaging protocols of real exchanges, and I have made a quick stab at it. But I am focused on getting something very simple working right now. If you wanted to play around with ITCH files the executable generated in the itch directory will run any ITCH file through the matching engine sort of like a debugger, allowing you to step forwards and backwards in time and see how the internal state of the matching engine changes.

zygomega 14y ago

We have some plans on the drawing board for market maker simulators that could do with some fast matching so I'll keep an ear open for that ping.

fmstephe 14y ago
What sort of performance baselines would you require?
- zygomega 14y ago
  I have no idea yet. I see you're geeking out in go and there's been a lot of advocacy coming through to look at go as an alternative.
  - fmstephe 14y ago
    Yeah, Go is a great language. However, I am trying to develop some low level queues that should be faster, and less generic, than the ones that Go provides. But I am having some difficulty putting memory fences into my code. But if I can get a reasonable level of performance out of the standard Go queues then I will just use those in the meantime.

ycombobreaker 14y ago

I see a comment about ITCH in there... Are you modeling your interface after NASDAQ's ITCH/OUCH interfaces? If so, I think it would be interesting to look at the protocol specifications for all of the other major US equity exchanges. I think they are all freely-downloadable.

fmstephe 14y ago
I was using ITCH data to try to test the matching algorithm. However, I found that the number of hidden trades made it fairly poor for validation, which was what I was most interested in. I _was_ using the ITCH format for messages and switched away from it. I may revisit that decision in the future. I agree that it would be really interesting to look at the messaging protocols of real exchanges, and I have made a quick stab at it. But I am focused on getting something very simple working right now. If you wanted to play around with ITCH files the executable generated in the itch directory will run any ITCH file through the matching engine sort of like a debugger, allowing you to step forwards and backwards in time and see how the internal state of the matching engine changes.