people can fly, anything
can happen...
..Sunrise..

1. hmmmmmm moj niepokoj , Nazgul 15/05/07 16:57
   jest coraz mniejszy:
   "Phenomy będą potrzebowały podstawki Socket AM2+, jednak nie będzie ona koniecznością – kosztem utraty niektórych funkcji z zakresu oszczędzania energii, a także wolniejszego HyperTransportu, będzie ich można używać w już posiadanych płytach głównych z podstawką Socket AM2. Zgodność jest zresztą dwustronna – do płyty z gniazdem Socket AM2+ można bez zahamowań zastosować dzisiejszego Athlona 64 X2."
   
   Za PClab.pl

   people can fly, anything
   can happen...
   ..Sunrise..

   1. i dla leni jeszcze jeden cytat: , Nazgul 15/05/07 17:02
      "Powołujemy się w niniejszym tekście na wyniki i oszacowania dostarczone przez AMD. Wielu Czytelników może więc postawić zarzut, że wyniki te są marketingowo zawyżone. Sam nie oparłbym się takiemu podejrzeniu, gdyby nie potwierdzenie ze strony... samego Intela. Korporacja sprawia wrażenie wyraźnie zaniepokojonej nadchodzącą konkurencją, chociaż pokłada duże nadzieje w Penrynie, który ponoć ma się rozprawić z K10."

      people can fly, anything
      can happen...
      ..Sunrise..

      1. dla leni mogles , malcolm_x 15/05/07 17:10
         po prostu podac linka do artykulu :-P
         1. leniu , Darek K. 15/05/07 20:24
            http://pclab.pl/images/mainreadall.gif

            Everything that has a beginning has an end

            1. upsss , Darek K. 15/05/07 20:25
               http://pclab.pl/art26386.html

               Everything that has a beginning has an end

