Faster Chips Are Leaving Programmers in Their Dust

mlimber writes "The New York Times is running a story about multicore computing and the efforts of Microsoft et al. to try to switch to the new paradigm: "The challenges [of parallel programming] have not dented the enthusiasm for the potential of the new parallel chips at Microsoft, where executives are betting that the arrival of manycore chips — processors with more than eight cores, possible as soon as 2010 — will transform the world of personal computing.... Engineers and computer scientists acknowledge that despite advances in recent decades, the computer industry is still lagging in its ability to write parallel programs." It mirrors what C++ guru and now Microsoft architect Herb Sutter has been saying in articles such as his "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software." Sutter is part of the C++ standards committee that is working hard to make multithreading standard in C++."

Comments

Re:Thank god

[zifn4b]

The only significant thing that managed languages make easier with regard to multithreading other than a more intuitive API is garbage collection so that you don't have to worry about using reference counting when passing pointers between multiple threads.

All of the same challenges that exist in C/C++ such as deadly embrace and dining philosophers still exist in managed languages and require the developer to be trained in multi-threaded programming.

Some things can be more difficult to implement like semaphores. You also have to be careful about what asynchronous methods and events you invoke because those get queued up on the thread pool and it has a max count.

I would say managed languages are "easier" to use but to be used effectively you still have to understand the fundamental concepts of multithreaded programming and what's going on underneath the hood of your runtime environment.

Sameless Plug: Qt 4.4

[scorp1us]

Full disclosure: I am a Qt Developer (user) I do not work for TrollTech

The new Qt4.4 (due 1Q2008) has QtConcurrent, a set of classes that make multi-core processing trivial.

From the docs:

The QtConcurrent namespace provides high-level APIs that make it possible to write multi-threaded programs without using low-level threading primitives such as mutexes, read-write locks, wait conditions, or semaphores. Programs written with QtConcurrent automaticallly adjust the number of threads used according to the number of processor cores available. This means that applications written today will continue to scale when deployed on multi-core systems in the future.

QtConcurrent includes functional programming style APIs for parallel list prosessing, including a MapReduce and FilterReduce implementation for shared-memory (non-distributed) systems, and classes for managing asynchronous computations in GUI applications:

        * QtConcurrent::map() applies a function to every item in a container, modifying the items in-place.
        * QtConcurrent::mapped() is like map(), except that it returns a new container with the modifications.
        * QtConcurrent::mappedReduced() is like mapped(), except that the modified results are reduced or folded into a single result.
        * QtConcurrent::filter() removes all items from a container based on the result of a filter function.
        * QtConcurrent::filtered() is like filter(), except that it returns a new container with the filtered results.
        * QtConcurrent::filteredReduced() is like filtered(), except that the filtered results are reduced or folded into a single result.
        * QtConcurrent::run() runs a function in another thread.
        * QFuture represents the result of an asynchronous computation.
        * QFutureIterator allows iterating through results available via QFuture.
        * QFutureWatcher allows monitoring a QFuture using signals-and-slots.
        * QFutureSynchronizer is a convenience class that automatically synchronizes several QFutures.
        * QRunnable is an abstract class representing a runnable object.
        * QThreadPool manages a pool of threads that run QRunnable objects.

This makes multi-core programming almost a no-brainer.