Распараллеливание программы (ядра/потоки)

[mihaild]

Andrey_Kireew в сообщении #1433499 писал(а):

Прихожу к такому выводу: просто _beginthreadex не всегда запускает все потоки

Вы бы всё-таки для очистки совести проверили, что цикл do...while иногда выполняется больше одного раза.
(вообще я удивлен, что на практике поток может не создаться; я с таким сталкивался только при неправильно сконфигурированном контейнере)

Andrey_Kireew в сообщении #1433499 писал(а):

пишу по мимо массивов. Такое, конечно в теории возможно, но только в 2-х случаях

Такое происходит в нетривиальном коде (где работа с индексами сколько-то сложнее "пробежаться по всему массиву") сплошь и рядом.

[Andrey_Kireew]

mihaild в сообщении #1433506 писал(а):

акое происходит в нетривиальном коде (где работа с индексами сколько-то сложнее "пробежаться по всему массиву") сплошь и рядом

я бы с Вами согласился, если бы не выкладывал свой код. Ведь выделение ресурсов в нём происходит самым обычным образом. Какая же тогда ошибка возможна при их освобождении? Единственный вариант - для этого нужно изменить значение указателя, ну или это значение как то теряется. А всё, что происходит внутри потоковой функции никак не может вызвать такой ошибки. Они ведь все завершаются нормально.

На счёт проверить число повторений

do...while

- это мысль хорошая, так и сделаю

[mihaild]

Andrey_Kireew в сообщении #1433507 писал(а):

Ведь выделение ресурсов в нём происходит самым обычным образом

В фрагменте, на который я отвечал, говорилось про запись мимо массива, а не про освобождение ресурсов. А куски с записью не показаны.

[Andrey_Kireew]

В общем, помимо

a[].ind[]

ничего не записывается, ни внутри функций ни в основном потоке. Он используется только в цикле

for()

, в котором границы заданы явно.

К стати, проведя проверку, ни одного повторного запуска потока я так и не обнаружил. Сейчас запустил 100 задач подряд - жду результатов. Может дело все и не в этом.

[Dmitriy40]

Вот чем и плохи недоисправленные баги — могут возникать и пропадать совершенно произвольно.

[Andrey_Kireew]

Гонял я программу много раз, подозрения по поводу _beginthreadex не оправдались, не одной ошибки она не выдала. 70% запусков - время выполнения 87-88 сек., но иногда оно увеличивалось до 90 - 110 сек. Всё это с натяжкой можно считать 4-х кратным ускорением. Но были и аномальные затяжки и от 120 до 150 мс. (около 10% от всех испытаний). Справедливости ради, нужно сказать, что и в однопоточном варианте время выполнение не всегда одинаково - от 360 до 380 сек.
Ни одного зависания за всё время не было. В общем, по крайней мере иногда, программа работает правильно.
С чем связаны затяжки - не совсем понятно. Может фоновые процессы windows влияют?

-- 05.01.2020, 22:20 --

Уважаемый Dmitriy40, если Вас не затруднит, поясните пожалуйста поподробнее, какой плюс может дать использование Sleep(0)?

[Dmitriy40]

Andrey_Kireew в сообщении #1433536 писал(а):

Уважаемый Dmitriy40, если Вас не затруднит, поясните пожалуйста поподробнее, какой плюс может дать использование Sleep(0)?

Уменьшение общего времени счёта если вдруг нагрузка на разные потоки окажется разной. Идея в том чтобы заставить ОС чаще переключать активные потоки (когда их больше количества ядер включая логические с гипертредингом) и соответственно более равномерно балансировать нагрузку между потоками. Ровно тот же эффект должен достигаться делением задачи на более мелкие куски, даже без увеличения количества потоков. Но это лишь идея, реально не проверял, да и условия тестов у нас разные.
Если же все потоки выполняются примерно одинаковое время, то пользы не будет. Как и если их меньше количества ядер. Особого вреда правда тоже не должно быть (если без фанатизма, не вызывать Sleep чаще пары-тройки раз в секунду).

[Andrey_Kireew]

Спасибо, с этим всё понятно. Видимо мне от этого толку не будет.
Гранулярность я тоже пытался увеличивать, но это только снижает общее быстродействие, хотя и не очень сильно. Наверное всё это даёт эффект только при неравномерном делении задачи.

