The promise of speed in more CPU cores is a big one, and it may soon solve long-standing performance problems. From pricing complex assets to low-latency trade execution to fast and accurate risk analysis, performance gained from parallel computing can make the difference between taking the lead and falling behind.
But most financial institutions are unprepared. The question is no longer one of buying the right hardware or adopting the right development tools. The harsh reality is that the vast majority of developers, modelers, and managers do not have the knowledge and skills required for reliability and performance in a multi-core world. This is a major business problem that IT on its own cannot solve-it demands attention and direction from institutional leadership.
Software developers have enjoyed a free lunch on processor manufacturers' tab, according to Microsoft evangelist Herb Sutter, whose 2005 article proclaimed, The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software.
For many years, chip makers were able to deliver ever more powerful processors that would accelerate single-threaded code, and the best possible performance could be ensured by buying new hardware. But starting in 2005, clock speeds began to push up against an inherent ceiling imposed by practical, physical limits of semiconductor engineering. The focus in newer processors shifted to increasing the number of cores.
The problem for a developer of financial applications is that code written in a single-threaded model sees no performance benefit from the additional cores. On today's dual- and quad-core systems, that means serial applications use only one half or one quarter of available computing power. With the number of cores expected to double every 18 to 24 months, in a few years that fraction becomes vanishingly small. In order to see performance improvements in future applications, code will need to be written to explicitly target parallel execution.
Skills Shortage
So why can't IT organizations simply instruct their developers to go forth and write concurrent code? The answer, and the fundamental problem, is that parallel programming is hard. Grasping the interaction of multiple, concurrently running, logical threads requires a basic shift in mindset, and is conceptually much more difficult than understanding traditional sequential code. Very few programmers have the necessary knowledge to get parallelism right; the deficit of skills, particularly among quantitative developers, is an industry-wide phenomenon.
Furthermore, bringing an organization's skills up to speed with concurrent programming can be painful, as implementing parallelism without truly understanding it means stepping into a bug-ridden minefield. The non-deterministic nature of multi-threaded code means that ensuring quality is a much greater challenge.
Program behavior is not guaranteed to be identical from one run to the next, even on the same environment. Applications that work as expected in development and testing can suddenly, and expensively, go wrong well into production deployment, and the bugs responsible can be difficult to reproduce and diagnose-in short, a quality nightmare. Handling concurrency correctly from modeling through development and testing is a difficult task in applications of any significant complexity.
Existing parallel toolkits and technologies-such as OpenMP or MPI-are more suited to injecting concurrency into an application than to managing concurrency's consequences. Additionally, the low level of abstraction at which these toolkits operate means that a lot more work needs to be done to get a parallel implementation going, with a potentially devastating slowdown in time to market.
Other tools and languages in development promise to more simply aid parallelization. However, only a few of these tools have so far moved out of research into production, and the pace of change in hardware is, for the moment, moving faster than the pace of software innovation in parallel tools. More importantly, there is no way that a tool, entirely on its own, will be able to understand all the effects of code well enough to know how best to parallelize and how to do so safely. The developer will ultimately still need to bear some of this responsibility. The truth is there is no silver bullet. Concurrency needs to be considered from the very beginning of the development cycle. Organizations that do not institutionally embrace parallelism and its challenges will fall behind in the new hardware environment.
Gaining An Edge
All of the above, taken together, paints a bleak picture for the future of fast-performing, reliable financial applications. But there are steps that firms can take to make this transition less painful, and to turn it into an opportunity to gain a performance edge.
Firms should make targeting parallel execution an organization-wide priority. This means, above all, undertaking a large-scale effort to train personnel in concurrency. It will take time and several iterations of training. It should begin by cultivating or hiring a handful of concurrency gurus, who will be a crucial asset in effecting change organization-wide. They should then direct a training project to eventually encompass everyone involved in software development and quality.
Quantitative developers also need to consider the implications of a parallel implementation from the beginning of their modeling. A model's performance needs to be measured by speed and reliability on a multi-core platform, and not just its efficiency in sequential execution. It can be challenging enough to translate a quant model into production code without at the same time having to re-jigger it to support parallelism. A serial-minded quant might not even consider some promising parallel methods for which there is no serial analog, thus dismissing potential latent innovation out of hand.
Once an application is implemented, IT customers need to demand that rigorous stress testing be done in a real parallel environment that closely imitates the production environment, in order to identify synchronization bugs early on.
Firms must invest resources in tools, languages, and frameworks to help integrate concurrent development into the organization's practice. This means using frameworks from vendors that increase the level of abstraction of parallel programming and thereby reduce development time, complexity, and likelihood of concurrency bugs. Internally, proprietary frameworks to achieve these ends can give a further competitive edge. Firms should point their concurrency gurus to code that is shared across the enterprise to make that code more amenable to parallelism. If the level of parallel programming's abstraction can be raised to the point that quantitative developers can comfortably write parallel execution into their code from the start, then a great deal can be done to decrease the impedance mismatch between quants and IT professionals and cut the time from model conception to execution.
Along the same lines, certain programming languages and paradigms lend themselves more naturally to parallelism than others. In particular, the functional family of programming languages-which includes, among others, OCaml, Haskell, and F#-is particularly well-suited for writing applications for parallelization. The resurgence of industry interest in functional approaches is very well timed, and no coincidence. However, no language or technology will ever entirely relieve developers of the burden of identifying opportunities for parallelism and considering the consequences.
Only a small fraction of developers can credibly claim expertise in concurrency. IT recruiters should seek out and vigorously pursue those few. Keyword searches won't do. To the extent possible, firms should lean on the few concurrency experts in their organization to oversee the recruiting effort and broaden the base of expertise in the organization.
Ultimately, it may be up to the next generation of IT professionals to fill the skills gap. To that end, companies should communicate their priorities to academia, to encourage integrating and emphasizing concurrency in standard curricula, and to make it clear that skill in this area is valued. Partnerships with universities and sponsorships of academic programs in parallel computing can help to show commitment to taking on new talent in this area.
The growing need for parallel programming requires a fundamental rethinking of priorities in financial IT-now. Firms can start by orienting training, recruiting, and tools to address the challenges and opportunities of concurrency. If they do not start now, they risk being left behind.
Daniel Simon is a senior consultant at Lab49. -->