Distributed.net prowadzi różnego rodzaju konkursy (RC5, OGR, CSC, DES). Ludzie z całego świata zapewne z nudów oraz z chęci rywalizacji coś tam próbują odszyfrować, szukają jakiś liczb, ogólnie mało ciekawe. Przy okazji udostępnione do celów konkursowych oprogramowanie zaczęto wykorzystywać w charakterze benchmarków, a to już jest ciekawsze.
Dodano: 2003-02-23 00:00, Autor: kb, Kategoria: Sprzęt, Liczba wyświetleń: 4211
Potestowali AmigaOne na OGR
W tym miejscu dochodzimy do AmigaOne. Konkurs OGR i jak sprawdza się AmigaOne na tle komputerów z x86.
AmigaOne G4/800 MHz (bez AltiVeca, z pamięcią L3)
OGR: using core #0 (GARSP 5.13 PPC-scalar).
OGR: Benchmark for core #0 (GARSP 5.13 PPC-scalar)
0.00:00:16.83 [9,576,566 nodes/sec]
Pentium 4/2.4 GHz
OGR: using core #0 (GARSP 5.13-A).
OGR: Benchmark for core #0 (GARSP 5.13-A)
0.00:00:16.71 [9,122,232 nodes/sec]
AmigaOne SE G3/600 MHz
OGR: using core #0 (GARSP 5.13 PPC-scalar).
OGR: Benchmark for core #0 (GARSP 5.13 PPC-scalar)
0.00:00:16.55 [7,120,713 nodes/sec]
AmigaOne SE G3 (przetaktowane z 600 na 733 MHz)
OGR: using core #0 (GARSP 5.13 PPC-scalar).
OGR: Benchmark for core #0 (GARSP 5.13 PPC-scalar)
0.00:00:16.78 [8,680,916 nodes/sec]
Athlon XP 1800+
OGR: using core #1 (GARSP 5.13-B).
OGR: Benchmark for core #1 (GARSP 5.13-B)
0.00:00:16.71 [11,750,304 nodes/sec]
-
Daniel Sternik
Czytelnik
-
komentarz #1 wysłany: brak daty
Cakiem ciekawe wyniki... Drobna uwaga techniczna: troche zbyt mala czcionka zostaly podane wyniki na tej stronie.
-
MandiATO
konto zablokowane
lub usunięte
Czytelnik
-
komentarz #2 wysłany: brak daty w odpowiedzi na komentarz #1
Daniel, czcionka jest w porządku, po prostu w przeglądarce masz za małe czcionki ustawione dla czcionek o stałej szerokości (nieproporcjonalnych). To taki mały off-topic
-
Konrad Mruk
Czytelnik
-
komentarz #3 wysłany: brak daty
oczywiście też ludzie fascynują się wynikami poczszególnych grup, anyway, jeśli kogoś to bawi to daję przepis na fakowanie wyników w OGR, 1.skopiować gdzieś plik buffout.ogr, 2.fetch/flush 3.przegrać zabezpieczony buffout.ogr z powrotem na swoje miejsce w dirze dnet 4. GOTO 2
-
Michał Podgórski
Czytelnik
-
komentarz #4 wysłany: brak daty
A zna ktos wyniki jakie uzyskal pegaz ??
-
Kornel Lesinski
Czytelnik
-
komentarz #5 wysłany: brak daty w odpowiedzi na komentarz #1
u mnie jest ok (czcionka wyglada na przecietna..)
-
Kornel Lesinski
Czytelnik
-
komentarz #6 wysłany: brak daty w odpowiedzi na komentarz #3
1. rozprzestrzenic dnet po wszystkich mozliwych kawiarenkach internetowych, szkolach itp.
-
Rafał Sańda
Czytelnik
-
komentarz #7 wysłany: brak daty w odpowiedzi na komentarz #4
Tak. 7,926,217 nodes/sec na PegasosG3/600.
Czyli w tego klienta OGR, Pegaz jest o ponad 11% szybszy od A1.
-
MDW
Czytelnik
-
komentarz #8 wysłany: brak daty
Nie znam sie zupelnie wiec prosze od razu mnie nie mieszac z blotem jak cos glupiego palne. Dlaczego ten Pentium 4 pomimo tyyyyylu megahertzow tak stosunkowo biednie wypada? Toz to zalosnie wrecz wyglada jak przegrywa z G4 800 MHz.
-
Jacek Rzeuski
Czytelnik
-
komentarz #9 wysłany: brak daty w odpowiedzi na komentarz #8
Bo x86 mają za mało rejestrów i muszą non-stop ładować i zapisywać dane na stos. Co prawda dzięki pamięci cache działa to całkiem szybko, ale to dalej nie to co operacja na rejestrze.
-
Grzegorz Kraszewski
Czytelnik
-
komentarz #10 wysłany: brak daty w odpowiedzi na komentarz #7
Zauważę tu jeszcze jedną ciekawą rzecz wynikającą z tych wyników. Weźmy wynik G3/600 i G3/733 i ekstrapolujmy go aby otrzymać wydajność hipotetycznego G3 podkręconego o 200 MHz (do 800). Proste obliczenia dadzą wynik 9 466 882 nodes/s. G4/800 ma tutaj 9 576 566 nodes/s a więc jest zaledwie o 1% szybszy. Moim zdaniem potwierdza to, że układ ArticiaS w płycie Teron (zwanej też AmigaOne), swoimi błędami skutecznie uniemożliwia procesorowi G4 osiągnięcie pełnej wydajności. Naturalna więc jest decyzja Genesi o nowej płycie dla G4 (prawdopodobnie z chipsetem IBM). Jak widać samo wetknięcie szybszego procesora w slot nieprzystosowanej do niego płyty nic użytkownikowi nie daje. Ale za to dobrze wygląda w kolejnych newsach bez pokrycia. No i nie zapominajmy, że te testy są ciągle robione na Linuksie, podczas gdy Pegasos pozwala na uruchomienie klienta dnetc pod MorphOS-em. Kto chce niech czeka na OS4. Dla CyberStormów PPC miał być w grudniu 2002...
-
MDW
Czytelnik
-
komentarz #11 wysłany: brak daty w odpowiedzi na komentarz #9
Ptanie 1: Czy nie mozna zrobic wiecej rejestrow?
Pytanie 2: Czy te benchmarki robia test uzywajac tylko rejestrow czy sa to tez operacje z wykorzystaniem pamieci/stosu? Jezeli to pierwsze to niezbyt dobrze obrazuja predkosc praktyczna (taka dla zwyklego uzytkownika) tych sprzetow. W koncu ogromny procent operacji w programach to operacje na stosie/pamieci. Mam racje? A moze wyniki tutaj zapodane to jakas srednia z jednego i drugiego?
-
MDW
Czytelnik
-
komentarz #12 wysłany: brak daty w odpowiedzi na komentarz #10
Hohoho BARDZO sluszna uwaga. Ta pierwsza uwaga. Zreszta nastepna tez.
-
MDW
Czytelnik
-
komentarz #13 wysłany: brak daty w odpowiedzi na komentarz #10
Widze, ze "troche" odwrociles sie od OS4. Czy to oznacza, ze niedlugo bedzie Cie mozna zobaczyc po morphosowej stronie? Czy sprobujesz cos podzialac na MorphOSie jak zadziala na nim w koncu Picasso96 (bo Prometeusz chyba nie mialby z tym chyba zadnych problemow)?
-
Grzegorz Kraszewski
Czytelnik
-
komentarz #14 wysłany: brak daty w odpowiedzi na komentarz #8
Wynika to z faktu, że rdzenia Pentium III nie dało się puścić szybciej niż 900 - 1000 MHz. Pentium 4 ma rdzeń, który daje się potaktować znacznie szybciej, ale odbywa się to kosztem wydajności "z megaherca". No i te GHz są bardzo korzystne marketingowo. Ty też się zastanawiałeś jak to możliwe że coś 800 MHz jest szybsze od czegoś 2.4 GHz... Czyli technika działa.
-
Marcin Juszkiewicz
Czytelnik
-
komentarz #15 wysłany: brak daty w odpowiedzi na komentarz #14
Wynika to z faktu, że rdzenia Pentium III nie dało się puścić szybciej niż 900 - 1000 MHz.Intel zakończył rodzinę Pentium III na modelu 1.4GHz a nie 1GHz. Miałem okazję pracować na maszynce z takim prockiem.
-
MDW
Czytelnik
-
komentarz #16 wysłany: brak daty w odpowiedzi na komentarz #14
Ooo tak. Marketing rules. Cala ta gates-owa platforma to jeden wielki marketing.
-
michalsc
konto zablokowane
lub usunięte
Czytelnik
-
komentarz #17 wysłany: brak daty w odpowiedzi na komentarz #11
Ptanie 1: Czy nie mozna zrobic wiecej rejestrow?
Dodanie rejestrow ogolnego przeznaczenia wymagaloby zmiekszenia ilosci opkodow akceptowanych przez procesor (chodzi o tak zwany bajt MOD R/M czy jakos tak, za pomoca ktorego procesor dowiaduje sie o trybie adresowania i o uzywanych rejestrach). Dodawanie rejestrow za pomaca SSE czy MMX nie daje zbyt wiele, bo do poslugiwania sie nimi sluza osobne zestawy instrukcji.
Zwiekszenie ilosci rejestrow zmusilo by projektantow procesora do stworzenia kolejnego trybu pracy (obok dotychczasowego zgodnego z 8086, chronionego i wirtualnego 8086) w ktorym procesor interpretowalby nowe opkody i pozwalal na wykorzystanie nowych rejestrow. To pociaga za soba poprawki w systemach operacyjnych itd.
Ogolnie mowiac takie rozszerzenie byloby na tyle skomplikowane, ze odwazylo sie na nie dopiero AMD projektujac nowy procesor. Dodano 8 nowych rejestrow ogolnego przeznaczenia (co daje "imponujaca" ilosc - 16) i chyba 8 nowych rejestrow xmm (vide SSE). Niejako przy okazji calosc jest w pelni 64-bitowa.
Ciekawe jak toto zachowywalo by sie przy tych benchmarkach
-
michalsc
konto zablokowane
lub usunięte
Czytelnik
-
komentarz #18 wysłany: brak daty w odpowiedzi na komentarz #14
Nie zapominajmy jeszcze o zabezpieczeniu termicznym Pentiuma IV (opisane w dokumentacji), ktore spowalnia w razie potrzeby procesor tak, aby rdzen sie nie przegrzal.
-
MDW
Czytelnik
-
komentarz #19 wysłany: brak daty w odpowiedzi na komentarz #17
No tak. Jezeli taka operacja mialaby sie skonczyc czesciowa niekompatybilnoscia to zrowumiale, ze tego nie chca zrobic. Zreszta co za roznica czy 2.4GHz jest szybsze czy wolnijesze od 800MHz - wazne, ze w cenniku jest tansze i duzo ladniej wyglada. Marketing
-
MDW
Czytelnik
-
komentarz #20 wysłany: brak daty w odpowiedzi na komentarz #18
Nie zapominajmy jeszcze o zabezpieczeniu termicznym Pentiuma IV (opisane w dokumentacji), ktore spowalnia w razie potrzeby procesor tak, aby rdzen sie nie przegrzal.
To dlatego GaduGadu czasem zwalnia do predkosci w ktorej nie da sie go uzywac?
-
michalsc
konto zablokowane
lub usunięte
Czytelnik
-
komentarz #21 wysłany: brak daty w odpowiedzi na komentarz #20
Nie mam pojecia. Wiem za to, ze mozna wzglednie latwo odczytac wielkosc "spowolnienia" PentiumaIV (klaniaja sie znowu manuale* ), nie wiem tylko na ile uprzywilejowane sa instrukcje ktorymi mozna sie do tego dobrac. Ciekawie by bylo miec na stale wlaczony programik pokazujacy o ile wolniej od nominalnej predkosci dziala dzisiaj twoje PIV
(*) Intela mozna nie lubic, nienawidziec, nie trawic, ale trzeba im przyznac, ze dokumentacje pisza genialna
-
MDW
Czytelnik
-
komentarz #22 wysłany: brak daty w odpowiedzi na komentarz #21
Intela mozna nie lubic, nienawidziec, nie trawic, ale trzeba im przyznac, ze dokumentacje pisza genialna
No tak, tylko trzeba miec jeszcze cos pod czaszka zeby umiec to przeczytac i zrozumiec.
-
Radov
Redaktor
-
komentarz #23 wysłany: brak daty w odpowiedzi na komentarz #22
A propo zwiększenia liczby rejestrów: wyobraźcie sobie procesor jako punkt w środku kuli, pamięć jako objętość kuli. Im więcej pamięci tym dłuższy czas dostępu - promień kuli. Tak to mniej więcej wynika. Nie można powiedzieć, że więcej rejestrów to lepiej. Bo są one wolniejsze. Większą rolę odgrywa różnicza pomiędzy technologią RISC(PPC) i CISC(x86). Ogólnie przy obecnej wydajności pamięci poszczególne poziomy powinny być nie większe niż: rejestry 1KB L1 64KB L2 2MB L3 16MB RAM 3GB W przypaku RAMU i L3 spokojnie można 'sądować' granice objętości, ale rejestry oraz cash L1 i L2 napakowane go granic objętości (powyższe wielkości) mogą wydatnie spowolnić system.
-
Jacek Piszczek
Czytelnik
-
komentarz #24 wysłany: brak daty w odpowiedzi na komentarz #11
Pytanie 2:
To zależy już od kompilatora, jakim dany klient został na procesor/system przygotowany. Oczywiście dobry kompilator dobiera najkorzystniejsze dla danego procesora parametry pracy - dlatego też testy jak najbardziej można porównywać, w końcu to samo dzieje się z każdą inną aplikacją w przypadku kompilacji.
-
Krzysztof Twardy
Czytelnik
-
komentarz #25 wysłany: brak daty w odpowiedzi na komentarz #23
Musze przyznac, ze pierwszy raz od bardzo dawna tak ciekawie czytalo sie komentarze do newsa. Zamiast kolejnej wojenki rzeczowo, ciekawie, profesjonalnie! i na temat - tak 3mac
-
Mariusz Barczyk
Czytelnik
-
komentarz #26 wysłany: brak daty w odpowiedzi na komentarz #23
Czy jesteś pewien, że PPC jest w architekturze RISC ? Czytalem w jakimś guide'dzie, że 68k to RISC, a PPC to CISC. Popraw mnie jeśli się myle.
-
Radov
Redaktor
-
komentarz #27 wysłany: brak daty w odpowiedzi na komentarz #26
Przyznam się, że sam już nie byłem pewien, dawno już o tym nie czytałem. Ale to RISC. http://e-www.motorola.com/brdata/PDFDB/docs/G4WP.pdf Na piątej stronie, w którymś wierszu: MPC7400 RISC Microprocessor User’s Manual
-
Krzysztof Miłota
Czytelnik
-
komentarz #28 wysłany: brak daty w odpowiedzi na komentarz #26
PPC to RISC, a 680xx to CISC. Natomiast obecne procesory dla pecetów to jakieś mieszaniny (RICS z emulacją CISC), albo jeszcze coś innego.
-
MDW
Czytelnik
-
komentarz #29 wysłany: brak daty w odpowiedzi na komentarz #26
Czytalem w jakimś guide'dzie, że 68k to RISC, a PPC to CISC.
Jest tak jak mowisz z tym, ze dokladnie odwrotnie
-
Spili
Czytelnik
-
komentarz #30 wysłany: brak daty
No to świetna wiadomość, że Ami jest szybsza od pentaka! Szkoda tylko, że w tak popularnym i bardzo wciągającym zadaniu jak OGR.
Jak mi napiszą, że wyciąga więcej klatek w QuakeIII to się będę podniecał.
-
Radov
Redaktor
-
komentarz #31 wysłany: brak daty w odpowiedzi na komentarz #30
Wbrew pozorom to jest właśnie ta wiadomość na którą czekasz. Bo są to testy na moc obliczeniową procesora (czyli to co się używa w świecie 3d). Tak więc Quake3 na Amidze z G4 800 i Radeonem 9700 chodziłby podobnie jak na P4 2.4Ghz z Radeonem 9700. Inna sprawa, że w teście na kodowanie/dekodowanie np: MPEG4 nie byłoby już tak kolorowo. Ale to już wynika z bajki o RISCach.
-
MDW
Czytelnik
-
komentarz #32 wysłany: brak daty w odpowiedzi na komentarz #30
Badz spokojny - jak zrobia sterowniki 3D do praktycznie dowolnego Radeona to ten upragniony QuakeIII bedzie chodzil idealnie nie tylko na G4/800 ale i na G3/600.
-
Spili
Czytelnik
-
komentarz #33 wysłany: brak daty w odpowiedzi na komentarz #32
No to też właśnie. "Jak zrobią sterowniki" I taką miejmy nadzieję. Miejmy również nadzieję, że zrobią port QuakeIII i jeszcze parę innych.
-
MDW
Czytelnik
-
komentarz #34 wysłany: brak daty w odpowiedzi na komentarz #31
Bo są to testy na moc obliczeniową procesora (czyli to co się używa w świecie 3d).
Już dzisiaj nie. Teraz procek byle jakiś był. Całą resztę przejmuje akcelerator 3D. "Dzifors" nawet geometrię przejmuje. Procek zostaje tylko dla sztucznej inteligencji, kolizji, czy ewentualnych koderskich popisów na procesorze których w typowych engine'ach gier nie ma za wiele (to nie scenowe dema/intra). No może jeszcze parę zastosowań by się znalazło ale najbardziej "zamulające" elementy gry zostały przerzucone na akcelerator. Noooo chyba, że ktoś włączy renderer softwareowy (hi PorneL). Wtedy to taaaak. Wtedy to procek aż się gotuje...
-
Radov
Redaktor
-
komentarz #35 wysłany: brak daty w odpowiedzi na komentarz #34
I właśnie z tą myślą wpisałem te Radeony. Swoją drogą interesują mnie amigowe sterowniki 3D. Na pieca wchodzi directx9. Ciekawe co 'warp5 nova' (czy jak mu tam) będzie z tego mieć. Tzn: jak bardzo aktualne wynalazki w tym umieszczą (vide znieczyszczanie cząsteczkowe.... ...odkurzanie dywanów, mycie okien..). Zresztą przy obecnych akceleratorach wąskim gardłem staje się maksymalna rozdziałka monitora
-
Sebastian Jędruszkiewicz
Czytelnik
-
komentarz #36 wysłany: brak daty w odpowiedzi na komentarz #31
Inna sprawa, że w teście na kodowanie/dekodowanie np: MPEG4 nie byłoby już tak kolorowo. Ale to już wynika z bajki o RISCach.
??? Objasnij prosze. Chce znac te bajke.
-
Kornel Lesinski
Czytelnik
-
komentarz #37 wysłany: brak daty w odpowiedzi na komentarz #36
ja tez bym chcial poznac ta bajke. szczegolnie ze ppc maja *bajeczny* altivec
-
MDW
Czytelnik
-
komentarz #38 wysłany: brak daty w odpowiedzi na komentarz #35
I właśnie z tą myślą wpisałem te Radeony.
Aaaa to miales na mysli. Ja mysle, ze jezeli nie bedzie sterownikow to i tak zadna gra 3D nie powstanie (czy to od poczatu czy port). Nie robmy jaj - sterowniki 3D musza byc i beda na pewno.
Ciekawe co 'warp5 nova' (czy jak mu tam) będzie z tego mieć.
Friedenowie strasznie sie chwala tym nowym Warpem. Podobno ma miec duuuzo wiecej niz to co mamy dzisiaj. Na pewno zawsze bedziemy w tej dziedzinie krok do tylu. Jezeli zawsze bedziemy o krok do tylu to i tak bedzie cudownie. Poza tym po drugiej stronie frontu tez chlopaki sie ostro zabrali za 3D. Pegasosowcy maja JUZ OpenGL akcelerowany (narazie sterowniki tylko dla Voodoo3).
przy obecnych akceleratorach wąskim gardłem staje się maksymalna rozdziałka monitora
Hehehehe to prawda. Smiesznie to brzmi ale faktycznie czasem tak bywa, ze w maksymalnych rozdzialkach cos chodzi bardzo dobrze. No nie wszystko, bo takie demo Doom3 to w 640x480 ma na moim najslabszym "dziforsie" od 0.5 do 4 fps. Ja jednak uwazam, ze wiecej niz 800x600 w grze 3D nie ma zupelnie sensu. Tego i tak nie widac. To co nas moze denerwowac czasem to male tekstury popakowane bezlitosnie JPEGiem (brrr). Sama rozdzelczosc ekranu nie wplywa jakos znaczaco na wyglad gry. No, oczywiscie jezeli to nie jest 320x240.
-
Radov
Redaktor
-
komentarz #39 wysłany: brak daty w odpowiedzi na komentarz #37
Bajka jest dluga, a poza tym skrobie ze szkoly i nie mam polskich literek. Od czego by tu zaczac... W latach 70 (pod koniec) bylo tak: -kilkanascie(dziesiat) formatow instrukcji w procku -dlugosc instrukcji dochodzi do kilkudziesieciu bajtow -czas wykonania instrukcji 4-28 taktow -wiecznie za malo mocy I dlatego wymyslono RISCi: -najwyzej kilka formatow instrukcji -i to formatow stalo bajtowych (cztero bajtowych) -implementacja statystycznie najczesciej wykonywanych polecen -skorzystano z obu zboczy sygnalo (cos jak teraz DDRy) -i czas wykonania instrukcji wynosi praktycznie 1 takt Poza tym duzy rejestr, mozna ladowac wiele danych i operwac bez zmiany polecenia (tez plus) Ale sa wady. Trudniejsze tworzenie kompilatorow. Oraz: Dluzsze kody programow. Dlaczego? Instrukcja X zaimplementowana w CISCu odpowiada wykonaniu 10 instrukcji podstawowych. RISC ma tylko instrukcje podstawowe. Czyli w specjalistycznych zadaniach CISC korzysta z gotowego polecania, RISC musi robic wszystko dookola. W niekktorych zastosowanich moze zajsc potzrzeba akcelerowania niektorych operacji. Tworzy sie instrukcje kompleksowe, ktore odwalaja mase roboty. CISCi maja ich mase, a RISCi wprost przeciwnie. Przyklad? W MMX jest cos takiego. Instrukcja dziala tak: wektor ABCD zamienia na BADC i przesuwa bity o jeden w lewo. Podobno bardzo przydatne przy kodowaniu obrazu. Ale przecietny uzytkownik RISCa nie zauwazy jej braku, roznica zedu ulamka sekundy. Chyba ze zrobi test PPC vs P4 w tescie na kodowanie obrazu. Tu P4 bedzie mial fory. I nie tylko tu. Pojawia sie tylko pytanie: po co robic uprzywilejowane polecenia, jesli roznica widoczna jest tylko w profesjonalnych zastosowaniach, przy ktorych stosuje sie karty przejmujace role tamtych funkcji. Pamietacie jeczenia ze wszystkie uklady A1200 sa zdublowane w trakcie rozbudowy kompa? (2 procki, 2 uklady graficzne? itd.) Taka sytuacja jest wlasnie w swiecie PC. CISC ma uprzywilejowanych wiele polecen, ktore sa dublowane przez polecenia kart graficznych i dzwiekowych. I tylko spowalnia caly system. (Dluzszy czas dostepu i nie tylko) Tak wiec: poza testami arytmetycznymi CISCi wypadna lepiej. Ale ujawnia swa moc w testach na zastosowania, do ktorych kupiles sobie karte graficzna itp. RISCI bardziej przypominaja jednostke, ktora ma stanowic srodowisko dla innych zasobow. To nie wszystko. Ale dam sobie spokoj. Poza danymi technicznymi wszystko jest tu potraktowane bardzo pobieznie i pewnie przeinterpretowane. wszelkie uwagi mile widziane.
-
Jacek Rzeuski
Czytelnik
-
komentarz #40 wysłany: brak daty w odpowiedzi na komentarz #39
Za dużo namieszałeś, żeby to prostować...
-
Jacek Cybularczyk
Czytelnik
-
komentarz #41 wysłany: brak daty w odpowiedzi na komentarz #39
Proponuje zajrzec tu a szczegolnie tu.
-
michalsc
konto zablokowane
lub usunięte
Czytelnik
-
komentarz #42 wysłany: brak daty w odpowiedzi na komentarz #39
Sugerujesz delikatnie, ze architektura RISC jest nieefektowna wzwyklych zastosowaniach, ze CISC z nia wygrywa. Strasznie namieszales w tym swoim wywodzie.
Obecnie wiekszosc nowych procesorow z rodzinki IA32 ma rdzen bedacy najnormalniejszym na swiecie procesorem RISC. Instrukcje sa tlumaczone w locie (o! niespodzianka. Najczesciej jednej instrukcji CISC odpowiada jedna instrukcja RISC. Skad wziales informacje o translacji jedna->dziesiec?), a dla rozkazow bardziej zlozonych procesor pobiera mikroprogramy z wlasnej pamieci ROM. Jak to wytlumaczysz? Spiskowa teoria dziejow?
Twoj wywod przypomina dyskusje zwolennikow technologii JIT, ktorzy czesto uwazaja ze ten sam program dla natywnego procesora moze dzialac wolniej niz na wirtualnym procesorze emulowanym z pomoca JIT na tej samej maszynie...
-
Stanisław Węsławski
Czytelnik
-
komentarz #43 wysłany: brak daty w odpowiedzi na komentarz #35
Co do DirectX9, to nie ma się co podniecać - podobno tylko jeden z najnowszych Radeonów potrafi coś z tym zrobić. Nawet 8.1 jest używane tylko przez kilka najnowszych kart graficznych. Wszyscy traktją komputery jako maszynki do gry w Quake'a. Mam pieca w pracy i w domu i oba wieszają mi się przy lada okazji - a używam głównie Corela i PhotoShopa. Software - to jest coś co chciałbym zobaczyć na nowej Amidze. Najlepiej zachowujący się jak Linux - tylko nie tak zawiły w obsłudze. Będzie to zanim całkiem stracę wzrok?
-
Radov
Redaktor
-
komentarz #44 wysłany: brak daty w odpowiedzi na komentarz #42
Od razu zaznaczam: nie jestem guru w technice komputerowej. Moja wiedza czerpie się głównie z wykładów w budzie. Proszę mnie poprawiać.
Sory, że tak namieszałem ale po 10h wykładów ciężko było zebrać myśli.
Po kolei: -wg. mnie to właśnie RISC jest efektywniejszy bo ma oszczędniejszą architekturę. To starałem się napisać.
-zgadzam się jeśli chodzi o rdzen IA32. Jeśli się nie mylę obecne x86 to wariacje na temat standardu RISC/2.
Ale za to: -Mikrorozkazy umieszczone w ROMie. Racja. Ale kod programu czytasz z RAMu. I tam masz zapisane co wykonac. I jeśli masz pokręcone formaty zapisu instrukcji mikroprogramu, może dojść do sytuacji, że przez 52 bajty sprawdzasz, czy to koniec adresu mikroprogramu, czy też jest coś więcej. (Tak ma ktoryś procek AMD)
-Jesli masz pokrecone formaty zapisu instrukcji zwiększa ci się powierzchnia rozdzielacza sterującego (układu sterującego prockiem). Pod koniec lat 80tych wielkość RS sięgała do 60 % całego układu.
-translacja 1-10: To był przykład. Chciałem napisać, że zdarzają się takie sytuacje, że jeden mikrorozkaz CISCa odwala tyle roboty co 10 lini kodu asemblera. RISCi takich instrukcji raczej nie mają. A to już wynika z idei, by nie umieszczać rozkazów, z których przeciętny użytkownik korzysta nie częściej niż raz w miesiącu.
-Poza mikrorozkazami skoków, czas wykonania ich na RISCu wynosi góra 2 takty. Na x86 dochodzi to do 28 taktów
-Instrukcja CISC odpowiada instrukcji RISC. Nie wiem czy dobrze Cię zrozumiałem, ale wg mnie tak nie jest. Racja: efekt wykonania będzie ten sam. Różnią się za to czasem wykonania w taktach zegarowych. A poza tym (to dane z wykładu) 65% instrukcji CISCowych po prostu nie ma odpowiednika w RISCU. I trzeba zastosować złożenie operacji by osiągnąc to samo.
Na temat JIT, wykonywania programu na wirtualnym procesorze i lotach kosmicznych nie wypowiadam się bo nie mam o tym zielonego pojęcia.
-
Władysław Czyżewski
Czytelnik
-
komentarz #45 wysłany: brak daty w odpowiedzi na komentarz #44
Może i masz rację, ale mnie to akurat nie wzrusza. Od roku korzystam z Amithlona i jestem bardzo zadowolony. Bardziej niż z najnowszych wynalazków z podwórka czysto amigowego... Wolę produkt jednego człowieka tyle, że prawie doskonały niż WIECZNE OBIETNICE. Amihtlon umarł, ale niebawem powstanie jego następca: UMILATOR. Wierzę w to. Na szczęście nie tylko ja jeden. P.S. Panowie z EXECa, czy przypadkiem nie przeoczyliście pewnych istotnych newsów? Czyżby ekipa EXECA uległa radykalnej zmianie?
-
Miloslaw Smyk
Czytelnik
-
komentarz #46 wysłany: brak daty w odpowiedzi na komentarz #42
Twoj wywod przypomina dyskusje zwolennikow technologii JIT, ktorzy czesto uwazaja ze ten sam program dla natywnego procesora moze dzialac wolniej niz na wirtualnym procesorze emulowanym z pomoca JIT na tej samej maszynie...Tu nie ma co uwazac. Wystarczy pomierzyc, zeby sie przekonac, ze to prawda. Mozna sie tez zastanowic, ale to juz rzadsza umiejetnosc.
-
michalsc
konto zablokowane
lub usunięte
Czytelnik
-
komentarz #47 wysłany: brak daty w odpowiedzi na komentarz #46
Tu nie ma co uwazac. Wystarczy pomierzyc, zeby sie przekonac, ze to prawda. Mozna sie tez zastanowic, ale to juz rzadsza umiejetnosc.
Ehm... odpowiedziales w dziwny sposob. Sugerujesz, ze program skompilowany na x86 i uruchomiony na nim, moze byc wolniejszy niz ten sam program skompilowany dla m68k i uruchomiony na emulatorze JIT na tej samej maszynie (x86)??? Bo twoja odpowiedz wlasnie cos takiego sugeruje....
-
Kornel Lesinski
Czytelnik
-
komentarz #48 wysłany: brak daty
jit nie ma szans byc szybsze niz natywny kod. w idealnych przypadkach moze najwyzej dorownac.
-
Miloslaw Smyk
Czytelnik
-
komentarz #49 wysłany: brak daty w odpowiedzi na komentarz #47
Ano sugeruje. Straszne, prawda?
-
Miloslaw Smyk
Czytelnik
-
komentarz #50 wysłany: brak daty w odpowiedzi na komentarz #48
A na jakiej podstawie tak Ci sie wydaje?
-
michalsc
konto zablokowane
lub usunięte
Czytelnik
-
komentarz #51 wysłany: brak daty w odpowiedzi na komentarz #49
Nie straszne, tylko glupie z twojej strony. Potrafisz przeprowadzic jakikolwiek zgodny z logika dowod potwierdzajacy slusznosc twojego rozumowania?
Jesli tak mocno trzymasz sie twojego przekonania, to powiedz mi dlaczego producenci procesorow nie wyposarzaja ich w na przyklad takie translatory: kod x86 za pomoca JIT tlumaczony jest na szybszy (wg ciebie) kod np. m68k, ktory z kolei ponownie za pomoca JIT tlumaczony jest na jeszcze szybszy (wg ciebie) kod x86... Zwielokrotnienie tego procesu daloby ultraszybkie procesory...
-
Miloslaw Smyk
Czytelnik
-
komentarz #52 wysłany: brak daty w odpowiedzi na komentarz #51
To co, porneL, wytlumaczysz koledze?
Aha, ten ostatni akapit to juz brednie, ale nie ja to powiedzia?em...
-
Kornel Lesinski
Czytelnik
-
komentarz #53 wysłany: brak daty w odpowiedzi na komentarz #52
mialem na mysli, ze dobrze zoptymalizowanego kodu pod dany procek zoptymalizowac bardziej sie nie da, a majstrowanie z JIT moze nawyzej spowolnic wszystko.
ale sprawa sie rozbija o "dobrze zoptymalizowany". zostalem uswiadomiony ze JIT moze wykonac profiling kodu i dzieki temu zoptymalizowac go jeszcze lepiej (pod konkretne srodowisko, a nawet dane na ktorych dziala) - tym ma przewage nad kompilatorem.
wynika z tego, ze jednak JIT [nie musi, ale] moze dzialac szybciej niz nietkniety kod...
- Discord
-
Online: 6
Cizar
Heng
IMPBot
juen
Laubzega
m...
- Menu
- Baza wiedzy
- Najpopularniejsze
