Tag Archives: HPC

Challenges in Multi-Core Era – Part 3

Previously, I compared the performance of today’s popular operating systems with respect to multi-core processors.  In this final part to Challenges in Multi-Core Era, I’ll talk about the multi-core capabilities found in today’s programming languages and development tools.

The Programming Languages

When language architects were designing the foundations of the most popular programming languages, multi-core microprocessors were hidden in laboratories. Only high performance servers had access to multiprocessing systems. Just a few specialized workstations had more than one CPU installed. Therefore, C# and Java offered support for concurrency and multi-threading intended to offer more responsive applications. However, language architects didn’t design this support to optimize applications for future multi-core CPUs. Hence, nowadays, it is really difficult to optimize existing code to take advantage of multi-core CPUs using frameworks prepared for serial code.

In order to take full advantage of multi-core, the applications need a task-based design and a task-based programming. There is no silver bullet. So far, there is no way to optimize an application recompiling it without changes. Some developers expected this to happen. There is a great need for new designs, new programming techniques and new tools. The software development industry needs a new great paradigm shift.

Besides, developers need a framework capable of handling tasks. There are new programming languages, or new versions of older concepts, like functional programming. Functional programming makes it easier to code task-based designs and to split the work to be done in multiple independent tasks that could be run in parallel on multi-core CPUs.

There are many new programming languages with a great focus on functional programming, prepared to take full advantage of multi-core and to offer a great scalability. Just to mention a few:

  • Scala
  • Haskell. Yes, the one that has more than twenty years. Pure functional programming languages are back and they can be the future for parallel programming.
  • Microsoft Axum (formerly Maestro).
  • Microsoft F#.

However, do developers want to begin learning new programming languages? Most developers want to leverage their existing knowledge to move onto multi-core programming.

C++ and Fortran programmers had early access to parallel programming. Nowadays, these are the only programming languages that can take advantage of the full power offered by modern microprocessors. C++ is closer to the hardware. Hence, it allows many optimizations that aren’t available in any other programming language – apart from C and assembler. You can access all the vectorization capabilities from C++ and Fortran.

OpenMP has been offering a high quality multi-platform and open source shared-memory parallel programming API to C/C++ and Fortran for many years now. Besides, Intel Threading Building Blocks, also known as TBB, allows developers to express parallelism in C++ applications to take advantage of multi-core.

Message Passing Interface (MPI), is a language-independent communications protocol used to program parallel computers. You can use MPI to take advantage of multi-core on many programming languages. However, its main focus is to help develop applications to run on clusters and high performance computers.

Intel offers compilers and libraries optimized to take advantage of multi-core. However, you still require coding your applications considering new parallel designs. The usage of vectorization in their math libraries is a great plus point. There is an outstanding opportunity for new libraries and components optimized for multi-core and vectorization. Parallelism brings new opportunities to the software development industry.

There are new companies taking advantage of the need for multi-core optimizations, like Cilk Arts, offering its Cilk++ compiler. It is based on GCC and includes a modified compiler and debugger to simplify multi-core programming for Linux and Windows platforms.

Mac OS X’s Xcode development environment offers access to Grand Central Dispatch and OpenCL. OpenCL allows C programs to run in the GPU instead of loading the main CPU. The interest of developers in Xcode has really grown since multi-core and OpenCL.

C# and Java are evolving in order to offer developers new ways of expressing parallelism in their code. Indeed, they are changing many aspects that were designed for another world, the old single-core machines.  Some of these changes include new garbage collectors, new frameworks and features, new functional approaches and task-based programming capabilities.

Java 7 will offer the new fork-join framework, really optimized for multi-core.

C# 4.0 (Visual Studio 2010) will add task-based programming capabilities and parallelized LINQ (PLINQ). Besides, it will allow the possibility to manage the desired degrees of parallelism.

Furthermore, there are new DSLs (Domain Specific Languages) to add parallel programming capabilities to existing high-level languages. For example, GParallelizer adds nice parallel programming capabilities to Groovy.

Most modern programming languages are evolving or adding inter-operatibility capabilities with other languages to favor multi-core programming.

However, don’t forget about vectorization. Mono, a free and open source .Net compiler, offers access to SSE3 and SSE4 for C# developers.

A few years ago, concurrency was about threads. Now, experts are talking about tasks and fibers. Why? Because in order to develop an application using a task based approach, threads are too heavy. Tasks and fibers are lightweight concurrency elements, much lighter than threads. They allow developers to implement complex task-based designs without the complexities of threads.

Ruby 1.9 added fibers and it simplify the creation of pipelines. Pipelines take great advantage of Hyper-Threading combined with multi-core.

If you want to go parallel, follow James Reinders’ eight key rules for multi-core programming. You can apply them to any combination of programming language, framework, compiler and virtual machine.

Java 7 and .Net 4 will not offer framework support for vectorization (SIMD instructions). SIMD has been there since Pentium MMX microprocessor.  This decision doesn’t make sense especially considering that there is a huge market for smart professionals in the new parallelism age.

The New Tools

A well-known proverb says “A good workman is known by his tools”.

A parallelized application requires new debugging and testing techniques. You need to catch potential bugs introduced by concurrency.

Intel has been offering tools for High Performance Computing and parallelism for many years now. A few weeks ago, Intel launched one of the most complete parallel toolkits for C/C++ developers, Intel Parallel Studio. Among many other features, it helps developers to compile applications tuned for multi-core CPUs and to find concurrency specific bugs and bottlenecks. You should expect to see more tools like this coming on the next quarters.

