Saturday, October 29, 2011

On vacation with my hands full of books to read, I found myself committed on a serious SICP reading that takes longer than predicted (specifically while doing the exercises in Clojure in the mean time).
The promise I made was also to start learning Erlang, while starting learning a Haskell for my great good (fans will understand:)). On the edge of opening the Haskell book this weekend, I already watched Francesco Cesarini and Simon Thompson videos on Erlang which provided me with some meat for Akka.

A very short project, indeed but food for the mind, still being with no pet project, nor Scala or Clojure Master for guidance.
One of the exercises proposed by Cesarini and Thompson consists in the creation of a ring of actors, one creating the following, then sending an acknowledgement message. The last created actor sends an actor to the source actor, notifying the end of the ring process. The implementation can be summarized into the following diagram:

The sbt build.scala file used for the project is contained into the following template:

The BuildSettings object flags the execution of the scala main methods as forked processes so there will be no interference between the sbt process and the execution of the ring. I added memory sizing info for the execution in order not to be constrained by undersized estimates and imposed the flag server as running a 32bits old dual core laptop (yes, shame on me, but a good laptop can reach far more than 2000 euros).

The addition of the server flag revealed to be a nice idea dividing the time of execution by two.

While achieving this small kata, I felled into a few traps. One of them, I was not expecting, was the chained creation of the Node in the ring one after the other. I could not chain them on construction unless generating an expected big stack overflow. So, on a first try, I overrode the preStart method, naively expecting for some asynchronous invocation of the method. The stack overflow took me by surprise. I then cheated and asynchronously ordered, via message sending, the creation of the next actor. The idea was to reproduce the following Erlang BIF invocation:

As one can see, I tried to reduce the volume of exchanged message, using only literal symbols during exchanges. The 'start and 'ok reproduces the Start, OK symbols on the ring schema.

While receiving a 'start message, a Node actor, creates a new Node actor, after notifying the source of all nodes that it has been created. It allowed to check all my actors where created.
On receiving an 'ok message, the actor poisons herself so to free the resources.
The reference to the source and the number of expected actors are communicated as constructor parameters. On receiving a 'start message, a Node actor, creates her follower decreasing the number of Node to be created., the last Node, matching the number 1, sends the 'ok message to the source.

The Node companion object, takes in charge the creation and start of new actors.

The Source actor, is slightly different as
collecting the ping notifications from the ring, tracing the complete execution of the ring
and relaunching a ring execution.
The ability to relaunch a ring process was important as the JVM warm up can take one or two ring processes before exposing a stable time of execution.

On receiving a 'ping message,the (missnamed ) total number of created actors is incremented
On receiving an 'ok message, that flags the end of the ring execution, a new ring process is initiated again until reaching the expected number of ring executions.
Here is the complete code content:

where the Ring object main method takes as input parameters respectively the number of node in a ring, and the number of ring processes to execute.
With an underlying jdk7 the kind of sampling I got are typically :

As I do not have enough knowledge (yet !!) about the Akka internals nor the Erlang one, I don't want to bring on the scene any conclusion in favor of one of the experiments or the other.

I would rather both welcome explanations and critics about the code sample in order to increase my knowledge of the framework, and understand better why the performances should be better for one or the other.

In addition, one should remember that

the machine is under sized for this kind of experiments
the number of messages exchanged during the Akka ring experiment (3000000) is greater that the number of messages exchanged during the Erlang test (1000000)
after all creating 1000000 actors, exchanging around 3000000 messages in about 7s could be considered a good performance on a three year old laptop

So what are the results on your machines ? Certainly better than mine ?

Sunday, October 23, 2011

Today a little bit of Scala. My Clojure current algorithm not being complete, I found myself with the same recurring dilemma. What am I going to talk about? This is a commitment in trying to understand, then expose a little subject, whatever it is, so to learn how to transfer ideas.

