I was recently introduced to the Two Generals' Problem at work as a thought experiment illustrating the impossibility of perfect coordination over an unreliable communication channel. I thought of a solution that doesn't require any improbable assumptions. Here is my algorithm:
1) Tell a group of messengers a time to attack
2) Send them all across at once
3) At equally spaced intervals along the route, have them leave one person behind such that each person left behind can see the last person left behind.
4) If at any time someone is captured, relay the "error" message backward and forward via each node. The sending general then sends more messengers to rebuild the link if it hasn't already been completed and increases the time of attack into the future. If someone was captured in the middle, when the message gets to the pack of traveling messengers, they invalidate their time and wait for a new time.
5) If the sending general doesn't get any notices of capture back before the attack time he sent out, he attacks. If the receiving general gets the message and no invalidations after some timeout, he attacks at the time he got.
After a lot of argument, I convinced my coworkers (volkan and peter) to accept this solution with only two easy assumptions:
1) That sight is a reliable communication channel (there are no mirages)
2) The time to cross the valley via foot and via sight hops can be bounded.
There are cool new built-in objects added to python 3.0 (and backported to 2.7), called memoryview's. They basically represent mutable subsections of data. Here's some examples of why they are awesome:
A naive way to write a large string of bytes to a socket:
sent = 0
while sent < len(message):
sent += sock.send(message[sent:])
This makes many unnecessary copies of message. You can imagine how bad it performs if message is 1GB long and the client only receives 1K at a time.
You can improve this by using Python's lesser known buffer built-in, which is like a memoryview except it's read-only:
buf = buffer(message,0)
while len(buf):
buf = buffer(message,len(buf) + sock.send(buf))
This doesn't make any copies of message.
But what if I want the equivalent for efficiently receiving data from a socket into a single buffer without having to allocate a bunch of small strings in the loop? Naive way:
msgparts = []
while True:
chunk = sock.recv(1024)
if len(chunk): msgparts.append(chunk)
else: break
message = ''.join(msgparts)
Awesome memoryview way:
view = memoryview(bytearray(bufsize))
while len(view):
view = view[sock.recv_into(view,1024):]
Slicing view just returns a new memoryview, so there aren't any unnecessary string allocations.
I think mutable views of data are one of the major missing pieces of python. A language shouldn't force you to make copies of data as it can be very inefficient. memoryview is a good first step. Next I'd like to see more built-in objects support operations involving views. For instance, a string operation like string.vsplit that is the same as string.split, except instead of returning a list of new immutable strings, returns a list of memoryviews so that the data is never duplicated.
It's not often I come across evidence of Steve Jobs' fallibility, so I'm biting on this opportunity to write about it. Here is his statement taken from Apple's press release announcing their patent infringement lawsuit against HTC:
"We think competition is healthy, but competitors should create their own original technology, not steal ours."
Patents were created to encourage R&D with societal benefit by letting companies profit from a temporary monopoly on technology they create. The whole point is for the technology to be disclosed so that people can eventually copy it. If every inventor had to reinvent the wheel in an original way before getting to build the car, we'd go nowhere.
Steve Jobs may not think its "fair" for people to copy the iPhone, but after some period of time its not really "fair" that I have to pay an absurd amount of money and deal with a terrible cell network for a phone with decent UI. They can't hold the monopoly forever.
So nobody is "stealing" your technology, Steve. You gave it to the world, and we've already thanked you with those multi-billion dollar quarters for three years. You should spend all that bread on more innovation instead of lawsuits.
Magnum is an HTTP server that I've been working on and decided to create an open-source project for it. The aim of the project is correct the misguided direction of modern web serving software. By focusing on efficient resource management down to the operating system level, Magnum can run faster than most servers written in compiled code (such as apache), can handle more simultaneous open keep-alive connections, and works well with slow clients. Because it's written in python, it's short and sweet, extensible, and integrates well with python web frameworks such as Django. The easiest way to explain its architecture is with this diagram:
A similar python-based webserver called Tornado was recently released by Facebook, and has many similar features such as epoll. I decided to release mine anyway since it has numerous advantages. For one, Tornado is a single-process web server, and they recommend using nginx as a reverse proxy on top of several instances of Tornado to use all the available resources on a machine. Magnum's multi-process approach is fully integrated and there are no unnecessary middle-man sockets tying up kernel resources.
Secondly, since Tornado only has one process, it cannot support blocking web app interfaces such as WSGI without turning off the epoll features that make it interesting. Magnum's non-blocking master process simply offloads every request it gets onto a shared memory queue, the worker processes can take however long they want to process each request, and the master process just picks up the response and sends it off when the worker is done. Magnum supports WSGI out of the box, and in fact mattgattis.com is now proudly serving this page with Magnum + Django over WSGI.
Anyone interested is welcome to contribute. I'll follow up with benchmarks.
With the release of OS X 10.6, Apple included libraries and device driver support for a platform of general-purpose GPU computing known as OpenCL. This allows developers to run parallelizable code on graphics cards. I decided to give it a spin since a lot of the machine learning work I do could benefit from parallel processing, and while modern CPU's can give us around 16 parallel threads of execution, modern GPU's can give us hundreds of threads by design.
I started off by trying a simple matrix multiplication program, which in theory can be easily broken into many threads. If you recall from linear algebra class, the multiplication of two matrices results in a third matrix where the element at row i and column j is calculated by taking the dot product of row i in the first matrix and column j in the second matrix. Since each element can be determined independently of the rest, this makes it perfect to split up the work into multiple threads. A familiar task for me is to multiply a random 200000x120 matrix by a random 120x120 matrix, as I've had to heavily optimize this task on a CPU, and on a multi-core CPU the heavily optimized version takes around a second.
First off, I found the lack of documentation and sample programs a little frustrating. OpenCL is so new that there isn't much out there. I started off with a python project called PyOpenCL, written by Andreas Klockner who has done a great job. It's still really early software, so it took a while to get up and running. Andreas was nice enough to fix a bug upstream that was blocking me. I used the matrix multiplication OpenCL code in nVidia's shared memory example, ran it on a MacBook Air with an nVidia 9400M GPU, and the GPU code was consistently about 9x slower with 32-bit floats.
I eventually came across a bunch of OpenCL example programs hidden in nVidia's CUDA SDK, which is a similar language to OpenCL, but works only on nVidia cards. There is a sample matrix multiplication C++ program that will multiply matrices of any size, so I tried that. It took about 8s to multiply my favorite matrices, much worse than I've gotten on a CPU. To make sure I wasn't doing something wrong, I then tried multiplying the matrices using CUBLAS, a heavily optimized matrix library that runs CUDA code on the GPU. 5 seconds there.
Turns out that instead of matrix multiplication being many times faster on GPUs, it can be many times slower. The reason is that matrix multiplication is memory bound. It takes longer to transfer the matrix tiles over to graphics card via the PCI Express bus than it does for the CPU to access the memory and do the multiplication and addition operations on many fewer threads. I verified this by using smaller ints instead of floats and got a significant speed-up. Next thing I want to try is running these tests on a better GPU. The 9400M on the MacBook air has a max memory bandwidth of 17.1 GB/s, while nVidia's latest and greatest, the GTX 285, claims 159 GB/s. The 9400M also doesn't even have its own local memory to cache tiles... it has to share system memory. At most though, I think I'm looking at a 2-3x speed-up multiplying my matrices, which is a lot less than I expected.
So long story short, took a long time to do something simple with OpenCL, and the GPU strengths aren't quite there yet to make it worthwhile for my problem. No doubt there are computations out there better performed on a GPU, but I don't really believe the marketing hype that says GP-GPU is going to make every-day applications run faster (yet, at least).
If you're interested in reading more about shortcomings of the GPU, I recommend reading Tim Sweeney's slides. I read this a few months ago, re-read it after this experiment, and it's interesting that his ultimate conclusion is the same as mine- GPGPU programming is too hard and limited, and the non-unified memory architecture is a big problem. Maybe I will put my money on the CPU... or on AMD/ATi since the synergies there might give us a nice hybrid architecture.
Hunch.com is open to the public! (*kazoo* *kazoo*)
Can't believe I've been working on it for two years now. It has certainly come a long way and been lots of fun. We've gotten some great coverage in the news already, including national television.
If you don't know what it is, it's a website that helps you make decisions by asking you a bunch of questions and delivering a customized recommendation. The cool part is that all the content is user-generated, from the topics to the questions to the results, and there is a pretty sweet machine learning algorithm that figures out what to tell you based on feedback from other users.
Curious? Try this embeddable version for picking a credit card.
My building finally got wired for FiOS (Verizon's fiber optic service). I had it installed today and am quite impressed!

If you don't understand these numbers, they basically mean I am unstoppable.
Speaking of domain names, I just learned today from a friend that you can register unicode characters in a domain if you use registrars that support "IDN" (Internationalized Domain Name). DomainSite.com was the only good one I can find. Now you can visit my blog from these awesome domain names:
I am told by my Chinese sources that the sword-looking character means "heart".
Yahoo raised their auto renewal rates for domain names to $34.95/year. They started out at $9.95 which makes this more than a 3X hike! I guess they are just betting that their customers are too lazy to transfer their domains elsewhere. Bad bet in a down economy. MattGattis.com is now registered via NearlyFreeSpeech.net. They have an interesting business model which is called good customer service and charging fair prices.
Here are some celebs I've seen around the city.
Dennis Rodman:

Chevy Chase:

Richard from Guess Who:

Happy 2009! '08 was not a bad year all-in-all. Dolphins made the playoffs, the GOP is no more, and it seems global warming is appearing to be less likely. The Earth's temperature actually got colder in '08.

Democratic Party Nominee for President of the United States
"I found a flaw in the model that I perceived is the critical functioning structure that defines how the world works, so to speak."
The history books aren't going to look too good for Alan Greenspan. He will probably go down as the man most responsible for this global financial crisis. He'll get credit for both the housing bubble and the debt crisis for keeping interest rates low and successfully blocking regulation on derivatives.
At least he's honest though. Hopefully now that the strongest supporter of deregulation has realized it doesn't work, the whole objectivist / neoliberal / reganomic theory will be put to rest.

I've never been a fan of Boston's poor excuse for a public transportation system. I'm not sure what combinations of failures led to such a poor system for getting around in such a tiny city. It has been in the news lately because a few MIT students exposed holes in basically every security measure it uses (including getting unlimited free rides from the RFID cards). The MBTA responded by suing the students and trying to prevent them from revealing their findings. The court ultimately found that this last ditch security measure was not valid, and it failed like the rest of them. I've read through their presentation, and I'm thoroughly impressed. Plenty of social engineering along with brute-force tactics aimed at weaknesses. It's still pretty embarrassing how easy the MBTA made it for them though. Without further adieu, here's the presentation:
http://www-tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf
A security researcher named Dan Kaminsky released a fundamental flaw in the design of the internet today that allows hackers to, among other things, send you their own web pages when you request a url such as "google.com". The flaw lies in the DNS system that translates domains to IP addresses (numbers that identify your computer on the internet). When you make a request for google.com or any other domain name, you ask your ISP what the IP address for that domain is, and then you connect to that IP address. Kaminsky published a way for an attacker to flood any ISP implementing the DNS protocol with requests in a way that sends other users to any IP address the attacker wishes.
Here is his webpage. He also has a tool that allows you to check whether your ISP has patched their system yet.
The manhattan solstice takes place yesterday and today. Every year at this time, the sun sets between every street in manhattan. Wikipedia has a more detailed article about it here. Here are some pictures taken from various streets walking up 6th avenue that I took yesterday around 8pm.
This is one of the most incredible stories I've read recently. Apparently tribes still exist in the rainforest of Peru and Brazil that (in the year 2008!) have never been contacted by the outside world. Here is a picture taken by a plane flying over the area, which they must have thought to be a bird or evil spirit.

From the article,
"It is extraordinary to think that, in 2008, there remain about a hundred groups of people, scattered over the Earth, who know nothing of our world and we nothing of theirs, save a handful of brief encounters."

This article is pretty interesting. It points to research done by Dr. Tadeusz Kawecki which indicates a negative correlation between intelligence and evolutionary fitness. They basically bred smarter flies by putting 15 successive generations through intelligence tests that determined their fate. It turns out these smarter flies die 20% faster than normal flies in typical fly conditions.
It's really no surprise then that not many animals are nearly as smart as humans. From the article, "Dr. Kawecki suspects that each species evolves until it reaches an equilibrium between the costs and benefits of learning... Humans' oversize brains require 20 percent of all the calories burned at rest. A newborn's brain is so big that it can create serious risks for mother and child at birth. Yet newborns know so little that they are entirely helpless. It takes many years for humans to learn enough to live on their own." So what is the great benefit to being so smart?
I added a brief bio and some links to the site. You can find it here if you're interested. Just don't stalk me or anything.

Photo courtesy of Ellen Campbell (click to enlarge)
So this is where Bernanke has been getting his advice lately. Hopefully Ben won't end up like Brazino here, found by my friend Ellen on her lunch break in DC today.
It took me a while to get around to it, but I've finally launched the site. Thanks to everything that made this possible:
Stay tuned for the launch party details!