Y
тогда не вижу причин использовать что-то кроме std, если у тебя нормальная имплементация стандартной библиотеки
Вот не хочется городить свои обвязки вокруг std
Size: a a a
2021 March 26
YA
да, я тоже хотел написать, что вы переезжали ведь
Ну и мы на англоязычную аудиторию поздно вышли, а когда вышли оказались в тени CAFа
YA
Поделитесь кто как работает с многопоточностью: task queue, thread pool ... Когда boos был в проекте, то использовал boost::asio, там где chromium то неплохо помогал base::Thread и все вокруг этого. А вот в маленькие проекты не хочется все это тянут.
Тут нужно уточнить, для чего именно используется многопоточность. Если для распараллеливания каких-то тяжелых вычислительных задач, то имеет смысл смотреть в сторону инструментов вроде OpenMP, HPX, TBB, taskflow. Грубо говоря, смысл всего этого в том, чтобы за счет использования множества ядер сократить время выполнения какой-то операции. Например, на одном ядре что-то считаем или перекодируем за 60 минут. На шести ядрах за 10 минут.
Если для того, чтобы упростить себе (почти) одновременное выполнение кучи разнообразных активностей, то тут другой набор инструментов: MS PPL, CAF, SObjectizer, rotor, actor-zeta, Asio. Смысл всего этого в том, чтобы делать разнородные вещи не сильно задумываясь о том, что происходит вокруг. Например, условный сервер БД: принимает подключения, принимает данные, парсит пришедший запрос, строит план, выполняет план с учетом кэшей и пр., подготавливает результаты для отсылки, отсылает в сеть. Что-то из этого можно делать на общем контексте, что-то нужно разносить по разным.
Так что сама по себе многопоточность — это только инструмент для решения какой-то задачи. И в зависимости от задачи многопоточность может применяться по разному и готовить ее нужно с помощью разных инструментов.
Прошу прощения за капитанство.
Если для того, чтобы упростить себе (почти) одновременное выполнение кучи разнообразных активностей, то тут другой набор инструментов: MS PPL, CAF, SObjectizer, rotor, actor-zeta, Asio. Смысл всего этого в том, чтобы делать разнородные вещи не сильно задумываясь о том, что происходит вокруг. Например, условный сервер БД: принимает подключения, принимает данные, парсит пришедший запрос, строит план, выполняет план с учетом кэшей и пр., подготавливает результаты для отсылки, отсылает в сеть. Что-то из этого можно делать на общем контексте, что-то нужно разносить по разным.
Так что сама по себе многопоточность — это только инструмент для решения какой-то задачи. И в зависимости от задачи многопоточность может применяться по разному и готовить ее нужно с помощью разных инструментов.
Прошу прощения за капитанство.
SP
Yauheni Akhotnikau
Тут нужно уточнить, для чего именно используется многопоточность. Если для распараллеливания каких-то тяжелых вычислительных задач, то имеет смысл смотреть в сторону инструментов вроде OpenMP, HPX, TBB, taskflow. Грубо говоря, смысл всего этого в том, чтобы за счет использования множества ядер сократить время выполнения какой-то операции. Например, на одном ядре что-то считаем или перекодируем за 60 минут. На шести ядрах за 10 минут.
Если для того, чтобы упростить себе (почти) одновременное выполнение кучи разнообразных активностей, то тут другой набор инструментов: MS PPL, CAF, SObjectizer, rotor, actor-zeta, Asio. Смысл всего этого в том, чтобы делать разнородные вещи не сильно задумываясь о том, что происходит вокруг. Например, условный сервер БД: принимает подключения, принимает данные, парсит пришедший запрос, строит план, выполняет план с учетом кэшей и пр., подготавливает результаты для отсылки, отсылает в сеть. Что-то из этого можно делать на общем контексте, что-то нужно разносить по разным.
Так что сама по себе многопоточность — это только инструмент для решения какой-то задачи. И в зависимости от задачи многопоточность может применяться по разному и готовить ее нужно с помощью разных инструментов.
Прошу прощения за капитанство.
Если для того, чтобы упростить себе (почти) одновременное выполнение кучи разнообразных активностей, то тут другой набор инструментов: MS PPL, CAF, SObjectizer, rotor, actor-zeta, Asio. Смысл всего этого в том, чтобы делать разнородные вещи не сильно задумываясь о том, что происходит вокруг. Например, условный сервер БД: принимает подключения, принимает данные, парсит пришедший запрос, строит план, выполняет план с учетом кэшей и пр., подготавливает результаты для отсылки, отсылает в сеть. Что-то из этого можно делать на общем контексте, что-то нужно разносить по разным.
Так что сама по себе многопоточность — это только инструмент для решения какой-то задачи. И в зависимости от задачи многопоточность может применяться по разному и готовить ее нужно с помощью разных инструментов.
Прошу прощения за капитанство.
какое капитанство, все по делу, спасибо
D
Yauheni Akhotnikau
Тут нужно уточнить, для чего именно используется многопоточность. Если для распараллеливания каких-то тяжелых вычислительных задач, то имеет смысл смотреть в сторону инструментов вроде OpenMP, HPX, TBB, taskflow. Грубо говоря, смысл всего этого в том, чтобы за счет использования множества ядер сократить время выполнения какой-то операции. Например, на одном ядре что-то считаем или перекодируем за 60 минут. На шести ядрах за 10 минут.
Если для того, чтобы упростить себе (почти) одновременное выполнение кучи разнообразных активностей, то тут другой набор инструментов: MS PPL, CAF, SObjectizer, rotor, actor-zeta, Asio. Смысл всего этого в том, чтобы делать разнородные вещи не сильно задумываясь о том, что происходит вокруг. Например, условный сервер БД: принимает подключения, принимает данные, парсит пришедший запрос, строит план, выполняет план с учетом кэшей и пр., подготавливает результаты для отсылки, отсылает в сеть. Что-то из этого можно делать на общем контексте, что-то нужно разносить по разным.
Так что сама по себе многопоточность — это только инструмент для решения какой-то задачи. И в зависимости от задачи многопоточность может применяться по разному и готовить ее нужно с помощью разных инструментов.
Прошу прощения за капитанство.
Если для того, чтобы упростить себе (почти) одновременное выполнение кучи разнообразных активностей, то тут другой набор инструментов: MS PPL, CAF, SObjectizer, rotor, actor-zeta, Asio. Смысл всего этого в том, чтобы делать разнородные вещи не сильно задумываясь о том, что происходит вокруг. Например, условный сервер БД: принимает подключения, принимает данные, парсит пришедший запрос, строит план, выполняет план с учетом кэшей и пр., подготавливает результаты для отсылки, отсылает в сеть. Что-то из этого можно делать на общем контексте, что-то нужно разносить по разным.
Так что сама по себе многопоточность — это только инструмент для решения какой-то задачи. И в зависимости от задачи многопоточность может применяться по разному и готовить ее нужно с помощью разных инструментов.
Прошу прощения за капитанство.
MS PPL также может использоваться для первой цели, потому что там есть алгоритмы как в TBB
YA
MS PPL также может использоваться для первой цели, потому что там есть алгоритмы как в TBB
Как и taskflow, насколько я помню, может использоваться во второй категории.
Y
Yauheni Akhotnikau
Тут нужно уточнить, для чего именно используется многопоточность. Если для распараллеливания каких-то тяжелых вычислительных задач, то имеет смысл смотреть в сторону инструментов вроде OpenMP, HPX, TBB, taskflow. Грубо говоря, смысл всего этого в том, чтобы за счет использования множества ядер сократить время выполнения какой-то операции. Например, на одном ядре что-то считаем или перекодируем за 60 минут. На шести ядрах за 10 минут.
Если для того, чтобы упростить себе (почти) одновременное выполнение кучи разнообразных активностей, то тут другой набор инструментов: MS PPL, CAF, SObjectizer, rotor, actor-zeta, Asio. Смысл всего этого в том, чтобы делать разнородные вещи не сильно задумываясь о том, что происходит вокруг. Например, условный сервер БД: принимает подключения, принимает данные, парсит пришедший запрос, строит план, выполняет план с учетом кэшей и пр., подготавливает результаты для отсылки, отсылает в сеть. Что-то из этого можно делать на общем контексте, что-то нужно разносить по разным.
Так что сама по себе многопоточность — это только инструмент для решения какой-то задачи. И в зависимости от задачи многопоточность может применяться по разному и готовить ее нужно с помощью разных инструментов.
Прошу прощения за капитанство.
Если для того, чтобы упростить себе (почти) одновременное выполнение кучи разнообразных активностей, то тут другой набор инструментов: MS PPL, CAF, SObjectizer, rotor, actor-zeta, Asio. Смысл всего этого в том, чтобы делать разнородные вещи не сильно задумываясь о том, что происходит вокруг. Например, условный сервер БД: принимает подключения, принимает данные, парсит пришедший запрос, строит план, выполняет план с учетом кэшей и пр., подготавливает результаты для отсылки, отсылает в сеть. Что-то из этого можно делать на общем контексте, что-то нужно разносить по разным.
Так что сама по себе многопоточность — это только инструмент для решения какой-то задачи. И в зависимости от задачи многопоточность может применяться по разному и готовить ее нужно с помощью разных инструментов.
Прошу прощения за капитанство.
Больше спасибо за развёрнутый ответ. Я про второй вариант имел ввиду
D
Yauheni Akhotnikau
Как и taskflow, насколько я помню, может использоваться во второй категории.
Не знаю
Это просто чуть более красивый аналог tbb::flow_graph, то бишь распараллеливание задач с зависимостями, как мне казалось
Но может быть есть апишки какие-то
Это просто чуть более красивый аналог tbb::flow_graph, то бишь распараллеливание задач с зависимостями, как мне казалось
Но может быть есть апишки какие-то
YA
Не знаю
Это просто чуть более красивый аналог tbb::flow_graph, то бишь распараллеливание задач с зависимостями, как мне казалось
Но может быть есть апишки какие-то
Это просто чуть более красивый аналог tbb::flow_graph, то бишь распараллеливание задач с зависимостями, как мне казалось
Но может быть есть апишки какие-то
В каких-то задачах цепочка действий может быть представлена как раз чем-то вроде flow_graph-а. И если поток данных от одного звена к другому идет только в одном направлении, то вполне себе flow_graph/taskflow попадет. Скажем, перекодирование каких-то данных из одного формата в другой. Каждая стадия перекодирования — отдельный узел графа.
D
Yauheni Akhotnikau
В каких-то задачах цепочка действий может быть представлена как раз чем-то вроде flow_graph-а. И если поток данных от одного звена к другому идет только в одном направлении, то вполне себе flow_graph/taskflow попадет. Скажем, перекодирование каких-то данных из одного формата в другой. Каждая стадия перекодирования — отдельный узел графа.
Ну кажется это больше задача параллелизма, а не асинхронности
D
Но если что я не шарю
YA
Тут грань тонкая :)
Для меня проверочный вопрос "нужно ли нам сокращать время за счет параллельности?"
Если это не принципиально, т.е. мы можем выстроить задачи в очередь и разгребать ее всего одним потоком, то мы в области конкурентного программирования. А разбиение на задачи используем для упрощения своей работы (удобство декомпозиции, например).
Для меня проверочный вопрос "нужно ли нам сокращать время за счет параллельности?"
Если это не принципиально, т.е. мы можем выстроить задачи в очередь и разгребать ее всего одним потоком, то мы в области конкурентного программирования. А разбиение на задачи используем для упрощения своей работы (удобство декомпозиции, например).
AV
более того, иногда сокращать время за счет параллельности НЕЛЬЗЯ, ибо это сожрет слишком много энергии например
2021 March 27
AP
Поделитесь кто как работает с многопоточностью: task queue, thread pool ... Когда boos был в проекте, то использовал boost::asio, там где chromium то неплохо помогал base::Thread и все вокруг этого. А вот в маленькие проекты не хочется все это тянут.
Y
Да спасибо. Знаком. Было интересно посмотреть что другие используют и попробовать
AV
кстати, а чем asio с бустом и без буста отличается?
AV
то есть, скорее так -- какие преимущества у асио с бустом?
DP
кстати, а чем asio с бустом и без буста отличается?
да вроде разницы особо и нет, кроме тех которые дают другие части буста
AV
а какие недостатки в юзании буста и, одновременно, асио не из буста?
DP
а какие недостатки в юзании буста и, одновременно, асио не из буста?
ну кажется что если уже есть буст то можно взять асио оттуда