We introduce an extremely simple transformation that allows composition of a more scalable concurrent blocking multiset, or bag, from multiple “lanes” of a potentially less scalable underlying multiset. Our design disperses accesses over the various lanes, reducing contention and memory coherence hot spots. Implemented in Java, for instance, we construct a multiset from multiple lanes of java.util.concurrent.SynchronousQueue [9] that yields more than 8 times the aggregate throughput of a single instance of SynchronousQueue when run on a 64-way Sun Niagara-2 system with 16 producer threads and 16 consumer threads. We experimented with various queues from java.util.conconcurrent and found that in general a MultiLane form will outperform its underlying counterpart

On the Scala road, essentially I’m interested in an architecture that leverage HTML5 SPI, Socket.IO/node.js for the last mile, and Scala/akka on the backend.

I’ve briefly looked at Typesafe, and see the appropriate buzz words, but I’m currently not 100% clear if Play 2.0 will delivery from a Node.js perspective – maybe I’ve missed something on the sites. vasilrem offers a read on “node.js and Scala without mediators” and “Building COMET applications with Redis PubSub, Atmosphere and Akka”

Update: Slide available from here.

As part of this release we’ve also updated the preview version of LINQ to HPC, however, this will be the final preview and we do not plan to move forward with a production release.

Changing direction a little, GPU-Accelerated Databases Envisioned by IBM Patent is curious. Should we expect something similar from Microsoft and the SQL Server team, given the C++ AMP effort?

Which leads me to another thought. Looking at the C++ 11 features that are supported in VS 2011, one can’t help but think its a small list Maybe the VC++ team could do with a few more developers to help improve the C++ 11 feature list – I’m sure the WinRT and Win8 Metro teams could spare a few.

Finally, Scila has an interesting article; Characteristics of High-Frequency Trading by Fredrik Henrikson.

SciFinance has been developed over 17 years with the input and guidance of practitioners at top tier institutions worldwide. SciFinance provides you the ability to efficiently, economically and quickly develop your own pricing models at a fraction of the cost (in both time and money) of trying to develop them internally or via open source systems. For state-of-the art model development we are not aware of any open source system that can credibly claim to provide comparable capabilities, particularly in the critical area of calibration. SciFinance provides an exponential increase in your team’s model development capabilities at a fraction of the cost of a single financial engineer.

SciFinance automatically generates CUDA-enabled or OpenMP pricing model source code:

• CUDA-enabled pricing models
  • Monte Carlo pricing models: 30X-60X or more faster than serial code (single GPU, double precision)
  • PDE pricing models: 10X-35X or more faster than serial code (single GPU, double precision)
• OpenMP-compliant code executes in the multi-processor environment with nearly linear speed-up 3.9X faster than serial code on a quad-core PC, 22X on a 24 CPU workstation

SciFinance can be used for modeling a broad range of financial instruments including:

• Equity/FX derivatives
• Convertible bonds
• Interest rate/cross currency structures
• Energy/commodity derivatives
• Credit products
• Hybrid instruments

Our platform works with existing Hadoop clusters (Cloudera, MapR, Amazon EMR, etc.), and automatically turns the questions of business users into Hadoop jobs that synthesize and distill Hadoop datasets into dimensional and predictive dashboards, reports and insights. The system intelligently drives Hadoop to create and maintain ‘work products’ — highly compressed partial results that are refined at the click of a button to achieve subsecond report delivery, analytics overlay, and drilldown performance.

Opa is a programming language and a standard library comprising a database management system, a web server, a server-side framework, a client-side framework, a distribution middleware, a security audit tool, but without the complexity of deployment, administration, or impedance mismatch stemming from the use of many different technologies.

Josette Garcia summaries Opa’s advantages:

Probably the most notable difference with existing approaches is Opa’s integrity. The typical technology stack for web applications involves a web server, a DBMS, a client side language (typically, Javascript), a server side language with an accompanying web framework and a database query language (typically, SQL). Developers need not only to master all those components, but also to configure them and to make them communicate and work together, which often involves writing a lot of (boring and error-prone) boilerplate.