The subject came to me while reading Stuart Halloway book, programming Clojure. Nice book, full of interesting exercises. One of the exercises aims to picture some very amusing use of STM (aka Software Transactional Memory) in the form of a simple Snake game.
A very entertaining part and potentially a nice code kata. One must steer a moving snake in a rectangular area. Some Apple(s) is(are) dispatched in the game area while the snake is rambling. The purpose is to catch apples in order to make the snake grow. One can control the snake using the arrow keys. Once the snake has grown enough you win. But beware the head of the snake must never hit the snakes body .
Simple.
Although I do not play game, programming Stuart Halloway example was quite fun and the game may be in implementing the solution. Stuart Halloway presents a nice simple architecture separating the purely functional aspect from the mutable state and the GUI.
The mutable part of the game can evolve in three ways

A game can be reset to its initial state.

Every turn, the snake updates its position. If it eats an apple, a new apple

is placed.

A snake can turn.

My (small !!) Scala brain started yelling : "God, You can do that in Scala" with actors. The game state can be managed by some actor that can reinforce the serialisation of the change. My Scala mind tortures me enough, so I do not want to upset her....but let spice the idea with some Akka.

Having not found a pet project yet in Scala and no Scala Master for guidance, this is the only opportunity I have to bring Akka into the game (may I say). Naturally, I would not recommand using Akka in order to program a little game, the Scala genuine actors being self sufficient in order to manage this kind of implementation.
In the large set of Akka modules we can also find a STM module, and I will not resist in using it.
Before starting, I provide here the sbtbuild.scala project content, sbt being a nice tool, not always very easy to start with:

Why not following Stuart Halloway path in reusing idioms from the language? Scala being a multi-paradigm language, we could use actors of course, and object oriented approach, colored by some functional treatment into the pattern matching implemented in the actors' bodies .

I wanted the stuff to be simple. The approach can be resumed by the following scheme:

The global state lays into an Entities Actor in charge of handling all events incoming from the graphic interface. I voluntarily split the Game board (a swing panel) from the entities actor using a second actor called a board driver.The board driver plays the part of a single access point to the game board, both sending and receiving events in coordination with the entities actor.
The entities actor will send notification concerning the model update to the board driver while the board driver will send direction update notifications and refresh notifications.
Basically, a timer will issue the periodic update to the board driver that will convert it into some actor message.
No big stuff.

Like Stuart Halloway we need useful tools in order to help us swapping from the model world to the screen world. First of all, the Game world must be described by abstractions like positions , dimensions etc... For the sake of simplicity, I introduced the following tool class:

where a position into our small universe can be pointed out by a WorldLocation.
The randomLocation method provides us a simple mean to pop an apple in a different location on need. The + operation has been implemented in order to provide more fluent expressions during WorldLocation manipulations. winLength defines the size a snake must grow up to in order for the player to win the game Describing a small universe serves no purpose unitl we convert our desription into a screen world language.

Here comes the GraphConverters object, very helpful when dealing with transformations from model to screen:

A scale factor of value 10 will provide a visible graphical panel surface delimited by a 750 * 1000 rectangle. The diplayPointFrom method takes in charge the basic conversion processe from the game World to the screen World, so it will be reused from the converted methods in charge of handling simple coordinates or list of coordinates.

Nice. The game started. We need a entities actor managing our entities. The entities are classified in two sub classes definitions: a snake and an apple. So two object abstractions:

I found case classes to be natural implementations of board entities
Some of you, dear pals, are going to yell at me. Yes, the Snake entity is a real object, taking in charge its own growth, like a real adult snake, being capable of changing its direction on demand etc...Or does it. As a matter of fact snake instances are immutable, so real "value objects". Every object invocation consists in a pure read access, like head position or leads to the creation of a new snake like moved, grown or go. Can it be more functional ? The location of the methods into the snake definition serves a modular purpose only.
Precisely the methods purpose:

method

purpose

go

change direction

moved

change snake position

grown

grow snake

ahead

provides next location of head

head

location of head

We have our two objects.

Good, we need an actor behavior to manage the transformations induced by the incoming events. An akka actor receives its event notifications via the ...receive method:

If the snake eats the apple, in essence , if the the snake head meets the apple location, then a new apple is re-created and the snake grown.
If coincidentally the snake head location meets the snake body, the game is lost, so restarted after notifying the main game board (Game.displayMessage)

