On Sun, 7 Mar 2010 12:22:43 +0100, Sylwester Łazar wrote:
>> procesorze amulet (asynchroniczny arm). W największym skrócie
>A to o ten z Manchesteru... Myślałem o tym lampowym.

>Czy możliwe jest zbudowanie komputera asynchronicznego, który nie wykonuje
>dokładnie krok po kroku programu?
>np.taki który ma zapisane w kolejnych komórkach pamięci rozkazy i wykonuje
>cały program w etapach, ale równocześnie po kilka instrukcji?

No coz, byl dawniej taki jezyk, Occam, na transputery,
ktory zasadniczo tak mial dzialac - jesli nie zaznaczyles specjalnie,
to kolejne linie byly wykonywane rownolegle.

Oczywiscie to w zalozeniach, bo w praktyce transputer byl w miare
normalnym procesorem sekwencyjnym, z tym ze chetnie dzialal w
srodowisku wieloprocerowym. Z czasem to nawet Inmosie przestali uzywac
Occamu, i transputery programowali w C.

Duzo pracy wlozyl Intel i AMD w to zeby wspolczesne procesory x86
potrafily zrobic kilka instrukcji na raz, oczywiscie ma to bardzo
ograniczony zakres, pomijajac fakt kilku rdzeni.

Przetwarzanie algorytmiczne jest z reguly sekwencyjne, i to sie szybko
nie zmieni.

J.

do góry

On 07/03/2010 11:43, J.F. wrote:
> Przetwarzanie algorytmiczne jest z reguly sekwencyjne, i to sie szybko
> nie zmieni.

Ale sekwencyjnosc i asynchronicznosc to zupelnie rozne sprawy - a mam
wrazenie ze w tym watku zostalo to troche pomieszane.

Zrobienie procka asynchronicznego powinno byc mozliwe, moze sie da
zrobic to tak ze kazdy blok generuje sygnaly 'busy/finished' (zeby
uniknac hazardu) przy zaczeciu/skonczeniu kazdej operacji? Przy
starannym pipeline powinno dzialac szybko. Tylko teraz rodzi sie problem
- zeby nie czekac na najwolniejsze operacje, to przydaloby sie cos
zrownoleglic ;-)
No i skad wziac pamiec - wszystkie DRAMy teraz sa synchroniczne
(robienie plytki do DDR3 to, tfu, zakrawa o pornografie - zrobilem sobie
'downgrade' do DDR2 po 2 dniach myslenia).


PS: Juz to sobie wyobrazam - przy wymagajacych grach user psika CO2 na
procek zeby przyspieszyc animacje ;-)

--
Jerry1111

do góry

On Sun, 07 Mar 2010 11:52:46 +0000, Jerry1111 wrote:
>On 07/03/2010 11:43, J.F. wrote:
>> Przetwarzanie algorytmiczne jest z reguly sekwencyjne, i to sie szybko
>> nie zmieni.
>
>Ale sekwencyjnosc i asynchronicznosc to zupelnie rozne sprawy - a mam
>wrazenie ze w tym watku zostalo to troche pomieszane.

Dokladnie, dlatego zrobilem nowy i zatytulowalem jak zatytulowalem.
Tu powinno byc tylko o procesorach ktore wiecej niz jedna instrukcje
na raz robia :-)


>Zrobienie procka asynchronicznego powinno byc mozliwe, moze sie da
>zrobic to tak ze kazdy blok generuje sygnaly 'busy/finished' (zeby
>uniknac hazardu) przy zaczeciu/skonczeniu kazdej operacji?

To jest jeden z problemow - jak np zrobic sumator zeby wygenerowac
taki sygnal jak juz wynik na wyjsciu sie ustabilizuje.

Dla innych blokow, np pamieci naturalne beda raczej zwykle uklady
czasowe do wygenerowania takiego sygnalu po czasie w ktorym juz
_powinien_ sie pojawic stabilny sygnal.


Tak czy inaczej - wspolczesny procesor ma w sobie duzo rejestrow
przelaczanych sygnalem zegara, dlatego nazywamy synchronicznym.

Asynchroniczny musialby z tego zrezygnowac.

>PS: Juz to sobie wyobrazam - przy wymagajacych grach user psika CO2 na
>procek zeby przyspieszyc animacje ;-)

