Haskell, HPC and Crypto - Beer in the Evening

We're organising another "beer in the evening" event somewhere round about Smithfield in London to discuss Haskell, multi-core, HPC, Security and all sorts really - so if you fancy having a beer or two with a gang of gnarly, middle-aged architects, programmers and scientists (attractive huh?) then you'll be very welcome.

We will be meeting on the 22nd May - details are here

To participate, please add your name to the Doodle Poll entitled Haskell + Beer. This is so we know how many buckets of chips to order...

As All Bar One has now closed, we will be in the Bishop's Finger, Smithfield. I'm planning on getting there around 530pm. My mobile number is zero seven eight three zero three six eight zero two four - when you get there give me a call. There's a good chance we'll get some of the beers paid for too but no promises yet.

Topics for discussion/contention

• Crypto in Haskell (Dominic is Mr Haskell Crypto btw). Opportunities for parallelism (e.g.)
  
• Is Haskell and multi-core the best solution to meet the projected demand for simulation in finance or has FPGA yet to have it's day?
  
• Challenges of Haskell and high performance messaging integration. 2.4 million messages per second (not transactions) are now possible using tools like LBM from 29West.
  
• The K language (an APL derivative), Fortran, Objective-C, LISP and Smalltalk gained a small foothold in the eighties/nineties in quantitative analytics but C++ remained the main language of implementation due to availability of skillset (K programmers are like hen's teeth.) Java and now C# are now the de facto implementation languages but have serious issues for high frequency finance - will Haskell be able to make an impact or will it be another marginal language used by quants.
• Is Haskell capable of high performance?
  
• Haskell and distributed memory (memcached) performance aspects
• Haskell Data Parallelism versus state of the art FPGA approaches. Check out HPCPlatform's offering btw.
• I hear rumours that Haskell is being rolled out to the HPC team of a major investment bank in Canary Wharf - watch this space...
  

More topics very welcome.

A Design Pattern Template for High Performance Messaging

This is a work in progress. High performance messaging is hard. There are many parameters which can be configured (or misconfigured) so I'm working on a series of pattern templates. Work in progress...

Pattern Name

{ Source: Single.All Topics, Receiver: Multiple.All Topics }

Synonyms



Related Patterns

{ Source: Per Topic, Receiver: Per Topic }

Overview


Topic Methodology

Source per topic
{ Single.Source , Receiver.All Topics }


Group Rate Control Policy

Extreme 1 { Sender.Rate.Slowest Receiver, Reciever:at leisure)
Extreme 2 { Sender: Fast As Possible, Receiver: Try to keep up)
Middle Ground (Send.Minimum Data Loss, Receiver.Minimise Latency)

Transport Protocol


Example

Diagram

Operating Environment

Related Patterns

Software Pairs

In my anonymous applications post, I talked about an idea for a web service marketplace delineated by several criteria, such as cost, reliability, performance etc. Consumers could chose a service based on their particular preference, or regulatory obligation for that matter, and return to the marketplace in realtime should a chosen service provider fail to deliver the required service level, decrementing the service's reputation in the process.

Service providers would range from the high profile corporation to the reclaimed linux box powered by a solar panel in Africa (anyone can download the jdk and learn to program). Investment banks may be forced by the regulators to only source from high reputational providers in production. In dev, you can source from whoever you like.

So this service analogue applied at a macro level leads the notion of software analogues e.g Oracle and mySQL, Data Synapse and [Hadoop|ICE]. Slightly more (IB) user friendly is the notion of Software Pairs as in the stock/currency analogue of being different sectors, our delineator is Commercial vs Open Source. It mght be useful to code this up one day - a kind of del.icio.us for applications - whereby the dev community categorise which pattern is exemplified by a particular type of software.