It doesn't seem that long ago that I was programming in C on a 25MHz Compaq. At the time it was the fastest thing around, a few months later and the 33MHz version came out and was blisteringly fast. Compared to the PDP-11 and 4MHz 8080 and Z80s I started on who would ever need anything faster than this?

RelatedVendorContent
Rich Internet Applications Project Portal

Download Adobe AIR SDK - Drag your Rich Internet Applications from browser to desktop

Lean Software Development Governance, a whitepaper by Per Kroll and Scott Ambler

Download Adobe Flex - free open source framework for building rich web apps on Flash

Open Source SOA eKit - Articles, Webinars, Whitepapers
At the time we were leading edge, we gave the banks a few seconds advantage over the competition and that made them serious money, this was the "Big Bang" days when the stock markets opened up. It's worth noting that the network was so slow that you could visible see the difference between updates from one machine and another, this created arguments between traders as they wanted to be closer to the start of the network ring, still this was progress over the RS-232 "network" we used before.

Over the coming years I was paid to upgrade other dealing room systems to compete with the first ones I'd worked on, each time we went faster and faster. Not just because of Moore's law but we'd also learnt lessons in how to and how not to design high performance trading systems. Interestingly one of the reasons C++ won over Objective C on the trading floor was because you could hack C++, Objective C was too object oriented and that slowed things down, both C++ and Objective C were great languages. The pressure to compete was so great that we even rolled out Windows NT 4 beta onto a live dealing room, that was great for my CV (resume) when it came to Windows NT work in the late 90s.

A year or two later along came Java, at the start it was a novelty language for making the pictures move on the web, a few years later that we started to see Java being used in production, the rest, as far was Java is concerned, is history.

By the late 90s it was unusual to see anything take more than a few hundred milliseconds and although most places were still using 10BaseT the faster dealing rooms had switched to 100BaseT or faster. The pressure to compete was still there and growing as the market became more and more global. As soon as the bank was over taken and became slower than average they had to re-invest to move back up the ladder. The cycle was anything from 3 to 7 years. Some banks took more risk than others and could jump further up the ladder thus extending the cycle. Others were more conservative and waited for the brave to test out the technology before accepting it. This pattern of early adopters and late comers was very evident with J2EE. The "thought leaders" were playing with EJBs back in the late 90s,. Some of these early adopters became experts and went on to find new ways to overcome EJB's limiting restrictions, I'm sure you'll know the names of people like Rod Johnson, Cedric Buest, Tyler Jewell, Robin Roos, etc. These guys were trying to work with EJBs back in the 90s and wrote books on the subject a couple of years later. Out of this came Spring, Hibernate, JDO and a lot of other interesting alternatives. At the same time Sun were still trying to keep their baby alive, EJBs are still on life support.

So, grid, where are we with grid? Assembler, C, C++, Java, J2EE and now grid. The leading banks dropped a lot of their J2EE and moved into grid in the early-mid 2000s (the naughties). Today the vast majority of banks are running some sort of compute or data grid, I'm sure there must be a few but I don't know an investment bank without it. Like most technologies grid is a rather lose classification, some systems fall within the classification but other might seem better classified as clustering or distributed ESB groups.

If you look up Grid in Wikipedia there's no simple answer, it starts... "Grid computing is a phrase in distributed computing which can have several meanings" it goes on to describe a number of meanings. While something like SETI@home is technically grid, it's not the grid I'm addressing here, "my" grid is a network of servers or blades in one or a few local subnets. Technically anything from as few as 2 or 3 machines (also known as a cluster) to several thousand. It's safe to say grid is distributed computing, similar to parallel computing but there's a larger element of distributed processes.

An interesting reason why grid has taken off is the sideways move in Moore's law. In the past it was simply the clock speed or bus width that changed as we moved up the Moore's law graph. In the past we could write a little for-loop and expect it to run roughly twice as fast every 24 months, that's 1,000 times faster in 20 years. Over the last few years though this little for-loop will still be running at the same speed. Now clock speeds have peeked as distributing heat has become a major issue. We've already reached a brick wall at around 3-4GHz so to continue we've moved "sideways" into multi core. The difference today is that you can run three or more for-loops at the same time without slowing down the first one.

Multi-core has come at a cost though, we finally have to embrace concurrency, something many programmers have happily ignored to date. Concurrency isn't just a Java problem, most of the office applications we use today have had to be largely re-designed to make use of these extra cores in the same machine. You can't simply leave it to the operating system to guess how to parallelise your application and very few applications were written with this idea in mind back in the 80s, 90s and early 00s. More work for the programmers, more money, we're all happy.

Over the last few years and interestingly just a few weeks ago I have been asked to review architectures and code. The recent one was very typical in that it had been designed in modules and nicely de-coupled using queues. In this case the they had assumed several JVMs running on one or several machines linked via a queuing mechanism, not a bad idea on paper but in practice it runs like a dog. Every single call to another module has to be serialised and de-serialised over the network, local host in many cases but there's no optimisation for local calls. This was a problem experienced by the early EJB programmers, everything went through the remote interfaces even if it was running on the same machine, stateless to entity bean for example. Sun applied a "patch" by introducing the local interface. While fixing the remote problem it meant that the programmer had to dictate the topology of the deployment, it worked for performance but wasn't a great fix from a design point of view. Spring provided a much more elegant solution offering abstraction of location. By looking at the class loader it could determine whether the calculation should be local or remote.