Multi-Processor access

  • 4 Replies
  • 156 Views

0 Members and 1 Guest are viewing this topic.

Offline admaxtv

  • *
  • Fractal Freshman
  • *
  • Posts: 1
« on: April 24, 2018, 05:21:29 PM »
Hi,

I put a ton of effort into building this bad ass system but it doesn't work.   Its a dual xeon processor system with 36 core/72 threads.  The program claims to run as many as 64, but when I check the resources the most it will use is 36.   Is there something I can do in regedit to make it use all the threads?  Are there technical limitations with the language that prevents it from accessing the second processor?

Love the new version.  Thanks. 

James

Offline 3DickUlus

  • *
  • Fractal Frankfurter
  • *
  • Posts: 572
    • Digilantism
« Reply #1 on: April 24, 2018, 11:35:02 PM »
36core =36threads unless hyper threading is implemented... not sure if xeon chips do that... do a little research on the motherboard hardware and bios version... that may give you a more definitive answer...

edit: xeon cpus do support hyperthread technology...

from https://www.intel.com/content/www/us/en/architecture-and-technology/hyper-threading/hyper-threading-technology.html
Quote
...and the Intel Xeon processor family. By combining one of these Intel processors and chipsets with an operating system and BIOS supporting Intel HT Technology...
so your BIOS and MoBo chipset also has to support it afaik.
« Last Edit: April 25, 2018, 02:27:27 AM by 3DickUlus »
Resistance is fertile... you will be illuminated!

https://en.wikibooks.org/wiki/Fractals/fragmentarium

Offline buddhi

  • *
  • Fractal Phenom
  • ****
  • Posts: 53
    • Mandelbulber GitHub repository
« Reply #2 on: April 25, 2018, 07:28:34 PM »
Have you tried to run Mandelbulber to see if this program will utilize all CPU cores?

Offline 3DickUlus

  • *
  • Fractal Frankfurter
  • *
  • Posts: 572
    • Digilantism
« Reply #3 on: April 26, 2018, 01:43:59 AM »
If the software you're running, Mandelbulber or whatever, only checks the number of cores and spawns one thread per core then 36 is all you will get.
On the other hand, If the software you're running allows you to choose how many threads to spawn then it still may just queue the extras and only actually run 36 at a time unless your hardware is setup to take advantage of hyper threading.

that's all I got  ::)

Offline hobold

  • *
  • Fractal Fanatic
  • ***
  • Posts: 39
« Reply #4 on: April 26, 2018, 11:20:51 AM »
(some half-knowledge here, not familiar with windows in detail, so this might be totally off)

The "traditional" programming interface under windows could handle at most 32 processor cores, because in several places you had to specify processor subsets as bit masks, and the respective value was stored in 32 bits. With the transition to a 64 bit programming model, an extension of this interface allowed up to 64 processor cores.

Beyond that, windows handles processors in so-called "processor groups", with the application having to use a different programming interface. As your system has more than 64 "logical cores", windows has probably organized them into two groups. Any application using the old programming interface will probably see only a single processor group.

I don't know if windows schedules multithreaded applications to distribute them among groups, but I would guess yes. Neither do I know how windows does the grouping in your case. It might put each of the two processor chips into its own group, or it might have put the first thread of each core into one group, and the second thread into the other group.

You could probably try to find this out with a bit of benchmarking:
 - verify that two simultaneously running instances of a multithreaded application do in fact load all 72 threads
 - then time a single application running alone
 - then time the same application again, but this time with another application loading the other half of the threads

If running alone is as fast as running with background load, then windows has separated the two processor chips into different groups. If a background load slows down the benchmarked application, then windows has made a "logical" split based on hyperthreading.

The latter case is arguably better for performance, because it means a single multithreaded application will already make good use of all 36 processor cores, as if hyperthreading was disabled. So you would already get 75% to 80% of peak throughput.

If windows seperates the two processors, then a single multithreaded application gets only 50% of system resources. In that case you'd be better off manually splitting the workload between two running instances of the application. Or maybe even disabling hyperthreading in the BIOS.


clip
Raspberry Pi OpenCL - bus access error

Started by Micha1982 on Mandelbulber

5 Replies
171 Views
Last post April 17, 2018, 08:21:10 PM
by buddhi