Dnia Sat, 12 Mar 2011 14:53:57 +0100, Radosław Sokół napisał(a):

>> AFAIK sporadycznie i to też tylko w niektórych. Co zresztą [...]
>
> Szczerze mówiąc, spodziewałem się po Photoshopie nieco wię-
> cej. Tym bardziej, że tyle się ostatnio mówiło o tym, że za-
> czyna wykorzystywać nawet GPU. A tu się nagle okazuje, że
> nawet wielordzeniowych CPU nie wykorzystali do końca dobrze.

Na GPU akcelerowane jest AFAIR tylko powiększanie widoku i obracanie obrazu.
Nie wiem, czy którykolwiek z filtrów wykorzystuje GPU do obliczeń. No ale
skoro Adobe z takim zadęciem się chwaliło, że od InDesigna CS5 eksport do
PDFa można wykonać w tle, to co się dziwić. :D

> Niepotrzebnie narzekałem na GIMPa, że nie przetwarza obrazu
> równolegle w większości filtrów ;)

:)

> Okazuje się, że Apple ze swoim Core Image może być do przodu,
> bo generowany dynamicznie kod filtrów może wykorzystywać wie-
> lowątkowość i przetwarzanie równoległe na GPU. Ciekawe jak
> wygląda wydajność np. Aperture w zależności od liczby rdze-
> ni i typu karty graficznej.

Nie moja bajka akurat, bo z japkami mi jakoś nie po drodze. :D

--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Kobieta jest jak cień, gdy ją gonisz - ucieka; gdy Ty podążasz ]
[ w przeciwnym kierunku - ona podąża za Tobą. ]

do góry

Użytkownik "Radosław Sokół" <r...@m...com.pl> napisał w wiadomości
news:2011031212482300@grush.one.pl...
>
> Przede wszystkim RISC *nigdy* nie miał redukować liczby
> rozkazów. Ba, często RISCe mają bardzo dużo rozkazów, czasem
> bardzo skomplikowanych nawet.

Ale miałyby ich jeszcze wiecej gdyby nie...

> Najważniejsza zmiana polega na likwidacji trybów adresowania.
> Rozkazy operują tylko na rejestrach wewnętrznych. Jedynie wy-
> dzielone operacje LOAD i STORE są realizowane z wykorzysta-

I właśnie na likwidacji rozmaitych trybów adresowania polega ta redukcja
która tkwi w nazwie.

do góry

Użytkownik "Radosław Sokół" <r...@m...com.pl> napisał w wiadomości
news:2011031212493000@grush.one.pl...
>W dniu 10.03.2011 22:34, Piotrek pisze:
>> Może niekoniecznie technologia ale był chyba taki program Multicore
>> Optimizer w którym dało się ustawiać programy tak by korzystały z kilku
>> rdzeni. Może to by pomogło?
>
> Nie ma możliwości, by jakieś zewnętrzne narzędzie zmieniało
> sposób działania programu niedostosowanego do pracy wielo-
> wątkowej.
>
> Owszem, można zoptymalizować przyporządkowanie procesów jed-
> nowątkowych do poszczególnych rdzeni, ale nie trzeba do tego
> specjalnych programów i daje to bardzo niewiele.

Widzę, że w końcu wychodzi na moje.

do góry

W dniu 12.03.2011 20:22, MC pisze:
> I właśnie na likwidacji rozmaitych trybów adresowania polega ta redukcja która tkwi
w nazwie.

Owszem, tylko że większość uznaje, że redukcja dotknęła
mnemoników ("zlikwidowano skomplikowane rozkazy, są tylko
najprostsze") a nie konkretnych kodów rozkazów (których
faktycznie jest o niebo mniej właśnie z racji braku koniecz-
ności kodowania w rozkazie informacji o operandzie).

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\...................................................
......./

do góry

W dniu 12.03.2011 19:05, Przemysław Ryk pisze:
> Na GPU akcelerowane jest AFAIR tylko powiększanie widoku i obracanie obrazu.

Tak, to wiem.

> Nie wiem, czy którykolwiek z filtrów wykorzystuje GPU do obliczeń. No ale

O ile mi wiadomo -- nie.

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\...................................................
......./

do góry