If hopefully the size of the snake is enough the game is won, so restarted after notifying the main game board (Game.displayMessage)

...else we move the snake in its current direction.

So suitable is pattern matching dealing with our update !!

The Updated message, wraps around locations only and not entities that do belong to the model world.
And that's all. Our model is safe, thanks to a containing actor:

We provided a companion object to the actor in order to simplify both creation and start of the actor. A reset action is fired while instantiating the actor.
The second part concerns the board and its driver.

There, we fall into Scala Swing. The Game extends the standard SimpleSwingApplication while gathering the three elements:

Call me a nit-picker if you want, but I did not want the display to know about the driver, although they do lay into the same Game class (making my own bakery of doom ?). So notification of key pressure is blindly fired through a function closing onto the driver.

The board by itself (not my favorite part), embeds some DSL's from the the Scala Swing layers:

As of Scala Swing the listenTo(keys) and reactions += {...} expressions elegantly set the environment as key event listener. We just added the constructor handle method to the list of reactions to be fired on key press event reception.

The apply method provides us with an idiomatic way to drive the panel repaint from the board driver. The apply methods receives ScreenLocation infornation immediately converted into a closure that will be invoked during the next paint action, issued from the repaint invocation. As a matter of fact I don't like the idea of storing a reference to the closure on a variable, although the driver board is an actor so serialises its incoming events treatment.

The board driver implementation remains very simple as a single entry point. Its purpose being only the translation of timer/user inputs into actor messages and actor messages into actions onto the main board:

As in all actors, the main purpose is implemented into its receive method.
An incoming Updated message implies the invocation of the board after conversion of WorldLocation abstractions into ScreenLocation abstraction.
The reception of a KeyPressed message will fire an update order to the entities model and finally a show message will display the dialog box.

The periodic timer is started into the Game definition. Here it is at the bottom of the whole Game class definition:

One minute pals. Didn't I promise for a STM implementation ? Well, the Game, its board and board drivers remaining almost unchanged, the stuff that do really changes is the Entities class. No more actor involved in this template.

The global state of game, consisting in a snake and an apple will be updated atomically in one transaction. The code will look familiar to Clojure developers. And it is, quoting Jonas Boner, "Refs (transactional references) are mutable references to values and through the STM allow the safe sharing of mutable data. Refs separate identity from value."

A transaction is delimited using the atomic keyword. The snake and apple definitions remaining the same, the snake and apple object "values" will be identified by two immutable reference fields:

The updatePositions method implementation makes use of the atomic keyword, using then the get/set methods of references in order to modify the references value. Invoked from the Game, the updateSnakeDirection method uses the alternate alter method which accepts a function that takes the old value while creating a new value of the same type, still in the scope of a transaction.

We used a closure for the purpose of our implementation. The reset method is made private as being exclusively invoked from an atomic scope.
Coming back to the Game class, we provide a version very close to the previous one:

Okay the game's very simple, the boundary positions are not controlled, but the kata is worth while. Thank you Stuart Halloway. Must go to fix my next blog code...in Clojure this time. Very strange bug indeed.

Sunday, October 9, 2011

Hi again. And thank you to the positive feedbacks of people having read the previous writings.

During a recent discussion with a bunch of interesting guys, one of them asked me why I was always expecting so much time between two consecutive writings.While explaining to him how hard it was to find both subject that might interest people and time to write about it, he then suggested that I should from time to time choose into one of my small Clojure/Scala/Java experiments and just reproduce this one it is.
It might not be perfect but should bring some interesting feedbacks. In addition to his comment, I noted, as from a personal point of view, that I liked too reading from other people short program stories because these small programs always present new keywords, other visions of problem analysis and so on...

As my current discovery of Akka fault tolerance takes longer than expected, I randomly picked up one of my last projecteuler implementation. I found the problem interesting as it provided some opportunity to experiment, on a (very) modest scale, on elements of parallelism in Clojure.

