Agner`s CPU blog

This means that there will be less interference between threads unless both threads have a lot of floating point or SIMD code. So far so good, but it will be very difficult for the operating system to detect if threads are FP/SIMD intensive and to move such threads around to avoid interference. And it is even more difficult to predict whether instruction fetch and decoding will be a bottleneck. There will probably be a buffer after the instruction decoder, but that doesn't help if there are many branch mispredictions.

The fact that different processors share different resources between threads makes it very difficult for software developers to optimize their code. You may have to test an application on several different processors in order to detect whether it is advantageous or not to run two threads per core on each particular processor. Processor-specific optimization is generally a bad idea because the software has to be updated every time a new processor appears on the market. Ideally, there should be CPUID feature bits to tell exactly which resources are shared and which resources are not shared between threads; and the programmer should make a code that predicts whether it is optimal to run one or two threads per core based on what resources are critical to that particular application and whether these resources are shared or not.

I can't wait to get access to the new AMD processor to test how much interference there actually is between threads.

References:
phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9MjAzMzJ8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1
phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9MjAzMjd8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1
www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137216
www.theregister.co.uk/2009/12/14/amd_bulldozer_preview/

This message modified 2010-03-19.