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

[SergeCpp]

Dmitriy40
1) Я не вижу кода [ == полного кода ]. По тем же частям, что здесь приводятся, видно, что (*) "страх и ужас".
2) У меня уже нет компьютера, поэтому практически (запустить код, посмотреть) я уже не помогу (да и сил уже нет, годы идут).
3) А по причине (*) и разбираться не имеет смысла, ибо (*).
4) Я не умею делать из непрограммиста (а это мне очевидно по частям кода, вопросам и реакции на них) программиста. Считаю, это невозможно.

-- 17.01.2020, 03:49 --

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

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

Потому что new использует межпоточную синхронизацию (так как куча оператора new одна на процесс). Пройдите отладчиком, увидите

т.е. Вы считаете, что запись массивов в стёк это правильное решение, а не какое то там "шаманство"?

Я вам много советовал вначале, но вы же не слушаете.

Быв моложе, я бы намудрил с placement_new. Но это всё баловство. Я вам дал пример программы своей, где всё, что нужно, выделяется при старте программы (arena) и потом использутся.

[Dmitriy40]

Самым логичным для данной конкретной задачи будет порадоваться решению проблемы и не делая никаких (глобальных) выводов оставить как есть. Это разумеется неправильно, по хорошему надо разобраться и найти причину, заодно узнав много нового/полезного про работу процессоров, но ... не так уж и редко бывают ситуации нахождения способа исправления проблемы без установления её причин. Это не нормально (я считаю), но такова жизнь.
Просто раз причина точно не установлена, то и выводов делать не надо! Заработало и ладно, помучаетесь в следующий раз.

[Andrey_Kireew]

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

Пройдите отладчиком, увидите

У меня нет отладчика, я прямо "наживую" программирую, ибо всё равно не программист, и сделать его из меня (по Вашему же мнению) невозможно. Да и не нужно, если честно, мне главное чтобы программа работала

-- 17.01.2020, 04:55 --

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

Я вам дал пример программы своей, где всё, что нужно, выделяется при старте программы (arena) и потом использутся

так у Вас там всё под DOS по большей части, меня это как то смутило ...

[SergeCpp]

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

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

Рихтера почему не читаете?..

ещё как читаю, именно благодаря ему я привязал потоки к ядрам и установил максимальный приоритет потоков

Плохо читаете, ибо вот это здесь не нужно.

мне главное чтобы программа работала
===
Я вам давал ссылку на статью ремарка, где сказано делить задачу на много мелких частей для балансировки. А вы -- всё своё... Ну, я не умею в таких условиях -- советую, а советы -- в игнор. Ещё информацию не даёте. Да и код у вас всё же -- больно же смотреть, вот физически больно...

[Andrey_Kireew]

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

что (*) "страх и ужас"

что же Вас так напугало и ужаснуло в том минимальном коде? уж не goto ли?

[SergeCpp]

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

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

Я вам дал пример программы своей, где всё, что нужно, выделяется при старте программы (arena) и потом использутся

так у Вас там всё под DOS по большей части, меня это как то смутило ...

??? Вы точно не программист. Там не ДОС. Это очевидно.

[Dmitriy40]

Andrey_Kireew
Отладчик встроен прямо в IDE VisualStudio.
И да, привязку потоков таки уберите. Как и realtime приоритет, вообще выше above normal никогда не ставьте! Этого никогда не нужно. Подвесите всю винду ... У меня вообще все вычисления дольше пары часов идут в Idle в фоне.

SergeCpp
Не скажите, был же опыт с 40 потоками, кажется даже улучшение стабильности поведения было. Но в релиз не пошло, да ...

[SergeCpp]

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

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

что (*) "страх и ужас"

что же Вас так напугало и ужаснуло в том минимальном коде? уж не goto ли?

Нет. Не goto. Ну вот киньте краской в холст и дайте художнику и спросите, что его ужаснуло, пусть перечислит.

[Andrey_Kireew]

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

Я вам давал ссылку на статью ремарка, где сказано делить задачу на много мелких частей для балансировки

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

[SergeCpp]

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

SergeCpp
Не скажите, был же опыт с 40 потоками, кажется даже улучшение стабильности поведения было. Но в релиз не пошло, да ...

А вы ведь программист. Стыдитесь. Почитайте статью ту. Так как вы программист, то не поясняю. Уже пояснял, кстати.

-- 17.01.2020, 04:11 --

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

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

Я вам давал ссылку на статью ремарка, где сказано делить задачу на много мелких частей для балансировки

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

Я бы мог лет 20 назад и попавшись на ваше "слабо" и для интереса решить вашу задачу ( == вы даёте всю информацию, код ваш не нужен ). Сейчас не буду, по упомянутому выше "нет компьютера" и "годы".

[Andrey_Kireew]

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

Не скажите, был же опыт с 40 потоками, кажется даже улучшение стабильности поведения было. Но в релиз не пошло, да ...

не пошло, потому, что чем больше потоков, при условии что задачи одинаковой сложности, тем работает медленнее, пусть не на много, но всё же. Помнится, 40 потоков давало 10% замедление, по сравнению с 4-мя потоками.
Может где то, это и хорошо, например, когда невозможно получить большие куски одинаковой сложности, но это не мой случай. Сейчас, самый лучший (самый быстрый) вариант - это 8 потоков с Hyperthread. Увеличивать их число не выгодно.