Visual Studio 2010 will add enhanced multi-monitor support capabilities. You’ll need more than one monitor in order to debug applications running with a task-based approach. It will also add task-based debugging capabilities. However, Visual Studio 2010 has recently entered Beta 1. Therefore, if you want to develop an application using a task-based approach using C# 3.0, you still have to work with threads. Visual Studio 2008 offers nice multithreading debugging capabilities.

Most IDEs are changing to offer new task-based programming, debugging and testing capabilities. You have to test parallelized applications on multi-core CPUs. Many bugs aren’t going to appear when running them on single-core CPUs.

There are many free tools to help you in the multi-core jungle. You can monitor your applications and test their concurrency efficiency using Process Explorer and Intel Concurrency Checker.  If you use these tools to check commercial software, you’ll be able to see the need for new multi-core aware developers. Besides, you’ll see a lot of opportunities in the multi-core age.

By the way, multi-core programming has a high quality weekly talk show lead by Intel experts, Parallel Programming Talk.

Summary

While the old free lunch is over, the industry is reshaping itself to take advantage of the new microprocessors architectures of today and tomorrow.

Hardware will continue to advance and offer more parallel processing capabilities, even though the software industry is moving more slowly than expected.

Bottom line is that multi-core seems to be a really sustainable competitive advantage that requires a great paradigm shift from developers throughout the software lifecycle. There is light at the end of the tunnel. Are you ready to reach it?

About the author: Gaston Hillar has more than 15 years of experience in IT consulting, IT product development, IT management, embedded systems and computer electronics. He is actively researching about parallel programming, multiprocessor and multicore since 1997. He is the author of more than 40 books about computer science and electronics.

Gaston is currently focused on tackling the multicore revolution, researching about new technologies and working as an independent IT consultant, and a freelance author. He contributes with Dr Dobb’s Parallel Programming Portal, http://www.go-parallel and is a guest blogger at Intel Software Network http://software.intel.com.

Gaston holds a Bachelor degree in Computer Science and an MBA.You can find him in http://csharpmulticore.blogspot.com and http://software.intel.com/en-us/profile/417051/

Tagged , , ,

Challenges in Multi-Core Era – Part 2

Previously I talked about the evolution of microprocessors and specialized hardware since the wide-spread adoption of multi-core began a few years ago.  In this second part to Challenges in Multi-Core Era, I’ll compare the multi-core capabilities across today’s popular operating systems.

The Operating Systems

No matter the version, Mac OS always had a great advantage over any other desktop operating system. It knows exactly the underlying hardware because it is designed for running on Mac’s certified hardware only. You can run it on different hardware, at your own risk.  The same company develops the computers and the operating system. Leaving its great innovation aside, this is its great secret. For this reason, it can be tuned to take full advantage of specific hardware. For example, Mac OS X’s latest versions running over Intel microprocessors take advantage of vectorization, they use SSE (Streaming SIMD Extensions) and SSE2. In fact, Apple has been promoting vectorization and SIMD (Single Instruction Multiple Data) instructions in its Developer Connection Website.

However, Mac OS X Snow Leopard is giving another great step, offering Grand Central Dispatch.  Nonetheless, there is a big problem. There are too few developers working with specific Mac developer tools. Mac is also going to the 64-bits arena.

FreeBSD is one of the free and open source operating systems that always offered great features when working with multiprocessor systems. FreeBSD 7 works great with multi-core CPUs as well. Therefore, many high-performance servers around the world trust in FreeBSD’s scheduler.

The key is the operating system scheduler.  It is responsible for distributing the physical and logical processing cores, and assigning processing time to each concurrent thread.  It performs a really complex task.  For example, an operating system running over an Intel Core i7 CPU has eight logical processing cores (it can run eight hardware threads concurrently), but four physical cores. It has to distribute dozens of threads on time-slices available from eight logical cores. Thus, the scheduler efficiency impacts on the application’s performance. An inefficient scheduler could ruin a highly parallelized application’s performance.

Linux works great with multi-core CPUs, FreeBSD works better , but Linux does a great job. However, many desktop applications running on Linux GUIs aren’t optimized to take full advantage of multi-core. Nevertheless, Linux running as a Web server in a classic LAMP configuration is really fined tuned for multi-core.  Free Linux versions have a great advantage on the multi-core world as they don’t limit the number of cores using expensive licenses. Therefore, you can upgrade your desktop or server without needing to worry about the number of cores supported by your operating system license.

Both FreeBSD and Linux have a great advantage over Mac and Windows, most new deployments using these operating systems are using the 64-bits versions. Applications running in 64-bits offer more scalability than their 32-bits counterparts.  Parallel algorithms require more memory than serial ones. Most operating systems running in 32-bits can only address 4 GiB. There are some techniques to work with more memory even in 32-bits. However, they reduce the memory access performance.

4 GiB could seem a lot of memory. Nevertheless, as the memory map is a bit complex, you need some spaces for other purposes, like writing data to the video memory and other buffers. Hence, the operating system cannot access the whole 4 GiB of main memory. Furthermore, some operating systems limit the maximum memory addressable by an application in 32-bits mode (2 GiB in Windows standard configurations). Again, there are some techniques to work with more memory for the applications.

Whilst working with large images, videos and databases, these limits could be a great problem to add scalability. More cores mean more processes, more threads, more tasks or more fibers. A 2 GiB memory limit for a single process could mean a great I/O bottleneck.

Hence, working with 64-bits is a great step ahead. You have the same driver problems in both 32-bits and 64-bits Linux. Thus, you can install 64-bits Linux without worrying about additional problems. Working with 64-bits, you can scale as the number of cores increase without worrying about memory problems. Of course, you do have to worry about available physical memory. However, that’s another problem.

