Jako bazę dam artykuł:
http://www.nvidia.pl/docs/IO/55972/220401_Reprint.pd
f

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ą 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.
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).

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 ?
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.

do góry

On Mon, 30 Mar 2009 12:12:58 +0200, "RedArt"
<r...@t...tez.op.pl> wrote:

>
>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 komorkowe sa znane od czasow Von Neumanna, czylo od lat 40.
Nie moga nic wiecej niz maszyna Turinga. I nie maja nic wspolnego ze
"strukturami neuronowymi"

A.L.

do góry

Użytkownik "A.L." <a...@a...com> napisał w wiadomości
news:9g91t49t0u15kompclp42jb3bjk4rd18e9@4ax.com...
> On Mon, 30 Mar 2009 12:12:58 +0200, "RedArt"
> <r...@t...tez.op.pl> wrote:
>
>>
>>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 komorkowe sa znane od czasow Von Neumanna, czylo od lat 40.
> Nie moga nic wiecej niz maszyna Turinga. I nie maja nic wspolnego ze
> "strukturami neuronowymi"

Oczywiscie - same w sobie nic ze sztucznym neoronem nie mają.
Natomiast projekt CM-Brain wykorzystywał je do tego, by w przestrzeni 3D
'drążyć' ścieżki
do przesyłania sygnałów. Jest to dość proste.
Lista stanów:
0 - martwy
1 - ścieżka - 'kawałek dendrytu/aksonu' ;)
2 - czoło sygnału (pobudzenia)
3 - sygnał 'schodzący'

Tablica przejść:
0 -> 0
1 -> 2, jeśli któryś z sąsiadów jest 2(propagacja sygnału), 1 w innym
przypadku(nic się nie dzieje)
2 -> 3 (sygnał wygasa)
3 -> 1 (sygnał wygasł)

Teraz jak sobie wydrążysz dowolnego kształtu ścieżkę/korytarz ( może mieć
rozwidlenia ) - czyli
pośród morza zer wydrążysz jedynki a potem jedną z jedynek wzbudzisz
(wstawisz 2) i zapuścisz
cykle przetwarzania - to uzyskasz efekt przesuwającego się wzdłuż ścieżki
sygnału, który na rozwidleniach
będzie się rozdwajał itp.
Jak podłączysz do wydrążonej ścieżki cykle o różnych długościach to może uda
się zasymulować prosty
efekt 'padaczki' - kiedy sygnały zaczynają się namnażać i zalewają całość. W
powyższym modelu zdaje się,
że sygnały idące w przeciwnych kierunkach po zderzeniu wygaszają się, wiec
być może padaczkę trudno byłoby
uzyskać, ale można z tym na różne sposoby eksperymentować modyfikując
tablicę stanów i przejść.
Jak to dokładnie wyglądało w projekcie CAM-Brain - nie wiem. Ale na pewno da
się ten najprostszy
model rozbudować o sygnały bardziej 'analogowe' (czyli o różnej sile),
wstawić progi, sumatory,
elementy inwertujące - możliwości są bardzo duże, szczególnie jak damy sobie
trochę bitów każdemu stanowi
do dyspozycji.

Główne zadanie dla projektu polegało zdaje się na zaprzeżeniu algorytmów
genetycznych do tego,
by jakoś sensownie drążyć te ścieżki, żeby struktura dawała na wyjściu
jakieś sensowne sygnały
w zależności od pobudzenia. No i tu już się zaczęło prawdziwe SF jak sądzę,
bo proste funkcje typu
XOR to siędało wyhodować, ale coś więcej ...

do góry

On Mon, 30 Mar 2009 12:12:58 +0200, "RedArt"
<r...@t...tez.op.pl> wrote:

>Jako bazę dam artykuł:
>http://www.nvidia.pl/docs/IO/55972/220401_Reprint.p
df
>
>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 ;)

Wsystko to bardzo ciekawe. Tacio ktory po raz drugi odkryl zarowke,
tez mowil ze to bardzo ciekawe.

No i oczywiscie, zgadzam sie: algorytmy juz nie beda potrzebne.

A.L.

do góry

Użytkownik "A.L." <a...@a...com> napisał w wiadomości
news:gbb1t4lj0p5a0u6en7toogc3qf3rt286kp@4ax.com...

> No i oczywiscie, zgadzam sie: algorytmy juz nie beda potrzebne.

