Transactional Memory, a distant dream?

28 03 2009

Have you ever felt the necessity for writing code which looks something like this?

atomic {
obj = msgNotProcessedMap.get(key);

Well, I have been following the evolution of both software transactional memory as well as hardware support for it. Back in 2006, when I first started my in-depth look at this new emerging area, I felt that there was a lot of promise and expected it to go mainstream pretty quick, but here we are, in 2009 now, and I have become a bit skeptical.

There is still a lot of ongoing research in this area and there are a few STM implementations available out there, but they are not really mainstream. As skeptical as I am, I still see some hope for it to be part of Java 8.0 or C# 4.0, yes, nothing short of native language support.

Sun Microsystems has come up with their Hybrid Transactional Memory (HyTM), which uses STM as much as possible and exploits the underlying hardware when it comes to optimistic concurrency control. Sun has confirmed it’s on track to ship its “Supernova” servers based on its “Rock” UltraSparc-RK processors before the end of 2009, so let us wait and see.

Without native language support, the effort that a programmer has to incur would be significant and in a way more error prone than what they are accustomed to currently (synchronized constructs and locks and mutexes).

The current benchmarks floating around for STM , doesn’t look that promising, even when running on multi- core processors, which are very prevalent nowadays. Cliff of Azul systems makes a point in his blog , that under heavy load, the performance is unpredictable. Another article on ACMQueue gives us a “not very optimistic” viewpoint.

But I do believe that Sun’s hybrid transactional memory approach will eliminate many of these known limitations of STM alone (inability to distinguish between transactional execution vs non-transactional execution, user code being able to see in-consistent state inside an in-complete transaction etc).

The only silver lining is this latest paper, published by Sun at the Fourteenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’09). It shows us that the folks at Sun have made great strides and the benchmark results sound very promising and makes us really believe that we are closer to mainstream adoption.

Time will tell.


And now, a memory appliance

16 02 2008

We now have an appliance for every component of the technology stack where high-performance and/or low latency is a requirement. I fumbled upon this new memory appliance from violin and was pretty impressed.

Their datasheet suggests that their appliance (Violin 1010) contains about 84 VIMM’s (Violin Intelligent Memory Module) which could have a combination of both DRAM and NAND flash memory. The DRAM module has a max of 6G and 6*84 gives us a max of 504G of memory. If one opts for a 64G flash memory, per VIMM, that gives us a max of 5TB.

The appliance itself could be hooked on to a server via the 10-20 Gbit/s PCI interface and the data is protected by both ECC and RAID. They claim to bring down the io latency to 3 microseconds, which is not a small feat. The device has the capacity to do 3 Million random I/O per second, per interface. The device also claims to be “green”, owing to its low power consumption.

What kind of applications benefit from using this device? Well, any application with large cache sizes, large datasets, applications which require extended memory, memory mapped files and so forth. How about if we can just dump all the database index files on this appliance (sort of a “RAM disk”), that could potentially boost the query performance by leaps and bounds? I also heard that they do have potential wall-street clients testing their devices in a stealth mode 😉

The benefits are definitely immense, but at what cost? Their site informs us that the starter kit will come for under $50K and comes with 20 6GB VIMM’s.

If you are too curious to take a look at this baby, go here.

Messaging at wire speed?

21 07 2007

My ex-boss mentioned about Tervela a while ago and I finally got a chance to learn more about it.

Coming from the Java world and having been exposed to JMS implementations like Tibco EMS, Websphere MQ and ActiveMQ; this came as a surprise to me and I would like to share this with everyone.

Tervela’s product is a messaging appliance which runs on the metal.

Its key features are as follows:

  • Message transformation and routing at the network level (layers 1-3). This will pretty much eliminate the network interrupts, which would otherwise overload the processor with interrupts for every packet that was received (thus increasing the latency). Besides this, the requirement for queuing of messages at the entire network stack, which is pretty common with software based messaging systems running at the application level messaging, is eliminated too.
  • Native instruction sets optimized for specific tasks and its pipelined architecture (no scheduling and interrupts so reduced latency).
  • No broadcast storms (a result of crybaby phenomenon). A typical scenario will be when a consumer is unable to catch up with the message load and thus drops some packets and requests for re-transmission. This is very common in multicast based communications and the re-transmitted message is eventually sent to all the consumers, instead of sending it to the consumer who requested it.
  • Custom routing algorithms eliminating filtering of the messages at the client level.

As you can see, the appliance mainly targets the financial verticals and will be a good fit for handling market data feeds at wire speeds (pub-sub domains). If you are looking for JMS semantics, look elsewhere 😉