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

[Aritaborian]

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

В диспетчере задач винды есть колонка (на странице процессов) "Счётчик потоков"

Я щас её включил (раньше она была отключена; обычному пользователю это не нужно) И что я вижу. Браузер Pale Moon. Счётчик потоков: 63. Торрент-клиент Tixati. Счётчик потоков: 39. Видеопроигрыватель MPC-HC. Счётчик потоков: 22. Comodo Internet Security. Счётчик потоков: 20.
Это для меня равносильно фразе из анекдота.

Цитата:

— Петька, приборы?
— Двадцать!

О чём оно вааще?

[Andrey_Kireew]

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

(Оффтоп)

По поводу компиляции - я бы конечно так и сделал, и не задавал таких несущественных (*на Ваш взгляд) вопросов, если бы это было так легко. Но дело в том, что в силу разных причин, я работаю без GUI, компилирую из командной строки. Ошибки сыплются как из рога изобилия, и отловить все их - целая история. И в такой неизведенной для меня области, как многопоточные приложения, в таких условия, чтобы дойти до правды, потребуется не один день. И не факт, что скрытых ошибок в коде не останется. Что плохого, если специалист-профессионал, коим в данной области я не являюсь, укажет мне на ошибки сразу, и избавит меня от многодневных мытарств? В конце концов, если кого то такие "мелочи" оскорбляют (например, такого персонажа как Aritaborian) они могут просто ничего не отвечать и всё). А тема эта, мне кажется многим была бы интересной

[Aritaborian]

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

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

Павел Майоров писал(а):

На Курском вокзале по ряду причин
Максим поедает огромный хычин

Компилирование из командной строки это обычная вещь, она в объяснениях и оправданиях в принципе не нуждается.

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

если кого то такие "мелочи" оскорбляют (например, такого персонажа как Aritaborian)

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

[Pphantom]

Andrey_Kireew, может быть, вы снача саму решаемую задачу опишете? Честно говоря, пока что по попыткам написания параллельного кода кажется, что сначала стоит оптимизировать непараллельный.

[Dmitriy40]

Aritaborian в сообщении #1433003 писал(а):

О чём оно вааще?

Для однопоточных приложений тут будет цифра 1, для многопоточных - больше 1. Вот так и можно отличить. А для 4 вычислительных потоков плюс основной будет цифра 5.
Разумеется это не говорит что все они работают, и тем более правильно, но они по крайней мере запустились. Что и будет ответом на Ваш вопрос как определить многопоточно ли выполняется программа. Не более того.

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

правильно ли я Вас понимаю, что худо-бедно, эта программа заработает, и ошибок теперь в ней нет?

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

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

Ошибки сыплются как из рога изобилия, и отловить все их - целая история.

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

[slavav]

Не увидел в обсуждении совета предпочитать процессы нитям.
Если задача позволяет, то разбейте её на части и каждую часть обработайте отдельным вызовом однопоточной программы. Программы запускайте параллельно средствами операционной системы.

[SergeCpp]

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

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

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

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

Когда я всем этим занимался (конец девяностых — начало двухтысячных), то информационным источником номер один для меня была MSDN (к VC++ 5 и 6), причём 5 версия была во многом лучше. Там, во-первых, были прекрасно и ясно написанные специальные разделы по разным тематикам (в частности, многопоточность, синхронизация процессов), во-вторых, было огромное количество работающих примеров, которые можно было изучать и модифицировать, в-третьих, было много журнальных статей, в-четвёртых, специально написанных статей (или для MSDN или просто авторских, не для журналов), в-пятых... многого я уже и не помню (вспомнил, что ещё книги там были). MSDN уже следующей версии было заметно "downgrade" в разных аспектах. Последующие версии я уже почти не отслеживал (редко-редко заходя уже онлайн и убеждаясь в снижении его уровня).

Книги (бумажные) были источником весьма дополнительным (неосновным и, скорее, беллетристическим, ибо всё книжное, что я тогда читал, было много лучше описано в той же MSDN, где, кстати, и некоторые книги были).

