7
$\begingroup$

I'm choosing components to set up a pc aimed to run large symbolic computations in Mathematica 9.0 under Windows 7 64 Bit Pro.

I have a limited budget therefore I'm considering this system:

  • Mother Board Asrock Z97 Extreme 4
  • cpu Intel Haswell Core i5-4690K (AVX2, BMI, TSX)
  • ram HyperX Fury Memory Black Memorie RAM, 32 GB, 1866 MHz HX318C10FBK2/16

and I have no chance to buy a second machine if the first prove to be badly effective.

At present moment, I have no money for a GPU video card. May be in future I can add one.

Does Mathematica's standard licence allow the use of all features of this hardware ?

Does the hardware lack some major features Mathematica could make use of ?

Thanks !!

$\endgroup$
1
  • 1
    $\begingroup$ Mathematica can't use the GPU for symbolic calculations. Regaring whether the standard license allows using all features: I am not knowledgeable about licenses. My university's license allows for launching up to 16 subkernels. This means that I can fully use a computer for as long as it has no more than 16 cores. $\endgroup$
    – Szabolcs
    Sep 10 '14 at 15:53
9
$\begingroup$

Memory size and speed are critical for only a few programs such as databases, video or audio processing, Mathematica, and similar applications that use the functional programming model. Because it's usually not critical for performance, memory is always the hardware component that is least well documented by PC manufacturers. It is also where they try to save a few bucks. Default memory speeds are always very conservative because memory issues are so hard to isolate. This means that almost any memory over-clocking will get you a measurable improvement for very little risk. Once you have the additional processors to enable parallelism, memory is the primary tuning knob that you want to adjust in order to speed up Mathematica. 32 gigabytes of memory is a goodly amount by today’s standards, but you might actually be happier with 16 gigabytes of slightly faster memory that can be over-clocked to improve buffer transfer speed and random access speed. 1866 is fairly slow memory by today's standards. The newest DDR4 memory is now available at 3300, but that won't work with a Z97 motherboard. If you’re interested in a few, or a lot, of over-clocking options then read on. The Z97 chipset over-clocks well and "enthusiast" motherboards such as the one you mentioned have an overwhelming array of over-clocking settings that you can tweak until you run out of patience. The memory and motherboard makers will each have forums with posts that discuss dozens of settings that will work, but may interact weirdly. They can advise you on the free benchmark programs that you can use to measure results. Tweak memory before you tweak the CPU. Be VERY cautious when applying more voltage. Go slow. Measure the result. The last time I built a serious machine I spent a week tweaking memory, but the results were about 150% over default memory speed. If that sounds like too much work, and it is a lot of work, just go with 32 gigabytes of slightly slower memory and apply a few of the simplest memory setting tweaks. Sometimes this can be as simple as clicking a BIOS option labeled AutoOverClock enable. Note: Once you have your system be sure to modify the Windows swapfile size from "system determined" to a pre-allocated swapfile that is either 1X, 1.5X, or 2X your total RAM size. It can be split over 2 disks. Personal note: I am a rank amateur with Mathematica, but I do hardware/software performance tuning for a living. Memory constrained applications were common 35 years ago, but are now very rare.

$\endgroup$
4
  • $\begingroup$ Thank you for your exhaustive answer. If I may, two more questions: - 1 - Every Mathematica's licences ( 9.0 ) allows the use of the whole 32 Gb. Doesn't it ? - 2 - Let's say I have to sort a large data file ( ASCII ), using the Sort function. On the pc, sketched above, equipped with 32 Gb ram is it possible to estimate the maximum file size that I can load entirely in memory ? $\endgroup$ Sep 11 '14 at 9:09
  • $\begingroup$ I've never noticed a WRI restriction on region size, but Mathematica is still partially (or mostly) running in 32-bit mode where the maximum region size per process is less than 4 gigabytes. That is much more likely to be a problem. Get your free copy of "Process Explorer", use it to monitor Mathematica memory usage while you load a few progressively larger subsets of your file on your existing system and see how much Mathematica's region size grows. It should be a quick experimental method to estimate the total required. $\endgroup$
    – undefined
    Sep 11 '14 at 13:53
  • $\begingroup$ What's free copy of "Process Explorer" ? The well known CRTL+ALT+CANC program ? $\endgroup$ Sep 12 '14 at 13:46
  • $\begingroup$ No, it's from SysInternals, although they are now owned by Microsoft. It gives more information than the standard Microsoft utility. $\endgroup$
    – undefined
    Sep 12 '14 at 16:01
5
$\begingroup$

You want a Core i7 CPU (more parallelism), and as much RAM as possible (RAM is much more important than processor speed).

However, a better alternative to buying a machine is renting one, from, say hetzner.de. Your configuration is probably under $100/month (and you can rent month-to-month). The only situation where this is not a great solution is when you are using GPU computing, which is a little hard/expensive to get in the cloud still.

$\endgroup$
15
  • 1
    $\begingroup$ @SimonWoods It's a simple matter of arithmetic, where you multiply the clock speed by the number of (real, not hyperthreaded) cores. Cache size is important also. $\endgroup$
    – Igor Rivin
    Sep 10 '14 at 15:35
  • 3
    $\begingroup$ RAM and speed are what matters for most symbolic computations. Core counts matter for those algorithms that one explicitly parallelizes, or for those that do so under the hood (to answer the next question, no, I do not have a list of those latter). $\endgroup$ Sep 10 '14 at 18:40
  • 1
    $\begingroup$ @DanielLichtblau But is "RAM speed" bandwidth, or latency? This is a hunch, but I'd assume typical symbolic workloads are more likely to be latency-limited (unless very specific performance primitives or large arrays are processed), while technical numerical computations are more likely to be bandwidth-limited. Although bandwidth of typical SDRAM solutions increases fast, decrease of latency is almost nonexistent. Both workloads benefit from more modern microarchitectures and larger caches, but it may well be that for specific workloads, increase in SDRAM bandwidth provides zero benefit. $\endgroup$
    – kirma
    Sep 11 '14 at 13:31
  • 1
    $\begingroup$ @kirma I actually had intended to write "RAM and processor speed" but seem to have dropped a word. $\endgroup$ Sep 11 '14 at 15:45
  • 3
    $\begingroup$ @I certainly agree memory speed is very important in this setting. So cache sizes, memory specifics, and the like do matter. My only point, which maybe people already knew, is that running out of RAM is a computation killer (it's hard on the OS too, in that one might need to reboot). $\endgroup$ Sep 11 '14 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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