5
$\begingroup$

I am using a program that utilizes the PARDISO solver as part of the Intel math kernel library. I am currently in the process of deciding on a new computer to run the simulations on. I have a question or two on how benchmarks with the program will transfer across systems.

My current machine runs older dual quad-core xeons (E5345's) at 2.3GHz with DDR2 RAM at 667 MHz in 2 channels. On this system, running with 8 threads, the program in memory bound with small cases (3000 cells or so, about 1/3 the usual size) running at about 3/4 of the cpu cap and larger cases bottoming out around 1/2 of the cpu cap. I don't have any way to benchmark it on a more representative system before buying the new one.

I can very easily benchmark my code on the smaller case on 1, 2, 4, and 8 cores on my current machine, which is what I am currently doing. I will use that information to decide between less faster cores or more slower cores in the future computer. The issue is that in going to the new computer will be upgrading to RAM at 1333 MHz, in 4 channels, and the sandy bridge architecture. I have heard that the sandy bridge architecture is very strong in memory-throughput benchmarks, but have not be able to locate any benchmarks comparing it to older architectures.

Do I have any reason to expect a change from memory boundedness to cpu boundedness of my model as I upgrade to 12 or 16 cores of comparable clock speeds with the faster RAM and architecture? I understand this is likely hard to answer due to a high level of model dependence of the solvers performance but I am hoping someone has experience benchmarking across architectures and can give some insight as to what to expect.

Improve this question
$\endgroup$

2 Answers 2

Reset to default
5
$\begingroup$

Since asking this question I have purchased a new machine and have run the same set of code on it. The new machine has 2 Intel Xeon E5-2640 2.50GHz for a total of 12 cores, and 64 GB of DDR3 RAM on 4 channels at 1333MHz. Regardless of the number of cores, we saw about a 3x-4x speed up between the two machines on identical problems. On smaller problems, we also saw slight speed-ups on the new machine on problem sizes where the larger cache was advantageous, but that isn't easy to exploit, since other factors determine our problem size. I feel fairly confident in saying that the speed-up was almost purely due to the higher memory bandwidth. Running the same cases on 1 core vs. 12 cores only sees about a 20% speed-up for this code.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Was this new machine AMD or Intel? I can guess, but you should put the model number of the chip and the manufacturer in your answer. $\endgroup$
    – Bill Barth
    Dec 27, 2012 at 16:34
  • $\begingroup$ Sorry, I added the model number to the answer. $\endgroup$
    – Godric Seer
    Dec 27, 2012 at 20:06
3
$\begingroup$

My stance on this is that you are spending your time on the wrong topic. The difference between fast and slow cores is going to be 10 or 15% in raw FPU capacity, but in practice you may see a 5% difference. The same is going to be true for the memory architecture. In other words, unless you do incredibly long computations, you are likely not going to see a lot of difference between cores of different speeds if you have the same number of cores.

On the other hand, I find that more cores are more better (TM) because they can be used in other contexts as well -- e.g. in compiling stuff in parallel. Finally, you may simply want to invest the time in profiling your code to see where there are bottlenecks: finding a spot where you can save 5% of the overall run time of a program is not usually very difficult.

Improve this answer
$\endgroup$
4
  • 3
    $\begingroup$ I couldn't disagree with this comment more. We've seen some codes improve by significant factors moving from Westmere to Sandy Bridge. We saw the same for some codes for the Opteron to Nehalem/Westmere transition. It would be best to get access to a machine similar to what you'd like to buy and actually benchmark it. $\endgroup$
    – Bill Barth
    Sep 25, 2012 at 15:07
  • $\begingroup$ The issue is that for the foreseeable future (until the end of my master's or so) the code is being treated like a black box. It was developed by another group and I am only learning how to run it. My only exposure to the actual source code is when I need to reference something, and never to edit it. While I understand that there are gains to be made elsewhere, I currently don't have the experience/knowledge to pursue them. $\endgroup$
    – Godric Seer
    Sep 25, 2012 at 15:31
  • $\begingroup$ I agree that more cores (for parallel numerical code) are generally better which means that for same price you're better of with AMD 6200's. If memory bandwidth is an issue then you can always use less core(s)/socket. $\endgroup$
    – stali
    Sep 25, 2012 at 15:53
  • 2
    $\begingroup$ I believe that benchmarking is a better approach than guessing. If you can beg/borrow/access a Sandy Bridge machine like the one you'd like to buy, then you can test the performance and see if there's more to be gained from cores or the increased memory performance. Our experience at TACC has been that many codes benefit substantially from the increased memory performance, and that the additional cores may go to waste. $\endgroup$
    – Bill Barth
    Sep 25, 2012 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.