The Day the LOLcats Laughed

I don’t know about you, but I feel like we have just witnessed the beginning of a new era. The Internet stood up to Congress and to the Senate and won. We have defeated SOPA and PIPA. Big corporations represented by MPAA (Motion Picture Association of America) and RIAA (Recording Industry Association of America) sponsored those bills and they spent huge amounts on lobbying in Washington. They were so close to having their wishes granted and then, unexpectedly, a spontaneous grass-root protest movement organized with the help of the Internet defeated them. Of course this is not Libya or Syria — people’s lives are not in danger, our system is based on democracy, and we have our rights. But those rights sometimes need defending.

I don’t expect everybody to spend time studying SOPA and POPA in depth, but we (still) have the Internet to provide intelligent explanations and summaries. I like this short video by the Khan Academy. It explains in simple terms what a disaster SOPA and PIPA would have been if they were written into law.

So what has just happened? A group of people — programmers, content providers, the Internet crowd — suddenly realized how much power they have, and were able to put politicians on notice. The Big Blackout of 1/18/2012, with the participation of major sites like Reddit, Wikipedia, WordPress, and many others, was extremely effective. Those sites took a big risk, and they succeeded because of overwhelming support for their actions.

But as Wikipedia says, the fight isn’t over yet. I’m sure MPAA and RIAA are hard at work trying to sneak another law that would give them power to block any site on a whim and without recourse. We should remain vigilant. But, in the meanwhile, why not rectify some mistakes from the past?

Mickey Mouse Laws

The logo of the opposition to the Mickey Mouse Protection Law

Don’t get me wrong, content creators deserve copyright protection. Just like inventors deserve patent protection. Patents expire after 20 years; but the Mickey Mouse Law provides copyright protection for a century. This is how long we have to wait until copyrighted material enters public domain.

Walt Disney is long dead but every time the copyright on his works nears expiry, the Congress enacts a new law that extends its reach.

If I drew a Mickey Mouse in my blog I’d be sued by the Disney estate (and, if SOPA passed, WordPress would be taken offline).

Do you know what was invented 100 years ago? Motorized film cameras — the replacement for the hand-cranked ones. If patents were valid as long as copyrights, the motion picture industry would still be paying patent fees to the great-grandchildren of Kazimierz Prószyński.

Copyright laws were originally designed to protect artists but have since degenerated into corporate welfare. Works of art and cultural icons should become part of public domain in reasonable time, before we and our children die. So why don’t we start writing letters to our representatives asking them to abolish Mickey Mouse laws and settle on something that would actually encourage creativity. It’s time to release poor Mickey from the corporate prison.

 

Virtual Machines: The Traps and The Thin Hypervisor

I have released the final part of the series on virtual machines, The Thin Hypervisor. It’s a very promising technology that allows you to virtualize a running OS on demand. My previous blog entry is a recommended reading before this one. It explains how the hypervisor interacts with the operating system.
Follow @BartoszMilewski
(You can also follow me on Google+, if you search for Bartosz Milewski.)

 

2011 in review

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 180,000 times in 2011. If it were an exhibit at the Louvre Museum, it would take about 8 days for that many people to see it.

Click here to see the complete report.

 

Virtual Machines: Virtualizing Virtual Memory

My new blog about virtual machines is out. It gives a peek at the tricks used by hypervisors to fool the operating system into running in a virtual box. I discuss nested page tables, shadow page tables, tracing, hidden page faults, and other interesting goodies.
Follow @BartoszMilewski
(You can also follow me on Google+, if you search for Bartosz Milewski.)

 

Virtual Memory

I started a new series of blogs about virtual machines. It’s a relatively exotic technology but the ideas behind it are simple. As an introduction, I explained how virtual memory is implemented by the operating system.
Follow @BartoszMilewski
(You can also follow me on Google+, if you search for Bartosz Milewski.)

 

Supercomputing: An Industry in Need of a Revolution

How would you like a job in the supercomputing industry? Programming those powerful Ks, Jaguars, Roadrunners, Blue Genes, or gigantic clusters of computers? How inspiring would that be?