Отмечу одну книгу очень хорошего уровня, и технического, и авторского (хорошо литературно пишет): Джеффри Рихтер. Windows для профессионалов, третье и четвёртое издания (много отличаются, причём в четвёртом издании отсутствует важная глава или две из третьего и есть много других нежелательных изменений; однако, есть и новое полезное).

Ещё три хорошие книги, где есть информация о многопоточности, скорее, более технического плана: Соломон и Руссинович. Внутреннее устройство Windows 2000 (3rd Edition), Свен Шрайбер. Недокументированные возможности Windows 2000 и Алексей Коберниченко. Недокументированные возможности Windows NT.

Эти книги были (и есть) у меня в бумаге и я их неоднократно читал-разбирал. И всё же, повторюсь, все они лишь "беллетристрическое дополнение" к совершенно достаточному MSDN (версий VS 5 или 6), пусть, порой, и весьма хорошо написанное.

Форумов и интернета тогда у меня не было, и, зарегистрировавшись на RSDN и некоторых других программистских форумах в 2005 году, я увидел, что форумы дают, скорее, отрицательную информацию и помощь, и в основном используются для развлечения, порой весьма профессионального (типа философских дискуссий по программированию или в разделе C++), но, всё же, развлечения (и отвлечения).

[Andrey_Kireew]

Pphantom в сообщении #1433013 писал(а):

Честно говоря, пока что по попыткам написания параллельного кода кажется, что сначала стоит оптимизировать непараллельный

спасибо, но в этом нет необходимости

В общем, выясняется, что программа работает: 4 потока загружает процессор на 50%, 8 потоков - на все 100%. Но это по диспетчеру задач, как пишет Dmitriy40 - неточно. Тем не менее - хотя бы в первом приближении ... Потом просто реальную производительность нужно будет отследить.

Единственный нюанс - не работает WaitForMultipleObjects() в том плане, что выполнение программы то она прерывает, но так навсегда на этом месте и застревает. Хотя, судя по диспетчеру задач, все потоки завершаются. В общем, ожидание завершения оказалось неправильным.

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

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

Я же, как Вы наверное догадались, пытаюсь всё сделать сразу, в надежде, что всё заработает, либо - ошибки очень быстро обнаружатся. Правда, надежды сбываются не всегда

[mihaild]

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

пытаюсь всё сделать сразу, в надежде, что всё заработает, либо - ошибки очень быстро обнаружатся

Так работает только у опытных разработчиков на простых задачах.
И проверка на компилируемость - самое базовое, что можно сделать. Код, который не компилируется, заведомо некорректен. Так что смело начинайте с того, что приводите его в компилируемое состояние, потом запустите хотя бы руками на нескольких примерах - это в любом случае нужно делать, и это стоит научиться делать самому. Потом уже с компилирующимся и как минимум иногда работающим кодом приходите на форум с вопросом "всё ли тут правильно".
Ну либо если какую-то ошибку исправить не получается - то постарайтесь сделать минимальный полный пример с ней (т.е. полный текст программы, в которой проявляется эта ошибка, но этот текст должен быть как можно короче), и приходить с ним. Это тоже важный навык - выделять как можно меньший кусок непонятного.

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

не работает WaitForMultipleObjects() в том плане, что выполнение программы то она прерывает, но так навсегда на этом месте и застревает

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

не вижу, как в вашем коде связаны создаваемые соытия и потоки, так что не выглядит как что-то правильное

[Andrey_Kireew]

slavav в сообщении #1433036 писал(а):

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

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

-- 01.01.2020, 23:43 --

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

mihaild в сообщении #1432986

писал(а):
не вижу, как в вашем коде связаны создаваемые соытия и потоки, так что не выглядит как что-то правильное

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

[Dmitriy40]

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

В общем, выясняется, что программа работает: 4 потока загружает процессор на 50%, 8 потоков - на все 100%. Но это по диспетчеру задач, как пишет Dmitriy40 - неточно.