The problem was to find the greatest product of four adjacent numbers in any direction (up, down, left, right, or diagonally) in a 20x20 grid. I immediatly started writing something based on the feeling I had, how suitable the problem was for a functional programming kata.
The matrix can be divided in sub matrices in charge each to identify their maximum product, then maximum maximorum of all matrices is the looked up result. A maximum search is idempotent, the product processing in matrices can be easilly implemented using higher order functions etc..
Having loaded the most recent version of Clojure (1.3) , the Leiningen project was configured with the following content:

I selectively chose to read the lines and trim them if necessary. Data copied and paste from the net can sometime be strange.
My first kata step was to load a file from the filesystem, a task - who believes it - I never achieved in Clojure before !!.
The test written to challenge that huge effort remained very simple as I tested that my loaded file was a real square matrix:

My test looks like an acceptance test as I did not get into detailed info. I took the opportunity to apply all the necessary conversions from character to numbers inClojure.
This drove me to the solution:

The matrix-definition function is the entry point, accepting a file path definition as a string expression.
The read-lines function from the Clojure contrib library delivers a lazy sequence of strings that the string-matrix function converts into a sequence of character sequences. The converted functionthen to-int function helps tranforming the matrix of Strings into a matrix of integers.
No big deal.
Nice, I have this big matrix now. In order to proceed, a next interesting step would be to able to grab square four matrices:

Basically, quoting Stuart Halloway, a list comprehension creates a list based on an existing list. Working, with matrix, I naturally transform the result in a vector of vectors, for being indexed list, mandatory in our case.
In possession of a matrix, we can work on the extraction of maximum products among rows, columns, and diagonals:

while extracting the maxima obtained from helping functions.
So far so good, I comment my current macroscopic test and define finer grained test so to challenge the helping functions input/output function:

Good, let's uncomment the previous test: max-product-in. Green(...figure of speech: in the REPL, you execute the (run-tests) methods and read the report). Good.
My attempts to get the maiximum maximorum can be resumed in :

Improvements on performance are not obvious, and more visible when the size of the matrix is dramatically extended by unfolding it for example, duplicating itself. Working on bigger multiplications, so bigger matrices would also make a difference.
As literally stated in pmap comment, pmap appears to be useful for computationally intensive functions where the time of the applied functions dominates the coordination overhead.
At the scale of my small computer (Dual core) processing small operations, the improvements are not to be obvious.

Just for fun, because it does not provide any improvement in this situation, let's try to with agents. Ideally we could save the main thread the work of processing the maximum, deferring the operation to an abstraction dealing with the operation asynchronously.
Clojure agents can take in charge this kind of operation. An agent binds a value like a reference in Clojure, so it can be dereferenced at will. As with actors in Scala(and naturally Akka), an agent works on a queue of messages, each message corresponding to new incoming action aiming to change the bound value.
Here stops the similarities between actors and agents. The agent only changes its internal bound value versus asynchronous queued incoming actions. So it remains value centric, on the contrary of actors who can swap behaviors, transfer continuations etc...
Michael Fogus and Chris Houser take time to explain the differences in the Joy of Clojure in far more technical descritpion than mine :)
As far as our little problem is concerned, I'd like to apply a little producer/consumer mechanic where my main thread of execution would push the values to an agent switching its bound value to a new value when the incoming value is greater then the one already bound. Here is the solution:

The agent is impersonated as a sorter, initialized with the value 1 and providing a validator method, in charge of checking that the input is effectively a number:

sorter (agent 1 :validator number?)

For each processed maximum in the matrix we send its result value to the agent:

(send sorter max (max-product-in (square-at x y 4 matrix)))

in respect to the send method syntax. The send method takes as input the agent reference in addition to a new value and a function to apply to both the bound and new value. The resulting bound value will be the output of the applied function.
Good, we are done, tests green !!

So we have seen how to apply a low cost change to our processing, migrating from map to pmap, and so preserving our algorithm. We have also used a Clojure agent in a producer/consumer pattern.

A short one, awaiting for incoming deeper subjects. Being on holiday soon, I will try to push more of these little experiments and take time to develop the biggest subjects.
Before I forget, the book of the week, by G.J.Michaelson, An Introduction to Functional Programming Through Lambda Calculus, to (re)discover...the postscript edition being available on line here.