Also since my last post, I’ve moved my blog to a new site (which I’m actually hosting myself, so I hope my server doesn’t explode on some magical good day).

The new blog (which has already imported all the posts from this blog) can be found at http://clusterfudge.endoftheinternet.org .

Thanks for those of you who are still subscribed to RSS after 9 months of no posts, I appreciate your laziness.

This will be the last post here.

I’m working on a new type of knowledge engine, which I have yet to name, but it has four basic parts. It will have its own data delivery system (which for now is just a url scraper and wget, but will later use AI techniques to further its intelligence), an indexer, a grouping analysis on the index, and then an HTM framework that has definitely yet to be designed. I’m going to start small (indexing a fraction of the web as I only have about 1tb of storage to work with, though my plan for indexing will be significantly smaller than the data indexed itself), and scale up from there, if at all possible. There will be statisctical analysis, heavy distributed database work, some theoretical AI techniqes, and stupid amount of multi-threading.

Possible applications of this include, but are not limited to:

Search Engines

Speech/image recognition

Predictive Trend Analysis

And many more!

If this project sounds even vaguely interesting to you, leave a psot on this board and I will contact you over the weekend. I’ll be setting up a repository on sourceforge soon.

Thanks!

A dual core 2.66ghz doesn’t mean you have a 5.32ghz box:

Bravo, you’ve discovered that I was glossing over some deep parallel processing theory. Two machines or cores will not get through a single process at the combined speed of their processors, as you will only be using one of the processors at a time. However, if you are to break your tasks into multiple processes, the work can be done with each process being given its processor or core. This is the brilliance behind parallel processing. You are not doing any particular work faster, you are just doing a bunch of it at the same time. With a little simple algebra, you can see that work being done brings your box’s or cluster’s total productivity average to roughly the equivalent of the SUM OF ALL CORES.

Moving on…

T5212 machines are bad machines:

Now, I cannot personally say anything negative about these machines, though it is entirely possible that they are a large steaming pile of crap and I’ve gotten very lucky with mine (I have 5). Now it is not important that you use these types of machines in your cluster. It is far more important that you use the processors within and compatible hardware, but let me speak to the primary issue: Intel Core and Core2 processors do not work with openMosix 2.4 . That’s all there is to it. You’re also going to run into freaky problems with AMD 64 bit systems, so I’d recommend you stay away from those as well. The basic gist is that this software will run on any system with a Pentium D class processor or lower, and X-Windows (if you want it) requires about 64mb of ram to run properly. My suggestion of the T5212 was out of good experiences.

Now diggers, please stop being so angry!

This seems difficult, at first glance, but really, it’s not.

At all.

From the time you get all your hardware plugged in to the time you’re doing some massive parallel processing, depending on your needs, can be anywhere from 2 hours to 10 minutes. And this simple guide will help you get there.

Get the Hardware

Now, mind you, I’m not trying to do this as cheaply as possible, but I am trying to do this with as much bang for your buck as possible. These are the things you need to get.

PCs: Duh, kinda the barebones necessity in a cluster, and I have a recommendation: eMachines T5212. It’s got a Pentium 805 Dual core Processor with each core running at 2.66ghz, for a total of 5.32ghz per machine, and 2x1MB L2 cache, which while not stellar, is pretty respectable. It’s also got 1gb of RAM and a 200gb hard-drive, so storage problems go away pretty quickly too. There’s a lower model with half the ram and a smaller hard drive, the T5216, but I need the RAM, so I go with the T5212. At Best Buy and other stores, these run about 534.99 for just the tower. Mind you I have chosen this box for the hardware’s compatibility to the software we’ll be using in a later step.

Network Cables: You’re going to need at least one for each PC, and probably a couple more if you have an external device or PC acting as your DHCP server and/or gateway.

