SYCL пока просто игрушка?

Звучит прикольно, но судя по Википедии ее только Интел пока поддерживает :)

ну и, кстати, не могу не заметить, что для OneAPI есть и OpenCL и Cuda драйверы. Вроде бы.

Не только, есть и для cuda

Хм, прикольно, значит нужно попробовать :)

между cuda  и  opencl  на nvideo  перформен ходит между 2- 10 %  по моему опыту  но  opencl  работает +/- везде  оддинаково и это жирный +

Позитива... Lock-free - это не серебряная пуля, к сожалению. Я надеюсь в следующий раз об этом подробно поговорить, выразить свое ИМХО (и потешить ЧСВ 😉

Lock-free позитивный

А wait-free?

wait free вообще скорее теоретическая гарантия

Да ладно, с чего бы это

коллеги, ни одно из чистых определений obstruction-free, lock-free и wait-free ничего не говорит о времени, только о той или иной гарантии окончания. То есть нельзя надеяться, что wait-free окажется быстрее, чем lock-free или locked. Более того, наберусь смелости  утверждать (эмпирически ), что wait-free будет дольше, чем lock-free.

ну если мы говорим о структурах данных и wf на всех методах то это крайне сложно и обычно требует много оверхеда (потоки делают сильно больше работы чем на тех же лф и локах)

Конечно будет. Потому что для соблюдения гарантированного latency операции нужно эту операцию делать хитро. И начать например с использования ОСРВ :)

ОС реального времени - это вообще отдельная песня, я с ними не работал.
Но для обычного user-space в обычной ОС очень помогло бы, например, API (кратко)временного запрета вытеснения user thread планировщиком. Такая фича была в Solaris.

Кажется очень страшная фича с точки зрения безопасности/надежности нет?
Мне скорее интересно в каких алгоритмах можно воспользоваться rseq.
Это про то чтобы перезапустить набор инструкций, если во время их исполнения произошло переключение контекста например. Из ограничений, то что нельзя писать в память.
В tcmalloc как мне кажется очень классно заюзали, сделав per process кеши.

rseq - интересная вещь, прошла мимо меня, спасибо за наводку.
(BTW, в комментах кто-то спросил то же самое, что и я - "а почему бы просто не сделать API запрета preemption потока"? Конечно, это очень опасное API при бездумном применении, но каждая фича потенциально опасна, если ее использовать не по назначению. Например, с футексами можно натворить черт-те чего)
Но тут у меня есть одно даже не возражение, а предупреждение. Использование новых kernel-specific feature хорошо, когда ваш продукт рассчитан на определенную платформу. Например, Linux kernel = 4.18.
Но когда вы пишете какую-то кросс-платформенную open-source либу, учет таких возможностей превращается в кошмар для разработчика (то есть вас).
Например, для линукса было бы здорово, чтобы ld при запуске процесса учитывал версию ядра и линковал именно ту функцию, которая рассчитана под это ядро, если таковая есть. Кстати, может такого рода фичи уже есть?.. Я знаю, что можно писать разные реализации под разную архитектуру (например, Sandy Bridge, Zen2, armv7...), а ld при загрузке выберет именно ту, на чем сейчас запускается процесс. Но учет версии ядра... такого не знаю.

Я не слышал про автоматический выбор оптимизации под архитектуру от ld. Мы это вручную делаем.

Насколько я понимаю, там основная проблема - это гранулярность этих оптимизированных кусков. Если на каждую функцию делать виртуальный вызов, будет дорого очень. Хотя, может, на уровне ld ещё какие-то способы переключения есть.