Friday, March 5, 2010

Memory Barriers article published by InfoQ

InfoQ has published an article I wrote about memory barriers and the JVM. Here's an excerpt:

"A trip to main memory costs hundreds of clock cycles on commodity hardware. Processors use caching to decrease the costs of memory latency by orders of magnitude. These caches re-order pending memory operations for the sake of performance. In other words, the reads and writes of a program are not necessarily performed in the order in which they are given to the processor. When data is immutable and/or confined to the scope of one thread these optimizations are harmless. Combining these optimizations with symmetric multi-processing and shared mutable state on the other hand can be a nightmare. A program can behave non-deterministically when memory operations on shared mutable state are re-ordered. It is possible for a thread to write values that become visible to another thread in ways that are inconsistent with the order in which they were written. A properly placed memory barrier prevents this problem by forcing the processor to serialize pending memory operations."

You can read the rest over at InfoQ ...

Friday, January 1, 2010

Presenting Memory Barriers at SpeakerConf 2010

The one thing I'd like to see more of on conference circuits are the basics. I often find myself more interested in concepts that have been around for decades more than the latest and greatest framework. This year at SpeakerConf I'll be doing another talk on concurrency and I'll be getting closer to the metal. Memory barriers, or fences, are a set of processor instructions used to apply ordering limitations on memory operations. Without memory barriers every mutex, actor or synchronization point in your application is broken; so consider this talk to be relevant to all languages. Looking forward to another great lineup this year:

Steve Vinoski, Neal Ford, Stuart Halloway, Obie Fernandez, Brian Marick, Philippe Hanrigou, Dave Hoover, Pramod Sadalage, Oren Eini, George Malamidis, Matt Deiters, Amanda Laucher, Michael Nygard, Freg George, Dave Thomas, Aslak Hellesoy, Pat Farley, Eric Yew and Robert Martin

Saturday, September 5, 2009

Presenting Erlang at the Polyglot Programmers of Chicago meetup on September 23rd

Update ... this talk has been moved from the 24th to the 23rd

I'll be visiting Obtiva later this month to present Erlang, here are the details. I'm probably going to gloss over plain vanilla functional programming principles in order to focus more on concurrency, as well as another equally important and overlooked core feature ... reliability. We'll cover the basics of what an Erlang process is, runtime code swapping, and a brief intro to a few Erlang OTP behaviours. Attendees should walk away from this presentation with a few new ideas in their heads and enough information to be dangerous. My slides are on SlideShare.

Tuesday, August 18, 2009

Option Volatility & Pricing in Erlang, Java and JavaScript

I wrote an application as I read Sheldon Natenberg's excellent "Option Volatility & Pricing". You can play around with it here. Here's a few screenshots ...

You can view the source code here if you want to in take a look under the hood. In a nutshell I used Erlang to model a #position{}, composed of long and short #side{} records. Each #side{} is composed of #option{} and #underlying{} records. The PNL of a #position{} is calculated and graphed. The data is serialized as JSON to any browser where it is rendered with a Java applet and JQuery event handlers.

Monday, August 17, 2009

My first impressions of the Scala programming language

update: The bug I describe below has since been fixed

Is Scala the new Java? I'd bet money on it for two reasons. First, Scala excels at several things that are not available in Java. The type system and closures have effectively grabbed the attention of language enthusiasts and fad followers. But to replace an institution like Java you need more. You need the average Joe to vote for you. This is the second reason: the cost of switching is low. Java developers won't have trouble with a transition like this. Idiomatic Scala might take a little effort ... but at a bare minimum, there is a one to one conceptual match up across the two languages. I dusted off a Java applet and ported it to Scala, see for yourself.

After playing with Scala a little bit I found my first problem with it. I could not have picked a worse way to get my feet wet. I'm not fond of applets but I had one laying around and thought I'd make things interesting by porting it. Then I fired up my web server and browser to find that my applet no longer worked. After a little while I traced the failure to a class loader problem in the browser. It turns out that everything that passes through scalac has a dependency on scala.ScalaObject and a host of other things in the Scala runtime. This means my applet gains 3.5 MB . Not a show stopper, but I think it's safe to say this is one thing Scala will not excel at.

And finally, I have no idea what's wrong with scala.collection.mutable.PriorityQueue . This REPL session says it all ...
scala> val q = new scala.collection.mutable.PriorityQueue[Int]
q: scala.collection.mutable.PriorityQueue[Int] = PriorityQueue()
scala> q.isEmpty
res0: Boolean = true
scala> q.size
res1: Int = 1     <- This has got to be a bug?