Network Hardware: You’re going to need a switch big enough for all your PCs to connect (or a series of small ones that you can daisy chain together). Life will also be a lot easier if you have a ONE DHCP server for all of your machines. All the machines need to be on the same IP subnet, but don’t need to be on the same network switch or in the same geographic area.

Setting Up your Hardware:

In my personal configuration, I have a small network appliance that acts as a dhcp server, router, and print server, so I use that as the base of my networking needs. I then have a series of smaller switches which have 1 (count them, 1) link total back to the DHCP server. This is important for me, so that network traffic on the cluster doesn’t bog down the rest of my home network. How else could I play Halo while factoring 100 digit non-prime numbers? This will also help your cluster have fewer jumps between nodes.

Your Software:

I strongly recommend the use of ClusterKnoppix. It’s a great tool, and is very stable. It uses the 2.4 debian kernel, and has openMosix installed and configured for auto-detect (which means nodes are essentially plug-and-play, though not really, and I’ll discuss why later). You’ll need one copy for each box, unless you choose to commit the knoppix image to the hard-drive of each machine. It’s not necessary, but it may be easier if you don’t have a stack of CDR’s at your disposal.

Booting up the Cluster:

This is probably the easiest part of the process. Place a ClusterKnoppix CD in each box, and boot it up. I can vouch that this hardware is compatible and you won’t have any issues loading, so now you’re ready to work! NOTE: If you do this with other hardware, I can’t guarantee things are going to work so swimmingly, and I am nowhere near qualified to help you trouble-shoot your hardware. If you have a DHCP server and DNS somewhere on your network, your cluster should be live to the internet, so you can pick up your code off other boxes on the network or from a CVS server somewhere out there in the intarwebs. There is a version of GCC and G++, though I can’t think of the version numbers off the top of my head (feel free to check the link on the side of this blog, I’m sure its there somewhere).

Making your Mosix Cluster a Beowulf

There’s two methods, but they essentially do the same thing. The first is to commit a knoppix image to the hard-drive of one of your boxes. There are tools for formatting and repartitioning the harddrive in the utilities menu in KDE (I think it’s GTPart that’s installed, as well as a few others). Follow the instructions from http://www.knoppix.org or from any other live-distribution site (they’re a little extensive, else I would include them here). The second is to commit an alteration image to your hard disk, and then boot knoppix from this alteration image (a new feature to Knoppix that I’ve never used, so once again, check the intarwebs).

Either method you choose, I would strongly recommend you use LAM/MPI (or openMPI if you so strongly desire the biggest and baddest). The nice thing about this setup, is that you do not need to configure each machine with lam, or configure your root node with machine lists of all the other nodes in the network. All you have to do is create multiple processes on the node that has MPI installed, and openMosix will balance the cluster. It’s truly beautiful. In order to run a process in mpi, follow these simple instructions (for lam):

bash$: lamboot

<some output here>

bash$: mpirun -np (some number of processes) <your executable name> <your arguments>

That’s it. You don’t even need to compile your binaries using the MPI compilers, assuming they don’t use the MPI libraries. If they do, use mpic++ or mpicc as you would g++ or gcc, respectively.

I’d love to hear success stories, so please, leave comments!

One of the nice things about mosix clustering is its ease of use, while one of the nice things about beowulf clustering is the ease of data sharing and segregation. I’ve discussed previously in GA In Parallel, some more interesting thoughts… that load balancing is a problem with Beowulf clusters, and even with my crazy scheme of Multi-Level Hybrid Clusters (MLHC). The basic idea behind MLHC is to create a beowulf cluster whose slave nodes are actually mosix clusters. It was an invention more of necessity than anything else, but it solved my problem nonetheless.

