Я прочитал, что в плюсах нет своего многопоточного программирования и поэтому плюсы это просто враппер над многопоточностью, которую предоставляет ось.

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

MasterZivLumixЯ прочитал, что в плюсах нет своего многопоточного программирования и поэтому плюсы это просто враппер над многопоточностью, которую предоставляет ось.


Начнем с того, что это уже не так. В последнем стандарте в C++ появилась уже встроенноая поддержка многопоточного программирования.

http://en.wikipedia.org/wiki/C 11#Threading_facilities

Да я в курсе за эту шнягу. Но я нигде не могу найти (в том числе по этой ссылке), информацию, что эта многопоточность не использует нативные потоки операционной системы, то есть не является враппером. Максимум, что я нашел это фразу типа "многопоточность в ++11 встроена в ядро плюсов", но значит ли это что теперь это никак не связано с потоками операционной системы я пока пруф найти не могу.



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

Понятно. Значит в нашем случае многопоточность дело лишнее, потому что у нас общие данные и так используются без усилий. Эту безусильность гарантирует менеджер пула процессов. А что касается запись в общий файл, то у нас используется фишка из фрилока: если занято усни, а потом попробуй снова.

PS. Кстати, именно на основе этого критерия я сегодня утром посоветовал чуваку вот тут 14691640 решить его задачу как раз многопоточно, а не многопроцессово. Хотя у него там питон, а я не в курсе как питон работает с многопоточностью...

MasterZivОдно не понятно -- чем тебе так мешает участие операционной системы.
Для справки -- в диспетчеризации процессов ОС участвует ровно так же, как и в диспетчеризации потоков, только стоимость переключения контекста дороже.

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


LumixВообще, многозадачность на процессах уже сейчас (я считаю) -- пережиток прошлого.

Соображения, почему решение на процессах пока ещё живы.

1) младшие кодеры часто совершают ошибки с нарушением атомарности при реализации многотредовых систем, а при организации параллели на процессах эту атомарность обеспечивает ось. мультитредовый код сложнее читать и он более error prone

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

3) параллель во многом это архитектурное решение, там организация получается более слоисто-списковая и в итоге все сводится к менеджеру и воркерам, а их проще понимать как две разные утилитки: распил, обсчет, премерж ака синхрон ака докрутка, мерж

Поскольку в нашем случае никакого функционального разделения нет, а задача 100% на дата-декомпозите, то и построение на процессах канает.

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

LumixПо одной простой причине -- потоки могут разделять ресурсы, а процессы -- нет.

Единственная причина которую я встречал в своей практике, где реально важен меморишаринг, это какая-то супержирная дата, которую дорого капусулить в сервис, ну например, какой-нибудь look-up на 1,5 Гб. Все остальные кейсы которые мне встречались сводились к организации общения через третье лицо, например, через файл, через базу, через сервер.


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

Ещё достоинства есть.
1) исчезает вопрос с контролем атомарности => проще разработка
2) управление нагрузкой может осуществлять сисадмин стандартными средствами оси, нет надобности мутить свои балансеры

- - - - - - - - - - - - - - -

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

MasterZivС чего ты взял, что существуют какие-то такие волшебные "потоки вне ОС", которые должны быть быстрее потоков обычных?

Ну вот так подумал, а вдруг такое есть. Создал тему. Оказалось, что этого нет. Вопрос закрыт.

chabapokа ssd довольно сильно поплохеет.

Прошу уточнить термин поплохеет для ssd, потому что у нас серваки как раз на ssd. У них реально резко сильно вырастает физический износ??? или под поплохеет имеется ввиду 100% нагрузка в течение очень долгого времени?

jmp_originalта же функция в разных процессахКстати, а кто в курсе, если одна и та же функция используется в разных процессах, то код этой функции копируется или размещается в разделяемой памяти и используется оттуда?
Разделяемый, при условии, что EXE/DLL, в которой находится этот код была загружена по одинаковому адресу (в виртуальном адресном пространстве процесса).

То есть вы получается утверждаете две интересные вещи

1) не всегда DLL означает загрузку функции один раз и если DLL загружается не операционной системой, а из кода вручную (аналог создания на куче), то такое "ручное" подсоединение DLL создаст столько же копий, сколько и процессов

2) что ось не оптимизирует память даже если чексум вновь исполняемого файла равняется чексуму уже находящихся в исполнении файлов

так-то странно...

chabapokА под термином поплохеет подразумевалось что изза seek-ов у вас производительность чтения просядет и это может нивелировать эффект от 15 параллельных потоков, может даже сделать гораздо хуже.

Хорошо намек понял. Попробуем поставить 8 дополнительных ssd дисков, на которых будут созданы точные копии сырой даты для чтения и тогда на один диск будет приходится всего 2 ядра / процесса.