When should I consider parallel search ?

[hgm]

Letting them think longer is a more efficient way to get more Elo than parallel search.

Sure, only that you will not be able to do it in a tournament

I thought you never went to tournaments.

Who cares what it does in a tournament? There is no money to be made participating in tournaments. Virtually all engine users are interested in analysis only.

[cdani]

I thought you never went to tournaments.

I meant that I'm not the operator of the engine

[hgm]

Ah. But the main point still stands. Tournaments are just a means to test the engine, and this can be done just as well on a single CPU. They are not a worthy goal.

No one cared that Volkswagen cars had a low emission on the test bench. Designing cars especially to perform well there was even considered cheating. Engine tournaments play a similar role in computer Chess.

[Sven]

Virtually all engine users are interested in analysis only.

And analyzing with multiple threads does not result in a better analysis (within a given time) than analyzing with one thread?

How should a user who is interested in strong engine analysis work with your proposal of running N single-threaded engines instead of one N-thread engine? How does he get his stronger analysis, then?

[hgm]

That is what I always do. I typically analyze a tree, so I can do multiple branches in parallel. Some people also analyze the same position with various engines.

[flok]

What kind of question is that? Are you able to make your own decisions?
Do whatever you want and when you see fit.
LazySMP is trivial to implement and can be done in less than a week (even less if you can afford to work fulltime on it).

Less than a week? What is taking so long then?
Because the "only thing" you need to do (as far as I know, please correct me if I'm wrong):
- start search n times
- if search-depth is d, then make thread 2 search d + 1, thread 3 d + 2 and so on
- for threads other than thread 1, unsort (shuffle) the movelist
- make sure your tt can handle multiple readers/writers in parallel
- wait for first thread to finish

Right?

[mar]

What kind of question is that? Are you able to make your own decisions?
Do whatever you want and when you see fit.
LazySMP is trivial to implement and can be done in less than a week (even less if you can afford to work fulltime on it).

Less than a week? What is taking so long then?
Because the "only thing" you need to do (as far as I know, please correct me if I'm wrong):
- start search n times
- if search-depth is d, then make thread 2 search d + 1, thread 3 d + 2 and so on
- for threads other than thread 1, unsort (shuffle) the movelist
- make sure your tt can handle multiple readers/writers in parallel
- wait for first thread to finish

Right?

It's relatively easy (if you know how to program), I don't understand your points 2-4 but nevermind.
What takes "so long"? Making sure it works (debugging, testing - I've seen engines that play worse with >1 cores .
If your engine is full of globals then you have to refactor a lot.
Correct me if I'm wrong but is Embla SMP?
If not then how can you say a week is a long time?!

There are people who go to work so a week of spare time feels about right.

[syzygy]

What takes "so long"? Making sure it works (debugging, testing - I've seen engines that play worse with >1 cores .

I wonder what engine you could possibly be thinking about.

[mar]

I wonder what engine you could possibly be thinking about.

[MahmoudUthman]

What kind of question is that? Are you able to make your own decisions?
Do whatever you want and when you see fit.
LazySMP is trivial to implement and can be done in less than a week (even less if you can afford to work fulltime on it).

I'm but I lack the experience to judge whether or not It's worth the effort (coding & debugging) at this level before trying other things like the ones I mentioned.

Never consider parallel search. It is an inefficient usage of resources.

Never as in never or not right now ? , I thought that current algorithms scale quite well on low number of cores which what I'm interested in "for now" , I only have a I7-5820k processor.

That is what I always do. I typically analyze a tree, so I can do multiple branches in parallel. Some people also analyze the same position with various engines.

what if the user runs the engine using a single thread , I've no idea about current algorithms , do they really add that much overhead to a single threaded search ?