[Dmitriy40]

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

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

SergeCpp
Не скажите, был же опыт с 40 потоками, кажется даже улучшение стабильности поведения было. Но в релиз не пошло, да ...

А вы ведь программист. Стыдитесь. Почитайте статью ту. Так как вы программист, то не поясняю. Уже пояснял, кстати.

Да читал, и не стыдно, я тогда сразу и ответил:

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

UPD. Ого, в той заметке вообще N=128 рекомендуют ... Честно говоря не согласен, думаю N=8..10 (для 4/8 процессора) для вычислительных задач будет всегда достаточно.

С остальным в ней согласен разумеется.

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

Помнится, 40 потоков давало 10% замедление, по сравнению с 4-мя потоками.

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

[Andrey_Kireew]

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

Там не ДОС. Это очевидно

я только титульную страницу смотрел, что внутри не знаю

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

Нет. Не goto

Ну, тогда ещё ладно ...

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

Я бы мог лет 20 назад и попавшись на ваше "слабо" и для интереса решить вашу задачу

Здесь Вы себе льстите, ни как бы не могли - запрограммировать алгоритм и решить задачу, это не одно и то же, равно как решить готовую задачу и её правильно поставить. Всё равно, что наборщице текстов претендовать на набираемые научные труды. Это просто смешно.

-- 17.01.2020, 05:46 --

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

Я вообще предлагал потоки запускать в начале и потом уже в них самих делить задачу

10% - это накладные расходы, связанные с увеличением количества задач, и с увеличением числа задач они только увеличатся. Да, у меня там было реализовано не оптимально, как у Вас наверное побыстрее, но всё равно, накладные расходы - это накладные расходы и они растут. Если Вы намекаете, что это эффективный путь борьбы с колебаниями времени выполнения потоков, то далеко не самый эффективный и не самый простой (ну может так только в моём случае).

И опять же, повторяюсь, мою задачу очень сложно разбить на очень мелкие куски. Вот в такой пропорции нужно делить входной массив на 4 части для одинаковой трудоёмкости задач 0:47:102:196:804. К чему приведёт увеличение числа задач - догадаться не сложно - рано или поздно наступит предел, когда первый фрагмент будет состоять из 1 элемента.

[SergeCpp]

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

Короче делайте на N потоков и прогонами проверяйте при каком N время выполнения меньше. Это самый разумный способ. По идее N=8 должно быть быстрее, но могут быть исключения.

UPD. Ого, в той заметке вообще N=128 рекомендуют ... Честно говоря не согласен, думаю N=8..10 (для 4/8 процессора) для вычислительных задач будет всегда достаточно.

Там рекомендуется: "общее количество задач должно быть не меньше чем, ну скажем, 16*количество_ядер". Задач! Не потоков!

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

2) Я же в самом начале приводил ссылку на статью remark, где написано: "общее количество задач должно быть не меньше чем, ну скажем, 16*количество_ядер (для обеспечения балансировки нагрузки), и так же абсолютный размер задачи должен быть в разумных пределах, скажем, не больше 100 мс". Ключевое я выделил.

Можно задать параметрами: число_потоков и число_задач. И смотреть-выбирать минимальное по времени работы. Задачи в очередь. Потоки в очередь. Свободен поток -- берёт из очереди.

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

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

Свободен поток -- берёт из очереди.

Именно эту модель я уже и привёл выше, с готовым исходником. И не нужно 16N потоков, достаточно лишь N.

Повторяю. Там рекомендуется: "общее количество задач должно быть не меньше чем, ну скажем, 16*количество_ядер". Задач! Не потоков!

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

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

общее количество задач должно быть не меньше чем, ну скажем, 16*количество_ядер

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

не нужно 16N потоков

Из "абсолютный размер задачи должен быть в разумных пределах, скажем, не больше 100 мс" видно, что задача здесь (в статье) -- не поток.

Повторяю. Нет в статье рекомендации про число потоков = 16*количество_ядер, а есть рекомендация про число задач = 16*количество_ядер.

Задача -- порция обрабатываемой информации. "Очень ориентировочно минимальный объём полезной работы на задачу должен быть порядка 10 000 тактов." После этого задача кончается и выполнявший её поток выбирает из очереди следующую задачу.

P.S. Ужас. Современные программисты...

[Andrey_Kireew]

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

Повторяю. Нет в статье рекомендации про число потоков = 16*количество_ядер

да поняли все это давно, точно так всё и делали, посмотрите выше - там даже пример кода я приводил, кажется 4 ядра и 40 задач было (ну да, потоками задачи назывались как то машинально, только никого кроме вас это не смущало)

-- 17.01.2020, 06:48 --

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

Отладчик встроен прямо в IDE VisualStudio.
И да, привязку потоков таки уберите. Как и realtime приоритет, вообще выше above normal никогда не ставьте! Этого никогда не нужно. Подвесите всю винду ... У меня вообще все вычисления дольше пары часов идут в Idle в фоне

Всё зависит от ситуации, для кого проблема "подвесить" windows, а для кого проблема притормозить windows-ом программу.

Если вычисления идут пару недель, то до windows дела никакого нет, тут дотронуться до компа лишний раз боишься, не то что посторонние задачи на нём запускать. А привязка к ядрам и повышенный приоритет в общем дают прирост производительности до 5%, это я уже проверил. Да, немного - но всё равно лучше чем ничего