RedArt wrote:

> W efekcie stopniowo dostajemy potężną moc obliczeniową drzemiącą w kartach
> graficznych 'do zabawy'
> w zastosowaniach zupełnie z grafiką niezwiazanych - z coraz bardziej
> 'normalnym' interfejsem
> programistycznym.

To nie jest zaleta: te urządzenia zawdzięczają swą potężną wydajność
właśnie "nienormalności". Jeśli więc będziemy starali się, by przypominały
zwykłe komputery wieloprocesorowe z pamięcia dzieloną, to... po którejś
iteracji projektowej dostaniemy komputer wieloprocesorowy z pamięcia
dzieloną, a więc to, co już mamy.

> Powstaje jednocześnie wymóg modyfikacji głownego toku myślenia
> o konstrukcji oprogramowania - z algorytmiczno-iteracyjnego
> na danocentyczno-blokowy ;)

Zauważyłem, że to jest nie do przeskoczenia dla większości znanych
mi ludzi. Sekwencyjność jest tak głęboko osadzona w ludzkim mózgu,
że zawsze będzie zaburzać wyobraźnię.

> konstrukcji wydajnych procedur ETL (extract-transform-load)

Znam się na tym :-)
Ostatnio pobiliśmy jakieś natywne narzędzie Oracla podłączone
do Oraclowej bazy.

> Wymaga to rewizji stosowanych wzorców projektowych

One są w wiekszości sekwencyjne, albo co najwyżej sekwencyjno
-wielościeżkowe (wątki itp. badziewie). Data-flow, zwłaszcza w
wydaniu bottom-up tampo prostu nie istnieje.

> nowa technologia bowiem od początku kładzie nacisk na
> ukrycie najbardziej niskopoziomowych aspektów
> oprogramowania za pośrednim interfejsem

To jest bez znaczenia. A jeśli mam osobiści wybierać, to
wolę mieć dostęp do tych niskopoziomowych cudeniek.

> Wracając do tematu oprogramowania: ciekawe, jak szybko języki takie jak
> Java będa
> zdolne do skorzystania z nowych możliwości

Częściowo -- już od dawna:

http://research.microsoft.com/pubs/70250/tr-2005-184
.pdf

A w pełni? Mam nadzieję, że nigdy. Bo to nie jest język do
wysokowydajnego przetwarzania równoległego. A jak taki
język wygląda? Tego niestety nikt nie wie. :-) Mam swoje
propozycje, ale...

> - na najniższym poziomie powstaje pytanie typu: czy da się w ogóle
> zintegrować istniejące w tym języku > mechanizmy wielowątkowości
> (z instrukcjami synchronised/wait/notify) z nowym sposobem myślenia ?

Dać to się da, udało mi się wykazać odtwarzalność tych konstrukcji
w swoim frameworku. Pytanie tylko: po co? Zamontowanie końskiego
siodła w F-16 też jest technicznie możliwe... :-)

>A idąc wyżej:
> jak głęboko trzeba zmodyfikować techniki obiektowe, powszechnie stosowane
> wzorce projektowe ?

Wyrżnąć do korzeni :-) Ale sama obiektowość ma się dobrze:
w końcu polega na przekazywaniu *wiadomości* między obiektami,
a więc data flow jak się patrzy. Co z tego zrobiły C++/C#/Java to
już inna sprawa...

> Jak organizować obiekty danych (różnych typów - polimorfizm) w wyraziste
> bloki pamięci, tak
> by na wyższym poziomie dalej przypominały one abstrakcyjne kolekcje ?

A po co mają je przypominać?

> A co ze standardowymi
> iteratorami i odpalaniem metod wirtualnych na obiektach danych, gdzie
> różnorodność klas pociąga
> za sobą różnorodność procedur ?

A jak działa RPC? :-)

> Swego czasu pewien naukowiec opowiadał (rzekłbym: rozgorączkowanym głosem
> ...) o projekcie CAM-Brain.

Kolejne bicie piany przez cuckoo cloud academics. :-)

> Jednym z filarów tego projektu miała być zaawansowana technologicznie
> pamięć, gdzie cechy
> automatów komórkowych były zrealizowane już na poziomie sprzętowym. Cyk -
> i w kilku cyklach
> maszynowych miliony(...) komórek pamięci przechowujących dane
> poszczególnych automatów
> zmieniały stan - zgodnie z zaprogramowaną tablicą przejść, w zależności od
> stanów sąsiadów
> - innych najbliższych komórek pamięci.

Zieeew. Ktoś uparcie stara sie ponownie odkryć to koło.

> Na pewno po raz kolejny udowadnia, że problemy tworzenia sztucznej
> inteligencjie nie leżą w brakach mocy obliczeniowej (a na pewno nie jest
> to problem
> podstawowy).

Automaty komórkowe to uczciwa nauka, a nie żadna, za
przeproszeniem, sztuczna inteligencja.

> Ale wychodząc z dygresji: kiedy pojawiły się mechanizmy pixel shaderów w
> kartach graficznych,
> pierwsza myśl, jaka mi przyszła do głowy, to: a, mamy już w domu w końcu
> tę technologię
> idealną do wspomagania automatów komórkowych

Skąd ta myśl? Moim zdaniem shadery nadają się do tego słabo.
FPGA powinno być znacznie bardziej obiecującym kierunkiem.

Pozdrawiam
Piotr Wyderski