SSE2 vs FPU

6.5.2009 00:40 | Přečteno: 1927× | Jiné

Překopávám semestrálku z minulého semestru z javy do C++ (to už jsem asi někdy psal), ten kreslič funkcí. A jelikož je to vyhodnocování pomalost sama, tak bych z toho stromu chtěl vytvořit strojový kód. Teď stojím před problémem, jestli do toho "šoupnout" SSE2.

Schválně jsem napsal funkci na sečtení 2 double a se SSE2 jsem dostal 1 instrukci (addsd xmm0, xmm1) oproti kýblu FPU instrukcí bez SSE2. Zase na druhou stranu s FPU mám možnost rovnou počítat sinus, cosinus a spol., v SSE2 nic takového není a musel bych to asi růčo napsat (na netu jsem nic nenašel) a to zas tak rychlé asi nebude. A nevím, jestli kombinovat SSE2 s FPU je dobrý nápad ... četl jsem např. něco o přepínání módu při práci s MMX a FPU zároveň, snad tím netrpí SSE2 ...

       

Komentáře

[linuxnew]

muzete trochu rozvect "Schválně jsem napsal funkci na sečtení 2 double a se SSE2"? jak jste toto provedl? To jako jste v to napsal v C a nechal prelozit via gcc s nejakou optimalizaci a nasledne to disasembloval?

Jen ciste lehka zvedavost... diky.

[Jardík]

Jj, napsal jsem

double add(double a, double b)
{
  return a+b;
}

přeložil a disassembleroval. SSE2 defaultně zapnuté na x86_64. Pak to samé s FPU (tj. gcc dostalo -mno-sse2) a byl z toho bastl. SSE2 kód měl 4B, FPU 27B, což je docela rozdíl a hlavně počet těch instrukcí byl v případě FPU nejmíň 7 i s -O3.

[Jary]

o parametru, tuším, -S v gcc jsi slyšel? Vychrlí to kód jdoucí do assembleru (část překladače) a umí to i dělat komentáře pomocí dalšího parametru, který bych ale musel hledat v man gcc

[Grunt]

Přesně tak. -E zastaví gcc po zpracování preprocesorem - výsledek je přežvýkaný zdroják vhodný ke kompilaci, -S zastaví gcc po projetí kompilátorem - výsledek je assemblerový kód, -c zastaví gcc po projetí assemblerem - výsledek je objektový soubor vhodný ke slinkování. Jinak se to celé dá udělat ručně pomocí programů cpp, cc, as, ld. A nic není třeba hledat v manuálu, protože celý proces je docela dobře popsán třeba v A Practical Guide to Linux(Samozřejmě se spoustou dalších užitečných věcí).

[deda.jabko]

co pouzivas za prekladac? me to gcc 4.2.3 preklada korektne vzdycky na dve instrukce FPU.

[Grunt]

Já používám při kompilaci -mfpmath=sse,387 už nějakou dobu a zatím jsem se s problémy nesetkal. A trochu je to znát.

[Deleted [8409]]

V SSE nejsou přímo funkce pro počítání sin() a cos() a podobných funkcí, ale na netu je možné ty implementace sehnat. Ideální je, když se počítá třeba 4xsin(), vycházelo to aso ~20 cyklů na jeden, což je slušné.

Zkus tady, zdroják je přímo zde

[linuxnew]

Mno tak tohle je mazec ... tohle bych se chtel naucit, je k tomu nejaky tutorial jak pouzivat z C takhle primo instrukce v ASM? kdysy jsem si hral s asm51 v atmelu, ale tohle je uplne jina liga. Prekvapuje me kolik je tam tech _ prakticky u kazde instrukce.

Gcc uz takhle prelozeny zdrojak dale neoptimalizuje?

[Deleted [8409]]

Ty _ to jsou compiler intrinsics, prakticky takový assembler v C++. GCC už takový kód moc neoptimalizuje, protože už moc není jak (intrinsics se překládají jako instrukce).

[Deleted [8409]]

Jo, jinak o něco podobného jsem se nedávno pokoušel pomocí AsmJit a výsledek je MathPresso. Je to nedokončené a parser obsahuje chyby (není problém udělat segfault), ale momentálně není čas na to to doladit.

[Mandarinka]

MMX a x87 (a 3dnow) sdílejí registry, ale SSE má svoje vlastní, čehož by se mělo dát zneužít :)