To czesciowo juz dzis dziala - jak procek za goracy to sie
automatycznie zegar spowalnia :-)

J.

do góry

> Ale sekwencyjnosc i asynchronicznosc to zupelnie rozne sprawy - a mam
> wrazenie ze w tym watku zostalo to troche pomieszane.
Tak, to prawda temat śmierci Pana Jacka Karpińskiego się poszerzył i poszedł
w 2D.
Zaciekawiła mnie ta asynchroniczność w 1971 roku na TTLach.
Wiem, że to nie jest nic dziwnego - dzisiaj.
Naprawiłem taką maszynę Voumard z 1976 roku zrobioną przez Szwajcarów.
Ma ona piękny dekoder kolejnych bloków algorytmicznych i pamięć na diodach.
Ale ta maszyna była zrobiona w technologi DTL.
Nie ma zegara centralnego, a wszystkie sygnały czasowe są generowane przez
układ RC (taki scalak jak 74123, ale w technologi DTL).

W związku z tym wydaje mi się, że te pomysły Pana Karpińskiego muszą być
naprawdę dobre i warto poznać ten K-202.

Teraz połączyć pomysł Jacka Karpińskiego (asynchronizm) z równoległością
może dać korzyści w kwadracie.

--
pozdrawiam
Sylwester Łazar
http://www.alpro.pl
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB

do góry

> W związku z tym wydaje mi się, że te pomysły Pana Karpińskiego muszą być
> naprawdę dobre i warto poznać ten K-202.
>
> Teraz połączyć pomysł Jacka Karpińskiego (asynchronizm) z równoległością
> może dać korzyści w kwadracie.

Myślę, że z uwagi na sekwencyjność procesory równoległe to mrzonka. Jest
problem z instrukcjami warunkowymi, z danymi uzyskiwanymi w operacji
poprzedzającej. W najlepszym razie będą to procesory wielojądrowe, gdzie
wielotorowość z uwagi na sekwencyjność programu będzie ograniczona i np.
procesory 256 kernelowe nie będą dawały znaczącego przyrostu wydajności.
Prawdziwe przetwarzanie równoległe to oczywiście sieci neuronowe, które
w porównaniu do technologi szeregowej dopiero raczkują. Sieci
neuronowych nie potrafimy programować (nie jest mi znany żaden
kompilator), póki co działają tylko w oparciu o uczenie się.

JanuszR

do góry

Użytkownik "JanuszR" <r...@o...pl> napisał w wiadomości
news:hn1f8b$iti$1@news.onet.pl...
>> W związku z tym wydaje mi się, że te pomysły Pana Karpińskiego muszą być
>> naprawdę dobre i warto poznać ten K-202.
>>
>> Teraz połączyć pomysł Jacka Karpińskiego (asynchronizm) z równoległością
>> może dać korzyści w kwadracie.
>
> Myślę, że z uwagi na sekwencyjność procesory równoległe to mrzonka. Jest
> problem z instrukcjami warunkowymi, z danymi uzyskiwanymi w operacji
> poprzedzającej. W najlepszym razie będą to procesory wielojądrowe, gdzie
> wielotorowość z uwagi na sekwencyjność programu będzie ograniczona i np.
> procesory 256 kernelowe nie będą dawały znaczącego przyrostu wydajności.
> Prawdziwe przetwarzanie równoległe to oczywiście sieci neuronowe, które w
> porównaniu do technologi szeregowej dopiero raczkują. Sieci neuronowych
> nie potrafimy programować (nie jest mi znany żaden kompilator), póki co
> działają tylko w oparciu o uczenie się.

A znasz może jakąś sieć neuronową szczególnie dobrze nadającą
się do przewidywania jutra? Na przykład jest duża instalacja
lakiernicza z lat 70-tych i warto by było wiedzieć co się
popsuje JUTRO...

Pozdrowienia. Krzysztof z Tychów.

do góry

