Есть регистр xmm0 с 4 значениями одинарной точности. Варианты получения суммы этих четырех значений в младшем элементе регистра:

1. CCE-вариант, совместимый с самыми старыми процами (естественно, с подддерживающими ССЕ):
movhlps    xmm1,xmm0
addps    xmm0,xmm1
movaps    xmm1,xmm0
shufps    xmm1,xmm1,55h
addps    xmm0,xmm1

2. SSE3-вариант:
haddps    xmm0,xmm0
haddps    xmm0,xmm0

Вопросы, собственно, по этим вариантам:
A) Насколько второй вариант шустрее первого? У меня в имеющейся интеловской документации растактовки команд нет, может, кто-нибудь знает или помнит растактовку команд?
Б) Нельзя ли первый вариант сделать пошустрее? Хочется всё-таки иметь возможность совместимости со старыми процами.
Если кто поможет - буду благодарен вплоть до плюсика в репутацию

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

как вариант
movhlps xmm1,xmm0
addps xmm0,xmm1
shufps xmm1,xmm0,1
addss xmm0,xmm1
производительность замерять нужно



Это сообщение отредактировал(а) airyashov - 7.12.2009, 16:32

airyashov, ОК, подумаю над предложенным.

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

В общем, думал, что тут есть кто-нить, занимавшийся анализом или переделкой мат.библиотек типа интеловской МКЛ - вот он бы мне и подсказал, как подобное сделано интелом (или может быть улучшено), т.к. код такой нужен для скалярного произведения векторов, матрично-векторного, матрично-матричного произведений, фильтрации с окном, етц. А самому декомпилировать МКЛ (ибо она по крайней мере в триальной версии идет в виде либ-файлов, без исходников) времени нет :(

Допустим имеется многоядерный современный процессор.

1 оптимизация.

Разработчики каждое ядро снабдили несколькими наборами инструментов для выполнения арифметических операций.
Таким образом АЛУ каждого ядра может выполнять параллельно несколько групп операций, при условии если рузультат выполнения каждой из этих групп не зависит от результатов выполнения других групп.
Например. Имеем код

На современном процессоре все эти инструкции выполнятся параллельно, если не задано никаких специальных настроек работы процессора.
По моему эксперименту современный Intel-процессор может выполнить не менее 5 SSE инструкций с 2-мерными векторами double параллельно, если соблюдаются вышеприведенное условие.
Итого параллельно 10 умножений вещественных чисел !
Можно совмещать обычные инструкции операций с вещественными числами с SSE-инструкциями. Я проводил и такие тесты. Как показали результаты, для тех и других инструкций процессор использует один и тот же набор инструментов АЛУ. То есть, допустим, чем процессор встречает в участке кода больше обычных инструкций умножения, тем меньше инструкций умножения SSE параллельно с ними он сможет выполнить, и наоборот.

2 оптимизация.

Если задача требующая большого количества вычислительных операций может быть разделена таким образом на части, что каждая из частей может быть решена независимо от решения остальных частей, то целесообразно выполнять каждую часть задачи в отдельном потоке. Операционная система оптимальным образом задействует несколько ядер процессора для выполнения нескольких потоков. Каждое ядро может выполнять собственный поток инструкций параллельно с другими ядрами. Каждое ядро может переключаться с выполнения одного потока на выполнение другого. Для этого существуют сегменты состояния задачи, в каждый из которых логический процессор сохраняет свое состояние (значения регистров) перед переключением задачи. Но на переключение задачи необходимо также некоторое количество тактов для сохранения значений регистров.
Допустим, что процессор многоядерный. Если при этом компьютер выполняет только один поток инструкций, то ядра для выполнения этого потока могут быть задействованы только псевдопараллельно. Ведь каждый поток может выполняться между переключениями задач только одним ядром. При этом будут простои в работе всего процессора. Для того, чтобы все ядра нагревались одинаково, ОС переключает ядра поочереди.
Программист должен подумать над делением задачи на части для выполнения каждой части в отдельном потоке. Наилучшим вариантом будет динамическое определение количества логических процессоров, и создание такого же количества потоков.
Программа должна уметь определять количество логических процессоров и создавать такое же количество потоков для себя.

При этом возникает проблема разрешения конфликтов потоков.
К примеру инструкция
or [eax], edx
обновляет значение ячейки памяти. Но так как эта ячейка используется несколькими потоками, то может возникнуть конфликтная ситуация.
Допустим, что эта инструкция выполняется двумя ядрами параллельно. Мы желаем получить результат в ячейке памяти, который эквивалентен результату выполнения двух инструкций or подряд. Регистр edx первого ядра содержит значение, отличающееся от значения регистра edx второго ядра. Если нет ограничений на выполнение данной нструкции, то результат может быть неверным. Здесь события могут происходить так. Вначале оба ядра загрузят параллельно в одних и тех же тактах предыдущее значение ячейки памяти [eax] во внутренние структуры собственных АЛУ. Затем каждое АЛУ выполнит собственно операцию or. Но ни один из двух рузультатов (от каждого ядра по результату) не будет равен рузультату выполнения двух операций or подряд. Затем начинается запись рузультата в память. Неважно какое ядро первым запишет свой результат, он в общем случае быдет неверен.
Решением является применение префикса блокировки системной шины. Префикс lock.
lock or [eax], edx
При этом одну и ту же инструкцию с префиксом lock все ядра будут выполнять друг за другом, и результат будет правильным.
Альтернативой является применение API-функции EnterCriticalSection (WINDOWS). Но в таком случае выполняется целая функция, а это во много раз медленнее чем выполнение префикса lock.


Это сообщение отредактировал(а) sgi1981 - 1.12.2009, 23:53

airyashov, работает неправильно 

sgi1981, и к чему этот оффтопик с оверквотингом?

да все равно получается 5 команд

Это сообщение отредактировал(а) airyashov - 7.12.2009, 16:33

To VictorTsaregorodtsev.
Вы понимаете назначение команд примененных airyashov ?

А почему ?

потому что вылезает всегда инструкция для перестановки, если можите предложить код из 4-х команд SSE хотелось бы увидеть