measure your application performance. anything else is BS.

well not really as we have different CPU's from Intel and AMD and we want to see how these benchmark without benchmarking the apps(s) as apps are many and benchmarking them all against all the apps is not possible.

Tom Brown wrote:

...

measure your application performance. anything else is BS.

well not really as we have different CPU's from Intel and AMD and we want to see how these benchmark without benchmarking the apps(s) as apps are many and benchmarking them all against all the apps is not possible.

In this month's IEEE Spectrum magazine there is an interesting study on multi core CPUs and 'intensive computing' done at Sandia labs Seems like with the current data bus architecture, 8 core is the max for data access intensive applications like data mining. So I am thinking that if you need to move lots of data for your applications, the CPU is not the limiter, it is how the system moves data into and out of the CPU(s) that needs to be considered.

On Thu, Nov 13, 2008 at 05:40:04PM +0000, Tom Brown wrote:

...

measure your application performance. anything else is BS.

h well not really as we have different CPU's from Intel and AMD and we want to see how these benchmark without benchmarking the apps(s) as apps are many and benchmarking them all against all the apps is not possible.

Published Spec benchmarks are valuable in this fuzzy context.

Once you have your application benchmarked, tools like "lmbench" may help you understand what the win/loss keys are.

http://sourceforge.net/projects/lmbench

More important than hardware can be your choice of compiler and IO (disk)... When looking at 'spec' benchmark results pay attention to the choice of compiler AND the hardware bits surrounding the CPU.

Benchmarks are worthless - your apps count. Benchmark your applications. Period.

i dont think thats completely true as we would like to benchmark the 6 core (dunnington), intel 4 core (harpertown) vs AMD shanghai, AMD Barcelona – as the disk / networking devices are handled by dom0, those elements won’t be as applicable as we’re looking mostly at the hardware enhancements in relation to page fault handling and TLB look-up speed, that the AMD Shanghai boasts about.

We wouldn't be benching I/O as that would increase the variability, which is why you wouldn't bother doing it; those kind of microbenchmark's would be applicable more for physical to virtualization microbencharks for linear regression calculations like:

U1/dom0 = c0 + c1 * M1/1 + c2 * M1/2 + ... + c11 * M1/11 etc

We're only interested in really the hardware benefits of the virtualization techniques in relation to the different cpu type. We're not interested exactly in the fact that it's virtualized, but knowing it's virtualized and process x has caused an interrupt, which has resulted in a page fault, which has made a TLB reference, which has resulted in paging etc, and has taken X period. If the Core improvements have said that page fault handles are processed quicker and TLB references have increased, then you should notice a big difference between VM1 in one environment without those to VM2 running with those hardware enhancements.