matlab quadprog is exteremely slow on my strong local machine vs another remote machine

I am using matlab's quadprog and it runs extremely slow on my local machine.

When I run the exact code on a remote machine, it completes within 10 minutes. When I run it on my local machine, it doesn't terminates even after 24 hours (I kill it at some point).

While the code runs, the memory usage on my local machine is ~10GB RAM (while my local machine has ~100 GB of free RAM). The usage on the remote machine is 20-30GB RAM .

Any idea on what to do to make it run faster on my local machine?

Important EDIT 18 Oct. : I executed a smaller scale problem on both machines. On the local machine it takes 1900 sec, on the remote it takes 8 sec, a factor of ~200. Both machine also have multi processors. I noticed this time with htop, that the remote machine uses all its processors, while the local machine use only a single processor (although all the others are available). Any idea how can I make matlab use all its processors on the local machine?

PS1: Below is `cat /proc/cpuinfo` on my machine vs remote machine (the remote machine is stronger, however the local machine is also strong)

PS2: nnz for H, Aeq =~ 10e6, dimensions are approx 11e6 x 11e6

PS3: quad programming with only equality constraints has a closed form solution (See Boyd ). When I solve it with the closed form solution, it takes ~10 minutes on my local machine vs 5 minutes on the remote machine. While both consume ~20-30GB of memory. Since I would like to add inequality constraints, I would like to be able to run quadprog quickly on my local machine.

Thanks!

Local machine cpu info of a single processor (out of many)

   vendor_id       : GenuineIntel
      cpu family      : 6
      model           : 26
      model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
      stepping        : 5
      microcode       : 25
      cpu MHz         : 1600.000
      cache size      : 8192 KB
      physical id     : 1
      siblings        : 8
      core id         : 3
      cpu cores       : 4
      apicid          : 23
      initial apicid  : 23
      fpu             : yes
      fpu_exception   : yes
      cpui level     : 11
      wp              : yes
      flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
      bogomips        : 4532.68
      clflush size    : 64
      cache_alignment : 64
      address sizes   : 40 bits physical, 48 bits virtual
      power management:

Remote machine cpu info of a single processor (out of many)

      vendor_id       : GenuineIntel
      cpu family      : 6
      model           : 63
      model name      : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
      stepping        : 2
      microcode       : 0x2d
      cpu MHz         : 1200.000
      cache size      : 35840 KB
      physical id     : 1
      siblings        : 28
      core id         : 14
      cpu cores       : 14
      apicid          : 61
      initial apicid  : 61
      fpu             : yes
      fpu_exception   : yes
      cpuid level     : 15
      wp              : yes
      flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
      bogomips        : 5189.05
      clflush size    : 64
      cache_alignment : 64
      address sizes   : 46 bits physical, 48 bits virtual
      power management:

[Martin Schätz]

Hi, I must confess i don't know much about quad programming. But, i do see the differences between remote machine and your local one. If your remote has actually acces to 14 cores at once and nearly 36 KB of cache, then it is unbeatable vs your local machine (isn't the remota a Blade system?). The RAM is probably used only for storing of your variables that MatLab is using in the moment.

If your script is parallelized, then this would be the solution. If not you can always speed up things by parallelization.

[Yuval]

Thanks, but the local machine has 4 cores vs 14 cores on the remote, so it is a gain of ~3.5.

About the cache, it is 2.5MB per core on the remote vs 2MB per core on the local machine, so that's also not a very large gain.

The run time gain I see is more than x144! because the remote runs in 10 minutes, while I kill the local after 24 hours, so I can't figure why it happens. It feels to me it's related to some configuration at MATLAB. Maybe its not using hyperthreading on the local machine, and fully exploit them on the remote? That's just a guess..

[John D'Errico]

"While the code runs, the memory usage on my local machine is ~10GB RAM (while my local machine has ~100 GB of free RAM). The usage on the remote machine is 20-30GB RAM ."

Your statement suggests to me that the local machine has 100 GB of free disk space, used for virtual memory, but not truly 100 GB of true fast access RAM installed.

If that is true, then MATLAB spends most of that time swapping information to and from slow memory. This is typically the reason why one machine would be so much slower, i.e., here a factor of 144 difference in time required.

[Yuval]

I am not sure why you are saying that.

Attached is a screenshot of a local machine while running the code.

You can see it doesn't do any swapping.

[Martin Schätz]

Hi, with the processors, if you have Parallel Processing toolbox, dont forget to setup and start your Parallel pool. If the code works like you are saying then it might be enough to let MatLab use other cores too, but it will not be as fast as with 14 cores.

[Yuval]

Thanks, but opening the parpool doesn't help.

[Steve Grikschat]

Can you give more detail, just to make sure we're comparing the same thing? For instance, What version of MATLAB are you running on each machine? What quadprog algorithm are you using?

BTW, parallel computing toolbox is not used by quadprog. Threading can be used for some of the linear algebra, but a high percentage of the operations are likely sparse, which are generally single threaded. You may want to make sure that you haven't locked threading for your local MATLAB session.

[Rakesh Kumar]

Can you please run the 'bench' command on two machines and post the results here?