FreeBSD and Linux schedulers already offer an excellent support for NUMA. However, you may see nice improvements in future kernel versions. The idea is simple, the more the number of cores, the more optimizations required for an efficient scheduler.

Now, let’s move to Windows wonderland. Windows has a great disadvantage; each version offers different capabilities related to multi-core. You should check the maximum number of cores and the maximum memory supported by each Windows version. This doesn’t mean that Windows newest versions aren’t capable of handling multi-core CPUs. The problem is that they have different licenses and prices.

If you want scalability, you shouldn’t consider 32-bits versions anymore. Windows 2008 Server R2 and Windows 7 will support up to 256 logical processor cores. Nowadays, 256 logical cores seems a huge number. However, an Intel Core i7 is a quad-core CPU, but it offers eight logical cores (2 logical cores per physical core, 2 x 4 = 8). New CPUs with 8 physical cores are around the corner. Besides, they will offer 16 logical cores (2 logical cores per physical core, 2 x 8 = 16). Hence, you will see 16 graphs in your CPU activity monitor. An operating system offering support up to 256 logical cores really makes sense for the forthcoming years.

Despite being criticized everywhere, Windows Vista offered nice scheduler optimizations for multi-core. Windows 2008 Server R2 and Windows 7 will offer support for NUMA in their 64-bits versions. However, you must use the new functions to take full advantage of NUMA capabilities.

No matter the operating system, the applications must be prepared to take advantage of multi-core CPUs.
The operating systems are adding multi-core optimizations. However, except from Mac OS X, most applications running on the operating system take advantage of neither multi-core nor vectorization. I really cannot understand this.

I do believe it is time to learn from Mac OS X. For example, Windows 7 should offer a special version, let’s call it 7 Duo. 7 Duo could require at least a dual-core CPU with SSE2. So, you wouldn’t be able to run 7 Duo on older machines. If you have newer hardware, you’d buy and install 7 Duo. The operating system would load much faser, taking full advantage of your modern hardware. Your favorite Web browser should take advantage of multi-core and vectorization when parsing HTML or XML. Check this white paper, Parallelizing the Web Browser.

The great problem with PCs (x86 family) is the backward compatibility. It’s been an incredible advantage over the last decades. However, it is time to take advantage of modern hardware establishing baselines.
The same happens with Linux. I’d love to install an Ubuntu Duo on my notebook.

The operating systems are really crucial to tackle the multi-core revolution. Their schedulers are very important to transform multi-core power into application performance. Vectorization and SIMD is also important and most applications are not using it. It seems logical to develop new operating system versions designed to take full advantage of really modern hardware. They would add real value to your notebooks, desktop, workstations and servers.

Click here for part 3 where I compare the new capabilities of programming languages and development tools with respect to multi-core processors.

About the author: Gaston Hillar has more than 15 years of experience in IT consulting, IT product development, IT management, embedded systems and computer electronics. He is actively researching about parallel programming, multiprocessor and multicore since 1997. He is the author of more than 40 books about computer science and electronics.

Gaston is currently focused on tackling the multicore revolution, researching about new technologies and working as an independent IT consultant, and a freelance author. He contributes with Dr Dobb’s Parallel Programming Portal, http://www.go-parallel and is a guest blogger at Intel Software Network http://software.intel.com.

Gaston holds a Bachelor degree in Computer Science and an MBA.You can find him in http://csharpmulticore.blogspot.com and http://software.intel.com/en-us/profile/417051/

Tagged , , , ,

Challenges in Multi-Core Era – Part 1

A few years ago, in 2005, Herb Sutter published an article in Dr. Dobb’s Journal , “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software”. He talked about the need to start developing software considering concurrency to fully exploit continuing exponential microprocessors throughput gains.

Here we are in year 2009 – more than four years after Sutter’s article publication. What’s going on? How are we doing? How did the industry evolve to tackle the multi-core revolution?

In this three part series, we’ll answer these questions by exploring the recent multi-core inspired evolution of components throughout the application stack, including microprocessors, operating systems and development platforms.

The New Microprocessors

Microprocessor manufacturers are adding processing cores. Most machines today have at least a dual-core CPU. However, quad-core CPUs are quite popular on servers and advanced workstations. More cores are round the corner.

There is a new free lunch. If you have an application designed to take advantage of multi-core and multiprocessor systems, you will be able to scale as the number of cores increase.

Some people say multi-core wasn’t useful. You can take a look as this simple video. It runs four applications (processes) at the same time on a quad-core CPU. Each application runs in a different physical processing core, as shown in the CPU usage history real-time graph (it uses one independent graph per processing core). Hence, it takes nearly the same time to run four applications than to run just one. Running just one application takes 6 seconds. Running four applications takes 7 seconds. What you see is what you get. There are no tricks. Multi-core offers more processing power. It is really easy to test this. However, most of the software wasn’t developed to take advantage of these parallel architectures in single applications.

There is another simple video showing one application running on a quad-core CPU. The first time, it runs using a classic, old-fashioned serial programming model. Hence, it just uses one of the four cores available, as shown in the CPU usage history real-time graph. Then, the same application runs in a parallelized version, taking less time to do the same job.

In recent years, parallel hardware became the mainstream standard in most developed countries. The great problem is that the speed of hardware evolution went much faster than the speed of software evolution, resulting in a large gap between the two. The microprocessors added new features that software developers didn’t exploit. Why did this happen? Because it was very complex to accomplish it. By the way, it’s still a complex task. I’ll get back to this later.

