bardzo ciekawy list, bardzo ciekawy!

TYPE "RedArt":
> Jako bazę dam artykuł:
> http://www.nvidia.pl/docs/IO/55972/220401_Reprint.pd
f
nie chciało mi się czytać. ;-) ale to musi być konkretne, specyficzne zastosowanie,
więc się domyślam co tam jest.

> W skrócie: mechanizmy pixel/vertex shaderów stosowane w kartach
> graficznych są intensywnie rozbudowywane - o większy dostęp do pamięci
> współdzielonej, o możliwości operowania
> na złożonych typach danych itp.
>
> 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 tak od strony naszej - programistów. Powstaje
> jednocześnie wymóg
> modyfikacji głownego toku myślenia o konstrukcji oprogramowania - z
> algorytmiczno-iteracyjnego
> na danocentyczno-blokowy ;) Jest to ciekawe zagadnienie, z pewnością
czyli masz na myśli przetwarzanie bloku danych przy pomocy zadanego algorytmu
obecnego w sprzęcie?
prawdopodobnie chodzi o zamianę przetwarzania iteracyjnego danych na przetwarzanie
liniowe w sprzęcie. coś podobnego do linii produkcyjnej fabryki, lecz z wymiennymi
modułami etapów. z chęcią rozwinąłbym ten temat.

> znane już tym, którzy
> siedzą głeboko w technikaliach przetwarzania baz danych czy konstrukcji
> wydajnych procedur
> ETL (extract-transform-load) w interfejsach międzysystemowych. Wymaga to


> rewizji stosowanych
> wzorców projektowych, przejrzenia praktycznej użyteczności stosowanych
> obecnie technik obiektowych
> itp - temat niewątpliwie bardzo szeroki i ciekawy.
>
> Natomiast jest to także temat ciekawy od strony przyszłych architektur
> mikroprocesorowych.
> Nie da się ukryć, że w miarę rozwoju oprogramowania dostosowanego
> (uwspółbieżnionego)
> wg nowych reguł siła centralnej jednostki-procesora będzie miała
> znaczenie coraz mniejsze.
po prostu pewna część programu, pewna procedura wykona się bezpośrednio na sprzęcie,
a nie przy pomocy wielu rozkazów procesora.

> Co najciekawsze wydaje się, że powstaje szansa na trwałe wybrniecie z
> problemu różnic
> architektonicznych(w rezultacie dających zupełnie inne języki maszynowe
> lub znaczne różnice
> w liście dostępnych instrukcji) powstających w miarę rozwoju
> mikroporocesorów różnych
> technologii i producentów - nowa technologia bowiem od początku kładzie
> nacisk na ukrycie
> najbardziej niskopoziomowych aspektów oprogramowania za pośrednim
> interfejsem dostępu
> stanowiącym dużo stabilniejszą warstwę funkcji-instrukcji lepiej
> odzwierciedlającą potrzeby
> programistyczne wyższego poziomu, skoncentrowane na organizacji danych i
> procedur
> biznesowych. Np. udaje siędo minimum zredukować wymóg ręcznej obsługi
> współbieżności
> (ochrona dostępu do współdzielonych zasobów, problemy typu deadlock czy
> zagładzania
> procesów).
był już język programowania, który na tym bazował-- nazywał się "BASIC".

> Wracając do tematu oprogramowania: ciekawe, jak szybko języki takie jak
> Java będa
> zdolne do skorzystania z nowych możliwości - 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 ? A
> idąc wyżej:
> jak głęboko trzeba zmodyfikować techniki obiektowe, powszechnie
> stosowane wzorce projektowe ?
zależy, o czym piszesz. jeśli mówisz tylko o przetwarzaniu blokowym, to nie jest ono
alternatywą, lecz nowymi możliwościami.

> 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
> co ze standardowymi
> iteratorami i odpalaniem metod wirtualnych na obiektach danych, gdzie
> różnorodność klas pociąga
> za sobą różnorodność procedur ? Ogarnąć powiazania między obiektami ...
> Tematów jest mnóstwo.
> Zapewne są one jużdobrze znane tam, gdzie zagościł temat obiektowych baz
> danych.

> A jeszcze mały wtręt do AI.
> Swego czasu pewien naukowiec opowiadał (rzekłbym: rozgorączkowanym
> głosem ...) o projekcie
> CAM-Brain. W skrócie: chodziło o budowanie/hodowanie/uczenie złożonych
> struktur neuronowych
> skonstruowanych i działajacych w oparciu o tzw. automaty komórkowe.
> Automaty komórkowe(sześciany)
> stanowiły podstawowe cegiełki do budowanych w przestrzeni 3D ścieżek, po
> których można było przesyłać
> sygnały itp. 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. Każda komórka pamięci stanowiła
> więc mini-procesor potrafiący
> wykonać bardzo proste czynnosci - ale współbieżnie z innymi. Dygresja:
> Losy projektu - no cóż ...
> Jak wielu projektów ... ;) 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).
> 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, a w perspektywie rozwoju
> dającą zupełnie
> nowe możliwości obliczeniowe.
> Technologia CUDA pokazuje, że ten potencjał jest intensywnie rozwijany,
> a zapewne w najbliższym czasie
> doczekamy siętakże ciekawych przykładów 'eksploatacji' - na początek w
> oprogramowaniu
> wspomagajacym obliczenia naukowe.
ta technologia ("CUDA") to po prostu użycie instrukcji procesora karty graficznej,
prawda? a konkretnie to w języku C/C++?
--
qo |) CPL: cs[0..1] (ss[0..1]) p lvl of curr code!
_x/ , RPL: seg_sel[0..1] privilege lvl of seg_sel!
| ng __ -- __ -- __ -- __ -- __ -- __ -- __ -x86-,
,__ -- __ -- DPL: 2._word_of_seg_desc[13..14]:`f seg_desc ,