Покупка нового компьютера. Выбор модели и комплектации

WinPooh Сколько движков в Aquarium 2018 можно будет задействовать в компьютере с процессором 4 ядра и 8 потоков?!

Благодарю!

Без замедленя работы чего?
Интерфейс, система, антивирус, фоновые процессы, другие приложения?

И во сколько раз будет увеличиватья скорость расчёта по сравнению с одним потоком? Что выгоднее с точки зрения прироста скорости рассчёта: увеличение тактовой частоты отдельного, единсвтенного, ядра процессора, на котором работает движок, в N раз или увеличение в те же N раз количества ядер, отданных в распоряжение движка?
Мне кажется, что первый вариант всегда предпочтительнее.

В случае с Hyperthreading это не совсем верно - 8 потоков будут чуть слабее чем 4 потока - что-то вроде по 1000 килонодов на 4 потоках и по 800 на 8 поскольку логические ядра не идеальные, но максимум производительности все равно будет на 8.

А если ядер будет много очень много, не возможна ли такая ситуация, что абсолютное количество просчитанных узлов окажется при N задействованных ядрах (по одному на поток) меньше, чем при N-1 при том, что останутся ещё свободные ядра для работы системы и прочих приложений?

А если есть два схожих процессора (техпроцесс, частота, TDP одинаковые), но один 4х4, а другой 4х8, то не получится ли, что с точки зрения эффективности работы шахматного движка второй (4х8) будет хуже ? Ведь во втором случае, чтобы использовать всю мощь процессора из 4 ядер, придется гонять 8 потоков, а это кажется менее эффективным при распараллеливании, чем честных 4 ?

Второй будет лучше. Современные движки хорошо параллелятся.

Но, вообще говоря, выбирать между процессорами не нужно. Гипертрейдинг легко отключается BIOS'е

Вообще-то гипертрейдинг должен заметно поднять скорость движка, от 30 до 70% (см. бенчмарки у ипмана) за счет большей загрузки процессора. Это касается современных движков с распараллеливанием методом LazySMP, то есть почти всех топовых.

Если такого не происходит, значит либо Гипертрейдинг работает не очень, либо Турбобуст на вашем процессоре компенсирует недозагруз повышением частоты. В таком случае особой разницы нет - увеличение числа потоков повышает "ширину" поиска, а увеличение частоты повышает глубину. Правда, за сверхдолгий анализ не поручусь - данных нет.

Именно лучше, а не эквивалентен? За счет чего лучше?
И ведь 4х8 будет хуже для старых движков, которые умеют работать только на одном потоке, т.к. на нем смогут получить только 1/8 мощи, так ?
(про отключение HT я понял, обязательно попробую у себя, спасибо)

Потому что на 30-70% быстрее. Уже проведено немало тестов показывающих, что при включении гипертрейдинга движки попросту сильнее играют.

Однопоточный движок получит в своё распоряжение одно ядро целиком, если конечно вы не перегрузите свой компьютер иными задачами. Таким образом это будет 1/4 производительности машины. Или даже 1/3, поскольку турбобуст обычно повышает частоту недозагруженного процессора.

Что такое "ширина" поиска?

Branching Factor - среднее количество продолжений, рассматриваемых в каждом узле. Долгое время считалось, что чем меньше мы смотрим продолжений в каждом узле, тем лучше, поскольку таким образом достигается бОльшая глубина и решения становятся более обоснованными. Но современные движки, по-видимому, отсекают так агрессивно, что многим неплохим ходам уделяется слишком мало внимания, поэтому увеличение Branching Factor (сопутствующее использованию метода распараллеливания LazySMP), неожиданно оказалось эффективным.

Ой!!! По вашему получается, что при распараллеливании движок играет по другому!? Ой!

Почему быстрее, сможете объяснить? Почему комп 4х8 может считать быстрее компа 4х4 при прочих равных?

Да, а что такого? Главное, и удвоение ядер и удвоение скорости/контроля заметно усиливает игру. Порядка нескольких десятков пунктов при любом из удвоений. Точнее я вам сказать не могу.

Читайте про гипертрейдинг:
https://ru.wikipedia.org/wiki/Hyper-threading

Давайте, например, посмотрим на внутреннюю структуру одного ядра процессора Ryzen:
https://3dnews.ru/948466

