Мне крайне редко (чтоб не сказать никогда) встречались системщики, которые находились бы ближе к прикладникам, нежели к схемотехникам
Ну, это по-разному бывает, а вот чего не отнять, так это того, о чем я написал выше — в эмбеде часто три с половиной землекопа, на которых все подряд. Особенно in Soviet Russia. Приходится выбирать между тем, чем нельзя не заниматься, и тем, что не необходимо. И это нормально, просто не надо ни гордиться этим, ни обличать это, ни устраивать холиваров вокруг. Часто еще в качестве ограничения бывает тулчейн такой, какой есть.
Дело в том, что у нас аж две священных коровы: скорость и надёжность
Как будто у плюсов с этим хуже, чем у pure C.
А те, ко то из нас, которые «от железа» к языкам уровня выше C относятся очень настороженно. Если хотите, то могу и причину назвать — все они так и норовят по каждому чиху использовать динамическое выделение памяти.
Я тоже «от железа», и никакой настороженности не испытываю. В том числе и в отношении new/delete, если просматривается горизонт.
Amomum вам расскажет, как избегать спорадических аллокаций, если вдруг вы их ощущаете.
общий параллелизм охота ограничить каким-то фреймворком для управления параллелизмом
Ну, это тогда надо смотреть, что за фреймворк… Если он действительно ведет себя так, как описано выше, то возможно не только в вычислении интеграла возникнет фатальная проблема.
А что с конструкторами не так? Это же как раз очень просто, понятно и удобно. Как и наследование впрочем, если оно вдруг понадобится. Возможно вы привели неудачное сравнение, но я не вижу тут объективного противопоставления битам и байтам.
Ваша логика мне в общем понятна, я ее тут сам много раз рассказывал — в эмбеде часто три с половиной землекопа, на которых все подряд, соответственно на софт остаётся не слишком много времени, чтобы обдумать красивые концепции.
Здесь я должен честно признать, что в моих задачах всегда хватало «запуска пачки std::thread руками» (образно выражаясь). Я смутно себе представляю, зачем может потребоваться делать то, о чем вы говорите.
Эм, не совсем понял, что вы имеете в виду в привязке к конкретному примеру — интегрировать в несколько потоков? Или в каждом из потоков считать свой интеграл, но по одному и тому же генерируемому функцией-генератором набору? Если второе, то thread_local с тем же самым вышеприведенным кодом вполне будет работать, почему нет?
А вы на каждый набор параметров генератора будете писать свою функцию?
Все зависит от обстоятельств. Если генератор в принципе должен быть параметризован (что не факт, и, кстати, выше это требование не предъявлялось), то это можно сделать разными способами, а можно не суметь сделать вообще.
А запускать вычисления в том же потоке ещё раз с нуля как будете?
Тут конечно не поспоришь, в приведенном выше примере придется мутить несколько более сложный генератор (и конечно в стиле "о Боже, что это").
Нет, если это обычная матрица кремниевых pin-диодов, то ловить на нее отдельные частицы — занятие наверное интересное, но бессмысленное (вот GaAs-матрица — совершенно другая песня). Поэтому речь выше и шла о том, чтобы приложить кусочек сцинтиллятора и при сколько-нибудь значительной мощности излучения наблюдать результат в интегральном режиме.
Да, наверное дело в этом.
Ну и в очередной раз мы говорим о проводимых сравнениях. :)
Насчет модификаторов интервала, я не совсем понял (и сходу не нагуглил, точнее нагуглил нечто обратно противоположное) — это что-то общее для всех контейнеров С++, или только для интервалов?
Вот, значит я правильно понял описание. И тогда единственный смысл этой операции — отбросить первый узел (который до цикла был взять через begin). При этом весь код до вызова integrate() может быть удален, насколько я понимаю (само собой потребуется альтернативный код для заполнения вектора). Но тогда непонятно, почему вдруг время так выросло по сравнению с вариантом 2.
… и это та мысль, которую я хотел высказать, но боялся )))
А если стоит задача генерировать узлы «на месте», то можно генерировать их прямо в теле функции, а можно передать указатель на функцию-генератор (привет Си), а можно корутину, или вот ranges, или вообще что угодно еще, с примерно одинаковым результатом.
А почему во всех вариантах вычисление сетки должно учитываться (по времени), а во втором — нет? Так нечестно
Потому что во всех вариантах это именно вычисление, а во втором — работа с памятью. И в зависимости от свойств системы результат получается разным. Я бы сказал так, что либо второй вариант в вашей статье лишний, либо наоборот — все остальные лишние. И, разумеется, самой идеи рассказать таким образом о ranges это никак не умаляет.
std::vector плох не только скоростью
Конкретно вектор ничем вообще не плох. Плох (или «плох») любой способ формирования набора узлов, который требует промежуточной памяти. А тут уже нет никакого выбора — либо вам без памяти не обойтись (набор получен по сети), либо нет никакого смысла хранить его в памяти (и вычисляем на каждом шаге, любым из предложенных вами способов).
Общности в таком подходе — хоть отбавляй, а что с производительностью? С потреблением памяти? Если раньше у нас всё суммировалось на процессоре, то теперь приходится сначала заполнить участок памяти, а потом читать из него. А общение с памятью — довольно медленная вещь.
Хм, ну подождите, если ставится задача «делаем универсальную функцию интегрирования трапециями, в которую снаружи передается набор узлов», то без трат памяти не обойтись. Кто-то где-то в другом месте этот набор генерирует и так или иначе записывает его в память, чтобы нам передать. Этот генератор может быть разным по устройству, не обязательно компилируемым вместе с функцией интегрирования, возможно набор узлов вообще по почте приходит.
К слову, если ваш второй пример запустить, то (количество узлов я взял поменьше, а то у меня чего-то bad alloc вылезал) результат таков: 1.3 секунды занимает заполнение вектора и 3.8 секунды собственно вычисление интеграла, отсюда и берется «худший результат из сравниваемых». Да и вообще сравнение получается немного странным:
1) Постоянный шаг, вычисление аргумента «по месту».
2) Постоянный шаг, вычисление аргумента где-то снаружи, но с учетом времени этого вычисления (!?).
3) 4) Постоянный шаг, вычисление аргумента «по месту» (если я правильно понимаю этот код, простите мое плохое знание С++ и ленивых вычислений).
5) Переменный шаг, вычисление аргумента «по месту».
То есть везде какие-то отличия по сути, что же мы сравниваем?
Но вообще спасибо за статью, узнал новое для себя!
P.S.: Я же верно понимаю, что для варианта 5 теряется совместимость с вектором?
Ну, возможно у них там специфическая ситуация, когда проблемы взаимодействия между потоками нет (но потоки нужны), либо хочется делать это все руками (и это не обязательно плохо).
Ну, это по-разному бывает, а вот чего не отнять, так это того, о чем я написал выше — в эмбеде часто три с половиной землекопа, на которых все подряд. Особенно in Soviet Russia. Приходится выбирать между тем, чем нельзя не заниматься, и тем, что не необходимо. И это нормально, просто не надо ни гордиться этим, ни обличать это, ни устраивать холиваров вокруг. Часто еще в качестве ограничения бывает тулчейн такой, какой есть.
Как будто у плюсов с этим хуже, чем у pure C.
Я тоже «от железа», и никакой настороженности не испытываю. В том числе и в отношении new/delete, если просматривается горизонт.
Amomum вам расскажет, как избегать спорадических аллокаций, если вдруг вы их ощущаете.
Ну, это тогда надо смотреть, что за фреймворк… Если он действительно ведет себя так, как описано выше, то возможно не только в вычислении интеграла возникнет фатальная проблема.
А что с конструкторами не так? Это же как раз очень просто, понятно и удобно. Как и наследование впрочем, если оно вдруг понадобится. Возможно вы привели неудачное сравнение, но я не вижу тут объективного противопоставления битам и байтам.
Ваша логика мне в общем понятна, я ее тут сам много раз рассказывал — в эмбеде часто три с половиной землекопа, на которых все подряд, соответственно на софт остаётся не слишком много времени, чтобы обдумать красивые концепции.
Полагаю, что вашему оппоненту не скобочки другие не нравятся, а другая их семантика чужда.
Искренне надеюсь, что вам все-таки мешает NDA, а не DNA. ;)
Все зависит от обстоятельств. Если генератор в принципе должен быть параметризован (что не факт, и, кстати, выше это требование не предъявлялось), то это можно сделать разными способами, а можно не суметь сделать вообще.
Тут конечно не поспоришь, в приведенном выше примере придется мутить несколько более сложный генератор (и конечно в стиле "о Боже, что это").
Ну и в очередной раз мы говорим о проводимых сравнениях. :)
Насчет модификаторов интервала, я не совсем понял (и сходу не нагуглил, точнее нагуглил нечто обратно противоположное) — это что-то общее для всех контейнеров С++, или только для интервалов?
Зачем войд-звездочка и пара функций? Вот вам без звездочек и пары функций (сказал он с хитрой улыбкой):
А если стоит задача генерировать узлы «на месте», то можно генерировать их прямо в теле функции, а можно передать указатель на функцию-генератор (привет Си), а можно корутину, или вот ranges, или вообще что угодно еще, с примерно одинаковым результатом.
Потому что во всех вариантах это именно вычисление, а во втором — работа с памятью. И в зависимости от свойств системы результат получается разным. Я бы сказал так, что либо второй вариант в вашей статье лишний, либо наоборот — все остальные лишние. И, разумеется, самой идеи рассказать таким образом о ranges это никак не умаляет.
Конкретно вектор ничем вообще не плох. Плох (или «плох») любой способ формирования набора узлов, который требует промежуточной памяти. А тут уже нет никакого выбора — либо вам без памяти не обойтись (набор получен по сети), либо нет никакого смысла хранить его в памяти (и вычисляем на каждом шаге, любым из предложенных вами способов).
Пардон, но если посмотреть на код в for()?
Хм, ну подождите, если ставится задача «делаем универсальную функцию интегрирования трапециями, в которую снаружи передается набор узлов», то без трат памяти не обойтись. Кто-то где-то в другом месте этот набор генерирует и так или иначе записывает его в память, чтобы нам передать. Этот генератор может быть разным по устройству, не обязательно компилируемым вместе с функцией интегрирования, возможно набор узлов вообще по почте приходит.
К слову, если ваш второй пример запустить, то (количество узлов я взял поменьше, а то у меня чего-то bad alloc вылезал) результат таков: 1.3 секунды занимает заполнение вектора и 3.8 секунды собственно вычисление интеграла, отсюда и берется «худший результат из сравниваемых». Да и вообще сравнение получается немного странным:
1) Постоянный шаг, вычисление аргумента «по месту».
2) Постоянный шаг, вычисление аргумента где-то снаружи, но с учетом времени этого вычисления (!?).
3) 4) Постоянный шаг, вычисление аргумента «по месту» (если я правильно понимаю этот код, простите мое плохое знание С++ и ленивых вычислений).
5) Переменный шаг, вычисление аргумента «по месту».
То есть везде какие-то отличия по сути, что же мы сравниваем?
Но вообще спасибо за статью, узнал новое для себя!
P.S.: Я же верно понимаю, что для варианта 5 теряется совместимость с вектором?
Ну, возможно у них там специфическая ситуация, когда проблемы взаимодействия между потоками нет (но потоки нужны), либо хочется делать это все руками (и это не обязательно плохо).