SETI@Home is far behind with only 16k.

                          

Some pictures of me moving, taken with my new HTC desire <3:

My old setup, stripped down already for moving.

My printer, which I was hoping might just appear at it’s destination due to uncertainty, but no such luck.

My new, temporary, setup @ my moms place.

Obviously, my final setup at my own studio will be over 9000 times more awesome :d

                          

Meanwhile I passed the 20k line with Milkyway@home and am going to soon with Einstein@home.

Don’t know what this is all about? Check out the Wikipedia article about BOINC and my previous blog post.

                          

Since I won’t use my Yahoo! address any more now, I’m also importing all my emails to GMail. Considering I have over 28k (which is over 3x >9000!), staring in may 2004, this is going to take a while though

                          

References

• Maps Ohloh project
• Semantic Maps Ohloh project

                          

What is Boinc? The Berkeley Open Infrastructure for Network Computing (BOINC) is a non-commercial middleware system for volunteer and grid computing. It was originally developed to support the SETI@home project before it became useful as a platform for other distributed applications in areas as diverse as mathematics, medicine, molecular biology, climatology, and astrophysics. The intent of BOINC is to make it possible for researchers to tap into the enormous processing power  of personal computers  around the world.

In essence BOINC is software that can use the unused CPU and GPU cycles on a computer  to do scientific computing—what one individual doesn’t use of his/her computer, BOINC uses. In late 2008, BOINC’s official website[6]  announced that NVIDIA (a leading GPU manufacturer) had developed a system called CUDA that uses GPUs for scientific computing. With NVIDIA’s assistance, some BOINC-based projects (e.g., SETI@home, Milkyway@home) now have applications that run on NVIDIA GPUs using CUDA. Beginning in October 2009, BOINC added support for the ATI/AMD  family of GPUs also. These applications run from 2X to 10X faster than the former CPU-only versions.

(Above text comes from the English Wikipedia.)

I’m participating in these programs cause I refuse to be part of the “let’s waste ~80% of our CPU time” attitude most people sadly enough have.

                          

1. I split the code into 2 projects: one holding the general GA code, which is now called GALib, and one holding the code specific to the TSP, now called Skynet (lol ). This allows for making any other GA implementation using GALib, even in .Net languages different from C#. The underneath diagram should give you a good idea of how the who thing works. The 4 most left classes are of Skynet, all remaining classes and interfaces are of GALib.

2. I rewrote the genotype of the Route individual type, the core of the TSP implementation. Instead of having a list of integers, referring to cities, I now have a list of Connection, each containing 2 instances of Location. I’ve done this to allow smarter crossover, decreasing the chance of not finding a better solution while it’s still in the converged search space significantly. As a result of this change, I also had to rewrite pretty much everything else of the Route class, including random initialization, mutation and fitness assessment. The biggest challenge here was preventing the creation of multiple loops in the crossover algorithm.

The interface of the TSP app (now called Skynet) also has seen quite some work. I figured out quite a lot of WPF stuff by further creating it. Some extra controls and progress indicators still need to be added though, and I also haven’t created the Cancel/Stop functionality.

Although the algorithm is efficient in the way that it takes relatively few generations to find a close to optimal solution, there remain a few mayor performance issues. If I compare the speed of evolution (measured in generations) with similar applications tackling the TSP, there are those performing up to 3 orders of magnitude faster. Although the fastest of those are written in C++ or C, I should be able to significantly speed up my application. Tracking down resource eating parts of code will be one of my next steps in developing this app. Another possible issue is diversity of the population. I have the suspicion that the diversity shrinks pretty fast, resulting into evolution driven only by mutation. I’m not sure of this though, and also have to investigate how I can prevent this from happening.

Here you have a few screenshots of the app in action