1. pomysł NIE ISTNIAŁ , Master/Pentium 15/05/07 19:37
   to była zwykła plotka. Wspólczesna matematyka nie zna takiego sposobu (i raczej wątpliwe jest jego istnienie).

   Nie ma tego złego , co by się w gorsze
   obrócić nie mogło - jak nie wierzysz
   włącz komputer :-)

   1. jak nie , RusH 15/05/07 20:35
      tak wlasnie dziala P4 z wylaczonym HT, zamiast niby 2 rdzeni wykonuje jeden potok programu uzywajac jednostek wykonawczych normalnie dzielonych przez niby dwa rdzenie przy wlaczonym HT
      
      zreszta kazdy procesor obecnie ma co najmniej 2 potoki, skoro intel dzieli cache miedzy rdzenie i juz ma doswiadczenie z dzieleniem jednostek wykonawczych miedzy pseudo rdzeniami to wcale bym sie nie zdziwil gdyby i Penryn mial jakies dynamiczne przydzielanie zasobow.

      I fix shit
      http://raszpl.blogspot.com/

      1. ależ to nie to samo , Master/Pentium 15/05/07 21:20
         wiele jednostek wykonawczych związane jest w architekturą potokową. I owszem można to wykorzystać pod pewnymi warunkami związanymi z kodem żródłowym. Ale dwa rdzenie z definicji mają OSOBNE potoki wykonawcze.
         Albo inaczej: przy pomocy jednego rdzenia można symulowac wiele (choćby owe P4) ale na odwrót jak na razie nikt nie potrafi.
         Potrzebne są odpowiednie algorytmy, które najpierw trzeba opracować i zaimplementować.
         Owszem ludzki umysł potrafi przetwarzać zadania defakto szeregowe w sposób równoległy (bo inaczej sieć neuronowa nie działa) ale jak na razie ani tych algorytmów nie znamy a i zapewne mają one poteżne zapotrzebowanie na moc obliczeniową.

         Nie ma tego złego , co by się w gorsze
         obrócić nie mogło - jak nie wierzysz
         włącz komputer :-)

         1. no wlasnie potoki i OoO , RusH 15/05/07 22:40
            to te algorytmy, tz rozbijanie kodu wykonawczego na operacje, ktore mozna wykonac rownolegle, c2d np ma 3 128 bitowe jednostki SSE (dwie rownolegle) i moze w jednym cyklu cyknac 2 instrukcje sse jesli tylko ooo stwierdzi ze nie zaleza one od siebie, wystarczy ze intel rozszerzy to na reszte jednostek i cpu bedzie mogl dzielic wszystkie zasomy jak paskudny komunista

            I fix shit
            http://raszpl.blogspot.com/

            1. Producenci pewnie wolą zwalić robotę na programistów. , Rhobaak 15/05/07 22:54
               Zamiast optymalizować wykonanie pojedynczego wątku, wolą wymusić pisanie większości aplikacji jako wielowątkowych? :)

               Kor2dual3,2hZ overkloc,4Gbit Ram
               G-forc 460 gietex,barakudy
               Children of Neostrada Association MVP

            2. tyle, że we wspólczesnych aplikacjach ... , Master/Pentium 16/05/07 08:07
               te instrukcje często zależą od siebie (instrukcje warunkowe, skoku etc.)
               W istocie trzeba przepisać programy tak aby korzystały z wielu potoków tj. wielu rdzenii :) W innym wypadku mamy zysk jak przy HT to jest do około 30% a czasem ujemny :)

               Nie ma tego złego , co by się w gorsze
               obrócić nie mogło - jak nie wierzysz
               włącz komputer :-)

               1. instrukcje warunkowe, skoku , RusH 16/05/07 20:23
                  intel ma taki myk jak fusion costam, jest to wlasnie laczenie instrukcji, np warunkowa + skok w jedna :)
                  no i mi raczej chodzilo o odwrotne HT, czyli uzywanie jednostek wykonawczych innych rdzeni w celu przyspieszenia jednego

                  I fix shit
                  http://raszpl.blogspot.com/

                  1. To połącz i wykonaj takie cuś ... , Master/Pentium 16/05/07 20:50
                     a+b=c
                     b*c=d
                     Oczywiście jednocześnie na dwóch rdzeniach.
                     Oczywiście to tylko przykład. Chodzi o instrukcje zależne od siebie. Tzn musisz wykonać jedną aby móc wykonać następną.
                     Co do połączenia instrukcji warunkowych i skoku to ich połączenie jest logiczne i matematycznie sensowne (czy masz if i jump razem czy osobno to nie zmienia sensu matematycznego). Ale teraz wykonaj takie coś w dwóch osobnych potokach (2 rdzenie).
                     Może inaczej. Problemem nie jest łączenie instrukcji a ich rozdzielenia na dwa NIEZALEŻNE potoki. Hipotetyczny odwrotny HT właśnie na tym polega. A z tego co wiem to nawet matematycy nie mają pojęcia jak to zrobić.

                     Nie ma tego złego , co by się w gorsze
                     obrócić nie mogło - jak nie wierzysz
                     włącz komputer :-)

                     1. tego , RusH 17/05/07 07:41
                        rece mi opadly, myslalem ze rozmawiamy o procesorach x86, ich instrukcjach i ewentualnie microopach, a ty wyskakujesz z dziwnym pseudokodem
                        moze zacznij od tego
                        http://www.azillionmonkeys.com/qed/cpuwar.html
                        
                        a teraz przyklad zeby bylo prosciej, quake
                        
                        C(VGA_UpdateLinearScreen):
                        pushl %ebp // preserve caller's stack frame
                        pushl %edi
                        pushl %esi // preserve register variables
                        pushl %ebx
                        
                        cld
                        movl srcptr(%esp),%esi
                        movl destptr(%esp),%edi
                        movl width(%esp),%ebx
                        movl srcrowbytes(%esp),%eax
                        subl %ebx,%eax
                        movl destrowbytes(%esp),%edx
                        subl %ebx,%edx
                        shrl $2,%ebx
                        movl height(%esp),%ebp
                        LLRowLoop:
                        movl %ebx,%ecx
                        rep/movsl (%esi),(%edi)
                        addl %eax,%esi
                        addl %edx,%edi
                        decl %ebp
                        jnz LLRowLoop
                        
                        popl %ebx // restore register variables
                        popl %esi
                        popl %edi
                        popl %ebp // restore the caller's stack frame
                        
                        ret
                        
                        teraz popatrz na ten kod i pomysl w ilu miejscach 4 rdzenie moglyby jednoczesnie wykonywac ten jednowatkowy kod ...
                        swoja droga po kiedo wala movl %ebx,%ecx siedzi w srodku lopa to ja nie mam pojecia, no ale ja sie karmak nie nazywam :)
                        
                        
                        propo piszac o fusion intela mialem na mysli cos takiego
                        decl %ebp
                        jnz LLRowLoop
                        intel w core potrafi zrobic z tego jednego macro-opa , nazwijmy go sobie decljnz %ebp, LLRowLoop

                        I fix shit
                        http://raszpl.blogspot.com/

                        1. rzeczywiście wygląda na całkiem podzielny , Master/Pentium 17/05/07 07:58
                           ale zrób to maszynowo. Zapewnij także wzajemną synchronizację wątków. Wiem, że człowiek potrafi rozbijać zadania szeregowe (patrz poprzednie posty) ale tutaj masz maszynę.
                           Ciekawe czy cały kod jest tak podzielny ;)
                           O ile pamiętam istnieje wersja SMP Quake ale nie daje ona istotnego wzrostu wydajności.
                           Co do pseudokodu to podałem go dlatego, że miał obrazować samą ideę problemu. W asemblerze będą to instrukcje korzystające z tych samych rejestrów, danych etc. Idea jest ta sama - tzn. aby wykonać krok b musisz znać wyniki kroku a itp.
                           
                           Dlatego puki nie zobaczę działających implementacji RHT lub chociaż dobrych matematycznych podstaw takowej implementacji puty ja to między bajki włożę.
                           
                           PS. W firmach zajmujących się CPU napewno niejedna głowa nad tym siedziała i jak na razie bez efektu. Ale jeśli masz pojęcie jak to zrobić to próbuj. I nie mówię tego żlośliwie.

                           Nie ma tego złego , co by się w gorsze
                           obrócić nie mogło - jak nie wierzysz
                           włącz komputer :-)

                           1. przeciez patrzysz na to , RusH 17/05/07 09:42
                              LLRowLoop:
                              movl %ebx,%ecx
                              rep/movsl (%esi),(%edi)
                              addl %eax,%esi
                              addl %edx,%edi
                              decl %ebp
                              jnz LLRowLoop
                              
                              to jest glowny loop, wykonuje sie ilesset (ebp=wysokosc ekranu) razy za kazdym razem kopiujac ilesset/tysiecy bajtow (ecx *4=szerokosc, bo movsl przenosi slowa)
                              
                              
                              rep/movsl (%esi),(%edi)
                              to mozna CUDOWNIE rozbic na 4 rdzenie, te dwie instrukcje (rep/movsl) kopiuja ecx bajtow z adresu pod esi do edi, wystarczy podzielic ecx na 4 i kazac kazdemu rdzeniowi skopiowac cwiartke = masz szyste czterokrotne przyspieszenie = kod jednowatkowy a skaluje sie liniowo na 4 rdzeniowym cpu. W prawdziwym cpu movsl jest rozbijane na microopy riscowe i wykonywane przez Load/Store units, niestety obecnie cpu maja ich malo, nawet Core ma tylko po jednej
                              
                              
                              >ale zrób to maszynowo. Zapewnij także wzajemną synchronizację wątków. Wiem,
                              >że człowiek potrafi rozbijać zadania szeregowe (patrz poprzednie posty) ale tutaj
                              >masz maszynę.
                              
                              masz zerowe pojecie o elektronice :(, wedlug tego co wlasnie napisales zwierzeta takie jak VHDL nie maja prawa istniec bo maszyna to nie czlowiek :). Jaka synchronizacja? rozbijasz zadania do jednostek wykonawczych i jazda, komputer, a co za tym idzie procesor to maszyna stanow skonczonych, w cpu NIE MA niewiadomych, kazdy cykl jest wziety pod uwage
                              
                              To o czym jak od poczatku pisze to superskalarnosc na sterydach, to o czym od poczatku pisze JEST W PROCESORACH od pierwszego PentiumPRO, ja tylko chce aby rdzenie mogly dzielic sie swoimi jednostkami wykonaczymi, zeby np 2 rdzeniowy Core2Duo mogl sam zdecydowac ze ma doczynienia z jednowatkowym kodem i wykastrowac jeden rdzen z dekoderow i jednostek wykonawczych pozwalajac drugiemu wykonac >5 rozkazow w cyklu (teoretyczny obecny limit core, 4 dekodery + macrofusion)
                              Gdyby core potrafil sie dzielic, i np potrafil zdlawic jeden rdzen do jednego dekodera ALU iAGU, za to wzmacniajac drugi o 3 dekodery, 2ALU i jeden AGU (plus moze jakis szeduler dla load/store) to 'podstawowy rdzen' moglby wykonac do 8 instrukcji w jednym cyklu, 150% wzrostu wydajnosci pracy jednowatkowej bez podbijania zegara, tylko optymalizacja OoO i reorganizacja polaczen niedzy rdzeniami

                              I fix shit
                              http://raszpl.blogspot.com/

                              1. ty robisz CPU czy sztuczny mózg ? :) , Master/Pentium 17/05/07 21:50
                                 Chcesz aby CPU dynamicznie zarządzało swoją strukturą. Zupełnie tak jak mózg. :D Elekroniki logicznej byłoby kilka razy więcej (lub więcej) niż ALU i FPU jak nie więcej. Do tego kwestia wydajności połączeń pomiędzy cache poszczególnych rdzeni.
                                 IHMO przy obecnym stanie techniki nie da się tego zrealizować.
                                 A teraz lecimy z argumentami:
                                 - rozbijanie a synchronizacja: rozbite instrukcje nie wykonają się w tym samym czasie na poszczególnych rdzeniach (to nie RISC tylko ułomny CISC)
                                 - nadal powtarzam kwestie zależności instrukcji. Że dana pętla da się rozbić to pikuś. Rzeczywisty program jest zdecydowanie dłuższy. Pozatym kwestia skoków warunkowych (słabość P 4). W cześci kodu dasz radę rozbić maszynowo, w cześci nie. Oczywiście pewne programy da się łatwo rozbić na wiele wątków inne już nie (nadal nie napisano DOBREGO algorytmu SMP dla kodowanie mp3)
                                 
                                 Co ma VHDL ( http://pl.wikipedia.org/wiki/VHDL ?) do naszego zagadnienia? O ile dobrze kojarzę to środowisko to symuluje operacje równoległe na "szeregowym" CPU. Ale to nic niezwykłego. Chyba, że potrafi odwrotnie to co innego ;)
                                 
                                 PS. O ile cię dobrze rozumiem marzy ci się CPU amorficzny płynnie, dynamicznie (itp.) adaptujący się do wykonywanego kodu. To pieśń przyszłości i to raczej nie tej z 2008 roku :)

                                 Nie ma tego złego , co by się w gorsze
                                 obrócić nie mogło - jak nie wierzysz
                                 włącz komputer :-)

                                 1. niom, pustynia elektroniczna , RusH 18/05/07 04:22
                                    Ty jestes polonista czy cos? :P
                                    
                                    Juz PPro mial podwojny dekoder i mogl wykonywac 2 instrukcje jednoczesnie, niezaleznie ile cykli zajmowaly.
                                    Core2Duo ma WSPOLNY cache dla obu rdzeni, wisi on na crossbarze. Co w dzieleniu zasobow jest takiego trudnego dla ciebie do zrozumienia? Wiesz ze KAZDY 2 rdzeniowy procesor dzieli JEDEN kontroler pamieci? wedlug twoich wczesniejszych 'pomyslow' to nie powinno dzialac bo 'wzajemną synchronizację wątków' i tego typu kwiatki :/
                                    
                                    
                                    >- rozbijanie a synchronizacja: rozbite instrukcje nie wykonają się w tym samym
                                    >czasie na poszczególnych rdzeniach (to nie RISC tylko ułomny CISC)
                                    
                                    lol, dalem ci link zebys sie podciagnal, Wszystkie cpu x86 od PPro sa w srodku RISCowe, instrukcje x86 sa rozbijane przez dekoder na microopy RISCowe, nastepnie te mikroopy trafiaja do jednostek wykonawczych w paczkach po x sztuk do wykonania rownolegle (myslisz ze po co A64 ma 3 jednostki ALU? dla jajec?)
                                    
                                    >- nadal powtarzam kwestie zależności instrukcji. Że dana pętla da się rozbić to
                                    >pikuś. Rzeczywisty program jest zdecydowanie dłuższy.
                                    
                                    wkleilem ci kod rzeczywistego programu, praktycznie 90% mozna wykonywac w skokach po 4 instrukcje na raz
                                    
                                    >Pozatym kwestia skoków warunkowych (słabość P 4).
                                    
                                    slabosc P4 z powodu dlugiego pipeline i slabej predykcji skokow, cos nie tak i 20 zdekodowanych instrukcji w dupe = 20 razy X cykli w dupe. Pipeline to taki bufor do ktorego procesor laduje zdekodowane juz RISCowe microopy aby je potem wykonac.
                                    Im dluzszy tym wiecej microopow CPU moze wykonywac NA RAZ (JEDNOCZESNIE, tak, tutaj dziala magiczna synchronizacja), jesli jednak okaze sie ze cpu nie zgadl, badz kod na zywca zmodyfikowal jakas dana/adres/skok to trzeba wyczyscic pipeline i zaladowac od nowa, jesli jednak zgadnie to caly cpu mieli pipeline z pelna predkoscia i jest milo i szybko jak w zoptymalizowanych pod P4 benchmarkach.
                                    
                                    
                                    > W cześci kodu dasz radę
                                    >rozbić maszynowo, w cześci nie.
                                    
                                    a w czesci tylko doskonaly umysl sobie poradzi? :))) ty moze zacznij rozbijac 'niemaszynowo' RSA w pamieci :)
                                    
                                    > Oczywiście pewne programy da się łatwo rozbić na wiele wątków inne już nie
                                    >(nadal nie napisano DOBREGO algorytmu SMP dla kodowanie mp3)
                                    
                                    nitk tu nie pisze o SMP, nikt tu nawet nie pisze o SMT, widze ze nawet nie wiesz o czym ja pisze (o wykorzystaniu zasobow wielordzeniowego procesora do zwiekszenia IPC POJEDYNCZEGO rdzenia,czyli calkowita odwrotnosc SMT)
                                    
                                    >Co ma VHDL ( http://pl.wikipedia.org/wiki/VHDL ?) do naszego zagadnienia? O ile
                                    >dobrze kojarzę to środowisko to symuluje operacje równoległe na "szeregowym"
                                    >CPU. Ale to nic niezwykłego. Chyba, że potrafi odwrotnie to co innego ;)
                                    
                                    to jest jezyk programowania pozwalajacy ogarnac w miare przystepny sposob programowanie rownolegle, procesor to NIE JEST maszyna turinga jak ci sie moze wydawac, procesor to wiele klockow wykonujacych wiele zadan rownolegle, wzajemnie magicznie (jak ci sie pewnie wydaje) ze soba zsynchronizowanych
                                    
                                    >PS. O ile cię dobrze rozumiem marzy ci się CPU amorficzny płynnie, dynamicznie
                                    >(itp.) adaptujący się do wykonywanego kodu. To pieśń przyszłości i to raczej nie
                                    >tej z 2008 roku :)
                                    
                                    nie, to transmeta z przed 5 lat (cpu z programowalnym dekoderem instrukcji), czy ARM996HS z przed roku (cpu kompletnie bez zegara systemowego, instrukcjie wykonuja sie wtedy, gdy sa gotowe, nie wtedy gdy tyka zegar)

                                    I fix shit
                                    http://raszpl.blogspot.com/

                                    1. nie, jestem po politechnice (elektronika/informatyka) , Master/Pentium 18/05/07 14:47
                                       Jak jesteś taki sprytny to zaprojektuj taki CPU. Do tego ma być tani i energooszczędny. :D
                                       
                                       Co do Transmety to jej wydajność była niska. Aczkowiek sam pomysł (wewnętrzna emulacja . Przypomina mi to historię Kyro (akcelatory 3D).
                                       Procki bez taktowania to też pieśń przyszłości, wielkie możliwości i równie wielkie problemy konstrukcyjne. Juz od conajmniej dwóch lat słyszę zapowiedzi ale egzemplarzy testowych nie widać.
                                       Czy przełącznik krzyżowy działa do L1 czy L2 ? Bo mi się zdaje, że do L2 (wyższe opóżnienia). A potrzebjesz takiego z wydajnością L1 lub lepszego. Na dodatek obsługującego swobodnie tak z osiem jednostek wykonawczych.
                                       Co łamania RSA niemaszynowo. Wypaczasz sens. Sensem było to, że rozumiąć kod (i intencję tego kodu) jesteś w stanie go optymalnie rozdzielić/przekształcić. Maszyny jak na razie są daleko od tego. To mimo wszystko nadal głównie maszyna Turinga. Oczywiście, że człowiek powoli interpretuje kod maszynowy. Pomiędzy siecią neuronową i naszą świadomością jest wiele (nawet nie bardzo wiadomo jak wiele) poziomów translacji/wirtualizacji/nie wiadomo czego :). Ale jakby udało się przetłumaczyć to RSA na poziomie sieci neuronalnej to kto wie :). Aha - wiem że sięć neuronowa nie umie dodać 2 do 2 (tzn wynik to ok. 4 a nie 4)..
                                       
                                       W skrócie: Ja nie neguję możliwości skontruowania CPU adaptacyjnych. Ale w najbliższym czasie. Zaś na klasycznych 2/4 rdzeniach nie znamy algorytmu, który na WSPÓŁCZESNYM sprzęcie umiałbym wykonać jeden wątek w dwóch wątkach :)
                                       
                                       I na tym konczę. Możemy się długo przekonywać, pokazywać kontrprzykłady itp. Ja nie stworzę CPU ty pewnie też (a może się mylę). Poczekamy na lepszych (i bogatszych) od nas. Jak w ciągu 2-3 lat pojawi się funkcjonalny RHT to przyznam się do niewiedzy, pomyłki itp. i przyznam ci rację. Na razie zostają przy swoim. Wolno mi :D.

                                       Nie ma tego złego , co by się w gorsze
                                       obrócić nie mogło - jak nie wierzysz
                                       włącz komputer :-)

