M$ says multicores no good without software threading

[Alpine]

Kicks off FPF day two with a big problem

DAY TWO OF MPF was kicked off by Herb Sutter of Microsoft talking about software and how to deal with the trends of current hardware. Massively multicore CPUs need massively multicore aware software and tools. One without the other doesn't get you far, and both sides seem to realise this.


The main problem is that the state of concurrency in modern software is pretty poor. Single threaded software is going to benefit almost nothing from the up and coming trends in software, 10,000 cores will not speed up a single threaded app. To get more speed, you need an advance much more profound than current out of object oriented programming. You need to get past locks.

On the server side, no problem. If you have 1000 people hitting your web server and can dedicate a core to each, things will positively fly. If you have a game that has a single critical thread, you are going to get some pretty lame frames d00d.

If you do manage to get you feet wet in massively multithreading programs, you have the harder problem of massively multithreaded debugging to deal with. Herb Sutter is pushing for hardware designers to think more about programmability of their new designs. If you come out with something that has 256 cores and runs billions of benchmarks/sec, great, but if you can't program it, you have a very high complexity doorstop. To get around this, you need concurrency in programming languages and paradigms, and you need new abstractions.

There are three problems that this may help with. Free threading is the first, where you can make threads and do whatever you want. You need a higher level of abstraction and to not explicitly define threads. Then there is mutable shared state, a world without locks. Locks can cause problems that may not show up for generations of hardware, and are just about impossible to test for. Last is that there are no languages not considered experimental. No languages means no real ability to write software.

So, what do you do? Start out with apps that have lots of concurrency at every level. Not that all problems can be broken down, but if you set out to write more concurrency in from the start, you end up with more at the end. Then you write apps that don't have threads explicitly designed, but more threads spawned when they are needed by the software. Last you need tools that help you do this. It may seem like a 'no, really?' situation, but until people start making the tools, people who don't want to write the tools can't use those tools. There is a lot of work to be done, and Microsoft, amongst a host of others, both in academia and industry are working hard on it. There are a ton of ideas and projects, but no clear winner here yet. In this case, hardware designers can help by making things easier to program. Together, we will get there eventually.

The INQuirer