Hi Jimmy (sorry, been away for 3 days), good question and we have investigated FPGAs, but abandoned for these reasons: We prefer “vanilla” code in the engine (less dependencies, don’t tweak the Linux kernel, minimal external packages and libraries etc) We also code-generate from a very general ER model on which is overlaid “metadata” to help code-generation, hence keeping our code generation to minimal dependencies of other tools and languages This is a commercial system and we may often deploy new releases or upgrades 3, 4 or more times a year via a tar image and patch releases perhaps once a month The application comprises 500,000 lines of code (350,000 of which are code generated from the ER model), but I am aware of a competitor running 16 million lines of code for this application (useless) We also deploy to AWS, so we prefer a single codebase for vanilla deployment to whatever medium a client requires We found programming in CUDA (GPU) or HDL (FPGA) too bespoke, due to: Having to reburn an FPGA on each upgrade/release Limiting for AWS deployment FPGA memory more limited than physical onboard memory (can’t scale to the levels required) Overall FPGA is great where a large amount of repeated processing is needed on data already on the FPGA Where we load a bunch of data to the FPGA for processing, performance is fast once loaded, but data in/out of the FPGA is less efficient Having said that, I am aware 8 years ago of another company that developed a complete matching engine on FPGA They claimed 1m transactions per second But turned out they had no functionality, only price/time matching and it could not scale in size We also do complete checks for permissions, sessions, order types, cash, holdings, short sell, price collars etc which explain our desire They went bust before they had their first client
So yes, have investigated and it holds promise for “components” of the system (eg we found it very suited to reducing “network latency” by bypassing the TCP/IP stack with a custom message protocol with other machines (eg market database or web services) that cooperate) but not flexible enough for regular updates for an application of this size. Hope that explains it, Regards Rob > On 22 Nov 2019, at 3:52 am, Jimmy Gauvin <jimmy.gau...@gmail.com> wrote: > > @Rob Have you considered using FPGA boards to boost your throughput ? > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