My plan now is to install LAM/MPI (beowulf software, essentially) onto one of my mosix nodes and then create all of the MPI processes on a single node and allow the mosix kernel to load-balance the cluster. At that point, I’ll have a load-balanced beowulf cluster. My main issue until now has been creating multiple instances of complete populations of my GANet software, because a single member of a population can be up to 100mb. Since some of my nodes have only 256mb of RAM, they can’t even run one instance of GANet with a decent sized population. The solution then is to create multiple small populations that share information, with each population being small enough to run on a single node. Also, I’ve learned that my population members don’t need to be quite as large as I’m making to start, especially considering that I allow them to grow dynamically.

Today’s lesson, beowulf is nice, but mosix load-balances. So take both.

So for the longest time, I’ve been desiring a beowulf architecture, but setting up the cluster has always been an issue. The bigger issue, however, is thread synchronization. The nice thing about clusters, is you can put them together with whatever crappy machines you have lying around. The not-as-nice thing about clusters is that you tend not to have 20 identical machines lying around.

With the standard MPI solutions, a process is created permanently on a node, typically with a set amount of work to do before exiting or requesting more work. There are some simple techinques you can use to try to sync everything up, and by simple, I mean archaic. You could (though I truly would never recommend this) balance the workload by hand (using arithmetic, God forbid) when developing, timing out each machine and such. There are more sophisticated methods, which I personally would recommend.

Thread Pooling

The basic idea behind this is to create a simple server/client architecture, where the server hosts a data set, and the clients request an element from the set, process it, and return the result. Clients may end up waiting while the servers has no data to be processed.

Data Pooling

This is very similary to thread pooling, but applied to the Genetic Algorithm. Imagine your server as having a population of whatever you’re working on, and the clients occaisionally pull the top few members from the population and working with them, then submitting results back to the population. Since there is always a full population in the server, clients will not hang up waiting for the server to have work for them to do. This offers complete asyncrhonization without delays (except perhaps server overload).

Each of these methods have are heavy on the implementation side, so I’d like to try a cluster-based solution. Tune in next time!

1) Operating Systems

If you’re going to do any kind of research, chances are your software is going to run for a long time, and is going to be a series of complicated processes, as opposed to your standard “Hello, world!” program.

Things I got:

Parallel processing, inter-process communication, sheduling, file systems.

2) Data Communications

Again, like OS, if you’re going to do research, chances are you’re going to need more than one machine, so it helps to know how to do networking. This was the class that gave me my basic foundation of knowledge to build my cluster.

Things I got:

Network structure, network administration, basic sockets programming, client-server architecture, multi-threaded server design.

3) Artificial Intelligence

There were two courses to our AI program at GU, and I feel like they didn’t hold the same weight. The first studied classical AI, which can be summed up as:

If A, then B. A. Thus, B.

Not particularly stimulating, am I right? There was a bit of game theory, and some state space traversal, but nothing too horribly complicated. And for some reason, none of the state-space stuff we generated worked real well anyways….

Things I got:

Overview of Genetic Algorithms, introduction to neural networks. Overview of past failures of AI.

Now I suppose AI isn’t a course that you really need to be a well rounded CS student, but I enjoyed it.

What I was supposed to be talking about…

My research; It’s complicated, kinda convoluted, and totally time consuming. Good thing I don’t have a life. As I’ve discussed before, GA is a great tool for optimization. As I haven’t discussed before, neural networks are a great tool for recognizing patterns. Neural networks can come in many different structures, and the plan of my research is to use GA to “evolve” the structure of a neural network, based on how well it learns a given training set. I’ve yet to decide what kind of training set I will use, but I’m leaning towards natural language processing.

A neural network can have several layers, and I’ve chosen to represent the links between each layer as a two-dimensional array of booleans (true signifying that a link exists, false that one does not). Since there will be multiple layers, then there will also be more than one of these two-dimensional arrays, thus giving birth to the three-dimensional boolean array that is the bulk of my genome (bool *** adjacencyMatrices).

I would love to use the standard templated 3DArray_Genome from GALib, but alas, I wanted more scalability. The adjacencyMatrices have the ability to “grow” in number of layers (height), and number of nodes in any individual layer (width). In 3DArray_Genome, genomes are of a fixed size as of GA initialization.

