Please note that the MTL is not set up for any kind of comparison of architectures or algorithms.
We don't have the resources to configure the system(s) to support a specific BIOS configuration or toprovide guidance onwhere one algorithm is performing better than another.

The MTL is primarily a tool toshowcase the thread scaling of a particular workload or algorithm.

We fully understand you are contrasting the >relative< performance of 2 algorithms, now providing relative scaling performance based on the number of threads.

It now appears that the scaling thread performance of the SixSort time ratio does scale slightly better than thePQuickSort in the numbers you have just provided.

But again, you're asking why is the SixSort ratio better on AMD, and worst on Intel platforms. This we cannot answer - there are many ways the resultscan be different, e.g.. BIOS configs, Processor speed & Turbo Boost,compiler andoptions, cache configoptions, even down to the SixSort code, etc, etc. And was the workload run as a benchmark on the MTL, you may recall that the login node is not set up as a benchmarking platform, and willl automatically degrade performance.

Finally we could suggest thatyou avail yourself of the extensiveIntel performancetool set on the MTL, to determine why the SixSort algorithm is deficient on Intel platforms, as you report.

You still have quite a bit more work to do before you can completely pin the blame on Intel. For instance:
- You are using quicksort as a baseline. Intel's current-generation
memory interconnects have both significantly higher bandwidth and
throughput than AMDs (see my tech report for more details
http://www.cs.uchicago.edu/research/publications/techreports/TR-2011-02

). This means that you should expect your ratios to be better on
the AMD machine because changing to an algorithm with better locality
will be more of a win on the AMD machine than the Intel machine.
You can see this information by looking at the difference between the 1 processor output for quicksort/sixsort.
- Which compiler are you using and with which flags? For example, for bulk-data synchronous parallel programs, switching from gcc to icc and turning on the streaming-stores optimization can increase your bandwidth by up to 40% on AMD machines (less effect on Intel, in my experience).
- Your dataset size may be a little small. Make sure to try it out across larger sizes to see how the ratio changes. At only a few million integers, you can end up starving for more parallelism. Our experience with our language (which has only 1/4-ish the speed of C) is that we needed 10M integers, so I suspect that with an optimized C program you might want at least a factor of four more. Try plotting your speedup across ranges of processors; elbows in that graph commonly indicate either bus saturation, limitations due to parallel overheads, or just running up against Amdal's Law.
- Along those lines, what are the raw numbers? I've frequently found that raw,
single-processor performance on Intel machines is so much larger than on
similar-generation AMD machines that datasets that are large enough to see good speedups on an AMD bottom out on Intel due to parallel overhead beginning to dominate the available work.

I hope this helps! And don't be discouraged -- doing high-quality systems research requires far more measurement and analysis than it might appear by looking at final papers. Even seemingly simple statements such as X is faster than Y on machine M because of Z can require a stunning amount of time. Doing that across two machines will take even more time and effort.
- Lars

Hey ddcc,

VERY interesting discussion here! I find myself admiring both your general approach and your professional restraint.

While its true that -- for a very, very long laundry list of reasons --us vs. them threads are discouragedin this forum, you raise a challenge that I can only describe as quite interesting.

Using the Intel VTune Amplifier XE on the SixSort code in question would allow one to drill down to (or pinpoint) its potential bottlenecks, to the object or line of code level (as suggested by Dr. Breshears to you some time ago). Finding the bottleneck(s) in this fashion does not require CPU expertise of course; changing the code to improve its performance on a specific system based on what is learned MIGHT

And of course, if the bottlenecks are precisely where expected, an entirely new course of action might emerge.

All this said, I get the distinct impression that your challenge here may pique the interest of more than a few of our technicians, who are scattered throughout the world. In that eventuality, can you provide your source and makefile in this thread so that any interested person can download them and dig in, as needed?

I know that youve appeared to dismiss the role of the compiler in this experiment, but it would be pretty standard to examine what works well in situation A with what might work better in the same situation (as well as in situation B).

If you agree this might be a good next step, I note that you can add files to responses here in this forum. Otherwise, feel free to email the files to intel_mtl@intel.com and Ill add them to this thread myself.

Your continued interest in the causes of this behavior is appreciated.

Cheers,

Jdg