Not much, according to the luminaries of the field. I went to a panel about the future of supercomputing at SC11, and learned that the future is… Fortran, MPI, OpenMP and CUDA. I have no reason to doubt the experts; after all some of them were with the industry when it was all ferrite core memory and punch cards. But it makes me wonder if there is a future at all for supercomputing, if things keep going in this direction.

Let me explain: Programming in Fortran, MPI (Message Passing Interface), OpenMP (a system of annotations for C or Fortran to help the compiler parallelize the program), and CUDA (Compute Unified Device Architecture for programming GPGPUs) is tedious, uninspiring, and boring.

I talked to a CS student who was demonstrating his summer work at the booth belonging to one of the large national labs. It was a project to improve Monte Carlo simulations of some physical processes. It was done, unsurprisingly, using MPI and OpenMP. I asked him what the exciting part of the job was. It was the learning of the Monte Carlo method. The rest was the tedium of combining barely compatible clunky programming paradigms into a workable program.

Why does it matter? Because a thriving industry or a company must attract talent. And talent can’t be bought, at least not easily. There was once a study, which showed that, above a certain compensation level, talented people don’t care so much about salaries as they do about the novelty, excitement, and freedom. Google knows it very well: They create an exciting work environments (I call them day-care centers for programmers), and encourage their employees to spend 20% of their time pursuing their own projects. No wonder there is an underground pipeline from Microsoft to Google through which the talent keeps leaking out.

By the way, I worked for Microsoft back when it was exciting. Our salaries were rather mediocre, but we felt the urge to work long hours and weekends because we felt that our contributions mattered. Unlike today, sales and marketing were not driving the company, developers were.

To confuse matters even more for the executives, programmers are relatively cheap. The cooling bill for a data center dwarfs the cost of software development. Let’s face it, from a distance, a programmer might look just like another commodity, like a computer rack, air conditioner, or a router. This is even more pronounced in supercomputing, where a single rack might go for a million dollars–an equivalent of 10-20 programmer/years.

If you drain all the excitement from work, your company, or the whole industry, is bound to stagnate. Bored people don’t innovate. And we know from experience that, in high tech industries, if you don’t innovate, you die. Old programming paradigms might have worked for years, but new unmet challenges are piling up. A lot of work that required supercomputers in the past is now done on clusters of off-the-shelf components. Google owns one of the largest supercomputers in the world, and it’s all built from cheap commodity boxes. But Google lets its people innovate.

But not everything is bleak in the land of supercomputers. I have met two teams that were brimming with ideas and enthusiasm: one was Brad Chamberlain’s Cray Chapel team and the other was Hartmut Kaiser’s Louisiana State University Ste||ar team. I’m sure there were many others, but those were the ones I had the pleasure of meeting outside of the exhibition hall.

You can tell that a team is dedicated to a task if they can’t stop talking about their work even after a few beers. Young creative people are attracted like moths to interesting and challenging projects. I don’t think writing simulations using OpenMP and MPI, even if they run on Cray X-MP, can generate this kind of enthusiasm.

 

C++11 Concurrency Series: 9. Condition Variables

The latest tutorial is out. I talk in some depth about condition variables and then show how to use them in constructing a message queue. I use the message queue to implement message-passing server threads.
Follow @BartoszMilewski
(You can also follow me on Google+, if you search for Bartosz Milewski.)

 

Supercomputing in Seattle

I firmly believe that supercomputing of today is the mainstream computing of tomorrow. A year and a half ago I wrote a blog about the future of concurrent programming based on new developments in systems and languages in the HPC (High-Performance Computing) community. Hopefully, this year I’ll learn more at the SC11 conference that’s taking place in Seattle in November (my employer, Corensic, will have a booth there). I’m especially interested in Chapel, the HPCS (High Productivity Computing Systems) language under development by Cray Inc., also here in Seattle. There will be a whole-day Chapel tutorial at SC11, which I’m going to attend.