I suppose that’s enough of a start for now, so until next time…

It's a pun. Get over it. Anyways, now it's time to talk a little parallel GA theory. There's a lot of variations, but essentially two different ways to parallelize the genetic algorithm.

Single GA Parallelism

GA is a great algorithm for parallelization. During the evaluation step, where each member of the population is given a value, the same function is being called on each member of the population, one at a time. This is referred to as embarrassingly parallel, in that parallelizing the process takes no separation of information or sophisticated communication between function calls. All that is required is that each function call be given its own process in which to operate. Here is some sample c-like pseudo code:

void evaluatePopulation(pop)
{
    for( each member of the population i )
    {
        create pipe[i]
        open(pipe[i]);
    }

    for( each member of the population j )
    {
        fork();
        if(this is the child process)
        {
            break;
        }
    }

    if(I am a child process)
    {
        TheReturn = pop[ME].evaluate();
        send(pipe[ME], TheReturn);
        exit(0);
    }

    else//I am the parent

    {

        for( each member of the population j )

        {

            pop[j].value = recv(pipe[j]);
            close(pipe[j]);
        }

    }

}
Multiple GA Parallelism

Another common use for parallelization is simply to scale one's application. GA is an interesting case of this, because the bulk of the work is done by "random" variation. Thus, the more "random" you have, the better chance you have of finding your optimal solution. The plan then is to create multiple instances of your GA and have each run in a separate process. Here is some sample c-like pseudo code:

void main()
{
    GeneticAlgorithm GA;
    GA.init();

    for( 10 times [i] )
    {
        create pipe[i]
        open(pipe[i]);
    }

    for( 10 times )
    {
        fork();
        if(this is a child process)
        {
            break;
        }
    }

    if( I am a child process )
    {

        for(int i = 0; i < 100; i++)
        {
            GA.step() // runs one generation of GA
        }

        send(pipe[ME], GA.pop.BestMember());
    }
    else
    {
        for( 10 times [i] )
        {
            cout << pipe[i] << " = " << pipe[i].value << endl;
            close(pipe[i]);
        }
    }
}

To improve upon this code, you could allow each process to share their best member(s) incrementally. Here is some sample c-like pseudo code:

void main()
{
    GeneticAlgorithm GA;
    GA.init();

    for( 10 times [i] )
    {
        create pipe[i]
        open(pipe[i]);
    }

    for( 10 times )
    {
        fork();
        if(this is a child process)
        {
            break;
        }
    }

    if( I am a child process )
    {
        for( 10 times )
        {
            for(int i = 0; i < 10; i++)
            {
                GA.step() // runs one generation of GA
            }

            send(pipe[ME], GA.pop.BestMember);
            GA.pop.WorstMember = recv(pipe[(ME+1)%10]);
        }
        send(pipe[me], GA.pop.BestMember);

    }
    else
    {
        for( 10 times [i] )
        {
            cout << pipe[i] << " = " << pipe[i].value << endl;
            close(pipe[i]);
        }
    }
}

The Implementation Differences