Użytkownik "Radosław Sokół" <r...@m...com.pl> napisał w wiadomości
news:2011031219410100@grush.one.pl...
>W dniu 12.03.2011 20:22, MC pisze:
>> I właśnie na likwidacji rozmaitych trybów adresowania polega ta redukcja
>> która tkwi w nazwie.
>
> Owszem, tylko że większość uznaje, że redukcja dotknęła
> mnemoników ("zlikwidowano skomplikowane rozkazy, są tylko
> najprostsze") a nie konkretnych kodów rozkazów (których
> faktycznie jest o niebo mniej właśnie z racji braku koniecz-
> ności kodowania w rozkazie informacji o operandzie).

Dla mnie to rozróżnienie jest mocno akademickie. Przecież i tak np. operacji
arytmetycznych nie wykonuje się w RAM-ie nawet jeśli istnieje taki rozkaz.
Musi nastąpić pobranie, a po wykonaniu operacji - odesłanie.

do góry

On Sat, 12 Mar 2011, MC wrote:

> Użytkownik "Radosław Sokół" <r...@m...com.pl> napisał
[...]
>> Owszem, tylko że większość uznaje, że redukcja dotknęła
>> mnemoników ("zlikwidowano skomplikowane rozkazy, są tylko
>> najprostsze")
[...]

Ja jestem w tej większości :>

>> a nie konkretnych kodów rozkazów (których
>> faktycznie jest o niebo mniej właśnie z racji braku koniecz-
>> ności kodowania w rozkazie informacji o operandzie).

To jest kolejny element. *Kolejny*, nie pierwszy. Patrz niżej.

> Dla mnie to rozróżnienie jest mocno akademickie. Przecież i tak np. operacji
> arytmetycznych nie wykonuje się w RAM-ie nawet jeśli istnieje taki rozkaz.
> Musi nastąpić pobranie, a po wykonaniu operacji - odesłanie.

Zgoda. Ale konstrukcyjnie różnica jest - w przypadku złożonych
metod adresowania odwołania musi "rozgryźć" elektronika procesora,
dekodując złożony rozkaz (a raczej jego pola bitowe), w przypadku
prymitywów - jest to zadanie dla kompilatora (z dołożeniem
w praktyce kawałkowi odpowiedzialnemu za optymalizację) plus
(jeśli w assemblerze) programisty.
Niemniej to jest "część druga".

Wracając do "sprawy CISC".
"typowy CISC", dajmy na to taki VAX, miał w architekturze takie
podstawowe :P rozkazy jak dzielenie wielomianów tudzież liczenie
CRC czy też "skok tablicowy" (niemal wprost implementację Fortranowego
"obliczane GOTO").
W tym świetle uznawanie x86 za CISC jest takie bardziej... marketingowe
właśnie, w nim jest więcej złozoności wynikłej z kompatybilności
wstecznej niż CISCa ;)

Fakt, że instrukcje mogły (w przykładowym VAXie) wskazywać
operandy na 3. poziomie wskaźników (z możliwością dodawania przesunięcia
jednocześnie na 2 poziomach, i to zarówno z rejestru jak i bezpośrednio!)
jest już IMO "dodatkowy", i tu się nieco rozmijam z Radkiem :)
(wersja o "złożoności adresowania" prowadzi do równie dużej różnicy
między "prawdziwym CISCem" typu VAXa a "uproszczonym CISCiem" w postaci
x86, trochę komplikacji zapewnia tylko fakt istnienia segmentacji w x86).

pzdr, Gotfryd

do góry

W dniu 12.03.2011 21:42, MC pisze:
> Dla mnie to rozróżnienie jest mocno akademickie. Przecież i tak np. operacji
arytmetycznych nie wykonuje się w RAM-ie nawet jeśli istnieje taki rozkaz. Musi
nastąpić pobranie, a po wykonaniu operacji
> - odesłanie.

I właśnie to pobranie i odesłanie powoduje, że dekodowanie
rozkazów jest znacznie wolniejsze. Ponadto utrudnia się
określanie zależności rozkazów, a więc i zmniejsza możli-
wość skutecznej zmiany kolejności realizacji operacji.

Mikroprocesory RISC są w stanie zmieniać kolejność odczytów
i zapisów do pamięci nawet. W rodzinie Intela jest to zaka-
zane -- wszystkie odczyty i zapisy muszą być w kolejności
zapisanej w programie (co upraszcza oprogramowanie, ale
zmniejsza wydajność).

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\...................................................
......./

do góry