Get list of OpenCL supported devices with jogamp.jocl

I recently got started on GPGPU, and the natural choice seemed to be OpenCL, since it's supported by both ATI and nVidia. The nice thing about OpenCL (other than being cross-platform) is also that it provides a layer of abstraction that allows you to use both CPUs and GPUs (not only GPUs as for nVidia's CUDA and AMD's Stream technologies).

I started investigating a few java wrappers (there's only a handful around) and ended up playing with jogamp.jocl.

This is just a snippet showing how to retrieve a list of OpenCL enabled devices on your machine:

// create context for all devices detected using default platform
CLContext context = CLContext.create();

// an array with available devices
CLDevice[] devices = context.getDevices();
         
for(int i=0; i < devices.length; i++)
{
   out.println("device-" + i + ": " + devices[i]);
} 

Goes without saying that if you don't see your GPU in the output it's time for some painful driver sweeping. I found that Snow Leopard works straightaway with both ATI and nVidia (MacOSX 10.6.x ships with OpenCl support), while windows can be a bit trickier to setup (as we all know, Catalyst software kinda sucks).

Just to give you a sneak-peek at what comes after, once you've had a look at the output then you can go ahead and select a device to create the queue(s) you'll use for sending data up to the devices:

// have a look at the output and select a device
CLDevice device = devices[0];

// create command queue on selected device.
CLCommandQueue queue = device.createCommandQueue();

You can see the entire code for the official jogamp.jocl  'Hello World' example here if you're curious.

Was Darwin Wrong?

In the beginning it was self-replicators.

Then it was self-replicators with metabolism (which kind of is the definition of life).

Now, to go from self-replicating blobs to human beings it takes a pretty good search algorithm.

Natural selection is that algorithm, and it happens to be the most robust search algorithm there is, beating hands down any other kind of human-designed search tool.

So, was Darwin wrong?

P.S. if you don't believe in facts then there is very little that can be done to convince you

How to load text files with jQuery

I was looking into this to help out @tarelli with one of his crazy tasks from hell (spare you the details). Here's how you go about loading local files using jquery:

// LOAD file
$.get('file:///C:/myPath/myFile.txt', function(data) {    
    
    var lines = data.split("\n");

    $.each(lines, function(n, elem) {
       $('#myContainer').append('<div>' + elem + '</div>');
    });
});

This will only work if you double click on the file that executes the script, obviously a web-server shouldn't allow you to go mess around in the file system (I tried on IIS and couldn't fool it, damn). Obviously the same snippet can be used to load files on a web-server by providing a url to an accessible file.

Notes:

• couldn't get it to work without specifying the file full path in format file:///C:/myPath/myFile.txt
• to get this to work on chrome you'll have launch it with the --allow-file-access-from-files cmd line arg

P.S. happy xmas

Javascript - strip off illegal characters from string

Recently had to come up with a piece of javascript to strip off a set of illegal characters from strings before passing down to the persistance layer.

Took me a while to come up with a regex for the replace, not because it's particularly difficult, but because I suck at regexes (and I am no js expert either).

I thought it could be handy to have this functionality as a string prototype:

// strips off illegal chars &%$
String.prototype.stripOffIllegalChars = function() {
 return this.replace(/[&%$]/g, "");
}

The /g above means that the replace will be global (so not just the first of those characters will be replaced).

It can be used like this on any string:

var dirtyString = "blah$blah%blah&";
var cleanString = dirtyString.stripOffIllegalChars();

Hopefully it'll save some time to the next in line.

WCF client hangs on big response: make it streamed

I have to blog about this - as I spent a few days having nightmares about it.

An operation from a websphere service was returning a pdf string, for a payload of about 500KB. The WCF client consuming the service was working fine on the test fixture, but when the operation was integrated in the web solution, with the exact same binding and endpoint, the client was hanging for more than a minute onto the response of this particular operation (every other operation with a smaller payload was OK) before coming back with the deserialized response.

I initially blamed the service, but then noticed (sniffing traffic via fiddler) the response was coming back quick enough and only then the client would hang for more than a minute obviously trying to deserialize or God knows what.

After quite a bit of hacking around on and off, I managed to change the transportmode config setting on the binding from buffered to streamed (I had nothing else left to try!), and it did the trick. In light of this it's pretty obvious that the response was being chunked in parts the size of the buffer and that was probably slowing down the whole process.

Morale of the story: if you've got big payloads transportMode="Streamed" could save your sorry ass.