However, the most widespread model for multiprocessor support, SMP (Symmetric Multi-Processor) leaves the pole position to NUMA (Non-Uniform Memory Access). On the one hand, with SMP, the processor bus becomes a limitation to future scalability because each processor has equal access to memory and I/O. On the other hand, with NUMA, each processor gains access to the memory it is close to faster than to the memory that is farther away. NUMA offers better scalability when the number of processors is more than four.

With NUMA, computers have more than one system bus. A certain set of processors uses each available system bus. Hence, each set of processors can access its own memory and its own I/O channels. They are still capable of accessing the memory owned by the other sets of processors, with appropriate coordination schemes. However, it is obviously more expensive to access the memory owned by the other sets of processors (foreign NUMA nodes) than to work with the memory accessed by the local system bus (the NUMA node own memory).

Therefore, NUMA hardware requires different kinds of optimizations. The applications have to be aware of NUMA hardware and its configurations. Hence, they can run concurrent tasks and threads that have to access similar memory positions in the same NUMA node. The applications must avoid expensive memory accesses and they have to favor concurrency taking into account the memory needs.

A new free lunch offers manycore scalability. Expect more cores coming in the next months and years. Learn about the new microprocessors. Be aware of NUMA and optimize your applications for these new powerful architectures.

The New Specialized Hardware

On the one hand, we have a lot of software that is not taking full advantage of the available hardware power. On the other hand, there are many manufacturers developing additional hardware to offload processing from the main CPU. Does this make sense?

This means that you are wasting watts all the time because you’re using obsolete software. In order to solve this problem, you have to add additional, expensive hardware to free CPU cycles. But, you aren’t using entire cores.

TCP/IP Offload Engine (TOE) uses a more powerful NIC (Network Interface Card) or HBA (Host Bus Adapter) microprocessor to process TCP/IP over Ethernet in dedicated hardware. This technique eliminates the need to process TCP/IP via software running over the operating system and consuming cycles from the main CPU. It sounds really attractive, especially when working with 10 Gigabit ethernet and iSCSI.

CPUs are adding additional cores. So far, modern software is not taking full advantage of these additional cores. However, you still need new specialized hardware to handle the network I/O… Most drivers don’t even take advantage of old parallel processing capabilities based on SIMD (Single Instruction Multiple Data) offered since Pentium MMX arrival. TCP/IP offload Engine is a great idea. However, if I own a quad-core CPU with outstanding vectorization capabilities, SSE4.2 and previous versions, I’d love my TCP/IP stack to take advantage of it.

Vectorization based on SIMD allows a single CPU instruction to process multiple complex data at the same time. Thus, using them, it speeds up the execution time of complex algorithms many times. For example, an encryption algorithm requiring thousands of CPU cycles could perform the same results requiring less than a quarter of these CPU cycles using vectorization instructions.

Something pretty similar happens with games. Games are always asking for new GPUs. However, most games take advantage of neither multi-core nor vectorization capabilities offered by modern CPUs. I don’t want to buy new hardware because of software inefficiencies. Do you?

Modern GPUs (Graphics Processing Units) are really very powerful and they offer an outstanding processing power. There are many standards to allow software developers to use these GPUs as a CPU, like CUDA and OpenCL. They allow the possibility to run general purpose code on the GPU to release the main CPU from this load. It sounds really attractive. However, again, most software does not take full advantage of multi-core. It seems rather difficult to see commercial and mainstream software considering the possibilities offered by these modern and quite expensive GPUs. Most modern notebooks don’t offer these GPUs. Therefore, I see many limitations to this technique.

Before considering these great but limited capabilities, it seems logical to exploit the main CPU’s full processing capabilities. Most modern notebooks offer dual-core CPUs.

Specialized hardware is very interesting indeed. However, it isn’t available in every modern computer. It seems logical to develop software that takes full advantage of all the power and instruction sets offered by modern multi-core CPUs before adding more specialized and expensive hardware.

In part two of Challenges in Multi-Core Era, I’ll compare the multi-core capabilities of the latest operating systems.

About the author: Gaston Hillar has more than 15 years of experience in IT consulting, IT product development, IT management, embedded systems and computer electronics. He is actively researching about parallel programming, multiprocessor and multicore since 1997. He is the author of more than 40 books about computer science and electronics.

Gaston is currently focused on tackling the multicore revolution, researching about new technologies and working as an independent IT consultant, and a freelance author. He contributes with Dr Dobb’s Parallel Programming Portal, http://www.go-parallel and is a guest blogger at Intel Software Network http://software.intel.com.

Gaston holds a Bachelor degree in Computer Science and an MBA.You can find him in http://csharpmulticore.blogspot.com and http://software.intel.com/en-us/profile/417051/

Tagged , , ,

Uncovering Time in the Financial Markets – Time of the Trade

Previously I listed examples of how small intervals of time are deeply rooted in modern electronic trading strategies and regulations. Although the process of buying and selling stocks, whether in a manual environment involving specialists on the floor of a major equities exchange, or in an automated environment involving two systems with complex decision rules for valuating and purchasing stocks, has significantly changed over the centuries, the outcome remains the same – to enable the exchange of shares (equity) of ownership, for a particular company, between a buyer and a seller at some agreed upon price, this is fundamentally the process of trading in the equities markets.

It is within this process that regulators and trading organizations have become incredibly sensitive to even the smallest measures of time. The trading process can be broken down into the following steps. First is the specification of the order details (eg. price, symbol, size) from the buyer or seller followed by the acknowledgment of that order by a trading venue such as an exchange, ECN, or broker dealer. The order is then optionally routed to one or more venues that will execute the trade by matching it with a counterparty order before reporting the details of the execution back to a trade-reporting facility.

