2021)
У нас в планах написать числодробилку, к примеру жёсткий обход и изменение графов или приближённое итеративное решение NP-полных задач (с функцией стоимости)
Мы хотим сделать «числодробилка as a service», в связи с этим вопрос - насколько велик overhead от корутин? Если делать co_await на каждую итерацию решения.
легче проверить на какой то конкретной задаче, вроде бы минимальные или вообще нет(в простых случаях), автор рассказывал о отрицательной стоимости)
Я не уверен, что верно понял вопрос, но оверхед от co_await полностью зависит от выполняемой в нём логики, а она пишется программистом. Насколько я понимаю, асинхронность на корутинах по производительности должна быть схожа с асинхронностью на коллбеках и определяется практически полностью тем, как реализован executor С другой же стороны, если я ошибся и асинхронность всё-таки не предполагается, а имеется ввиду написание стейт-машин на корутинах, то стоит обратить внимание на этот доклад
Спасибо вам за развёрнутые ответы! 👍
не понял, а зачем для числодробилки корутины?
А корутины вам нужны чтобы в произвольный момент времени получать приближенный, подсчитанный на данный момент результат?
Да, и также чтобы было можно вычислять несколько числодробилок одновременно
вам для этого отлично потоки подойдут
Да, вы правы. У меня просто числодробилка очень плохо распараллеливается, там условно travelling salesman problem методом отжига, поэтому можно фокусничать
но корутины тут не помогут с параллельностью никак - им то ведь придется под капотом параллелится как-то всё равно на экзекуторах
На сколько я помню, добавление честной обработки исключений (сохранение в std::exception_ptr и перебрасывание) ломало оптимизацию даже простых генераторов. Но я не измерял время, а только смотрел асм. Да и дело было уже год-два назад, может быть компиляторы поумнели с тех пор.
Обсуждают сегодня