> Myślę, że z uwagi na sekwencyjność procesory równoległe to mrzonka. Jest
> problem z instrukcjami warunkowymi, z danymi uzyskiwanymi w operacji
> poprzedzającej. W najlepszym razie będą to procesory wielojądrowe, gdzie
> wielotorowość z uwagi na sekwencyjność programu będzie ograniczona i np.
> procesory 256 kernelowe nie będą dawały znaczącego przyrostu wydajności.
To w takim razie warto dobudowywać kolejne protezy do synchronicznych
systemów?
Może lepiej od razu zrezygnować z programów pisanych sekwencyjnie.
Zdaje się, że objektowość rodzi pewne nadzieje,
ale wygląda na to, że sam komputer jest nieobiektowy.
Może warto pokusić się, o zbudowanie szybkiej- obiektowej maszyny, jak
zapewne próbował Pan Karpiński,
a programistów zmusić do dostosowania się do dobrego sprzętu.
Należy w instrukcjach powtarzać ulubioną mantrę programistów:
"Do dobrych zwyczajów programowania należy..."
S.

do góry

Użytkownik "Jerry1111" <j...@w...pl.pl.wp> napisał w
wiadomości news:hn042l$v7t$1@news.onet.pl...
> On 07/03/2010 11:43, J.F. wrote:
>> Przetwarzanie algorytmiczne jest z reguly sekwencyjne, i to sie szybko
>> nie zmieni.
>
> Ale sekwencyjnosc i asynchronicznosc to zupelnie rozne sprawy - a mam
> wrazenie ze w tym watku zostalo to troche pomieszane.

Od mojego posta sie zaczelo, ale nie ja tu winien. Kolega wyznajacy k202
pisal cos o geniuszach czekajacych na slabeuszy i widzial na to rade w
asynchronicznosci. Gdzies sie to zagubilo w meandrach watka, a ja probowalem
jedynie wskazac, ze asynchrnicznosc nie jest na to rada, gdyz i tak
sekwencyjnosc wymaga tego "czekania".

> Zrobienie procka asynchronicznego powinno byc mozliwe, moze sie da zrobic
> to tak ze kazdy blok generuje sygnaly 'busy/finished' (zeby uniknac
> hazardu) przy zaczeciu/skonczeniu kazdej operacji? Przy starannym pipeline
> powinno dzialac szybko. Tylko teraz rodzi sie problem - zeby nie czekac na
> najwolniejsze operacje, to przydaloby sie cos zrownoleglic ;-)
> No i skad wziac pamiec - wszystkie DRAMy teraz sa synchroniczne (robienie
> plytki do DDR3 to, tfu, zakrawa o pornografie - zrobilem sobie 'downgrade'
> do DDR2 po 2 dniach myslenia).

I pytanie po co?

do góry

Użytkownik "JanuszR" <r...@o...pl> napisał w wiadomości
news:hn1f8b$iti$1@news.onet.pl...
>> W związku z tym wydaje mi się, że te pomysły Pana Karpińskiego muszą być
>> naprawdę dobre i warto poznać ten K-202.
>>
>> Teraz połączyć pomysł Jacka Karpińskiego (asynchronizm) z równoległością
>> może dać korzyści w kwadracie.
>
> Myślę, że z uwagi na sekwencyjność procesory równoległe to mrzonka.

Nie, to rzeczywistosc.

> Jest problem z instrukcjami warunkowymi, z danymi uzyskiwanymi w operacji
> poprzedzającej.

Sa obliczenia w sposob naturalny dajace sie podzielic.

> W najlepszym razie będą to procesory wielojądrowe, gdzie wielotorowość z
> uwagi na sekwencyjność programu będzie ograniczona i np. procesory 256
> kernelowe nie będą dawały znaczącego przyrostu wydajności. Prawdziwe
> przetwarzanie równoległe to oczywiście sieci neuronowe, które w porównaniu
> do technologi szeregowej dopiero raczkują. Sieci neuronowych nie potrafimy
> programować (nie jest mi znany żaden kompilator), póki co działają tylko w
> oparciu o uczenie się.

Ale emulacja dzialania seici neuronowych idalnie na daje sie na maszyny
(bardzo)wieloprocesorowe.

do góry

Użytkownik "Krzysztof Tabaczyński" <k...@w...pl> napisał w wiadomości
news:hn2435$7o5$1@inews.gazeta.pl...
>
> A znasz może jakąś sieć neuronową szczególnie dobrze nadającą
> się do przewidywania jutra? Na przykład jest duża instalacja
> lakiernicza z lat 70-tych i warto by było wiedzieć co się
> popsuje JUTRO...

Ale juz maszyny rownolegle dobrze nadaja sie do przewidywinania jutra.

do góry