Vendors, regulators, data providers, and marketers of trading technology mislead when quoting microsecond, millisecond or any temporal measures by failing to describe the inherent inaccuracies of such measures in a distributed systems context. Because the trade process described above is fundamentally distributed across machines whose concept of time is largely subjective, a measured interval of one second between any nodes in this trading process may amount to significantly more or less than one second when measured on the scale of an atomic clock.

To ensure that regulatory or strategic measures of time, are in fact accurate, it is necessary to create a single global understanding of time between related machines. Clock synchronization refers to the problems caused by clock skew and jitter, and the solutions that enable a common, more accurate understanding of time, albeit with built in margins of error.

Tagged ,

Uncovering Time in the Financial Markets – Law & Profit

As I mentioned, the measure of small intervals of time, in the financial markets, is deeply rooted in both modern regulatory policies as well as electronic trading strategies. The SEC, FINRA and other industry regulators have innovated their way towards temporal constraints that reflect the lightening speed of today’s electronic trading landscape. On the business side, the continuing arms-race towards low-latency algo trading platforms is built on the premise that profit comes to those who discover and trade the best available price first. With milliseconds and now microseconds separating competing trade requests, industry participants are paying huge premiums for technology that promises even the smallest temporal improvements over competitor offerings.

Regulatory Time

Here is just a small sampling of the temporal references found in today’s electronic-trading compliance requirements:

FINRA Trade Reporting:

…transactions that are subject to NASD Rules 6130(g) and 6130 (c) and also required pursuant to an NASD trade reporting rule to be reported within 90 seconds.

SEC Regulation NMS Self-Help:

If a market repeatedly does not respond within one second or less, market participants may exercise “self-help” and avoid that market for purposes of the Order Protection Rule.

OATS Reporting

…Order Sent Timestamp (date and time) is within +/- 3 seconds

SEC Regulation NMS Intermarket Sweep Order Workflow

Answer: Yes, waiting one full second to route a new ISO to an unchanged price at a trading center would qualify as a reasonable policy and procedure under Rule 611(a)(1) to prevent trade-throughs.

SEC Regulation NMS – Flickering Quote Exemption

In addition, Rule 611 provides exceptions for the quotations of trading centers experiencing, among other things, a material delay in providing a response to incoming orders and for flickering quotations with prices that have been displayed for less than one second.

SEC Regulation NMS – 3 Second Quote Window

To eliminate false trade-throughs, the staff calculated trade-through rates using a 3-second window – a reference price must have been displayed one second before a trade and still have been displayed one second after a trade.

At best these temporal references serve as explicit requirements that drive the necessary software decisions to stay compliant. However, interpreting these time-intervals without considering the distributed nature of the trade-lifecycle and the ambiguity of time in this context, can lead to misinterpretation and confusion.

Profit Time

Similarly, on the business side, there is an unprecedented awareness and profit-sensitivity to small time intervals. Here are some quotes from industry stakeholders:

Chicago Mercantile Exchange

“Traders using CME Globex demand serious speed. If the network is even a few milliseconds slower than 40 milliseconds of response time, they don’t hesitate to notify CME.”

Philadelphia Stock Exchange

“The standard now is sub-one millisecond,” said Philadelphia Stock Exchange CEO Sandy Frucher. “If you get faster than sub-one millisecond you are trading ahead.”

Investment Banks

“Firms are turning to electronic trading, in part because a 1-millisecond advantage in trading applications can be worth millions of dollars a year to a major brokerage firm.”

The TABB Group

“For US equity electronic trading brokerage, handling the speed of the market is of critical importance because latency impedes a broker’s ability to provide best execution. In 2008, 16% of all US institutional equity commissions are exposed to latency risk, totaling $2B in revenue. As in the Indy 500, the value of time for a trading desk is decidedly non-linear. TABB Group estimates that if a broker’s electronic trading platform is 5 milliseconds behind the competition, it could lose at least 1% of its flow; that’s $4 million in revenues per millisecond. Up to 10 milliseconds of latency could result in a 10% drop in revenues. From there it gets worse. If a broker is 100 milliseconds slower than the fastest broker, it may as well shut down its FIX engine and become a floor broker.”

Brokerage House

“Arbitrage trading is critically dependent on trading off valid prices and getting the orders in as fast as possible without overwhelming the exchange gateway and so latency on the market data stream and order entry gateway capacity is a big issue.”

Chi-X/TransactTools Press Release

“TransactTools’ standard benchmark tests found that over 95 percent of messages sent to Chi-X were responded to in an average of 10 milliseconds…with the fastest response time being four milliseconds.  For high volume throughput testing, in which five million messages were generated in total, Chi-X maintained an average roundtrip latency of 18 milliseconds while handling 16,000 messages per second.  Chi-X’s internal latency, which is a measure of the system’s ability to process messages in its core rather than the roundtrip measurement, was measured by Instinet Chi-X at 890 microseconds, or less than one millisecond.”

Millisecond Marketing

With the industry’s increasing awareness to small time intervals, marketers are playing their temporal cards. Vendors of market data distribution platforms, high-performance messaging solutions, complex event processing and many of the other high-performance technologies on Wall Street can also misinform and sometimes disinform the capabilities of their offerings with respect to time and performance. Suggesting a vendor’s market data distribution technology offers millisecond or microsecond improvements over a competitors offering, without describing the testing context and particularly how clocks were synchronized in reaching the final measure is unethical. As high-performance trading technologies continue to commoditize, the pressure to show even the most minute temporal improvements will only increase.

Next I’ll describe the lifecycle of a trade request, and why measures of time in this context are inherently innacurate.

Tagged ,

Uncovering Time in the Financial Markets