If Microsoft has given up on the CLR (BUILD/Win8 Metro), coupled with the likely hood of Silverlight 6 never seeing the light of day (Silverlight 5 is the end of the road in my view – and others), then maybe its time for Microsoft to consider leveraging C# as the Opa language for Azure

• NVIDIA Tesla GPUs Used by J.P. Morgan Run Risk Calculations in Minutes, Not Hours – if I am not mistakened, the Compute Backbone infrastructure leverages Platform Computing
• Deutsche Bank Autobahn(R) Equity Continues Low Latency Product Expansion in US

The investment bank worked with HPC solutions provider Maxeler Technologies to develop an application-led, HPC system based on Field-Programmable Gate Array (FPGA) technology that would allow it to run complex banking algorithms on its credit book faster.

The MIC architecture is viewed as Intel’s answer to GPUs from companies like Nvidia and Advanced Micro Devices, which pack hundreds of computing cores.

The eagerly awaited Intel Sandy Bridge processors have finally been announced (yesterday) and have received superb reviews. Read more at Macrumors, Engadget, TechReport, Intel, Intel Blogs (an older link). They feature, amongst overall improvements on all fronts, vastly improved graphics performance and battery life. These really can’t be found on the mac line soon enough. No doubt Apple will be touting 15 hours battery life with these if they’re touting 10 hours now. Mid year release, I reckon, along with Lion though I’d like to see those on the MacBook Air more than any other model as they are, without a doubt, best of breed now. To quote Intel on the most significant feature of this release in my opinion:

Improved Cores with Innovative Ring Interconnect: The 2nd generation Intel Core Processor family microarchitecture features vastly improved cores that are better connected with an innovative ring interconnect for improved data bandwidth, performance and power efficiency. The ring interconnect is a high bandwidth, low latency modular on-die system for connection between processor components for improved performance. The ring interconnect enables high speed and low latency communication between the upgraded processor cores, processor graphics, and other integrated components such as memory controller and display.

In particular, at my first engagement with HPC in 2007 – we found the hard way that some nodes were miss-configured and had no access to a file-share containing referential data; other nodes could not run the code due to not properly registered .NET/C#/F# dlls with the local GAC, etc. All of such problems and their proposed solutions were identified/verified by multiple runs followed by a root-cause analysis per failed nodes – it took a lot of time!
New HPC version out of the box provides tools (and extensibility to script custom ones via PowerShell) to solve these problems before start-of-business. For full load-down of features, etc. check out the HPC main site: microsoft.com/hpc

One other feature that stood out for me is HPC embrace of Network of Workstations (NOW) paradigm. It is long overdue for NOWs to solidify its foothold in the mainstream. Unfortunately, product presenters spend little time on the NOWs; from what I can tell, feature-set is still very simplistic. For example, there is a large body of studies on best techniques of identification of available resources – in 2008-R2 version there is no out-of-the-box way to share under-utilized boxes/cores, only idling ones; concept of “social contract” is unexplored, so as more advanced NOW features – for example, distributed RAM, which is ideal optimization for high-volume, small-size transaction systems. Presenter of SOA on HPC alluded to that bottleneck – transaction commit to disk on high-volume systems – while describing another HPC’s new feature – “durable sessions” (his suggestion – a reasonable compromise, was to use solid-state disks in-place of conventional spindle ones); those basically use MQ to cache task results in case task-owner disconnects from the broker before retrieving all the results.

For me the biggest take-away was a positive and a negative ones. Negative: HPC client-machines for NOW-style computing could only be Windows 7, not XP desktops – which puts a significant throttle on HPC+NOW adoption in enterprise where up to 70% of business desktops are still XP. Even if companies agree to initiate the upgrade programs today, the actual rollout will be at least a year away, or more. This is just an extra barrier HPC+NOW adopters would need to battle, selling cost of HPC to upper management.
The positive take-away – HPC provides Java API for communication between the broker and compute-nodes (CN) making possible situation where HPC provides all grid management and job scheduling functions (and cyclically brings online additional capacity from the NOW) while utilizing existing dedicated linux-based compute nodes.
That is a big win for HPC giving businesses ability to adopt HPC without the need to re-write all of the modeling software and reimaging of the existing grid nodes.