[Dmitriy40]

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

[Andrey_Kireew]

Andrey_Kireew в сообщении #1433552 писал(а):

Гранулярность я тоже пытался увеличивать, но это только снижает общее быстродействие

Приношу извинения за неправильную формулировку, тут нужно было написать уменьшать. Т.е. я увеличивал количество потоков, вплоть до 40, но это не приводит к желаемому эффекту, наоборот, быстродействие даже немного уменьшается. Ну и 87 сек. это ровно 1/4 от 340, 4-х кратное ускорение уже достигнуто.
Остаётся лишь один вопрос - почему в некоторых случаях это время может так сильно увеличиваться? иногда почти в 2 раза
могут ли фоновые процессы оказывать такое сильное влияние на работу?

[Dmitriy40]

Плюс осталась непонятка с гипертредингом, ускоряет ли оно программу и насколько.

[SergeCpp]

Измерения

Если мерять посредством GetThreadTimes, то будут две важные полезности:

1) Независимость от других потоков (системные, другие);
2) Появится полезная статистика по временам: а) главного потока; б) каждого из рабочих.

Выдавать в конце табличку: суммарное, главный, рабочий_1, ...

N.B. А времён будет по три для каждого потока: exit-creation, kernel, user. Ага, все нужны.

Relinquish

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

[Andrey_Kireew]

Я ещё раз проверил без Hyperthread. Лучшее время на 4-х ядрах с 4-мя потоками 96-97 сек. Иногда появляются те же самые глюки и время выполнение почти удваивается. Увеличение количества потоков так же ведёт лишь к весьма незначительному замедлению работы. В общем, получается, что с Hyperthread примерно на 10% лучше.

По поводу этого глюка, я отследил следующее. В некоторых случаях, когда потоки начинают завершатся, последний поток начинает "метаться" по разным ядрам. Ядра загружены хоть и понемногу но все. И этот процесс довольно продолжительный. Если бы все потоки оставались на своих ядрах, наверное, такого бы не было. В программе ошибок может никаких и нет.
Как бы привязать потоки к ядрам?
Есть и ещё одна идея: поделить задачу на много частей, но не запускать их все сразу. Сначала, скажем, запустить только 8 потоков, а остальные - "подбрасывать" по мере завершения уже запущенных. Так получится, что все ядра будут загружены на 100% почти постоянно и не будет этого длительного периода, когда они работают только на 25%.

Что Вы думаете по этому поводу?

-- 06.01.2020, 02:13 --

SergeCpp в сообщении #1433591 писал(а):

Если мерять посредством GetThreadTimes
, то будут две важные полезности

спасибо SergeCpp
надо будет попробовать

[Dmitriy40]

SergeCpp
По вашей последней ссылке как раз объяснение почему Sleep(1) лучше Sleep(0) в плане балансировки загрузки потоков.

Andrey_Kireew в сообщении #1433597 писал(а):

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

Это непринципиально. Максимум чем грозит потоку перескок на другое ядро - грубо говоря перезагрузкой всего кэша L2. Я тоже это боялся — пока не посчитал времена, оказалось эти перескоки тратят много меньше 1% времени в самом худшем случае.

Andrey_Kireew в сообщении #1433597 писал(а):

Как бы привязать потоки к ядрам?

Привязать можно, но не нужно.

Andrey_Kireew в сообщении #1433597 писал(а):

Есть и ещё одна идея: поделить задачу на много частей, но не запускать их все сразу. Сначала, скажем, запустить только 8 потоков, а остальные - "подбрасывать" по мере завершения уже запущенных. Так получится, что все ядра будут загружены на 100% почти постоянно и не будет этого длительного периода, когда они работают только на 25%.

А это Вы своими словами повторили мой совет (даже с готовым исходником!) разделить задачу на много мелких частей и выполнять в каждом потоке следующую часть.

[Andrey_Kireew]

Dmitriy40 в сообщении #1433601 писал(а):

это Вы своими словами повторили мой совет
(даже с готовым исходником!)

Да, верно. Я видимо тогда не до конца осознал всего смысла. Ели поступить так, то по идее, этот "хвост" где процессор работает на 25% мощности станет короче. Надо будет попробовать