In this era of low-latency, high-performance electronic and algorithmic trading, vendors, regulators and business strategist continue to misinform and sometimes disinform industry participants with references to time. Vendors, for example, can selectively manipulate their marketing campaigns to suggest dubious sub-millisecond advantages over competitor technologies. Regulators, who continue their ambitious drive to innovate for the twenty-first century industry changes, may get a bit ahead of themselves when not providing the appropriate clock synchronization context in quoting their temporal constraints. Investment banks and brokerage firms continue to preach the million dollar advantages of millisecond improvements in their trade lifecycle.

The widespread industry shifts in the financial markets have created an unprecedented and collective awareness and sensitivity to small intervals of time. The fact is that despite driving both regulatory and strategic policies, the quoted measure of these intervals remains another piece of misinformation and sometimes disinformation that misleads and confuses industry stakeholders.

In this three part series, I’ll first show examples of time’s importance from a financial market regulatory and strategic perspective. Second I’ll show exactly how and why this time is misinterpreted. Finally i’ll talk about how clock synchronization techniques can be used to better rationalize the measure of time across system boundaries.

Tagged , , , ,

Designing for Performance on Wall Street – The Storage Dilemma

What and How Much?

Prediction, transparency and compliance all come with a heavy storage price these days. Electronic trading applications, and specifically the algorithms that drive them, depend on access to high-quality historical data both at runtime and design time when the data is mined in an effort to identify new patterns which can drive future trading strategies. Risk analysis, a discipline that attempts to valuate a firm’s investments in real time, relies on the ability to detect and predict patterns found by mining the same high-quality historical data. The SEC’s Regulation NMS, which requires that trades execute at the best available price mandates that firm’s retain records that show a history of trading at the best price. These records should include both the trades the firm executed, as well as the stock quotes that inspired them.

Previously I showed how electronic trading, regulation and innovation have indirectly resulted in the bandwidth problem and the need for speed. The storage dilemma is closely related. It is a dilemma because what to store, how much of it to store, and how to store it is an inexact science which can have enormous consequences on storage requirements. It can potentially cost 60GB a day (January 2008 conditions) to store each and every level-1 quote, disseminated on a daily basis from any of the ECNs, exchanges, and OTC markets. Knowing how to resolve the storage dilemma requires a balanced view of constraints in the problem and solution domains as well as a little bit of luck.

Compliance History

The storage dilemma was initially and in many ways continues to be driven by regulatory compliance. The US financial accounting scandals, that spilled into the start of this century, and resulting debacle, as well as the terrorist attacks in 2001 led regulators to write and in some cases rewrite the rules surrounding digital communications (voice, chat, email) within and between firms, and the need to retain the history trail of communication, for all individuals within a firm, for a predetermined period of time. The general regulations I’m referring to here include Sarbanes-Oxley Act of 2002, NASD 3010 & 3110, NYSE 342/440/472, SEC Rule 17a-4.

These regulations are as ambitious as the technological innovations that are needed to support them. Requiring that firms store all digital communications for a period of three years, for example, is largely based on the fact that with today’s technology you can. From a regulatory standpoint the technology capacity and capability exists on paper, but from an implementation standpoint, it’s not so easy. For example, we can backup anything these days, but can you easily restore from that backup? The same applies to email archiving. Sure you can store all emails for all members of your organization as far back as you want, but when regulators come asking for specific email records dating back 5 years, the true test begins. Amazingly, and i say amazingly because compliance here is largely determined by the design and implementation of the storage/archival system, incredibly large fines are being issued for failure to comply, on the order of hundreds of millions of dollars.

The storage dilemma surrounding these regulatory requirements is further fueled by willing and paranoid compliance departments, whose job it is to ensure a firm’s compliance with all applicable regulations, and sometimes unwilling IT departments, who are fully aware of the financial, technological, and temporal constraints surrounding these ambitious regulations. You’re not supposed to meet halfway on these requirements, but there are many reasons to try to compromise. Finding a balance between the regulatory, financial, temporal and technological requirements is just one example of storage dilemma.

It Gets Worse

Electronic trading has introduced incredible efficiencies in the markets, resulting in lower per-order profit margins. Simultaneously, the structure of the securities themselves, think mortgaged-backed securities, credit default swaps, has become so complex it becomes almost impossible to valuate them. How can a firm design the most intelligent, empirically backed electronic trading algorithm, or the most sophisticated empirically backed risk analysis model? The answer is access to high-quality historical data. Deriving intelligence from the mining of market data is a key differentiator in the electronic trading and risk analysis space. When you add to this the exponentially increasing data volumes we’ve shown in the bandwidth problem, you have another example of the storage dilemma. There are no easy answers for which market data to store, and how much of it to store. The need is clear, and is even more clear if you consider that Regulation NMS requires that trading firms capture sufficient amounts of quote and trade data to show they are executing trades at the best prices across all market centers.

If you build it, they will saturate it…

As we’ve shown at the start of this series, the convergence of regulation, innovation and electronic trading have redefined the magnitude of problems and solutions in the capital markets. Technological innovation, however, is the primary driver. Just like mobile communication devices have inspired the increasing amounts of email and chat conversations between related and unrelated (i.e. junk mail) parties, innovations in technology have creatively inspired regulators, investors, brokers, investment banks, exchanges, hedge funds to stay ahead of their objectives.

Regulation NMS, in particular, implicitly addresses the sophistication of today’s technology, and shows that regulators can be as innovative as for-profit firms in demanding transparency and fairness. Algorithmic trading’s thirst for predictive intelligence is driven by the necessity to be accurate and fast, as we’ve shown in the need for speed. This transparency and prediction requires data, and if you thought email archiving was a lot, wait until you need to store and efficiently mine terabytes upon terabytes of market data information – assuming you’ve found the budget or technology to store it all.