• jQuery- JavaScript Library Write less do more
• HTML5 Reset
• HTML5 Boilerplate
• Azure Throughput Analyzer
• Orleans: Microsoft’s next-generation programming model for the cloud
• Rx on the server, part 3 of n: Writing an observable to a stream

So lets get back to DryadLINQ. Dryad has been on my radar for a long time – I’ve also blogged about it a little. One of the problem I have with Dryad and Windows HPC 2008 R2 is the amount of hardware you need to just do development I’m sure that if I could get more hardware I would have done a lot more than I’ve currently been able to achieve. One think I’ve found to date is that the HPC API is “painful”.

So let me get back to Dryad and Real-Time Market Risk (a topic I seem to be spending a fair amount of time on from solutions to iPad UX). In DryadLINQ, I can get the trades I want to process using

PartitionedTable trades = PartitionedTable.Get(inputUri);

Which lead to calculating market risk using something like:

var result = trades.Select(t => Risk(t, curves);

Assuming I have a function:

TResult Risk(Trade t, Curve[] curves);

However the above is flawed, since I don’t want to send all the curves to every trade as its network bandwidth unfriendly

Sidebar: The DryadLINQ Programming Guide’s samples are primarily driven from a dataset within flat files which again isn’t what I typically have the luxury of using as a trade repository. Given the amount of hardware/software to install for Dryad development, one would have thought Microsoft would propose a simulator mode to speed up development, and reduce cost?

Anyway, back to a better solution which possible comes from the Histogram sample and specifically the BuildHistogram function.

return inputTable
.SelectMany(x => x.line.Split(‘ ‘))
.GroupBy(x => x)
.Select(x => new Pair(x.Key, x.Count()))
.OrderByDescending(x => x.Count)
.Take(k);

Specifically if the trade set is a full book/portfolio, then maybe we want to do a SelectMany and spit to trades by product and then maybe GroupBy currency. We could then send the appropriate yield curves to the correct trades.

More thought needed.

DryadLinq0.dll was built successfully.
Query 0 Output: file://\\Lab49HPC\Drop Area\output\17325799-fb79-4c93-a624-80f8f
84066e2.pt
DryadLinq1.dll was built successfully.
Input:
[PartitionedTable: file://\\Lab49HPC\Drop Area\output\AddPair.pt]
RangePartition__5:
RangePartition(p => p.Left,_)
Super__8:
DryadMerge()
Select(x => (x.Left + x.Right))

13/05/2010 15:35:39 Connecting to HPC cluster.
13/05/2010 15:35:39 Creating job submission information.
13/05/2010 15:35:39 Requesting min of 2 and max of 1000 nodes.
13/05/2010 15:35:39 Copying 8 files to server
13/05/2010 15:35:40 Submitting job.
13/05/2010 15:35:51 Job submitted.
The job to create this table is still queued. Waiting …

But the in the HPC Job Manager, I saw “Not enough available cores.” So close and yet so far, and strange when the box has 16 cores.

The message queues will also be purged when their corresponding job’s TTL expires. The messages aren’t deleted when the job ends (for durable sessions) because a client may come back to retrieve the results after the job completes and resources are given back to the cluster.

Having looked at the samples, read though some of the documentation I am struggling to find a trading usage for DryadLINQ. DryadLINQ applications use PartitionedTable objects to represent persistent data as an IQueryable collection. PartitionedTable is basically an abstraction that represents stored data as a collection, and can represent an arbitrary storage. The data can be on the local system, in a SQL database, on the cluster, and so on. So I guess I can pass it a collection of trades to DryadLINQ to calculate the cashflows:

        string uri = "trades.pt";
        IQueryable<Trade> trades = trade_array.ToPartitionedTable(uri);

I believe Temporary tables are stored in the folder specified by DryadOutputDir key in DryadLinqConfig.xml file

Now I suppose you might want to GroupBy the trades that require identical market data/curves to calculate the cashflows, and then Select and calculate each cashflow, Sum‘ing the PV of each cashflow to calculate the final PV.

Anyone got any suggestions? Maybe Monte-Carlo simulations are a better use of DryadLINQ?

It’s nice to be back in NYC, it’s been a year or so, and luckily today was pleasant from a weather perspective. Sometimes you need to do these short duration trip to help out clients – luckily my body clock doesn’t suffer from jetlag

Whilst in-flight I managed to do some more work on the StreamInsight presentation and demos for the up and coming Leveraging Technology to Drive Customer Connections. I do think the AppFabric Caching Real-Time Market Risk demo is cool, its just unfortunate that I suspect the slides and time will not do it justice.

Dryad. I’ve had the samples on my machine for about 4 weeks now, and have yet to spend enough time looking at them. Generally from the HPC work that has already been done from a Market Risk cashflow perspective, Microsoft need to spend more time in the area of scheduler performance connectivity coupled with diagnostics of understanding why a HPC SOA service is failing. On the diagnostics side of things, it’s just painful. We need a better User Experience (UX) from the developer toolset.

MSDN Magazine May 2010 didn’t have a lot from my perspective:

• LINQ Projection Queries and Alternatives in WCF Services
• Production Diagnostics Improvements in CLR 4

And I missed this one from April 2010:

• Entity Framework 4.0 and WCF Data Services 4.0 in Visual Studio 2010

I need to find time to getting back to Azure. As I said in a previous posting, given the start of the various home projects, the next logic step is to move them into Azure.

Sidebar: Web Application Exploits and Defenses

Read more

Taking a feed from my simulated market (and the Market Strategy Engine POC) the trades will be submitted to the HPC cluster, where the F# cashflow/PV code I blogged about a few months ago will run as a service, crunching the trades, and generating PV numbers. Obviously to calculate the cashflows I need appropriate market data and curves. For this initial POC, I’ll pre-populate AppFabric caching with this data, and pass the velocity object keys to the HPC SOA with the trade data. A further POC will look at snapping this data, and updating Velocity at specific intervals, hence forcing portfolio recalculations – real world scenario.

The need for the HPC custom broker has been discussed in a previous posting, so I won’t re-iterate again. Likewise, the design of the Real-Time Cube (RTC). The VelocityClient on each HPC node is however important to discuss.

The HPC cluster needs to be party stateless, and partly stateful. This is driven by the need to reduce the amount of data sent around the LAN coupled with the type of Market Risk processing that will be undertaken. Stateless is probably more common on a cluster, since the process running the job/service will usually be ripped down on completion. Even if the process isn’t ripped down, one has to cater for the instance where the process crashes for some reason. Hence in stateless clusters, all data is shipped to each node, each time, but this is expensive.

The reason we need stateful nodes is when we move into the world of snapping market data/curves, and re-calculating portfolios. Given that we have snapped, we know that for x trades/positions/portfolios, certain data will be identical. Hence to reduce the expense of sending data, and improving performance, I’m planning to run a VelocityClient Windows Service on the Market Risk nodes. This Windows Service would do exactly what the service name implies, act as a node VelocityCache, drawing down certain a specific set (probably by currency) of market data/curves to nodes for a duration, and then flushing the service. The VelocityCache could be done away with if we kept the node service process (F#) running indefinitely, but as I said earlier this doesn’t cater for the process crashing, which could happen . Obviously not all nodes will cache the same market data/curves – as discussed in a previous posting.

The data coming out of the HPC cluster will be used to populate the RTC (previous POC), which also leverages Windows Server AppFabric caching, and hence provide cache notifications which via a streaming server (Nirvana in the case of this POC) update a Silverlight 4 RIA in real-time.

I’m sure there are flaw in this HPC design, but for the moment it appear viable, and worthy of a POC. Obviously I have a few other interesting idea up my sleeve post this POC, some of them are unfortunately dependant on Microsoft giving me access to some new technology