Single GA parallelization is easy to implement in the way shown in that you do not need to pass any genetic information, just the calculated values of each member of the population. It is also very easy to distribute across a Mosix type cluster, given one small drawback: the evaluation function needs to be very processor intensive in order to be distributed by the Mosix kernel. A fork()ed process must be in existence for about 3-5 seconds to give the kernel time to identify and migrate it. So, for little tiny calculations (like the airline example from my previous post, or from TSP if you're more familiar with these types of problems), your processes will not migrate and you're wasting your time.

Implementation of this style of parallelization in a Beowulf cluster requires you to specify a node for a member to be calculated on, send all genetic material, and then await a response. This also requires writing a separate worker application on all other nodes, to accept the incoming genetic material and process it, as was mentioned in the post "Clustering, A Continuation…".

If you're already using a Beowulf cluster, Multiple GA parallelization is the easy way to go. A distribution like LAM/MPI will create identical copies of your GA on each slave node, so you don't need to fork() off any processes. For communication between slave nodes, it depends on whether or not you use blocking I/O.

For blocking I/O, you'll need to use your root node as a server to send material from slave node to adjacent nodes, in order to avoid nodes idling while waiting for adjacent nodes to get to an accept state.

For non-blocking I/O, you can use your root node to set up something called a gene-pool, where each process intermittently drops a little genetic material into the pool, then checks to see if there's any new material in the pool to grab. If not, it can continue on without waiting. This strategy can also be implemented with blocking I/O, but it's a little bit more convoluted.

That just about covers the basics for GA parallelism. Next time, I'll post my research from last semester, and then perhaps get into my new clustering scheme. Until next time…

"Solutions," and why that's in bunny ears:

Imagine you're trying to get from LA to NY. There's a lot of ways you could get there, or "solutions" to your problem. Different airlines, different connections, first class vs. coach; the list goes on and on. If you ask someone how to get from LA to NY, you'll get a myriad of answers, so it's not a problem where you can't find a solution, it's a matter of whether or not that solution is very good. It's not a good plan to book a first class non-stop flight when you only have $45 to spend, and if you're on a deadline, you'll need to be there without a three-day layover in Cleveland. Especially if you're allergic to Cleveland. I heard about a guy once….

Anyways, there's a lot of different variables that go into choosing the best way for you to get to NY. Now imagine this as a graph theory problem, LA and NY are at different ends of the graph, and all the different cities you could stop in on your way there are points on the graph inbetween the start and destination. The edges in the graphs represent where you can go (probably completely interconnected; every point connected to every other point). Now imagine on each of these edges, there's a weight or cost (associate with airline ticket costs, for our example problem). Since the graph is fully connected, there's a lot of ways to get from LA to NY, but which is best (AKA cheapest)?

Graph Theory and Why It Sucks So Bad

Graph problems, like the one described above, are notorious for being a royal pain. If you were to do the math a little, you would notice that the number of paths increases at an alarming rate when you increase the number of points in the graph. These problems typically fall into a category of problems called NP-Complete. The exact definition of an NP-Complete problem is several pages long, but it goes something like this:

A problem is NP-Complete iff there does not exist a polynomial time algorithm to find the optimal solution (least cost path from above).

A lot of optimization problems (problems with more than one feasible solution, and possibly more than one optimal solution), also fall into this class, as well as a similar class called NP-hard, which basically means it's very similar to some NP-complete problem, but has yet to be proven NP-complete by the full definition. Typical proofs to prove an NP-hard problem to be NP-Complete involve reducing an NP-hard problem to a form of an already proven NP-Complete problem.

On to GA, already…

So, GA is a handy-dandy little tool for solving lots of problems like these. First, you randomly generate a bunch of "solutions" (which for the sake of my math profs, I'll now call feasible solutions), and call them your population. Then you'll rank each of these members of your population.

Ranking, Elitism at its Most Useful
The ranking system can be very simple, or very complicated. For our example above, the simple version would be to add the costs on the edges in our path from LA to NY. This is known as a single-objective GA. A more complicated version might include shortest travel time, in which case the GA is attempting to minimize ticket price as well as travel time. This is known as a multiple-objective GA (MOGA).

Now that we've ranked our population, we need to use this information to our advantage, much like the young Hitlers we all want to be. Now that we've assigned each member a value and put them in their proper place, it's time to start the breeding.

Mating, as dirty as your nerdy mind wants it to be

There's a lot of algorithms for mating, but they all essentially do the same thing: take two members of your population (parents), and make two more (children). As in biological sexual mating, the children will share the traits of both parents.

Depending on the type of problem, you can make your mating algorithms simpler or more complex, but there are some industry standards: simple crossover, which simply takes a random combination of genes from each of the parents; and blended crossover, which takes the two sets of genes from each parent and blends them with a random weight (which works well cause sometimes kids look more like their dad than their mom, which can really unfortunate for little Sally with the hairy back).

Matching, dating for bits

The key part to dating for a bit is to put your best foot forward. Unfortunately, since its been a long time since ram manufacturers have included the "foot" option (though SanDisk is getting back to it with their new MP3 players), that's not always as simple as it sounds. So, we take more simplistic, and unfortunate methods. Each of these algorithms has its benefits and drawbacks (both real and theoretical), but I won't address them here. If you read between the lines, you can probably determine my preferences. I'm not a subtle writer.

Random Pairing
I really don't feel the need to go too indepth into this. It's random. Deal with it.

Best-First
Again, kinda simplistic. Take the two best and mate them, the third and fourth, the fifth and sixth, etc. Every generation, you end up with a new set super-jocks and down at the bottom your unfortunate group that has epilepsy with a side of polio.

Tournament Pairing
Create a tournament bracket NCAA March Madness style. Say that each member has a certain percent chance of winning each round in its bracket, based on its rank compared to its opponent. Each member is assigned a random number between 0 and their percentage. Whichever of the members has the larger number moves on to the next round. The better valued members will always have a better chance of winning, but statistically, the lower members still have a shot at being that cinderalla team.

Plutonium in the Water
Now I don't actually remember if plutonium is one of those horribly feared elements that'll cause you to grow a third limb if you look at it crosseyed, but everyone knows what I'm talking about.

Everyone in their family has that red-headed kid that nobody knows where his red-hair came from and suspects the milk man cause he's always been a little off and never looks mom in the eye, but maybe mom's a standup lady and that's just a random mutation. It can happen. Really.

After you've finished mating, the idea is to go through and randomly mutate a few genes, just to keep things interesting. There's actually a lot of reasons for mutation which I will address at a later date, but this will do for now.

Lather, rinse, repeat.

Now that you've done all this, it is highly recommended that you do it again. And again. And again. Thousands of times, actually. Each of these iterations is called a generation, and the more generations (typically), the better your answer will get. This isn't entirely true, but again, this discussion goes beyond the scope of a first time reader.

Now that everyone has a good idea of what GA is all about, I can continue my fireside chats about my research. Until next time…

So now, some more concepts.

I'm now limited by my limited knowledge of systems administration to a lam/mpi cluster. Not a shabby thing; MPI is a very powerful tool, and is much easier to configure than a mosix cluster.

The plan then? Worker apps!

Worker Applications

So, you've got this root node and these worker nodes. All process are created at runtime and stay in existence throughout the run of whatever it is you're doing. With GA, to mimic the work I did in mosix clusters, I would usually want to create a thread to compute each chromosome. Unfortunately, this isn't so hot for beowulf, cause that means creating popSize*numGens threads on startup. So instead, I creat a worker application, and run an instance of it on each worker node. This node will sit in an endless loop, like a server application, waiting for chromosomes to be passed to it, and it will then pass back the cost or value or fitness, whatever you like to call it, of the chromosome it evaluated, signalling that it can now accept a new chromosome.

The Problem

With mosix-style clustering, forking a process automatically creates a new process with all the chromosome information it needs, and then it needs to pass back a single variable (usually a float). With MPI style clustering, you have to pass all of the genetic material to the worker application using mpi_send() commands, much like with sockets, which means you have to specify the size of the data being transmitted, which in the case of large dynamic arrays for chromosomes means variable sized data transmissions are being sent and received, which makes your sending (and worker application) problem specific. This means that you're not writing library code (which means that it can be used for any old type of genetic algorithm problem), but instead writing problem specific code that you would have to one-off to make work for another problem.

So, I don't really like this plan much at all. I've also noticed that I've started talking alot about the genetic algorithm, so my next post will be a breif runthrough of that.