Jinak SSE kód, byť by měl víc instrukcí nejspíš bude rychlejší. On ten sinus (a jiné komplexní operace) přes x87 se bude určitě počítat hodně cyklů.

[Miloslav Ponkrác]

Nepleťte si pojmy s dojmy – FPU je z větší části řešena hardwarově. Vypočítání sinu FPU zvládne obvykle během několika taktů. Jen pro představu:

výpočet sinu na FPU trvá zhruba stejně jako trvá stejně tak dlouho jako provedení dvou instrukcí push register

prakticky za plus mínus stejnou dobu, jako je výpočet sínu může pomocí instrukce fsincos získat naráz sínus i kosínus hodnoty naráz, což je v mnoha případech velmi užitečné

výpočet odmocniny zvládne FPU během jednoho taktu procesoru

výpočet arcus tangens s FPU je stejně rychlý, jako je provedené jedné instrukce push register

Nepodléhejte mylnému dojmu, že FPU je pomalá. FPU není program!!! FPU je hardwarově zadrátovaná výpočetní centrála, která téměř vše potřebné má zadrátováno jako elektronický obvod (tedy počítá neskutečně rychle, což si programátoři ani nedokáží představit), a jen v některých případech si maličko vypomáhá více více cykly, ale zase nad výkonnými a speciálně navrženými výpočetními FPU jednotkami. Výpočty i složitých matematických funkcí i s vysokou přesností jsou nad FPU pekelně rychlé.

Pokud provedete sinus za 20 cyklů, jak psal kdosi výše, nebudete moci rychlosti FPU vůbec konkurovat, protože FPU to dokáže několikrát rychleji. A znovu je nutno dodat, FPU zvládá výpočet matematické funkce za danou dobu nejenom pro základní úhly, ale ona v tom čase také stihne otestovat hodnoty na speciální případy (nekonečno, NaN, shodu s definičním oborem funkce, je-li to potřeba a další) plus normalizovat hodnotu do intervalu potřebného pro výpočet. Zatímco algoritmy, které naleznete na internetu pro SSE jsou zhýčkané cimprlich, které umí počítat jenom čísla mimo speciální případy a předpokládají, že normalizaci si uděláte navrvh k tomu.

Hardwarově zadrátované věci nejsou pomalé. Ba právě naopak. Nepodceňoval bych rychlost.

 

[Deleted [8409]]

According to the Intel manuals, fsin takes 160 to 200 clock cycles, fcos takes 180-280, fpatan takes 150-300, and fsqrt roughly 40. The exact number depends on the range of the input, and the processor model. AMD processors are almost twice as fast for the trigonometric functions.

[Miloslav Ponkrác]

Kecy z DevMasteru, navíc vágně a mlhavě specifikované – jsou k ničemu.

[Deleted [8409]]

Profesionál jako vy nemá určitě problém sehnat si tabulky. Toto co jste napsal, jste si vymyslel, a nemáte to ničím podložené. Sinus za jednu push operaci, LOOOOL

[Miloslav Ponkrác]

Ano, a profesionál také pozná rozdíl mezi mikrooperacemi procesoru a takty procesoru.

Ale nechť, zkopírovat sem kus tvrzení kdekoli z internetu, třeba když uklízečka na DevMasteru měla čas a rozhodla si, že si zahraje na odborníka, to dokáže kdekdo.

[Deleted [8409]]

Intel 64 and IA-32 Architectures Optimization Reference Manual - Appendix C Instruction Latency and Throughput

Rozdíl mezi mikrooperacemi by jste si měl asi zopakovat vy, protože vaše tvrzení, že výpočet sinu trvá asi jako push je naprostý výmysl, kdybych použil vaši terminologii tak tady lžete. Mimochodem fcos 180-280, fpatan 220-300, takže uklizečka z devmasteru je na tom mnohem líp než vy...

[Grunt]

Nechci vám kecat do zajisté pěkně rozjetého flejmu, ale ono se to dá docela snadno ověřit(a to jak počet vygenerovaných instrukcí, tak doba jejich běhu).

[Deleted [8409]]

Já nechci flekmovat, jen mi vadí, když někdo dezinformuje. Kdyby byl pan ponkrát chlap, tak přizná, že tentokrát hodně přestřelil.

[TM]

Mr. Ponkrác a sebereflexe? Přiznání vlastních chybných či pochybných tvrzení? To je ta nejortodoxnější fantasy. Člověče, vy se v podobných diskusích asi moc dlouho nepohybujete...
To se spíše dočkáte výrazů typu: "blbej jako punštok" a jiných hodnotných perel.

