 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello everybody,
today I got a new toy: a server with two sockets, each equipped with an AMD EPYC
7451 24-core processor with 2-way multithreading. It's running on Windows Server
2019. As a benchmark I installed the most current stable version of POVRay
(3.7.0.msvc10.win64). Unfortunately I had to notice that POVRay just uses the
first half of all virtual processors (48 instead of 96). Even starting two
instances of POVRay and letting it run crams all processes to just the first
half shown in the task manager. Also increasing the number of threads from 48
(default) to 96 doesn't occupy all virtual processors, but again just half of
them.
Do you have any idea, how to solve that issue?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I just found out that it has something to do with 'processor groups', as Windows
divides the cores for >64 core machines in several groups and a program which is
not aware of processor groups is limited to stay in one group. In my case the
groups are 48 processors and both groups are equal in size.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.12.2018 um 20:37 schrieb Mirfaelltkeinerein:
> I just found out that it has something to do with 'processor groups', as Windows
> divides the cores for >64 core machines in several groups and a program which is
> not aware of processor groups is limited to stay in one group. In my case the
> groups are 48 processors and both groups are equal in size.
Yes, you're stuck with 48 threads. I don't think that will change any
time soon - we're using Boost for thread management, which does not seem
to support processor groups yet.
It might be worth trying whether the "Windows Subsystem for Linux" can
make use of all processors simultaneously.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmmmm, here
https://www.boost.org/doc/libs/1_68_0/libs/fiber/doc/html/fiber/numa.html
is something written about it. So it should be able with Boost...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.12.2018 um 14:24 schrieb Mirfaelltkeinerein:
> Hmmmm, here
> https://www.boost.org/doc/libs/1_68_0/libs/fiber/doc/html/fiber/numa.html
> is something written about it. So it should be able with Boost...
Boost is actually not a single homogenous library, but a collection of
libraries. POV-Ray is using Boost.Thread for multithreading; the linked
page however is about NUMA support in Boost.Fiber, which is an entirely
different library for somewhat similar purposes.
I find it a bit odd to find NUMA support in Boost.Fiber, as that library
is all about /fibers/, which aren't full-fledged threads, but rather
just a programming aid to more easily manage different jobs in a single
thread, using cooperative scheduling.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, I have to admit, that I have little knowledge about it.
I'm just hoping, that in future releases POVRay can use all available resources
under Windows, too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/12/2018 15:20, clipka wrote:
> Am 08.12.2018 um 14:24 schrieb Mirfaelltkeinerein:
>> Hmmmm, here
>> https://www.boost.org/doc/libs/1_68_0/libs/fiber/doc/html/fiber/numa.html
>> is something written about it. So it should be able with Boost...
>
> Boost is actually not a single homogenous library, but a collection of
> libraries. POV-Ray is using Boost.Thread for multithreading; the linked
> page however is about NUMA support in Boost.Fiber, which is an entirely
> different library for somewhat similar purposes.
>
> I find it a bit odd to find NUMA support in Boost.Fiber, as that library
> is all about /fibers/, which aren't full-fledged threads, but rather
> just a programming aid to more easily manage different jobs in a single
> thread, using cooperative scheduling.
How do render farms cope with multiple CPUs? Could a variant of that
method be used?
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.12.2018 um 11:02 schrieb Stephen:
> How do render farms cope with multiple CPUs? Could a variant of that
> method be used?
I'm pretty sure they're either not running Windows, or they're using
software that manages threads via Windows' native API.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.12.2018 um 10:20 schrieb Mirfaelltkeinerein:
> Ok, I have to admit, that I have little knowledge about it.
> I'm just hoping, that in future releases POVRay can use all available resources
> under Windows, too.
It should be possible to utilize multiple processor groups by running
multiple instances of POV-Ray, each using a different processor group.
The problem there is that programs are assigned to processor groups in a
round-robin fashion, so if any other program happens to be started in
the background between running the POV-Ray instances, they'll happen to
be assigned to the same processor group.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/12/2018 11:04, clipka wrote:
> Am 10.12.2018 um 11:02 schrieb Stephen:
>> How do render farms cope with multiple CPUs? Could a variant of that
>> method be used?
>
> I'm pretty sure they're either not running Windows, or they're using
> software that manages threads via Windows' native API.
Thanks, I was just wondering.
Now I expect that jr will be going :P :P
;)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
