Проблемы разработки реально быстрого ПО в наше время

Плюсик в карму поставил, я не жадный (светлое будущее должно быть у всех), но посту — только минус

распределение задач на все threat'ы будет ити поровну

threat — это угроза, а имелось в виду слово thread — поток. Разница огромная

Стиль изложения конечно у каждого свой, но стиль с ошибками на каждом шагу выглядит ужасно, читать в следующий раз такое лично мне уже не захочется

Спасибо за внимание, больше постараюсь не брюзжать :)

ну во-первых не threat, а thread.
во-вторых, использование или не использование потоков это очень контексто-зависимый параметр. Где-то можно и обойтись, а где-то нет. Опять же там где можно обойтись не всегда стоит обходиться. Вообщем вопрос ни о чем, ибо слишком абстрактен

На самом деле в некоторых ситуациях 16 потоков на 4х процессорах могут выполнить задачу быстрее, чем 4 потока на 4х процессорах. Если эта задача в каких-то местах не нагружает собственно сам процессор, а использует различные DMA или обращения к другим устройствам напрямую.
Попытка написать компилятор для решения этой задачи это попытка создать универсальное решение, которое не существует. Разве что вы сможете найти хороший генетический алгоритм. Но наиболее близким решением я здесь вижу создание компилятора, который будет строить различные гипотезы (переводить отдельные части исходного текста в различные машинные последовательности) и затем проверять их (запускать данные машинные последовательности, находя наиболее оптимальные по заданному числу параметров). В таком виде компилятор может давать существенно более эффективный код при правильном подходе. Но компилировать он будет очень долго))).

Вы о производительности всех алгоритмов так судите обычно — на выпуклый военно-морской глаз и записи в блокноте, или все же иногда пользуетесь профилировщиками и другими тулами, типа Intel Parallel Studio?

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

Не знаю, проработав с многопоточкой год, а уже на автомате проставляю блокировки и вижу эффективные стратегии использования ресурсов с минимальным количеством блокировок. Насколько они эффектвные — не знаю, но вроде никто не жалуется.

Потоки то нужны не только для распараллеливания одной задачи, но и для параллельного выполнения разных.

Разработчики Nvidia говорят на английском языке, поэтому «сменой режимов ядра CUDA» они это назвать не могли. По вашему же переводу совершенно не понятно что имеется в виду. Смена ядер CUDA? Инициализация CUDA? Переключение графического контекста между процессами?

По крайней мере на счет смены ядер, мой опыт показывает, что он занимает порядка 10 миллионых долей секунды, что по-моему весьма не плохо.

Эмс, дата-параллельное железо подходит только для одноимённых задач. Я больше по ATI карточкам — но в что нужно некоторые функции выполнять на проце верится слабо. Разве что если очень маленькие массивы с параметрами — тогда это имеет смысл. И поверьте от этого только плюс производительности системы. «Оптимальное количество потоков» на этапе компиляции — бред, про ThreadPool слышали? Он позволяет абстрагироваться от количества ядер и использует всегда столько потоков сколько ядер в системе. Узнать количество ядер в системе пользователя на этапе компиляции — невозможно ))) Почитайте в нете про латентный параллелизм.
«Оооо может лучше я объявлю несколько потоков для обработки этого цикла, а может быть он исполниться когда-то на 64 ядерной машине» — потоки должны создаваться динамически и только. Исключение — программирование приставок, спец. контроллеров.

«Люди забыли что у шейдерного конвейера ограниченная точность и набор комманд.
Вот ему и приходится иногда сбрасывать часть кода на выполнение в процессор.»

у любого конвейера ограниченная длина, набор команд у декодера и он ограничен у любого устройства иначе это был бы философский камень, а не процессор.