Building PC

[ouachita]

"I strongly suggest studying the Ipman benchmarks:
http://www.ipmanchess.yolasite.com/amd- ... -bench.php

I am planning to buy a nice 7nm Epyc machine when they come out this summer, but then again, I'm criminally insane.

How do you do that, files tablebases in one folder?"

For single CPU systems, the obvious winner for me at Ipman Chess is the Intel Xeon W-3175X, a 28-core overclockable beast

[MikeB]

Dollars per node, the new Epyc chips win. And I expect the new threadrippers to really shine. I hope for October. I may just go Epyc, but it would be nice to have a quiet machine for once.

https://www.newegg.com/supermicro-mbd-h ... 6813183691

This motherboard with a dual 7702 will certainly be over 200M nps , whether its' worth it or not, depends on the user. Although I would love to have one, I would be hard-pressed to justify that type of investment for me.

[Dann Corbit]

I am pondering buying a dual Epyc but if I do go that route, my computer chess illness will have officially transformed into plague.
On the other hand...
Well, there is no other hand.

[dragontamer5788]

I am pondering buying a dual Epyc but if I do go that route, my computer chess illness will have officially transformed into plague.
On the other hand...
Well, there is no other hand.

I'd be interested in how the various multithreading strategies would perform under NUMA-contexts, especially TTD vs Nodes-per-second.

For example: NUMA may mean that the transposition table is "staler" for half the threads (since half of the threads would be accessing memory remotely). Lazy SMP would show a weaker time-to-depth, but still have a similar nodes-per-second in such a case.

Otherwise, I think sticking with a single-socket UMA machine would just be easier to work with. I guess even with "stale" data, the cross-socket memory coherency would still synchronize the data more than "not" doing the work at all. But there are probably efficiency gains to be had if search strategies were message-passing based...

Is there any research paper on Komodo's search strategy? They had a 8x NUMA architecture in the recent chess tournament. I'm curious how their multithreaded strategy works.

[jdart]

I am pondering buying a dual Epyc

For what I am doing (mostly testing) I need a lot of cores but they don't have to be fast. So older cheaper machines work fine. But I am putting in solar this fall because my electricity bills hit $500/month in the summer, with the A/C and servers going.

For what do you need a whole lot of fast cores? I can see it if you were a correspondence player.

[Dann Corbit]

If I bought such a machine, I would very rarely do a search with all 256 threads.
In fact, I might run 250 instances of a chess program with 1 thread each (leaving a few threads idle to keep the machine responsive).
The reason is that there is no SMP loss at one thread per engine instance.

My goals in analysis are to produce the largest possible volume of data with the given compute resource.

I often do run with multiple threads for two reasons, though.
First, as Inigo Montoya once said, "I hate waiting." and it takes a long time for a single thread to search to decent depth. So it is more fun to search faster and get rapid feedback on a project.
Second, it is harder to manage 250 program instances.

So I would have to play around a while to find the analysis sweet spot.
With a machine such as that, I would also want to have 4 GPU cards (probably Nvidia 2080 Super cards or maybe the new AMD 7nm cards that are due soon). I know that currently, you can't really run LC0 with 4 cards efficiently, but I can always run 2 instances with 2 cards or 4 instances with one card. And it is possible that a machine with absurd I/O bandwidth might be able to run 4 cards at once with LC0 so it would be fun to try an experiment like that. But I think I will probably wait until October and see what sort of output we can get from the 7nm Threadripper (assuming it is 64 cores it might actually be cheaper to buy 2 threadrippers to get the same or better volume of analysis). If it is only 32 cores, then I probably would not buy a threadripper and we have not seen any leaked benchmarks with more than 32 cores yet.

[Dann Corbit]

I am pondering buying a dual Epyc

For what I am doing (mostly testing) I need a lot of cores but they don't have to be fast. So older cheaper machines work fine. But I am putting in solar this fall because my electricity bills hit $500/month in the summer, with the A/C and servers going.

For what do you need a whole lot of fast cores? I can see it if you were a correspondence player.

I also spend a pile of cash on electricity (I have had bills close to $700 a few times). I get notices every few months from the power company asking me if I want consultation on how to lower my energy bill. The long term cost will actually be less with a shiny new AMD Epyc server than with the old machines I now run. And I think that I can probably even run during the summer. Right now, the family room becomes insufferable and I have even had the servers shut themselves down due to temperature. I might have my son help me with building a real server room in my house (with high end cooling -- he does industrial HVAC). But with a 2p Epyc machine, I could probably get by with a lot less cooling. I also think it is more environmentally responsible to use less energy for my computations. In the Seattle area, most of the energy is actually from coal. So my carbon footprint is probably rather disturbing. The solar is a good idea, but I think that the tax breaks have evaporated.

The second thing is time. A single 2p server with 7742s in it would eclipse my entire server collection that I use right now in output. I could get better data faster.

So, I think that initially, the investment would be costly, but in the long run it might actually save me money. And I would get better quality data faster.

[jdart]

The solar is a good idea, but I think that the tax breaks have evaporated.

There is a 30% tax rebate available this year. Goes down the next few years.

--Jon

[dragontamer5788]

In fact, I might run 250 instances of a chess program with 1 thread each (leaving a few threads idle to keep the machine responsive).
The reason is that there is no SMP loss at one thread per engine instance.

I've done thought-experiments with such architectures. My main issue is how to organize the volume of data you get.

1. If you are making an opening book, MCTS seems superior as a methodology to organize all those threads. You'll want the statistics of all threads to coalesce together on the more "interesting" branches of a tree.

2. In the case of Alpha-Beta search (finding the best move for a given position), the other threads would benefit from having alpha-bounds or beta-bounds set. If the threads could somehow "message pass" bounds forward. Ex: Thread #0 discovers that its evaluation is going to be somewhere between <-2, +1>, but hasn't figured out the exact bounds yet. Thread #250 may use that knowledge to set its alpha-beta bounds to <-2, +1>.

In both cases, your analysis benefits from thread communication. Granted, #2 doesn't seem to be super-well researched yet, but #1 is easy to do with MCTS virtual-loss as a coordination scheme.

[Dann Corbit]

In fact, I might run 250 instances of a chess program with 1 thread each (leaving a few threads idle to keep the machine responsive).
The reason is that there is no SMP loss at one thread per engine instance.

I've done thought-experiments with such architectures. My main issue is how to organize the volume of data you get.

1. If you are making an opening book, MCTS seems superior as a methodology to organize all those threads. You'll want the statistics of all threads to coalesce together on the more "interesting" branches of a tree.

2. In the case of Alpha-Beta search (finding the best move for a given position), the other threads would benefit from having alpha-bounds or beta-bounds set. If the threads could somehow "message pass" bounds forward. Ex: Thread #0 discovers that its evaluation is going to be somewhere between <-2, +1>, but hasn't figured out the exact bounds yet. Thread #250 may use that knowledge to set its alpha-beta bounds to <-2, +1>.

In both cases, your analysis benefits from thread communication. Granted, #2 doesn't seem to be super-well researched yet, but #1 is easy to do with MCTS virtual-loss as a coordination scheme.

This leads to an interesting idea.
Have a collection of engines performing independent searches, but still share the same hashtable by using shared memory.
I often analyze related positions, and in such a case there could be a clear benefit.