NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Możliwości budowy asynchronicznego komputera z równoległym przetwarzaniem instrukcji?
J.F.
Guest
Guest
Sun Mar 07, 2010 12:43 pm
On Sun, 7 Mar 2010 12:22:43 +0100, Sylwester Łazar wrote:
Quote:
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?
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.
Jerry1111
Guest
Guest
Sun Mar 07, 2010 12:52 pm
On 07/03/2010 11:43, J.F. wrote:
Quote:
Przetwarzanie algorytmiczne jest z reguly sekwencyjne, i to sie szybko
nie zmieni.
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
J.F.
Guest
Guest
Sun Mar 07, 2010 1:14 pm
On Sun, 07 Mar 2010 11:52:46 +0000, Jerry1111 wrote:
Quote:
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.
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 :-)
Quote:
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?
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.
Quote:
PS: Juz to sobie wyobrazam - przy wymagajacych grach user psika CO2 na
procek zeby przyspieszyc animacje
procek zeby przyspieszyc animacje
To czesciowo juz dzis dziala - jak procek za goracy to sie
automatycznie zegar spowalnia :-)
J.
Sylwester Łazar
Guest
Guest
Sun Mar 07, 2010 9:27 pm
Quote:
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ł
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
JanuszR
Guest
Guest
Mon Mar 08, 2010 1:09 am
Quote:
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.
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
Krzysztof Tabaczyński
Guest
Guest
Mon Mar 08, 2010 7:05 am
Użytkownik "JanuszR" <rniski@o2.pl> napisał w wiadomości
news:hn1f8b$iti$1@news.onet.pl...
Quote:
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ę.
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.
Sylwester Łazar
Guest
Guest
Mon Mar 08, 2010 8:25 am
Quote:
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
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.
Ghost
Guest
Guest
Mon Mar 08, 2010 8:58 am
Użytkownik "Jerry1111" <jerry1111alwaysattackedbyspam@wp.pl.pl.wp> napisał w
wiadomości news:hn042l$v7t$1@news.onet.pl...
Quote:
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.
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".
Quote:
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).
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?
Ghost
Guest
Guest
Mon Mar 08, 2010 9:05 am
Użytkownik "JanuszR" <rniski@o2.pl> napisał w wiadomości
news:hn1f8b$iti$1@news.onet.pl...
Quote:
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.
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.
Quote:
Jest problem z instrukcjami warunkowymi, z danymi uzyskiwanymi w operacji
poprzedzającej.
poprzedzającej.
Sa obliczenia w sposob naturalny dajace sie podzielic.
Quote:
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ę.
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.
Ghost
Guest
Guest
Mon Mar 08, 2010 9:05 am
Użytkownik "Krzysztof Tabaczyński" <ktabaczynski@wp.pl> napisał w wiadomości
news:hn2435$7o5$1@inews.gazeta.pl...
Quote:
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.
Ghost
Guest
Guest
Mon Mar 08, 2010 9:09 am
Użytkownik "Jerry1111" <jerry1111alwaysattackedbyspam@wp.pl.pl.wp> napisał w
wiadomości news:hn042l$v7t$1@news.onet.pl...
Quote:
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?
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?
Inaczej nie ma szans - ale korzysci z takiej architektury obawiam sie, ze
zostana zjedzone przez komplikacje i niewiele na koncu uzyskamy, a nawet
troche stracimy. Np. wspomniana juz mozliwosc ograniczenia czestotliwosci
zegara w razie zbyt wysokiej temperatury, oczywiscie mozna to protezowac,
ale lawinowo wzrosnie stopien komplikacji .
Sylwester Łazar
Guest
Guest
Mon Mar 08, 2010 10:07 am
Quote:
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".
C=A+B
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".
C=A+B
"Nawet jeśli A dąży do 0, to i tak nic z tego, bo jeszcze jest B?"
S.
Zbych
Guest
Guest
Mon Mar 08, 2010 11:03 am
Sylwester Łazar pisze:
Quote:
To w takim razie warto dobudowywać kolejne protezy do synchronicznych
systemów?
Może lepiej od razu zrezygnować z programów pisanych sekwencyjnie.
systemów?
Może lepiej od razu zrezygnować z programów pisanych sekwencyjnie.
Bardzo dobry pomysł. Można by go też zastosować np. w budownictwie -
zamiast zaczynać od fundamentów, można by od razu zbudować wszystkie piętra.
Quote:
Zdaje się, że objektowość rodzi pewne nadzieje,
ale wygląda na to, że sam komputer jest nieobiektowy.
ale wygląda na to, że sam komputer jest nieobiektowy.
Nie wiem co palisz, ale to nieźle kopie.
Ghost
Guest
Guest
Mon Mar 08, 2010 11:21 am
Użytkownik "Zbych" <abuse@onet.pl> napisał w wiadomości
news:hn2i77$r4m$1@atlantis.news.neostrada.pl...
Quote:
Sylwester Łazar pisze:
To w takim razie warto dobudowywać kolejne protezy do synchronicznych
systemów?
Może lepiej od razu zrezygnować z programów pisanych sekwencyjnie.
Bardzo dobry pomysł. Można by go też zastosować np. w budownictwie -
zamiast zaczynać od fundamentów, można by od razu zbudować wszystkie
piętra.
Zdaje się, że objektowość rodzi pewne nadzieje,
ale wygląda na to, że sam komputer jest nieobiektowy.
Nie wiem co palisz, ale to nieźle kopie.
To w takim razie warto dobudowywać kolejne protezy do synchronicznych
systemów?
Może lepiej od razu zrezygnować z programów pisanych sekwencyjnie.
Bardzo dobry pomysł. Można by go też zastosować np. w budownictwie -
zamiast zaczynać od fundamentów, można by od razu zbudować wszystkie
piętra.
Zdaje się, że objektowość rodzi pewne nadzieje,
ale wygląda na to, że sam komputer jest nieobiektowy.
Nie wiem co palisz, ale to nieźle kopie.
To prawda, choc na poczatku trudno bylo orzec...
Sylwester Łazar
Guest
Guest
Mon Mar 08, 2010 11:21 am
Quote:
To w takim razie warto dobudowywać kolejne protezy do synchronicznych
systemów?
Może lepiej od razu zrezygnować z programów pisanych sekwencyjnie.
Bardzo dobry pomysł. Można by go też zastosować np. w budownictwie -
zamiast zaczynać od fundamentów, można by od razu zbudować wszystkie
piętra.
systemów?
Może lepiej od razu zrezygnować z programów pisanych sekwencyjnie.
Bardzo dobry pomysł. Można by go też zastosować np. w budownictwie -
zamiast zaczynać od fundamentów, można by od razu zbudować wszystkie
piętra.
Hmm... Przecież to już dawno jest zrobione.
Zdaje się, że firma z Krakowa nieźle na tym zarabia, sprzedając gotowe
moduły do Anglii.
Quote:
Zdaje się, że objektowość rodzi pewne nadzieje,
ale wygląda na to, że sam komputer jest nieobiektowy.
Nie wiem co palisz, ale to nieźle kopie.
Nie tak trudno sobie wyobrazić komendę:
ale wygląda na to, że sam komputer jest nieobiektowy.
Nie wiem co palisz, ale to nieźle kopie.
Nie tak trudno sobie wyobrazić komendę:
Rób pętle, i wyjdź z niej jak wartość Y mieścić się będzie w przedziale 2202
a 2358?
np:
loopoutrange Y,2202,2358
Palenie rzuciłem jakieś 15 lat temu.
Od tego czasu wiele rzeczy mi się rozjaśniło
S.
elektroda NewsGroups Forum Index - Elektronika Polska - Możliwości budowy asynchronicznego komputera z równoległym przetwarzaniem instrukcji?