Dla usprawnienia procesu dyskusji proszę o spreparowanie z góry listy
wyrażeń/słowek/nieścisłości,
których można (czytaj BEZWZGLĘDNIE NALEŻY) sieprzyczepić, postaramy się je
przetworzyć
blokowo - będzie wydajniej ;)

do góry

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 ,

do góry

i tak jeszcze dodam, że sztucznej inteligencji (prawdziwej) nie da się utworzyć
dlatego, że bazując na budowie sieci nerwowej-- trzeba by osadzić ją na kontakcie ze
światem zewnętrznym, inaczej się nie da. poza tym konieczne jest utworzenie
wewnętrznego mechanizmu sprzężenia zwrotnego dla nowo powstających definicji, co
raczej mogło by być o wiele prostsze. no i okreslanie 'ja' takiego układu...
dziękuję... to ostatnie to już ktoś inny. :-)
--
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 ,

do góry

On Mon, 30 Mar 2009 12:11:35 +0000 (UTC), czas dOSa <u...@i...sk>
wrote:

>i tak jeszcze dodam, że sztucznej inteligencji (prawdziwej) nie da się utworzyć
dlatego,
>że bazując na budowie sieci nerwowej-- trzeba by osadzić ją na kontakcie ze światem
zewnętrznym, inaczej się nie da.?poza tym konieczne jest utworzenie wewnętrznego
mechanizmu sprzężenia zwrotnego dla nowo powstających definicji, co raczej mogło by
być o wiele prostsze.?no i okreslanie ?ja' takiego układu... dziękuję... to ostatnie
to
już ktoś inny.?:-)

Inteligencji sztucznej nie uda sie stworzyc dopoki inteligencja
naturalna nei nauczy sie ze od czasu do czasu tzreba przyciskac
klasisz "enter"

A.L.

do góry

On Mon, 30 Mar 2009 13:32:35 +0200, "RedArt"
<r...@t...tez.op.pl> wrote:

>
>Użytkownik "A.L." <a...@a...com> napisał w wiadomości
>news:9g91t49t0u15kompclp42jb3bjk4rd18e9@4ax.com...
>> On Mon, 30 Mar 2009 12:12:58 +0200, "RedArt"
>> <r...@t...tez.op.pl> wrote:
>>
>>>
>>>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 komorkowe sa znane od czasow Von Neumanna, czylo od lat 40.
>> Nie moga nic wiecej niz maszyna Turinga. I nie maja nic wspolnego ze
>> "strukturami neuronowymi"
>
>Oczywiscie - same w sobie nic ze sztucznym neoronem nie mają.
>Natomiast projekt CM-Brain wykorzystywał je do tego, by w przestrzeni 3D
>'drążyć' ścieżki
>do przesyłania sygnałów. Jest to dość proste.
>Lista stanów:
>0 - martwy
>1 - ścieżka - 'kawałek dendrytu/aksonu' ;)
>2 - czoło sygnału (pobudzenia)
>3 - sygnał 'schodzący'
>

Przepraszam,. ale to jest nonsens. Proponuje jakeis inen miejsce na te
rewelacjie

A.L.

do góry

Użytkownik "A.L." <a...@a...com> napisał w wiadomości
news:0sd1t45gci7forr1so6p7qqva1jehtkfvn@4ax.com...

> Przepraszam,. ale to jest nonsens. Proponuje jakeis inen miejsce na te
> rewelacjie

http://en.wikipedia.org/wiki/Hugo_de_Garis
He became known in the 1990s for his research on the use of genetic
algorithms to evolve neural networks using three dimensional cellular
automata inside field programmable gate arrays. He claimed that this
approach would enable the creation of what he terms "artificial brains"
which would quickly surpass human levels of intelligence.
...
Though it was initially envisaged that these cellular automata would run on
special computers, such as MIT's "Cellular Automata Machine-8" (CAM-8), by
1996 it was realised that the model originally proposed, which required
cellular automata with thousands of states, was too complex to be realised
in hardware. The design was considerably simplified, and in 1997 the
"collect and distribute 1 bit" ("CoDi-1Bit") model was published, and work
began on a hardware implementation using Xilinx XC6264 FPGAs. This was to be
known as the "CAM Brain Machine" (CBM).
...


http://citeseer.ist.psu.edu/cache/papers/cs/2145/htt
p:zSzzSzwww.hip.atr.co.jpzSz~degariszSzpaperszSzWWW-
Nagoya-95.pdf/degaris96cambrain.pdf
Polecam rysunki na trzeciej stronie.

do góry