Pamatujte na 3 základní zákony po vzoru Isaaca Asimova:
1/ Ponkrác má vždy pravdu
2/ Ponkrác má vždy právdu
3/ Pokud nemá Ponkrác pravdu, platí zákon číslo 1 a zákon číslo 2

[Deleted [8409]]

Ale teď se chytl

[Grunt]

Nechci nikoho soudit, ale IHMO je mnohem směrodatnější nějaký benchmark(stačil by i prostý cyklus, pár pseudonáhodně vygenerovaných hodnot a příkaz time - sám už jsem si to zkusil) než nějaké citace bůh ví odkuď. Pan nech Mr. Ponkrác zpochybňuje jak chce.

[trekker.dk]

Intel 64 and IA-32 Architectures Optimization Reference Manual mi nepřijde jako "jen tak odněkud"

[Grunt]

Aha, to jsem jaksi v záchvatu přehlédl. Ale i tak se to p. Ponkrác pokusil zpochybnit.

[Deleted [8409]]

Já bych vám ale nechtěl přihodit záchvat, chodím se sem spíš odreagovat

[Grunt]

Jsem měl na mysli spíše záchvat zlosti od blbosti než ten opravdový záchvat.

[Deleted [8409]]

Tady máte kompletní materiál: Instruction Tables

Pokud chcete dělat benchmark, tak se vykašlete na nějaké pseudonáhodné čísla, protože jejich výpočet může ve výsledku ten benchmark naprosto zdiskreditovat. Něco jako toto by bylo nejvhodnější a data pro funkci by byly generované pomocí jednoduchého cyklu:

double inline f0(double a) { return a + a; } // nejrychlejší
double inline f1(double a) { return 1 / a; } // pomalejší
double inline f2(double a) { return sin(a); } // killer

Pokud se vám chce, klidně to udělejte, ale já mám zajímavější věci na práci

[Grunt]

Pokud chcete dělat benchmark, tak se vykašlete na nějaké pseudonáhodné čísla, protože jejich výpočet může ve výsledku ten benchmark naprosto zdiskreditovat.

Nebo něco podobného co by mohlo vyřadit optimalizace, keše a nějaké pomocné algoritmy či techniky.

Pokud se vám chce, klidně to udělejte, ale já mám zajímavější věci na práci

Heh, to já zrovna také. Sám pro sebe jsem si jednoduchý test udělal. Jen jsem chtěl říct, že pro příště než se na 50 příspěvcích hádat s p. Ponrkrácem o podstatě h*vna a přebíjet se odkazy a citacemi je lepší umlčet ho reprodukovatelnými čísly, protože vnášení stínu pochybnosti pro nezainteresované(jako jsem já) mu jde moc dobře(skoro po čase nabývám dojmu, že se tím živí).

 

A ještě by mě zajímalo o jakém instrukčním smetí u FPU to ten Jardík brblal:

$ diff test2_sse.S test2_387.S
8c8
<       subl    $24, %esp
---
>       subl    $16, %esp
17,20c17,18
<       movsd   -8(%ebp), %xmm0
<       addsd   -16(%ebp), %xmm0
<       movsd   %xmm0, -24(%ebp)
<       fldl    -24(%ebp)
---
>       fldl    -8(%ebp)
>       faddl   -16(%ebp)
34,37c32,35
<       movsd   .LC1, %xmm0
<       movsd   %xmm0, 8(%esp)
<       movsd   .LC2, %xmm0
<       movsd   %xmm0, (%esp)
---
>       fldl    .LC1
>       fstpl   8(%esp)
>       fldl    .LC2
>       fstpl   (%esp)

 

[Jardík]

Mně vyplivne gcc toto

double add(double a, double b)
{
  return a+b;
}

# gcc -mno-sse2

000000000040069c <add>:
  40069c:	55                   	push   %rbp
  40069d:	48 89 e5             	mov    %rsp,%rbp
  4006a0:	0f 13 45 f8          	movlps %xmm0,-0x8(%rbp)
  4006a4:	0f 13 4d f0          	movlps %xmm1,-0x10(%rbp)
  4006a8:	dd 45 f8             	fldl   -0x8(%rbp)
  4006ab:	dc 45 f0             	faddl  -0x10(%rbp)
  4006ae:	dd 5d e8             	fstpl  -0x18(%rbp)
  4006b1:	0f 12 45 e8          	movlps -0x18(%rbp),%xmm0
  4006b5:	c9                   	leaveq 
  4006b6:	c3                   	retq