Для оценки запустились ли все потоки - вполне точно.
Для оценки быстрее ли 8 потоков чем 4 - не точно, иногда совсем.

Фактически диспетчер задач показывает лишь возвращает ли поток управление в ОС (запросом функций ОС, например ввода/вывода) или сам по себе что-то там молча фурычит. И в последнем случае совершенно неважно что именно фурычит, главное в ОС не уходит - и всё, загрузка ядра будет 100%. Пустой цикл из одних nop загрузит тоже ровно на 100% каждое ядро. В то же время два цикла в разных потоках с разными командами (скажем только плавающими и только целочисленными сдвигами если эти типы выполняются всегда в разных портах запуска) выполнятся практически ровно за то же время что и любой из них по отдельности, т.е. 100%+100%=100% по показаниям диспетчера задач. В этом смысле - он совсем врёт. Потому самый надёжный метод - время прогона.
Надеюсь не надо пояснять что 100% загрузка ядра для 8-ми ядерного процессора в диспетчере задач отображается как 12%.

Ещё один общий совет: если нужен обмен любыми данными между работающими потоками (в том числе между вычислительным и основным), то он должен быть через критические секции (как самые быстрые из семафоров в винде) или другие средства синхронизации. Допускаемое исключение - если поток гарантированно ещё не запущен или уже остановлен (и последнего точно дождались!).

(SergeCpp)

Для меня в документации, в любой, хоть MSDN, хоть книги, главной засадой является недокументированность возможных реакций на возвращаемые ошибки. Закрыть открытые handle это понятно, но очень часто непонятно что можно и даже что нужно предпринять если некая функция вернула некую ошибку. Бывает по документации даже непонятно как вообще в таком случае определить текущее состояние системы (или файла или соединения или чего там ещё) чтобы продолжить работу корректным способом. И искать эти варианты приходится буквально методом тыка.

[mihaild]

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

В общем непонятно как лучше сделать

Ну вот я абсолютно ничего не знаю про эту библиотеку потоков. Но пошел в гугл с запросом "_beginthreadex" и первой ссылкой получил официальную документацию, где есть пример, как создать поток и дождаться его завершения.

[Andrey_Kireew]

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

для 8-ми ядерного процессора в диспетчере задач отображается как 12%

да, я догадался, однопоточная программа именно на столько его и загружает

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

если нужен обмен любыми данными между работающими потоками

в этом нет необходимости, все данные можно хранить отдельно друг от друга

[Dmitriy40]

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

должен быть через критические секции

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

[SergeCpp]

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

Для меня в документации, в любой, хоть MSDN, хоть книги, главной засадой является недокументированность возможных реакций на возвращаемые ошибки. Закрыть открытые handle это понятно, но очень часто непонятно что можно и даже что нужно предпринять если некая функция вернула некую ошибку. Бывает по документации даже непонятно как вообще в таком случае определить текущее состояние системы (или файла или соединения или чего там ещё) чтобы продолжить работу корректным способом. И искать эти варианты приходится буквально методом тыка.

Это да. Здесь необходима (даже обязательна) большая начитанность-насмотренность, ибо в том же MSDN, как я говорил, есть множество standalone-статей, порой, весьма высокого уровня (припоминается Мэтт Питрек, но память может подвести), также там "тихонько" лежат примеры (а примеров там, сколь помню, тысячи), в которых иллюстрируется то или иное, не описанное где-либо. Помянутые книги, при всей беллетристичности, дают некие ориентиры и направления (и нетривиальные тоже). Разумеется, отладчик. Некоторые вещи нигде не встречаются и с ними сталкиваешься на практике (в той же Sync моей есть немного такого). Совсем "отчаявшиеся" товарищи идут по пути Соломона-Руссиновича, Шрайбера и Коберниченко (с которым я даже "почти знаком" IRL, через одного человека). И "тётя Ида".