Which is better: AMP or SMP?

This is an argument that will never end, much like C vs C++, VI vs Emacs and Windows vs Mac OS vs Linux. There is no right answer to any of these questions, well, nothing better than 'it depends'. (though for me the OS war has been won by Apple hands down).

With regards to Asymmetric Multi Processing versus Symmetric Multi Processing on a multicore processor, one of the arguments is convenience vs performance. In convenience SMP clearly wins, running multiple processes on an SMP OS puts the scheduling responsibility at the OS level, where in an AMP configuration the user has to make the first level decision as to which instance of the OS the processes and threads should go.

The performance argument is not so easily settled. Raw computing performance is usually better served by AMP. Especially when the number of cores increase significantly, scheduling on a single core is more efficient and scalable then scheduling over many cores, the kernel (scheduler) can become a bottleneck if the number of processors scale up. Of course, this all depends on your processor architecture, cache and memory layout and speed, operating system, configuration of all these and your application.

In my experience the best way to settle these arguments is to run measurements on different configurations. This also came up in a book I read over the weekend by Max Domienka, "Software Development for Embedded Multi-Core Systems, a Practical guide for using embedded Intel(R) architecture". Chapter 9 talks about Virtualization in detail and lists a number of use cases for different industries.

Chapter 9.4 especially talks about a telecom case study of partitioning of 2 dual-core Intel Xeons into either a 4-core SMP configuration or 2 2-core AMP configurations, both running Linux. The board used has 2 separate ethernet cards that can be assigned to the partitions. The book has a lot of detail on both the configuration performance measurements of running network traffic to the partitions. A summary of the end-result is that for large frame sizes, the difference is very small, but for small frame sizes (under 1024 bytes) the difference is significant (10% and up).

The result here is what I would have expected, smaller packets mean more interruptions, more scheduling and hence an advantage for the AMP configuration.

The rest of the book is a good read as well, it has a good developer level coverage (it does cover disassembly of application at one point) of the technologies involved and has pointers to resources with more information on low-level details where required.