# gcc -mno-sse2 -O3

0000000000400670 <add>:
  400670:	0f 13 44 24 f8       	movlps %xmm0,-0x8(%rsp)
  400675:	dd 44 24 f8          	fldl   -0x8(%rsp)
  400679:	0f 13 4c 24 f8       	movlps %xmm1,-0x8(%rsp)
  40067e:	dd 44 24 f8          	fldl   -0x8(%rsp)
  400682:	de c1                	faddp  %st,%st(1)
  400684:	dd 5c 24 f8          	fstpl  -0x8(%rsp)
  400688:	0f 12 44 24 f8       	movlps -0x8(%rsp),%xmm0
  40068d:	c3                   	retq

# gcc -msse2

000000000040069c <add>:
  40069c:	55                   	push   %rbp
  40069d:	48 89 e5             	mov    %rsp,%rbp
  4006a0:	f2 0f 11 45 f8       	movsd  %xmm0,-0x8(%rbp)
  4006a5:	f2 0f 11 4d f0       	movsd  %xmm1,-0x10(%rbp)
  4006aa:	f2 0f 10 45 f8       	movsd  -0x8(%rbp),%xmm0
  4006af:	f2 0f 58 45 f0       	addsd  -0x10(%rbp),%xmm0
  4006b4:	c9                   	leaveq 
  4006b5:	c3                   	retq

# gcc -msse2 -03

0000000000400670 <add>:
  400670:	f2 0f 58 c1          	addsd  %xmm1,%xmm0
  400674:	c3                   	retq

[Deleted [8409]]

Příčina je v tom, že ty 2 argumenty funkce jsou předány v SSE2 (xmm) registrech a aby se provedla FPU operace, je nutné je nejdřív uložit do paměti a z paměti natáhnout do FPU registru, to jsou 4 instrukce, výsledek je nutný stejným způsobem uložit do xmm registru opět přes paměť. V 64 bitech se nevýplácí používat FPU na tak krátké funkce (v tomto případě to je těch 6 instrukcí).

Musím dokonce říct, že to ani není chyba GCC, pro 64 bitů (ať už Win64 nebo ADM64 konvenci) žádný překladač nemůže v tomto případě udělat lepší kód pro FPU (na 32 bitu by ten rozdíl mezi FPU a SSE2 byl menší minimálně o 3 instrukce)

[Grunt]

na 32 bitu by ten rozdíl mezi FPU a SSE2 byl menší minimálně o 3 instrukce

Přesně tak:

add:
        pushl   %ebp
        movl    %esp, %ebp
        fldl    16(%ebp)
        faddl   8(%ebp)
        popl    %ebp
        ret

[Grunt]

# gcc -mno-sse2

000000000040069c <add>:
  40069c:	55                   	push   %rbp
  40069d:	48 89 e5             	mov    %rsp,%rbp
  4006a0:	0f 13 45 f8          	movlps %xmm0,-0x8(%rbp)
  4006a4:	0f 13 4d f0          	movlps %xmm1,-0x10(%rbp)
  4006a8:	dd 45 f8             	fldl   -0x8(%rbp)
  4006ab:	dc 45 f0             	faddl  -0x10(%rbp)
  4006ae:	dd 5d e8             	fstpl  -0x18(%rbp)
  4006b1:	0f 12 45 e8          	movlps -0x18(%rbp),%xmm0
  4006b5:	c9                   	leaveq 
  4006b6:	c3                   	retq

Ještě musíš -mno-sse a úplně nejlépe -mfpmath=387.

A neodpustím si rýpnutí: pod rootem se ani nepracuje ani nekompiluje.

[mimi.vx]

a z doby kamenne

[Mandarinka]

Na to, že odmocnina bude trvat o hodně dýl, bych vsadili vlastní barák, kdybych nějakej měl :P

[M. Lox]

Altivec, jedině Altivec. SSE je ******.

[Daniel Kvasnička ml.]

Souhlas! Vcera jsem nasel na netu AltiVec accelerated LAME binary for Mac OS X a nestacil jsem se divit. Muj staricky dedecek PowerMac s jednou 733MHz G4 byl v enkodovani WAVu do 128kbps CBR MP3 jen 3,5x pomalejsi nez MacBook late 2007 (Core 2 Duo 2,2 GHz -- overil jsem si, ze pouziva pro vypocet obe jadra, nesrovnatelne rychlejsi pameti i disk oproti PM ze zacatku stoleti...). Zkousel jsem 3 ruzne binarky LAME pro Intel OS X (vcetne te AltiVecove, je to UB) a vysledek byl u vsech stejny, u binarky z MacPorts dokonce pro MacBook jeste horsi.

