On 01.03.2013 11:14, M.M. wrote:
>> To cierpi nawet, jeśli są rozgałęzienia programu.
> To niedobrze :(

To jest po prostu inny sprzęt i go się inaczej programuje. Na klasycznym
procesorze sporo przypadków opiera się o różne formy pętli, na GPU na
podział danych na jednorodne bloki i wykonywanie na nich takich samych
operacji.


>
>
>> Bardzo dobrze. Ale w swoich zadaniach, to nie jest uniwersalny
>> procesor do wszystkiego.
>
>
>> Z lekkim przymrożeniem oka możesz patrzeć na to jak na
>> koprocesor, tylko on nie dostaje do przemnożenia
>> dwa double, tylko dwie macierze zespolone po 200MB,
>> albo jakąś funkcję do policzenia w tysiącach punktów naraz.
> Myślę o tym głównie pod kątem czegoś podobnego do symulowanego
> wyżarzania, czyli w kółko liczenie wartości funkcji. Niestety
> ta funkcja, choć nie jest funkcją rekurencyjną, ma
> dużo ifów.

Wszystko zależy od przypadku - czasami lepiej napisać if, czasami lepiej
zamienić coś pokroju (to tylko przykład)

if(b>10)
a = 123*b*y;
else if(b<-10)
a = 321*b*x;
else
a = b*x*y;

na

a = (b>10)*123*b*y + (b<-10)*321*b*x + (!(b>10))*(!(b<-10))*b*x*y

>
> Może to jednak kwestia asemblera? Nie wiem jak jest dzisiaj.
> Ale jakieś kilkanaście lat temu, jak przepisałem niechlujnie
> procedurę w asemblerze, to działała 3 razy szybciej niż
> skompilowana kompilatorem C/C++.

Przez kilkanaście lat naprawdę sporo się zmieniło to raz. Po drugie na
dzisiejsze procesory czasami lepiej jest wygenerować "ciaśniejszy" kod,
niż "szybszy" bo zaoszczędzenie na dostępach do cache potrafi dawać
kilkukrotny boost. W języku pokroju C++ wystarczy zmienić atrybuty
dotyczące optymalizacji, w asm musisz przepisywać ;) W ogóle asm poza
bardzo rzadkimi przypadkami to strata czasu - liczy się doby algorytm a
go im wyżej poziomowy język tym szybciej zapisać, przetestować,
tuningować. Mikrooptymalizacje to robota na sam, sam koniec.

--
Pozdrawiam
Michoo