Is anyone here already using a Ryzen 1800X processor ?

[Dann Corbit]

I run it on 58 cores.
My machine has 64 physical CPUs, but I find when I set more than 58 the machine becomes less and less responsive.
Ubuntu 14.4 = OS
128 GB RAM.

[cma6]

I run it on 58 cores.
My machine has 64 physical CPUs, but I find when I set more than 58 the machine becomes less and less responsive.
Ubuntu 14.4 = OS
128 GB RAM.

Dan,
So if I have 36 physical cores (HT is set to ON in BIOS), then would you suggest running popcnt engine with 35 threads?

[Dann Corbit]

I run it on 58 cores.
My machine has 64 physical CPUs, but I find when I set more than 58 the machine becomes less and less responsive.
Ubuntu 14.4 = OS
128 GB RAM.

Dan,
So if I have 36 physical cores (HT is set to ON in BIOS), then would you suggest running poipcnt engine with 35 threads?

Run experiments to find the happy spot where your machine is still snappy and yet you get plenty of CPU power.

I guess every machine is different.
I also have services running in the background (e.g. database daemons). So your system might respond differently than mine does.

[shrapnel]

I agree that using all 16 threads on Ryzen is probably not best. To take a stab at how many threads is best for my program Wasp, I ran the arasan19.epd test suite (200 positions) for 1 second per position and calculated the average depth reached. My system is a Ryzen 1700 running at 3.7 Ghz on all cores with SMT turned ON. I used 64 Mbytes hash. Here is some data. Knps is the combined nodes/second, Depth is the average depth reached (not necessarily fully completed), and EBF is effective branching factor for the last 4 completed plies.

Code: Select all

  Threads  Knps   Depth   EBF
    1          1447    14.2   1.72
    2          2886    14.9   1.72  
    4          5660    15.9   1.68
    6          8294    16.5   1.71
    8        10806    16.7   1.68
   10       12045    16.7   1.69
   12       13141    16.7   1.71
   14       14149    16.7   1.69
   16       15135    16.7   1.67

So for my program anyway, I don't get any depth increaset from using more than 8 threads. But I did a similar test a couple weeks ago at 5s per position and got very slightly higher avg depth for 10 threads as compared to 8. Also, sometimes more cores can give a different (hopefully better) move for a given search depth. So maybe 9 or 10 threads is best for me. Maybe if I improve my lazy SMP search I can make better use of the additional nodes/second for threads beyond 8.

FYI, as a comparison I get 1534 Knps for 1 thread on an i5-4690K at 3.9 Ghz. So for my program the Ryzen and Intel systems have nearly identical speed if clock rates are equal.

John

Very interesting. Your results seem to indicate that Ryzen is not that much different from Intel, insofar that it seems to prefer Real Cores to Virtual Cores. Using virtual cores may not do any harm but it doesn't seem to be doing much good either.
At worst, it will increase energy consumption and heat production.
Your Test results seem to be in sync with what I've observed in my online engine-engine matches.

[Tom Likens]

Code: Select all

  Threads  Knps   Depth   EBF
    1          1447    14.2   1.72
    2          2886    14.9   1.72  
    4          5660    15.9   1.68
    6          8294    16.5   1.71
    8        10806    16.7   1.68
   10       12045    16.7   1.69
   12       13141    16.7   1.71
   14       14149    16.7   1.69
   16       15135    16.7   1.67

Hi John,

It's interesting to me, going from 8 threads to 16 yields a speed increase of almost 5 million nodes per
second but no depth increase. I wonder why that is? I would have expected a small increase, but you
get an identical depth of 16.7 for all threads at 8 and beyond yet the nodes per second is clearly increasing.

regards,
--tom

regards,
--tom

[Laskos]

Code: Select all

  Threads  Knps   Depth   EBF
    1          1447    14.2   1.72
    2          2886    14.9   1.72  
    4          5660    15.9   1.68
    6          8294    16.5   1.71
    8        10806    16.7   1.68
   10       12045    16.7   1.69
   12       13141    16.7   1.71
   14       14149    16.7   1.69
   16       15135    16.7   1.67

Hi John,

It's interesting to me, going from 8 threads to 16 yields a speed increase of almost 5 million nodes per
second but no depth increase. I wonder why that is? I would have expected a small increase, but you
get an identical depth of 16.7 for all threads at 8 and beyond yet the nodes per second is clearly increasing.

regards,
--tom

regards,
--tom

The search widens with more threads. So that 16.7 depth with 16 threads is stronger than 16.7 depth with 8 threads. According to this data, 16 threads is the best to use strength-wise.

[corres]

[quote="Laskos"]

The search widens with more threads. ....

[/quote]

But why?
If you swells the number of cores from 1 to 2, from 2 to 4 or from 4 to 8
not only the wide of search but the depth of search grows too - presuming the cores are physical cores. But if you uses logical cores (by HT/SMT modes) you can experience this strange phenomenon described above.
I think this issue is caused by the behavior of CPU and maybe the operating system too.

[jstanback]

Code: Select all

  Threads  Knps   Depth   EBF
    1          1447    14.2   1.72
    2          2886    14.9   1.72  
    4          5660    15.9   1.68
    6          8294    16.5   1.71
    8        10806    16.7   1.68
   10       12045    16.7   1.69
   12       13141    16.7   1.71
   14       14149    16.7   1.69
   16       15135    16.7   1.67

Hi John,

It's interesting to me, going from 8 threads to 16 yields a speed increase of almost 5 million nodes per
second but no depth increase. I wonder why that is? I would have expected a small increase, but you
get an identical depth of 16.7 for all threads at 8 and beyond yet the nodes per second is clearly increasing.

regards,
--tom

regards,
--tom

Hi Tom,

With "lazy SMP" search, the number of nodes required to reach a given depth increases as #threads increases. In the case of Wasp, it appears that the additional nodes and additional speed for cores beyond 8 just balance and the depth stays constant. But ask Kai mentioned, the search "widens" with more threads -- which means that different branches are examined and the chance of finding a better move increases. So perhaps Kai is right that 16 threads is best for Wasp. Maybe I'll run a match between 16 threads and 8 threads to see what happens. But it will take quite a while to get enough games....

John

[shrapnel]

WOW ! So many different interpretations of the same data !
Now what Kai Laskos says seems to make sense....until someone else contradicts him !

[Laskos]

Code: Select all

  Threads  Knps   Depth   EBF
    1          1447    14.2   1.72
    2          2886    14.9   1.72  
    4          5660    15.9   1.68
    6          8294    16.5   1.71
    8        10806    16.7   1.68
   10       12045    16.7   1.69
   12       13141    16.7   1.71
   14       14149    16.7   1.69
   16       15135    16.7   1.67

Hi John,

It's interesting to me, going from 8 threads to 16 yields a speed increase of almost 5 million nodes per
second but no depth increase. I wonder why that is? I would have expected a small increase, but you
get an identical depth of 16.7 for all threads at 8 and beyond yet the nodes per second is clearly increasing.

regards,
--tom

regards,
--tom

Hi Tom,

With "lazy SMP" search, the number of nodes required to reach a given depth increases as #threads increases. In the case of Wasp, it appears that the additional nodes and additional speed for cores beyond 8 just balance and the depth stays constant. But ask Kai mentioned, the search "widens" with more threads -- which means that different branches are examined and the chance of finding a better move increases. So perhaps Kai is right that 16 threads is best for Wasp. Maybe I'll run a match between 16 threads and 8 threads to see what happens. But it will take quite a while to get enough games....

John

What I said is valid for Stockfish with Lazy SMP, I forgot that the numbers are for another engine.