Tagged ,

Designing for Performance on Wall Street – The Need For Speed

Collapsing Time

While the impact has already been enormous, history will show how the shift from floor-based specialist trading to electronic trading changed the way investors, specialists, investment banks, brokers, exchanges and other industry participants make their money. Wall Street as a whole is now firmly entrenched in this new electronic trading frontier and the barriers to entry have shifted from the human imperfections of floor based traders or specialists, to the high-speed, low latency capabilities of profit seeking electronic algorithms.

Low latency in the scope of electronic trading refers to the utilization of high-performance technology that collapses the time between price discovery (i.e. 100 shares of IBM are now available at $100.00) and the execution of orders (i.e. buy or sell) at the newly discovered price. Electronic trading has created a world where the lifecycle of price discovery to trade execution is on the order of single-digit milliseconds.

Time is Money

Previously, I talked about the bandwidth problem. Inability to handle the required bandwidth utilizations of modern market data feeds will certainly cause significant delays in this millisecond-sensitive trade lifecycle, resulting in lost profits. However, the single most important need that has resulted from the unanimous shift to electronic trading is the need for speed, where speed refers to the ability to “see” stock prices as quickly as they appear in the electronic marketplace and similarly the ability to immediately trade on that price before competitors do

Some of the low-latency design strategies or techniques exhibit the elegant characteristic of solving the bandwidth problem as well as the need for speed. For example, colocating your electronic trading algorithm in the same facility as an exchange’s matching engines (i.e. the systems that execute the buy/sell orders) will not only save your firm the wide-area network infrastructure required to feed market data to your trading algorithm, but will also minimize the propagation delays between market data sources and execution venues. Incredibly, some of these solutions, such as FAST compression, can theoretically address the bandwidth problem, the need for speed, and the storage dilemma.

Low-Latency Approaches

How does Wall Street solve the need for speed? Here are just some of the approaches used to minimize stock trading related delays:

Chip Level Multiprocessors (CMP)

When Intel’s microprocessors started melting because of excessive heat, the multi-core chip industry became mainstream. Smaller multiple cores on a single chip could now permit multi-threaded code to achieve true parallelism while collapsing the time it takes to complete processing tasks. Multi-core chips from Intel and AMD have a strong presence in the capital markets and can achieve remarkable performance as shown in SPEC benchmarks.

An emerging challenge on Wall Street is to deploy microprocessor architectures capable of scaling to the enormous processing required by risk-modeling and algorithmic-trading solutions. If one-core architectures encountered space and heat limitations which eventually lead to the introduction of multi-core architectures, what new limitations will emerge? The shared message bus found with existing multi-core processors is one such limitation as the number of cores multiply. Vendors, such as Tilera are innovating around these limitations and you can expect more to follow. Furthermore, evidence is building to support the notion that multi-core microprocessor architectures, and the threading model behind them are inherently flawed. Multi-core CPUs may provide near term flexibility for designers and engineers looking to tap more processing power from a single machine. Long term however, they may be doing more harm then good.

Concurrency

With multiple cores now in place, the software and hardware community are steadily catching up. For example, older versions of Microsoft’s Network Driver Interface Specification (NDIS) would limit protocol processing to a single CPU. NDIS 6.0 introduced a new feature called Receive Side Scaling (RSS) which enables message processing from the NIC to be distributed across the multiple cores on the host server.

As Herb Sutter explains in his paper “The Free Lunch is Over: A Fundamental turn Towards Concurrency in Software”, software applications will increasingly need to be concurrent if they want to exploit CPU throughput gains. The problem is that concurrency remains a challenge from an education and training perspective as described in David A. Patterson paper. Conceptually concurrency can drive the need for speed. The practice of this approach remains a challenging one.

Colocation

Colocation is a fascinating approach towards achieving low-latency, mainly because it reconfigures physical proximity between application stacks instead of relying on a sophisticated technology approach. We’ve already shown how it can minimize the bandwidth requirements for a firm’s algorithmic trading platforms, but its biggest accomplishment is to minimize the distance between electronic trading platforms and the systems that execute the trades. Organizations such as BT Radianz have armed their high-performance datacenters with the fastest, highest throughput technology on the planet. When coupled with colocated hosting services, these data centers provide the the lowest latency money can buy while opening up new opportunities to translate this value throughout the application stack starting at the NIC card and moving on up.

The Exchanges themselves, are also using colocation services as a way to attract customers and introduce new sources of revenue. For example, International Securities Exchange ISE, offers colocation services while promising 200 microsecond service levels.

Hardware Accelerators

Field Programmable Gate Arrays

The name says it all – an integrated circuit that can be customized for a specific solution domain. Specialized coprocessors have existed for years, handling floating point calculations, video processing and other processing intensive tasks. FPGA builds on this by offering design tools allow programmers to customize the behavior of the FPGA’s integrated circuit, usually through a high-level programming language which is then “compiled” into the board itself. An example of how FPGA boards are being deployed on wall street includes replacing software feed handlers, the components that read, transform and route market data feeds, with their FPGA equivalents. This approach results in higher throughput and lower latency because message processing is handled by the customized FPGA board, instead of the host CPU/OS, saving the precious cycles that would have been required for moving messages up the protocol stack and interrupting the kernel. ACTIV Fiancial, a leading vendor of a feed handling solution claims that the introduction of FPGA accelerators to their feed processing platform reduced the feed processing latency by a factor of ten while allowing them to reduce the servers required to process some US market data feeds from 12 servers, in the software based feed processing approach, to just one server in the FPGA accelerated approach.  Celoxica is another firm specializing in FPGA solutions for Wall Street’s electronic trading.  Celoxica’s hardware accelerated trading solution promises microsecond latency between host NIC and user application with support for throughput rates reaching 7 million messages per second.