I fix shit
http://raszpl.blogspot.com/

1. nie żartuję , Master/Pentium 18/05/07 22:39
   poczekamy kilka lat to dowiemy sie kto miał rację.
   Co ma OpenMP czy inne języki uławiające paralizację procesów do tego zagadnienia? Wielowątkowy program można na upartego napisać w większości języków. Co z tego jak ktoś musi to zrobić ;).
   Bo jakoś zalewu aplikacji wielowątkowych nie widziałem, a mówi się o tym od lat conajmniej 15 (a pewnie i więcej ale nie uważałem na historii :D).
   Ty chcesz aby wielordzeniowy CPU wykonał jednowątkowy program w wielu potokach jednocześnie. Ja mówię, że przy obecnej technologii to niemożliwe. Nie twierdzę, że nie jest możliwe w technologii przyszłości (do pewnych granic wyznaczonych algorytmem). Ale mówimy o prockach które możemy kupić w sklepie a nie swoich marzeniach ;). I mówimy o obecnych (już napisanych) programach. Tutaj wszelkie nowe języki (i rozszerzenia starszych) są nieistotne.
   
   A skoro juz odświeżamy wiadomości, że szkoły to polecam Prawo Amdahla przypominając , że we współczesnych algorytmach te kilka % nie da się w żadnym języku zrównoleglić (zmienne zależne, niektóre przypadki instrukcji warunkowych itp.)
   
   A i taka zabawna obserwacja. Oracle nie potrafi rozdzielić zadania JEDNEGO użytkownika (a raczej jednej jego operacji) na wiele CPU. Drugi rdzeń/CPU nudzi się w tym czasie a user czeka:). Przynajmniej w niektórych przypadkach (nie chciało mi się sprawdzać wszystkich operacji). Oczywiście drugi/kolejny user może zapychać kolejny rdzeń/CPU.
   A miałem cichą nadzieję na takie działanie :D
   
   Tak więc pozdrawiam w pokoju czekając na przełom w technologiach CPU :D.
   
   Moim zdaniem wystarczy - ja czekam na wyniki prac laboratoriów AMD/Intel'a i innych graczy.
   
   PS. Przepraszam za literówki. Muszę uważniej pisać.

   Nie ma tego złego , co by się w gorsze
   obrócić nie mogło - jak nie wierzysz
   włącz komputer :-)

