Comments 12
Если речь о Windows, то определение процессов и потоков лучше не придумывать, а просто взять у Майкрософт https://learn.microsoft.com/en-us/windows/win32/procthread/about-processes-and-threads?source=recommendations
Если пишите на С для Windows, то пул потоков, лучше и проще не изобретать , а просто взять у Майкрософт https://learn.microsoft.com/en-us/windows/win32/procthread/thread-pools
еще можно почитать книгу Джеффри РИХТЕР : Создание эффективных WIN32-приложений с учетом специфики 64-разрядной версии Windows
Честно говоря, я даже и не знаю, зачем сейчас на С++ использовать что-то для многопоточности, кроме oneTBB:
- Данная библиотека открытая под лицензией Apache 2.0;
- Использует под капотом либо современные С++ потоки "свежих" стандартов (собственно, поэтому собственные велосипеды на них по большей части лишены смысла), либо старые системные напрямую, при необходимости работы в т.н. "Legacy"-режиме;
- В библиотеке реализованы все наиболее серьезные алгоритмы, необходимые для обеспечения качественной реализации многопоточности, такие как work-stealing, пулы, приоритетные очереди и т.п. и все это опять же, качественно увязано между собой;
По данной библиотеке есть очень хорошая книга - "Pro TBB C++ Parallel Programming with threading building blocks", Michael Voss, Rafael Asenjo, James Reinders
Ядро процессора в каждый такт работы выполняет строго одну операцию
Это давно уже не так. Еще в первые пентиумы была добавлена суперскалярность, благодаря чему они могли одновременно выполнять 2 целочисленные команды при условии независимости по данным. Ну и с появлением гипертрейдинга одно физическое ядро может выполнять параллельно 2 разных потока (именно поэтому логических ядер в 2 раза больше физических).
Согласен, что, возможно, допущена неточность. Но разве 12 чистых ядер эквивалентны по производительности 6-ти ядерному процессору, допускающему гипертрейдинг? По моим представлениям, у логических процессоров параллельность выполнения потоков будет "урезана".
Да, даже по самым оптимистическим предположениям гипертрейдинг добавляет до 30% производительности. Но ведь и удвоение физических ядер не приводит к удвоению производительности :(
Практическая ценность гипертрейдинга, что минимальное усложнение ядра позволяет загружать простаивающие вычислительные ресурсы, не занятые одним потоком. То есть этакая урезанная многозадачность :)
MIPS выполняет вообще 4 инструкции.
И еще в пользу использования готовых решений - работа с исключениями. Реализация библиотеки пула потоков с корректной обработкой исключений, которые могут возникнуть в процессе работы пользовательского кода довольно нетривиальная задача.
Отвечаю тут всем, кто "рекламирует" существующие библиотеки (без негатива). Согласен, что изобретать велосипед глупо, но иногда, чтобы прийти к использованию готовых решений, все-таки нужно лично покопаться руками и понять на какой глубине "подводные камни". Эта статья именно для тех, кто хочет немного пощупать.
Тоже нравится многопоточность, особенно чувство когда медленный процесс ускоряешь с 6 часов до 6 минут.
Было бы здорово упомянуть библиотеку OpenMP, которая позволяет делать то же самое гораздо проще и быстрее. Например thread pool с динамическим распределением ресурсов одной строкой кода.
Многопоточность и Thread Pool в C++