TCP Offload Engine

The idea with TCP Offload Engines (TOE) is for the host operating system to offload processing of TCP messages to hardware located on the network interface card itself, thus decreasing CPU utilization while increasing outbound throughput.  Windows 2003 Server includes the Chimney Offload architecture which defines the hooks required for OEM and 3rd party hardware vendors to implement layer 1, 2, 3 and 4 of the OSI protocol stack in the NIC itself, before passing the message to the host operating system’s protocol handlers.  Similar examples of offload technology include TCP Segmentation Offload (TSO) or Generic Segmentation Offload (GSO) where the NIC handles the segmenting of large blocks of data into packets.

Network Processing Offload

Coming Soon

Kernal Bypass

Coming soon

High-Performance Interconnections (I/O)

Infiniband

From the Infiniband Trade Association website:

In 1999, two competing input/output (I/O) standards called Future I/O (developed by Compaq, IBM and Hewlett-Packard) and Next Generation I/O (developed by Intel, Microsoft and Sun) merged into a unified I/O standard called InfiniBand. InfiniBand is an industry-standard specification that defines an input/output architecture used to interconnect servers, communications infrastructure equipment, storage and embedded systems. InfiniBand is a true fabric architecture that leverages switched, point-to-point channels with data transfers up to 120 gigabits per second, both in chassis backplane applications as well as through external copper and optical fiber connections.

Infiniband technologies also exhibit the characteristic of solving multiple problems facing Wall Street today including bandwidth, latency, efficiency, reliability and data integrity. Visit the Voltaire website for a vendor specific look into the performance benefits of Infiniband on Wall Street.

Please check back in second quarter 2008 when The Techdoer Times presents a detailed look into the many existing and future applications of Infiniband technology.

Remote Direct Memory Access

RDMA is a zero-copy protocol specification for transferring data between memory modules of separate computers without involving either source or target operating sytem or CPU, resulting in low-latency and high-throughput computing.

Fibre Channel

Gigabit Ethernet (GbE) & 10 Gigabit Ethernet (10GbE)

AMD HyperTransport (Chip-level)

Intel Common System Interface (Chip-level)

Ethernet Virtual Private Line (EVPL) and Ethernet Virtual Connection (EVC)

Faster Compression

As we mentioned in the bandwidth problem, some firms are relying on innovations in compression as a way to minimize escalating bandwidth costs. FAST is an example of this but there’s more. In our previous postings on measuring the latency in messaging systems we explained how the different components of latency react to variations in packet size or transmission rates. Herein lies the potential latency improvements resulting from the adoption of FAST. FAST can potentially minimize packetization and serialization delays. It is true that the process of compressing messages requires additional CPU cycles and therefore adds to the application delay, however, depending on the nature of the solution, this additional delay may be offset by the savings that result from serializing significantly smaller sized packets onto the wire, potentially 80% smaller. FAST can be incredibly effective at bandwidth reduction and can potentially reduce end-to-end latency as well.

Messaging

Messaging technology has evolved greatly to the point where requirements for speed and reliability are no longer in conflict. Publish/Subscribe messaging paradigms can be supported with different levels of service quality, ensuring that latency-sensitive subscribers can forgo message recovery for the sake of speed, while data-completeness sensitive subscribers can rely on extremely fast message recovery built on top of layer 3 protocol and routing technologies such as UDP and Multicast. These real-time messaging technologies also ensure robustness and scalability across a number of downstream subscribers. Cases where slow subscribers begin to “scream” for message retransmission (aka. ‘crying-baby’) can be handled individually and gracefully by the messaging layer, ensuring uninterrupted service to other subscribers. Messaging technology vendors include:

Multicast Routing

As mentioned in the bandwidth problem, multicast routing technologies can potentially reduce latency in addition to bandwidth utilization. The latency play results from the fact that multicast packets are rejected or accepted at the Network Interface Card (NIC) level, and not the more CPU expensive kernel level.

Data Grids/Compute Grids

With the industry’s reliance on the timely evaluation of strategic trading and risk models comes the need to access and crunch large amounts of data efficiently. This reliance has spawned innovations in the form of data and compute grids which offer highly-resilient, scalable distributed processing infrastructure on demand for compute intensive as well as data intensive environments. Data grids, in particular, offer a high-performance, highly-resilient middle-tier data layer that sits on top of storage technologies and other information sources but offers ubiquitous data access to enterprise business processes. Key vendors or technologies in this space include the following:

  • Gigaspaces
  • Gemstone
  • Tangosol
  • Intersystems
  • Memcache
  • DataSynapse
  • Terracotta
  • Collapsing Distributed Processing

    Yet another approach to decreasing the overall end-to-end latency of messaging systems is to collapse the ends, which also minimizes the propagation delays. The closer each distributed processing node is to being within the same process of dependent nodes, the better the overall performance. The rise of Direct Market Access (DMA) approaches where firms connect directly to the exchanges and other providers of market data, instead of third party vendors of the data is an example of this. DMA alone spawned a new market data distribution industry with the net result being end-to-end latency for market data measuring in the low milliseconds, which for a while remained faster than the same data distributed by vendors such as Reuters and Bloomberg.

    Thus far we’ve shown how firms in the capital markets are confronting their bandwidth problem and need for speed. The third category of challenges is the Storage Dilemma facing these firms.

    Tagged , , , ,