Samozrejme, v realu to je rozdil zcela jednoznacny a znatelny. Ale moje otazka zni: nemel by ten MacBook predvest trosku lepsi divadlo, vzhledem k tomu, ze je mezi temi stroji z hlediska historie vyvoje HW propastny rozdil...?

[Mandarinka]

Ehm... borci, co přepsali většinu důležitých částí x264 do assembléru s vámi zásadně nesouhlasí. No zkuste si srovnat rychlost na PPC a x86 (lol).

 

[M. Lox]

A přepsali to i do PPC assembleru, nebo jenom pro x86? Jestli je to porovnání ručně optimalizovaného x86 programu s přeloženým PowerPC, tak je výsledek jasný. A i kdyby ne, tak většina assembleristů se daleko lépe vyzná v x86 než v jiných architekturách.

[M. Lox]

PS: Kde se ty knihovny dají sehnat? Nebo je to placené?

[Mandarinka]

Je tam jeden přispěvatel, který pravidelně přidává optimalizace pro altivec. Kvalitou optimalizace ale PPC verze zaostává, na core 2 procesorech (u k10 by to mělo být podobné) jsou SSE funkce velmi rychlé. Podrobnosti djou naprosto mimo mě, ale je fakt že x264 je co se týče x86 optimalizovaná prakticky definitivně, tuším uváděli, že víc jak 5% už asi neuvidí, snad jen kdyby používali cache profiling.

Ono také druhá věc je, že desktopové PPC čipy pocházejí tak maximálně z roku 2003 (Apple), což byla doba SSE2, P4 a A64, kterýchž rychlost v SSE z dnešního pohledu není nic moc. Dnes je tu SSSE3, SSE4, core 2 a Nehalem. Výkon SSE kódu se znásobil, mnoho instrukcí přibylo (zejména SSSE3, které iirc v x264 hrají velkou roli) ...

[M. Lox]

Ono také druhá věc je, že desktopové PPC čipy pocházejí tak maximálně z roku 2003 (Apple), což byla doba SSE2, P4 a A64, kterýchž rychlost v SSE z dnešního pohledu není nic moc. Dnes je tu SSSE3, SSE4, core 2 a Nehalem. Výkon SSE kódu se znásobil, mnoho instrukcí přibylo (zejména SSSE3, které iirc v x264 hrají velkou roli) ...

Taky proto je zajímavé, že i dnešním procesorům, o tolik let novějším, nakopává pozadí šunka z roku, kdy ještě uhlí rostlo na stromech.

[curious]

Možná tuhle myšlenku sestřelí někdo s lepší znalostí konkrétního HW, ale procesor není na této trase jediným prvkem. Velmi záleží i na rychlosti pamětí a HDD a je tedy klidně možné, že je v tom dotyčné C2D tak trochu nevinně a že ho brzdí paměti, ev. diskový subsystém.

[M. Lox]

Dobře, úprava: … že i dnešním procesorům s moderními paměťmi a rychlejšími disky nakopává pozadí sestava z roku …

[Mandarinka]

jestli to někde zaniklo: nenakopává, právěže, naopak je velice přehledně nakopáváno.

[Daniel Kvasnička ml.]

Ale porad jsme od tebe jeste nevideli vysledky tech testu a nemame informace o tom, jak dobre je to pro ten AltiVec optimalizovano. Jak sam vidis nize, LAME optimalizovany pro AltiVec se dokaze na stare jednojadrove G4 bezici pod 1GHz dostat na trikrat mensi vykon oproti 2.2GHz dvoujadru od Intelu, coz neni dostatecny rozdil (s tim, ze oficialni LAME uz ma intel-specific optimalizace pro SSE/MMX). Brzu budu mit doma 1.25GHz G4, tak to na ni zkusim taky. A nepochybuju o tom, ze kombinace dvou 2GHz PowerPC 7448 by se s klidem dostala na uroven toho Core Dua, ne-li pres ni... (a to je 7448 nekolik let stary cip a spotrebu ma <15W @ >1.5 GHz)

[Daniel Kvasnička ml.]

