2

I'm looking for a server to run large number of parallel processes for statistical calculations (Ubuntu + Python). Currently we use 2x16 cores and 512Gb RAM (disk is of secondary importance):

  • Supermicro SuperWorkstation 7048GR-TR Barebone System - Intel C612 Express Chipset - Socket R3 (LGA2011-3) - 2 x Processor Support
  • 2 x INTEL HASWELL 16C E5-2698V3 2.3G 40M 9.6GT/s QPI
  • 8 x 32GB DDR4-2133

We paid 14K+ for this config 3 years ago (bought from Supermicro resellers). Any cheaper way to replicate this or significantly improve in the same budget?

Some more detail on our calculations (EDIT)

We can parallelize our calculations to 3000 separate processes. Runtime is 6 hours on current setup, would like to make this smaller so I can experiment with system parameters at least 2x in a working day.

The calculation is mostly in LAPACK (through Python/numpy). Prefer one big machine to several small ones, until a reasonable limit on price efficiency. Can spend 15K or 30K (if performance still doubles for the extra money).

The code: Python with numpy, vectorized. Very few matrix multiplications happen, most of the operations are element-wise addition, multiplication.

Code is already written (100K lines), we don't have the capacity to re-write. Also we change it every day and are glad for a flexible language as Python. This means GPU / resource sharing / multiple machines / AWS is not a possibility.

Any hint is welcome on what to look at, I'm newbie in hardware.

Improve this question
5
  • 1
    What are your specific requirements?
    – user1691
    Nov 30, 2017 at 18:55
  • 1
    Why are you looking to upgrade? Is there a bottleneck with your current system, and if so, what is it?
    – Cfinley
    Nov 30, 2017 at 19:52
  • @Cfinley The bottleneck is CPU, takes 6 hours to run those 3000 processes on 64 threads. This means I can't really experiment with system parameters during a single day (in a research role). Assuming we double CPUs we'll also have to double (or 1.5x) the RAM.
    – Mark Horvath
    Nov 30, 2017 at 20:03
  • @SiXandSeven8ths We can parallelize our calculations to 3000 separate processes. The calculation is mostly in LAPACK (through Python/numpy). Prefer one big machine over several small ones, until a reasonable limit on price efficiency. Can spend 15K or 30K (if performance still doubles for the extra money).
    – Mark Horvath
    Nov 30, 2017 at 20:04
  • If you're currently using LAPACK, it sounds like you might be able to switch to GPGPU computation. If so, you can save a great deal of money by using GPUs instead of CPUs.
    – Mark
    Nov 30, 2017 at 20:41

1 Answer 1

Reset to default
2

You're not going to do that much better just due to updated models of hardware. For instance, current RAM will probably be 2400 rather than 2133, and current Xeon/Epyc chips will offer more banks (6-8 per socket, which only helps if your code is memory-bandwidth limited.) The latest Xeons support AVX-512, which could double performance if your linear algebra is big enough, vectorizable, and you're linking with something like MKL.

I see you mention 64 threads - have you actually measured whether HT is benefiting you? It does only if a single thread can't keep the pipeline busy (and if you're spending all your time deep in a well-tuned LAPACK kernel, that's not the case...) OTOH, if your code is really all about slamming big matrices around, have you turned on hugepage support?

From the huge memory footprint, it doesn't necessarily sound like GPUs will be a good fit (to be efficient, they need a lot of work to do on relatively small memory).

Improve this answer
2
  • Hi again :) ! Good point on no big improvement by small processor increment. MKL with AVX 512 sound like a good idea! Hugepage would only help if we are swapping, which we're avoiding on purpose by using this much of RAM. Indeed, GPU is not an option. Thanks for all the support!
    – Mark Horvath
    Nov 30, 2017 at 23:40
  • Turning on huge page support will help even in situations where there is no paging to mass storage. The issue is that with small pages there aren’t enough entries in the TLB for a large matrix. The TLB misses slow things down. Try turning on transparent huge pages and see what happens.
    – Brian Borchers
    Mar 31, 2018 at 1:08

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.