Как видите, каждое ядро содержит по 8 вычислительных блоков - четыре ALU, и по два ADD и MUL. В определенном смысле каждый из таких блоков можно сравнить с обычным калькулятором, но с ограниченным набором возможных математических операций ("кнопок"). Нам сложно загрузить сразу все эти блоки параллельной работой одновременно, поскольку обычный микропроцессор в общем-то в первую очередь адаптирован для выполнения последовательного порядка операций над числами. То есть операций, для начала которых требуются результаты предыдущих операций.

Даже несмотря на все ухищрения, навроде спекулятивных предварительных вычислений, часть блоков все равно остается не занятой. Но мы можем запустить на этом ядре второй поток расчетов. И в те моменты, пока первый поток вычислений частично или полностью простаивает, мы можем выполнять расчеты для второго потока. Понятно, что двухкратного увеличения скорости не будет, но прибавка будет очень и очень значительной.

Спасибо!
В принципе, этого хватило для моего понимания! Очень многое прояснилось простейшей ссылкой, которую я сам поленился открыть ранее. Я смотрел на это все значительно проще.

Однако, я все еще хочу оспорить про Branching Factor. Возможно не так понял. Кажется, что Branching Factor (судя по статье под ссылкой, вы имеете ввиду "Effective Branching Factor", т.е. речь про "реально просмотренные продолжения") - все же важнейшая характеристика конкретной сборки движка, и не должен меняться в зависимости от мощности железа, кол-ва ядер и наличия HT (в одной и той же позиции и глубине поиска). То есть, одна и та же сборка движка за N перебранных узлов пройдет один и тот же путь по дереву независимо от мощности железа и кол-ва потоков, на котором ее запустили (но за разное время само собой). Так ведь?

Чем больше потоков/ядер, тем больше BF. Каждый поток по сути запускает своё дерево перебора, практически независимое от других (потоки обмениваются данными только через хэш-таблицу). Таким образом, чем больше потоков, тем больше "деревьев", больше позиций смотрится на каждой глубине, соответственно больше BF.

А разве нельзя координировать движки, чтобы они не рассматривали повторяющиеся позиции?

Раньше так и делали. Расщепляли единое дерево перебора, раздавали каждому потоку индивидуальную ветку, на которой он работал. Только метод оказался не очень эффективным. При превышении 16-ти потоков прибавки в силе, по факту, нет. Возможно из-за того, что последние потоки получали худшие ветки, в которых вряд ли можно что-то найти (ИМХО). Кроме того, потоки часто простаивали в ожидании задания.

Я знаю, это звучит контринтуитивно, но текущий метод лучше работает. Он демонстрирует хорошую прибавку в силе как минимум до 384-х потоков. [1] [2]

Насчёт hyperthreading:

В каждом ядре процессора есть много разных модулей, которые умеют выполнять разные задачи (умножать числа, читать из памяти, выполнять битовые операции и т д.). Во время выполнения программы в всегда какие-нибудь модули простаивают.
Идея hyperthreading в том, чтобы использовать это, запустив два потока на одном ядре. Тогда два потока могут одновременно использовать два разных модуля одного ядра. Но если нужный модуль оказывается занят, второй поток ждёт.

Поэтому ускорение от двух потоков в рамках одного ядра зависит от характера задач. Для некоторых (очень редко) ускорение действительно может быть почти в два раза, но для большинства вычислительно сложных задач, когда все потоки делают одно и то же, ускорение относительно одного потока обычно от 0 до 30%.
Именно для шахмат я нигде информации не читал, но думаю, что ускорение от hyperthreading небольшое.

Данные есть у Ипмана, например:

Хочу так же обратить внимание, что под гипертрейдингом частота ядер может автоматически немного снижаться.

Это типичные случаи, но есть и более экстремальные прибавки, например:

В обычных шахматных движках потоки практически независимы друг от друга, поэтому они хорошо ускоряются от гипертрейдинга.

Не, надо отличать потоки ("threads") которые являются объектами операционной системы, от hyperthreads.

В многопоточном программировании (там где много threads), действительно, если задачи независимые и не надо тратить время на синхронизацию между ними, то эта многопоточность помогает лучше, чем если требуется передача информации между потоками.