Jeste jedna zajimavost: 2GHz P4 vs 350MHz G4 v SETI http://blog.i-logout.cz/612545-downgrade.php

[Daniel Kvasnička ml.]

A to je taky duvod, proc Apple ukoncuje podporu PowerPC v 10.6. S dostupnyma upgrade kartama (PowerPC 7448 az do 2 GHz SP nebo 1.8 GHz dual) by znacny mnozstvi lidi jinak mohlo svoje PowerMacy a PowerBooky jeste hezky dlouho pouzivat a Intel Macy by se neprodavaly tak dobre

Nemluve o tom, ze i bez upgradu je dneska 12" PowerBook v slusnem stavu a dobrou baterkou mnohem lepsi netbook nez nejaky EEE (a v podstate za stejnou cenu)... taky tyhle veci mizi z bazaru pekne rychle.

Kazdopadne, Apple s PPC neskoncil. Ma dost slusny PPC kapital (sef Xboxu, PA Semi s jejich 64bit PowerPC dvoujadrem, co na 2 GHz zere jen 15W) a spekuluje se o herni konzoli, ktera by x86 urcite neobsahovala Navic uz je temer jiste, ze Apple pripravuje neco jako "MacBook trouch" a ten jestli nebude na PowerPC, tak minimalne na ARM. x86 by se snad nepokouseli do toho rvat...

[Daniel Kvasnička ml.]

Ono také druhá věc je, že desktopové PPC čipy pocházejí tak maximálně z roku 2003

Posledni G5 sly ven na konci r. 2005...

[Daniel Kvasnička ml.]

A v kodu x264 (at uz assemblerovem nebo jinem) jsou nejake optimalizace pro AltiVec a binarka pro PPC byla zkompilovana cim a s jakym nastavenim? (mate nejaky link na benchmarky?) Je x86 rychlejsi i pri aplikaci http://code.google.com/p/x264-altivec/?

[Miloslav Ponkrác]

Vše má svoje.

Míchat FPU a SSE instrukce není problém. Nic se nemusí přepínat.

Ale: SSE vyžaduje zarovnání na 16 bajtů, budoucí AVX dokonce na 32 bajtů. Pokud děláte malou akci, tak se zarovnávání nevyplatí. V některých os, jako třeba Windows64 z důvodů preference SSE zavedli povinné zarovnávání stacku na 16 bajtů.

Pak: FPU je čistější, plně ošetřuje všechny možnosti a krajní stavy při výpočtech float čísel, SSE na to sem tam dlabe.

Vsuvka: Na internetu najdete řadu možností, jak spočítat sinus, nebo cosinus pomocí SSE (většinou rozvojem řady), ale před to si budete muset přiřadit normalizaci čísla do základního rozsahu úhlu a kontrolu a ošetření na mezní stavy čísla (nekonečno, NaN, atd..) aby to bylo ekvivalentní tomu, co vše dělá fpu.

FPU je přesnější – a to zcela bez debaty. FPU jednak počítá s 80-ti bitovými čísly, což z SSE nevymáčknete, a aby to nebylo málo, většinou FPU vnitřně počítá ještě s několika bity navíc, takže přesnost je ještě vyšší. To znamená FPU je pro vysokou přesnost, u SSE při větších výpočtech můžete vlivem zaokrouhlovacích chyb dostat také hodně nepřesný výsledek až úplnou kravinu – podle citlivosti algoritmu na zaokrouhlovací chyby.

FPU má zásobníkovou orientaci, SSE registrovou – někdy jsou algoritmy šikovnější pro to první, někdy pro to druhé.

Kdysi jsem měl debatu s asm profíky poté, co jsem sám zkoušel výrazněji použít SSE2 pro své programy, a došel jsem k závěru, že SSE není až natolik užitečné, jak se všude preferuje. Respektive užitečné je, ale její výhodnost je jen pro některé typy algoritmů, zatímco pro řadu algoritmů je výhodnější SSE nepoužít. Chtěl jsem jen zjistit, zda v tomto názoru nejsem sám, a jak jsem zjistil, nebyl.

Udělat matematické funkce nad SSE není problém, jen to chce trochu času. Jde o základní matematiku – počítání odmocnin pomocí Newtona, počítání základních matematických funkcí jako rozvoj pomocí Taylorových a jiných řad, atd.. Na druhou stranu to klidně můžete smíchat – klidně funkce počítat na FPU a zbytek na SSE, budete-li chtít.