I fix shit
http://raszpl.blogspot.com/

1. trzeba obadać, może się przydać , Master/Pentium 19/05/07 10:11
   szczególnie sprawdzić stopień automatyki. Dzięki za info.
   PS. Ile oprogramowania (nie mam na myśli projektów badawczych) w tym powstało? Coś znanego? Pytam z ciekawości.

   Nie ma tego złego , co by się w gorsze
   obrócić nie mogło - jak nie wierzysz
   włącz komputer :-)

   1. rzeczywiście ... , Master/Pentium 19/05/07 12:22
      od czasów studiów pewien postęp się dokonał :). Jednak 5 lat to sporo czasu w IT. Nie jest to co prawda rozwiązanie idealne (lista zastrzeżeń na wikipedii jest spora) i nierozwiązuje wszystkich standardowych problemów zrównoleglenia ale i tak jest sporym postępem.
      
      Wszystko cacy a programów wielowątkowych nadal jak na lekarstwo :(.

      Nie ma tego złego , co by się w gorsze
      obrócić nie mogło - jak nie wierzysz
      włącz komputer :-)

2. a i jest drobna różnica ... , Master/Pentium 19/05/07 10:14
   pomiędzy zrównolegleniem programu w kompilatorze (miliardy cykli CPU i więcej do dyspozycji) a zrobieniem tego w CPU (kilka taktów CPU do dyspozycji).
   Ale to tak na marginesie.

   Nie ma tego złego , co by się w gorsze
   obrócić nie mogło - jak nie wierzysz
   włącz komputer :-)