Lunch was some big tasty sandwiches but the talks were better. We got onto the topic of parallelism which was quite interesting.  Scott Guthrie  got up onto the whiteboard to talk about scaling applications

List<person> people
for(i=0;i<people.Length(); i++)
{
   person.DoTask();
}

this code will not scale as the interpreter cannot easily split this code across processors. As a programmer you may be able to write some code that starts new threads and does locking but it might perform even worse (due to managing your locks) or might work on two processors but will not scale up to 400 cores

The power comes from lamda expressions and extension methods  in .NET 3.0
people.With(p=>person.DoTask())

By using this technique the compiler should be able to split the tasks across cores/processors. Note that the .net framework does not do any balancing across cores/processors but by this is the best way to deal with parallelism in the future (Well this week anyways)

A few of us had a talk about why we should worry about parallelism. If you have a task that needs to perform well then it is obviously to your advantage to program for multiple cores. The point I brought up is that if you have a simple task that 100 people are using simultaneously then each person will run one after another (basically). If you code to make it parallel you will not get much advantage. The advantage will be that the OS will more of the simple tasks simultaneously so that there is not a huge queue. Trying to use multiple cores in this scenario might actually hurt performance as now more cycles are spent allocating and managing threads instead of just allocating a core/user. Either way you have to be careful and think about these things.