Превключване между SSE и нормалното FPU

[aSmith]

Някой ден може да ми се наложи да вкарам малко SSE в сметките с вектори и матрици и се чудех как става автоматичното превключване на SSE код и неSSE код в зависимост от процесора, на който върви приложението?

Май успявам да се сетя за няколко варианта и май единствено инжектирането на правилният код остава като достатъчно производително решение.

Как го правите или бихте го направили ако ви се наложи?

[GeLeTo]

Аз ползвам template specialization за някои методи където SSE и не-SSE кода е различен и темплейти с F32vec4(това от SSE SDK-то, а също така и негов не-SSE вариант) там където ме мързи да пиша различен код.
Втория вариант би трябвало да ти свърши работа за сметки с вектори и матрици - всеки клас да има SSE и не-SSE вариант и тези класове да влизат в template параметрите ...

Ако искаш да използваш SSE за стандартни векторни класове - според мен няма голям смисъл. За оптимално SSE трябва данните да се подреждат в SoA (Struct of Arrays), да се подравняват в паметта, да prefetch-ваш и т.н. Не че няма да помогне, ама не очаквай много.

[gemicha]

DirectX го прави това за теб. Ако ползваш математиката на различните процесори се пуска различен код.

[aSmith]

@GeLeTo: Хм ти говориш за структуриране на кода и компилиране на изпълним файл, в който има само един път за изпълнение: SSE или x87. Аз питам за начин за динамично избиране на пътя след стартиране на приложението и определяне на възможностите на процесора.

@gemicha: Това, че DirectX го прави автоматично е хубаво, но не ми помага, защото не го ползвам

Въпросът е принципен, не дали ще има ползва или не (това може да се види само с тестове).
Ако имаме следният клас:

Код: Избери целия код

class Vector
{
    float x, y, z;

    operator + (Vector const &v)
    {
          код за събирането... според процесора
    }
}


Как може да се направи кода в оператора + да е оптимален според това на какъв процесор върви (със ССЕ или без примерно)?

[pdimov]

Никак. Оптимален код може да се постигне само ако се събират стотина вектора наведнъж, най-добре хиляди. На това ниско ниво просто няма как да се вкара динамично SSE по оптимален начин. Най-доброто, за което се сещам, е

if( sse )
{
// ...
}
else
{
x += v.x; // ...
}

с надежда, че branch predictor-а на процесора (ако има такъв) ще се справи. Пак няма гаранция дали ще е по-бързо като цяло от нормалната не-SSE версия.

[Kerberos]

Аз го правя с динамични библиотеки. Просто след проверката за SSE зареждам библиотеката, която ми трябва.

[malkia]

Просто си правиш няколко exe-та в зависимост от платформата, или както Kerberos пише - динамични билбиотеки.

Навремето Intel имаха някакво решение (незнам дали още е валидно за техният компилатор) където при стартиране на приложението, то проверяваше какъв процесор е инсталиран и го набъркваше. Разбира се това беше само за Intel съвместими процесори.

MAC OS X има подобен проблем, там обаче е нужно дадено приложение да се стартира и под x86 и под PowerPC, за това имат "fat"-executable format, който всъщност са две платформи компилирани в едно .EXE.

Ако не те притеснява размера на изпълнимият файл, или бройката им то просто генерирай код за всички платформи/архитектури.

[Zemedelec]

...

+1

Особенно, ако if-а стои преди целия блок с работата.

[GeLeTo]

@GeLeTo: Хм ти говориш за структуриране на кода и компилиране на изпълним файл, в който има само един път за изпълнение: SSE или x87. Аз питам за начин за динамично избиране на пътя след стартиране на приложението и определяне на възможностите на процесора.

Пътищата са два. Просто по този начин елегантно се изнася if-a да не е във всеки метод на векторния ти клас, а някъде, където не пречи:

Код: Избери целия код

if( useSSE )
    DoComplexComputation<fvec3_sse,mat4_sse>(...);
else
    DoComplexComputation<fvec3,mat4>(...);

Това с инжектирането на правилния код или свързване на динамични библиотеки не ми се вижда разумно - няма как да стане нито inlining, нито компилатора да си направи оптимизациите.

[gemicha]

Това с проверката преди всяка операция е далеч по зле от динамичните библиотеки.

Ако много държиш можеш да имаш два изпълними модула.

[zaphod]

аз съм за вариант 2,3,4 ехета (ММХ, SSE, FPU, гледане на боб), решава се кое да се сложи със тест по време на инсталация. това с разни рънтайм проверки само ще яде перформанс.

[Zemedelec]

Това с проверката преди всяка операция е далеч по зле от динамичните библиотеки.

Ако много държиш можеш да имаш два изпълними модула.

Нали не мислиш, че някой сериозно ще предложи тази проверка пред всяко умножение на матрица?
Това се прави преди всеки солиден блок сметки. Да кажем анимация на 30-40 кокала.
На дребно цялата работа издиша, дори тази с D3DX - предпочитам да се инлайне обикновен FPU код, отколкото да call-вам събиране на вектори на SSE...

[Zemedelec]

аз съм за вариант 2,3,4 ехета (ММХ, SSE, FPU, гледане на боб), решава се кое да се сложи със тест по време на инсталация. това с разни рънтайм проверки само ще яде перформанс.

Колко според тебе яде един if пред код, който смята десетки матрици?
Колко такива if-а ще има в един кадър?
Отговори на този въпрос, а после вече ще видим кой и как яде перформанс...

[zaphod]

Колко според тебе яде един if пред код, който смята десетки матрици?
Колко такива if-а ще има в един кадър?
Отговори на този въпрос, а после вече ще видим кой и как яде перформанс...

ако е пред десетки матрици - николко.
обаче ако е във тялото на функция за събиране на вектори, ще яде много. остава да го изнесем навън, но това не ме кефи по много причини. не винаги тежките изчисления са добре пакетирани, така че да могат да се хванат със иф. освен това, писането на подобни ифове натоварва програмиста със неприятната задача да мисли за технически въпроси некасаещи пряко това върху което работи, понеже те трябва да се мушката навсякъде из кода. аз смятам че е по-добре избора между различните техники да се прави само във функциите за математически операции - умножение матрици, умножение вектори, ротации и други такива. те са на практика библиотеки които веднъж се пишат и много пъти се ползват, така програмиста няма постоянно да мисли къде да сложи иф, и ако случайно утре излезе нов набор инструкции, няма да се пренаписва всичко, а само ще се добави по още един #ifdef в не повече от 100 базови математически функции.

[YE]

Като някой ден може да ти се наложи, някой ден се опитай да решиш проблема. Засега това е от по-безсмислените неща, с които да си хабиш времето.