Why Chapel? Whenever I go to a conference and hear about a new language development to support parallel programming, I immediately compare it with Chapel. Chapel does task-based parallelism better than Cilk, TBB or PPL; data-based parallelism better than AMP or ArBB; generic programming better than D (sorry, Andrei, I’m really partial to concepts) — the list goes on. It’s unfortunate that Chapel is pigeonholed as an HPC language, because it’s perfectly adequate for general purpose programming. In fact I installed it on my laptop and wrote a few programs in it.

A lot of HPC is dedicated to scientific computations, modeling of complex systems, and processing of large quantities of data. That’s where parallel and distributed programming shines. There is no doubt in my mind that the kind of computational power that’s used in scientific computations today will soon be available on game consoles, desktops, and then on tablets and smartphones, likely in concert with cloud computing. But we are not going to use our iPhones to simulate chain reactions in nuclear warheads or heat conduction in rocket engines, are we?

So what everyday tasks could benefit from this kind of power? Obviously the game industry has insatiable appetite for computing resources. Enhanced and virtual reality are peeking from around the corner. Speech recognition and natural language processing have already made inroads into smartphones. But I’m sure that, once the power is there, we will find plenty of new and unexpected applications — If you build it, they will come.

The question is: How do we write programs that can harness the power of multicores, GPUs, and distributed systems like the Cloud — possibly all three at the same time? One thing I know for sure: Not by painstakingly managing threads, locks, message passing, copying of data over the network, etc. And this is where the current C++ (C++11) is stuck, and Chapel blazes the trail.

The major advantage of Chapel, in my mind, is that it separates the logic of the algorithm from the details of its implementation on a particular system. In the ideal world you would write a program in a high-level language and the compiler plus runtime would figure out how to run in on a particular system — what can be run in parallel, which parts can be delegated to GPUs, which parts can migrate to other machines on the network, and so on. Well, we can always dream! In reality the programmer must still tell the compiler all those things. Yes, you can do this in C++ but you’ll make your code totally unreadable. The details of implementation would quickly obscure the heart of the algorithm.

In Chapel, you express parallelism in terms of tasks; not threads, thread pools, processes, or computers. You express communications in terms of shared global address space that can span whole clusters of computers. Separately, on the side, you describe the distribution of computations in terms of locales. Each node on the network is a separate locale. Each GPU is a locale (this feature is still under development). You define your data structure in global address space, but you separately describe how you would like it to be cut up and distributed between various locales.

You may see elements of this approach in other languages, libraries, and language extensions, but never in such comprehensive manner as in Chapel. Tasks, for instance, appear in Cilk, PPL (Parallel Pattern Library), and TBB (Threading Buildg Blocks), together with elements of data-driven parallelism. Intel extended its TBB library to ArBB (Array Building Blocks); Microsoft came up with a C++ extension, AMP (Accelerated Massive Parallelism); AMD put its weight behind OpenCL — everybody and his brother are trying to catch the wave of parallelism and high-throughput computing. It just so happens that the HPC crowd has been riding this wave for a long time and there’s a lot we can learn from them.

Which is why Seattle will be hot during the week of November 12-18, no matter what the weather reports predict.

Additional Links

1. Chapel events at SC11
2. SCC11 schedule
3. Birds of a Feather, Chapel Lightning Talks

 

C++11 Concurrency Series: 8. Data Races

In this tutorial:

• I summarize safe ways of passing arguments to threads, and their gotchas
• Show an optimization of monitors based on epochs, together with its maintenance pitfalls
• Debug the resulting data race

Follow @BartoszMilewski
(You can also follow me on Google+, if you search for Bartosz Milewski.)

 

C++11 Concurrency Tutorial: 7. Mutex, Lock, and Monitor

Why did I do six concurrency tutorials without mentioning mutexes? I think people resort to explicit locking much too early. In this installment I compare two implementations side by side and the results might be surprising. One is moving data between threads (the new C++11 move semantics), the other is using a shared monitor. Whatever the overheads of copying or locking are, they are drowned by the work the threads are doing; and locking is much more error-prone (especially if you try to optimize it).
Follow @BartoszMilewski
(You can also follow me on Google+, if you search for Bartosz Milewski.)