hyperthreads — это способ выполнения нескольких потоков (threads) одновременно на одном ядре, и в этом случае случается потеря производительности дополнительная к замедлению из-за синхронизации threads.
При этом для hyperthreads совсем не важно, зависимы потоки или нет. Важно, какие инструкции процессора они выполняют.

Например, если на одном гиперпотоке считается например прогноз погоды, который активно работает с числами с плавающей точкой, а на другом какая-нибудь симуляция из квантовой механики, которой тоже нужны операции с плавающей точкой, то вместе работать они будут медленно (хоть данные совсем независимы, и вообще это скорее всего разные программы).
А вот если второй процесс — это подбор паролей к какому-нибудь архиву (где требуется целочисленная арифметика и копирование больших кусков памяти например), то он может выполняться параллельно прогнозу погоды с гораздо меньшим замедлением.

У шахмат все потоки делают одно и то же (целочисленная арифметика и битовые операции), поэтому с первого взгляда кажется, что шахматам hyperthreads не поможет.
Но с другой стороны на современных процессорах обычно 16 или даже 32 ALU на ядро (arithmetic logic unit, модуль как раз-таки для целочисленной арифметики и битовых операций), и может одному потоку процессора не всегда удаётся занять их всех.

Согласен со всем написанным далее. Но в любом случае движки получают большой плюс от гипертрейдинга.

Четыре ALU на ядро:
https://3dnews.ru/assets/external/illustrations/2017/03/02/948466/slide-1.png
https://3dnews.ru/assets/external/illustrations/2017/07/07/955164/xa_12.png

Вектора не в счёт. От них, по факту, всего 10 % прибавки к скорости обычных шахматных движков.

Насколько я понимаю, в программах присутствует много ветвлений (Branch), есть логические операции (Bool), в битбордах есть битовый сдвиг (Shift). Конечно же есть деление (Divide). Ну и операций с плавающей точкой (FP) очень даже не мало. Так что загрузить всего 4 порта, если скажем какие-то из них не заняты целочисленной арифметикой, найдётся чем. Это не 32 Cuda-Core на один Warp в видеокарте.
Отсюда и значительная прибавка в скорости движков на гипертрейдинге.

Напрашивается аналогия, когда есть 2 бригады по решению шахматно-шашечных задач. В одну набрали по 10 мастеров шахмат и по 10 мастеров шашек. Заказчик дает задания, бригада решает. Когда дают 15 шахматных задач в час, 5 шашечных. Шашечные мастера простаивают. Когда наоборот - простаивают шахматные специалисты. А у конкурирующей бригады 20 шахматных мастеров, являющихся одновременно мастерами по шашкам. У них такой гипертрейдинг будет повышать производительность. Никто не простаивает, все 20 мастеров в работе.

.

Это новый 12-ядерный AMD Ryzen 3900X, но в потребительском сегменте ещё должна быть 16-ядерная модель 3950X.

AMD внезапно выносит интел с рынка. Для того чтобы выбрать сейчас интелловский проц как основу нового компьютера нужны очень специфические требования.

Хотелось бы надеяться и видяшки подкрутят постепенно. Хотя мне и моей rx570 за глаза. А Проца Интел и не бывало никогда.

У меня дома стоИт 3 компа (все принудительно шахматами занимаются и я в том числе )
Первый самый древний (2013 года рождения) Проц 2яд AMD 1600, оперативная память 4гб, на программе Фриц11 Стокфиш 9 перебирает примерно 800 позиций в секунду. Далее Ноутбук (2018гв) Процессор 4яд Интел Пентиум Силвер 1100 (полный тормоз) оперативной памяти 4гб, на программе Фриц 11 стокфиш 10 обрабатывает примерно 650 позиций в секунду, но при этом набирает условную глубину 35 ощутимо быстрее чем первый компьютер (почему, если позиций в секунду он меньше смотрит). Ну и я сейчас работаю - 4яд Интел Кор ай3, 3600, оперативной памяти 8гб, на программе Фриц 11 движок Стокфиш 11 перебирает примерно 1800 позиций в секунду. На таком железе работать конечно приятней. Ну брат у меня - точно не знаю что у него за железо, но знаю что супер дорого, на программе Фриц16 перебирает аж 22000 позиций в секунду