Да, уж давно. Уже и следующую сделал(но там другие задачи).
Методика "докинь еще нод(тредов)" оказалась вполне себе рабочей. Там без этого вряд ли бы удалось обойтись.
Сейчас время тех. долга. Рефакторинг старых проектов, тесты в новых, поиск багов, эксприменты для возможных новых фич, улучшение точности в других экспериментах и всякие мелкие дела. Ибо сейчас подготовка к релизу у всех, а я имею крайне косвенное отношение к релизу.

Йеее, докидывание нод!

Это хорошо

(вообще всего два треда в дополнение к мейну, так что не так много)

Блять, эти оптимизации компмлятора нужны максимум  на олимпиадах и в 1-2 задачах

Вот  почему  ты не знаешь законы республики конго?

Какие

Volatile

К сожалению, это не оптимизация, а наоборот - деоптимизация, и это нужно для многопоточных программ, или программ которые работают в разных режимах.
Тем не менее, суть того о чем я говорю такая:
Я задал вопрос, в одной из групп, о том прав я или нет, а вопрос был связан с барьерами памяти и С++.
В тред ворвался Зелененький Кузнечик - Крис, и сказал, что все просто и легко, я не прав и сказал - вот, volatile тебе в помощь(хотя volatile, ну никак в С++ не связан с атомарностью и синхронизацией данных в потоках), и далее на все мои аргументы что он не прав более чем и как выскочка лезет куда не нужно, он продолжал веровать в свои слова, пока, наконец другие участники не пояснили ему, что он Днина. Конечно, Крис не лыком шит, и в ответ парировал - блин, чуваки, я случайно, в Java у этого volatile, другое значение.... То есть, даже очко зажало неправоту свою признать. Зелень, что тут сказать! В общем, shit merged!

Я пробовал как-то убрать volatile в одном коде. Он после этого переставал работать.

1-2 задачи? Ну, давай, на той же ардуинке (это как самый банальный и распространённый пример) без volatile переменную в прерывании обнови

1-2 задачи (в данном контексте)  == говорит, что таких задач мало

На сппреф есть краткий абзац о теме нашего обсуждения

Within a thread of execution, accesses (reads and writes) through volatile glvalues cannot be reordered past observable side-effects (including other volatile accesses) that are sequenced-before or sequenced-after within the same thread, but this order is not guaranteed to be observed by another thread, since volatile access does not establish inter-thread synchronization.

In addition, volatile accesses are not atomic (concurrent read and write is a data race) and do not order memory (non-volatile memory accesses may be freely reordered around the volatile access).

One notable exception is Visual Studio, where, with default settings, every volatile write has release semantics and every volatile read has acquire semantics (Microsoft Docs), and thus volatiles may be used for inter-thread synchronization. Standard volatile semantics are not applicable to multithreaded programming, although they are sufficient for e.g. communication with a std::signal handler that runs in the same thread when applied to sig_atomic_t variables.

are sequenced-before or sequenced-after within the same thread, but this order is not guaranteed to be observed by another thread, since volatile access does not establish inter-thread synchronization.
Вот это довольно важное отличие от той же джавы, где подобные гарантии существуют для многопотока.

И задачи в которых нужны подобные гарантии возникают довольно часто

ты в бауманке учишься?

Что?

а, нвм

Что?