Вот тебе задачка: есть легко векторизуемая прога, которая тратит 80мс на обработку данных скалярно 32-битными флоатами и ещё 20мс на I/O этих данных.
Вопрос - на сколько ускорится обработка данных, если вместо 32-битных флоатов использовать 128-битный SSE или 256-битный AVX? Ну а свежий 512-битный AVX512?
Очевидно, что проц в теории может перемалывать данные в 4/8/16 раз быстрее.

И ещё одна, на количество инструкций:

1. res = A*B + C
2. res = FMADD A, B, C

Тут всё логично, у второго варианта есть FMA и всего одна инструкция. У первого варианта нет FMA и нужно 2 инструкции для той же задачи.
Первый выполняется за 5 (*) + 3 (+) тактов, второй - за 5 (FMADD) тактов.

А теперь давай вот так:

1. res = A*B + C*D
2. tmp = C*D
res = FMADD A,B, tmp

первый вариант - 3 инструкции без FMA
второй вариант - 2 инструкции с FMA
На сколько второй вариант будет быстрее?

Так давайте рассуждать о ЦПУ с точки зрения его "среды обитания" и его прямых функций в составе Персонального Компьютера, а не гипотетического калькулятора по сложению/умножению матриц. Иначе мы скатимся к тому, что уровень шахматистов будем оценивать по скорости перемещения фигур по доске.

в составе персонального компьютера одна из прямых функций ЦПУ - это считать
так что пример корректен и показывает как на простых операциях (коих масса внутри любой программы) можно уменьшить количество отрабатываемых инструкций, но для этого потребуется глубокий рефакторинг кода и отказ от legacy совместимости
в винде этого пока даже в проекте не предполагается

А это вообще не задача ОС. То что ты сейчас написал - принцип работы JIT с кэшем.
И такое есть в куче языков программирования, в трансляторах архитектур и даже в железе (Tegra K1 Denver и Transmeta Crusoe/Efficeon).

devl547 Я тщательно забыл и математику и программирование так что ответа не знаю. Мозг не воспринимает задачки.
DarkOne функции цпу в составе пк год от года меняются в доле использования. К примеру доля браузеров год от года растет так, что пора браузер делать частью системы и чтобы он работал всегда, включаясь с пк и выключаясь вместе с ним.

в таком случае почему это не делается повсеместно?

Ну так не интересно, задачки-то примитивные, там кроме сложения-умножения-деления ничего не нужно.



Потому что это неэффективно в общем случае и имеет кучу ограничений. Но аудио-видеокодеки так и делают - выбирают ветки исполнения в зависимости от проца.
И интеловский компилятор так делает автоматом.

Одна из - да! Главная - управлять периферийными устройствами. В идеале проц вообще должен только настраивать всякие боковые того_сего_ускорители и подавать на них данные... Ну и забирать итоговые данные от них.

devl547, а если еще вспомнить об обязательном сохранении промежуточных результатов, то кол-во инструкций в первом варианте еще возрастет.

Не возрастёт, результат умножения сразу идёт на вход другого исполняющего устройства.
Кто даст ответ, насколько увеличится производительность в случае перехода с 32-битной обработки на 128/256/512-битную.
И насколько выполнение 2 инструкций быстрее, чем 3х.

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

Я то-то упустил похоже, что вы под legacy имеете ввиду? Не уж-то опять про CISC х86 "костыли" речь идет? Если да, то уже как-то не смешно. Современные декодеры тратят не преобразование любых команд 1 такт и делают это параллельно с тем, как данные движутся по конвейеру (можно считать его как часть конвейера) и свой побочный результат это даст только в случае перезапуска конвейера, т.е. при промахе. А вот предсказатели в современных x86 куда лучше, чем в ARM. Но прогресс идет, может через пяток лет и сравняются.

Это не так на самом деле. Большинство действительно за 1 такт,но не все. Можно ещё за 2. А можно ещё сложные команды декодировать 3-4 такта.

Ну это я утрирую ) Для чего и делают широкие декодеры, да еще и по несколько штук на фронт, плюс OOO и HT, дабы исполнители не простаивали. А правильные компиляторы должны стараться избегать случаев, когда исполнители ожидают данные от декодеров.
П.С. что-то мы совсем в дебри уже полезли... В общем и целом что я хотел сказать то. Покамест, в реальном коде старички х86 все же прилично быстрее ARMов, но прогресс идет. А будущее похоже точно за APU. Только вот декодеры в случае с APU будут еще сложнее, еще шире и умнее, а в этом (проектировании декодеров) у разработчиков х86 рука уже набита и на этом поприще они продвигаться будут шибче. По крайней мере первое время. И то что АМД пару лет назад взялась за разработку ARM-совместимых процессоров, это очень хорошо. Для всех.

DarkOne , что-то задачки выше никто не решает(

А что их решать то? Понятное дело, что используя модули FMAС одинаковые по сути задачи будут исполняться быстрее, тем более что умножение+сложение одна из самых частых комбинаций в вычислениях. На то FMACов в современных ЦПУ все больше и они все шире. Другое дело их довольно сложно реализовать в железе, учитываю очень сложную схемотехнику (в том числе и по части увязывание их в общую архитектуру) и ограниченный бюджет транзисторов. Точнее бюджет площади на кристалле.

Результат неожиданный будет. Поэтому и выложил.

Домой приду - порешаю на досуге ) А вообще реально заставить современный ЦПУ исполнять так, как написано? Компиллятор и декодер все равно преобразуют две операции в одну FMA. Или речь о том что на одном ЦПУ FMAС есть, а на другом нет?

Размер ядра(в транзисторах) уже несколько поколений техпроцессов почти не растет.

Только если попросить принудительно. Самоволки с автовекторизацией не будет.



Да, можно хоть на ассемблере написать.



Нет, выполняется на одном процессоре с FMA (использовался Haswell, но справедливо и для остальных).