So yesterday I wrote about the AIAX initiative, specifically how it’s the ontological underpinning of all the work we did at the ULISSESProject.org. That resulted in what we call the POM (something I’ll likely expound on in future postings) but now let’s go on to the heart of the matter, the ARGOS Initiative.
ARGOS – The Heart of the ULISSES Project
ARGOS (Actively Routed Grid and Object Store) has its roots in what I think is one of the most unfortunate named projects in UC Berkeley’s history, BOINC (for those of you who don’t get it, that’s pronounced “Boink”). BOINK stands for Berkeley Open Infrastructure for Network Computing. I was fortunate enough on my first foray into industry to work with some of the talented individuals from BOINC, which first came to the world’s attention by a massive project done by SETI (the Search for Extraterrestrial Intelligence) in distributing and processing microwave messages. Interestingly, the widescale launch of BOINC via SETI@home (shipped via a screen saver app) corresponded with the launch of the movie version of Carl Sagan’s 1985 sci-fi book Contact starring Jodie Foster. Despite BOINC’s unfortunate name, it’s packaging in SETI@home in 1997 was an undisputed hit.
I remember downloading SETI@home and digging into its workings, little did I know that two years later I would be working with one of its key programmers adapting it to finance. That was fun, and important. The first hedge fund I went to, a launch from a proprietary trading desk, relied very explicitly on BOINC. I remember going over the specs of the workstations as we were preparing for launch, with the sellers wondering what we were going to do with so much firepower. Even the receptionist’s desk had an overbuilt machine. Why? Because we going to use BOIC to harness all that firepower to process high frequency trading data. That firm became the top volume trader in Europe.
CUDA (and GPUs) join the Stack
A few years later I found myself back at Berkeley where I started what as to become the ULISSES Project. It was when I was there that Hal Tolley, my closest collaborator, joined Vhayu as their lead engineer with the mandate to refactor and improve their entire stack. I knew the group well, founded by a couple of former Intel programmers, it provided high frequency trading tools for some of Wall Street’s biggest banks. To be clear, we knew them so well because we arbitraged their slowness. Because of this susceptibility I thought it would be an interesting place for Hal to further perfect the craft we’d started together by improving their systems so they wouldn’t be arbitraged by the big boys of the day like DE Shaw or Renaissance Technologies.
Everyday Hal and I met, lifted weights and strategized in the morning before he’d go on the long drive to Los Gatos (we lived in the East Bay). It was amazing and before long CPU distributed computing and bespoke FPGA usage was not enough. Hal suggested GPUs for some of the more “mundane tasks” and soon he started doing lunches with Nvidia engineers, driving from Los Gatos to Santa Clara and giving advice on how CUDA could be adapted to make it more useful to our purposes in high frequency finance. As far as I know, Hal and Vhayu were the first group to use GPUs for high frequency data processing, and it worked like a charm—so well that Vhayu as soon purchased by Thomson Reuters.
After the sale of Vhayu, Hal went back to Utah to take the reins as the lead engineer at a company based on the codebase he’d developed on a government project. I knew the call was coming because I’d hired him out of that government project, but it somehow seemed to never come. Finally, I brought it up one morning as we lifted weights, and he admitted he’d been sitting on the offer for months. I told him it was time, and we as we tearfully hugged, I told him we’d be there in Utah soon enough, which happened a few months later when I moved to Park City, Utah.
The Model of all Models
It was there when living in Park City that I began a project working with Hal and his father, a prominent statistician who’d been instrumental in the open-source framework that eventually became SAS. My project, put simply was to link all my various mathematical models together. As soon as I finished that project, I was contacted by a friend at Renaissance Technologies who told me that RenTech had just fired a professor from the University of Washington go who, for five years had tried to do what I had just finished, an ontological integration of financial models. That led me to several other discussions, and soon I found myself as a small part of a very big project. That project was the roll-out of IBM’s Watson in financial services.
IBM had sold exclusive rights to select groups. Those groups included Citigroup, Morgan Stanley, Bloomberg and a few select hedge funds (we were the ones that would test it all). As it turned out, I knew key people at three of the “sponsoring firms” and as a result I got a unique perspective on their efforts. Initially asking me to join their efforts, I demurred stating I preferred to work with smaller, more nimble hedge funds. They countered by introducing me to an emerging markets hedge fund, with which I partnered with Bloomberg, the brokers, and IBM on the development of the systems.
The Watson team had great hope that we’d be able to solve their problems, a hope manifested one night as the commercial lead told me he’d give me free processing if I gave his team use of my modeling system that I was using to organize the data. As good as that offer was, I politely refused telling him that “organizing the data is all it’s about.” Now, to be clear, Watson was not ever useful on that project, what was useful was CPLEX, IBM’s commercial optimizer, and to be even clearer, I hadn’t quite finished my great ontological project. I had built the prototype system that would eventually become AIAX.
When you’re trading billions of dollars and even a slight slip can put you out of business, almost perfect isn’t good enough. I’ve told my friends it’s like Formula 1 racing. Most people are used to driving cars off the lot, or occasionally something like a Ferrari or Masserati. When you drive a Formula 1, even a bump can kill you. This is not six sigma (99.99966% correct)—this is something that must always be correct. Otherwise, you’re out of work in a day. I often tell the story of the South Korean markets. One mistake you’re sanctioned, two you’re out (banned). In a situation like this an ontological framework that wasn’t quite perfected will kill you.
My Microsoft Solution to an IBM Problem
My solution back then was one I adopted from Microsoft’s partner for its mathematical compute. It was a high-level declarative modeling language specifically designed for optimization, simulation, and decision analytics. It sounded wonderful, but it was only good for toy problems. Once I got the prototype up, it choked hard. Not only was it not able to compute my problem at an appropriate speed, but it also would have cost more to calculate the result than I would have made from the trade (assuming I could get it in time). What resulted was simplification, and more simplification. To give you an idea, I started out with 30,000 firm models linked together with over 17 linked schedules per firm, and over 33 data vendors (some such as Bloomberg with hundreds of sources themselves). I cut it down to 3,000 models, linked together by 5 linked schedules, and a subset of the data. By my math the model was more than billions of times easier to calculate. As far as Microsoft’s partner? We ended up recoding in a mix of C, C++, Java, and R.
The funny thing is it worked exceptionally well, running for over 3 and half years it produced a Sharpe ratio over 3.5. That’s to be expected with high frequency trading, but the trick was this wasn’t traditional high frequency trading, it was “high complexity modeling” executed in a high frequency manner. The kicker was I looked at the results and did simulations of what we could achieve if could process the information faster with higher complexity. What I found was that for every order of magnitude I increased the complexity, it would improve performance. This is where I had a need that became an obsession, the need for speed.
As my NYC-based tech team stayed on the project, I went back to the University of Utah and started the Computational Finance Lab with the support of the Dell EMC open-source team (@code) that worked with the top hedge funds. What I thought would be a few years kept expanding. I first had to fix the ontology, which I did working with a team that had worked with Microsoft on the rollout of .NET, a team led by Bertrand Meyer. You think I would have learned from the earlier mishap with a Microsoft partner, but instead I leaned heavily in and got the new prototype up and running with Bertrand’s language Eiffel.
After that we leaned into the compute. We used SCOOP, Eiffel’s native concurrency model and by lifting concurrency to the architectural level of the type system, we were able to write parallel, multi-core applications using standard, clean object-oriented reasoning. We also used C and CUDA in the mix, and we got our project done, but it was too much bespoke code that from my and Hal’s perspective was bound together with “duct tape and bailing wire” like so many “academic projects.” The main problem is while we could now address the models, we still couldn’t process them fast enough.
The Need for Speed and Rust
At the time the ULISSES Project was housed in the Scientific Computing and Imaging Center (sci.utah.edu), otherwise known as SCI (pronounced “Ski” as in “skiing the slopes”). Back then many of the researchers from SCI were working closely with Nvidia, so it was only logical to concentrate on CUDA, but the problem was we couldn’t get past the bottleneck for complex compute where we needed a CPU. Then one day, Hal who was moonlighting with me as he worked with an Israeli/American tech start-up suggested Rust. He proposed that we could recode everything, all the Eiffel, C, C++ and CUDA in Rust and then utilize the LLVM to recompile. With these suggestions, something that I would now describe as “bulk routing of compute,” could now be much more precise.
Going with Rust that early had a lot of implications, chief among them returning to Portland (where I’m from), the global center of the Rust culture. I had learned to mathematically program from people here and as it turned out some of those very same people had been instrumental in fostering the Rust community. We made an early decision to be as much Rust as possible, pushing the bounds of what was possible. Coding all the tools in Rust allowed us to use those very tools in routing the compute, something we found allowed us to do things that had only been dreamed of back at the University of Utah.
Rust What? Rossinovich Answers.
When we started, every person that I mentioned Rust to in Seattle had to ask for an explanation, something I did so many times all these people in Seattle thought of me as “the Rust guy.” Then about a year ago everything changed. We were invited to a Washington State business meeting that the office of the Governor had set up. It was held in Microsoft’s Building 33, also known as the Executive Briefing Center (the EBC). It was there at the EBC as Mark Rossinovich, the CTO of Azure dropped the bomb. In front of those execs without press of fanfare he said Microsoft was “all in on Rust.” Everyone at the table and several nearby turned to look to me. Rossinovich, a respected voice, continued waxing eloquent about the virtues of Rust. As the people came up afterwards and asked me how I knew, I simply said “I didn’t, I had a partner that did.” Furthermore, I stated that while we were aware of the benefits Rossinovich cited, it was our need for speed in complex compute that had driven us to Rust.
Now, the ancillary benefit for this is that in the AI revolution there is an almost insatiable need for more processing power, something that our Rust based system can solve better than other bespoke solutions. Sure, if you plan on just using Nvidia chips, they have you covered with CUDA, but if you’re looking to use a larger set of the ever-expanding set of chips that will be increasingly used to cover our demand, our system has your AI needs covered.