Here are some of the most important things you should take with you from this presentation:

Parallel processing can significantly reduce wall-clock time

The whole reason for getting involved in parallelism is to reduce the time you spend waiting for your results. The characteristics of algorithms virtually insure that there will be points in most applications where significant savings can be achieved by judicious use of parallelism.

Writing and Debugging Software is More Complicated

Parallelism involves at least an order-of-magnitude more complexity in your code -- this need not be evident in the code that you write, but will certainly be evident in the size of the executable that results. The important aspect, of course, is the conceptual complexity that has been added, which has immediate implications for its debugging and maintenance.

Parallelization is not yet fully automatic

You'll have to assume that whatever parallelization is needed, you'll have to provide. There are specific situations where you'll be able to get away with as little as adding a few parallel-directives as comments in your still-serial source, but this is not yet a commonly-encountered scenario.

Overhead of parallelism costs more CPU

Parallelism doesn't come for free; not only do you have to do more work, but so does the computing system, and parallelism itself involves additional effort in terms of process-control: starting, stopping, synchronizing, and killing. Besides this, parallelism requires that, in general, both code and data exist in multiple places, and getting them there involves additional time as well as the additional space needed to hold them.

Decide which architecture is most appropriate for a given application

The characteristics of your application should drive your decision as to how it should be parallelized; the form of the parallelization should then determine what kind of underlying system, both hardware and software, is best suited to running your parallelized application.