06.02.2016 18:16
[#211]
Re: RTG i Vampire 600 V2
@Hexmage960, post #193
Ja jestem zwolennikiem teorii, że oprogramowanie należy przyśpieszać, a nie wymieniać sprzęt na szybszy.J
Dobrze tylko niekiedy a najczęściej tak jest że się już nie da. Ile z mokrej ściery dasz rady wycisnąć ? Mimo że jest mokra i ją wykręcasz a z niej nawet kropla nie skapnie .Niestety są ograniczenia i sprzęt musi być szybszy .
06.02.2016 18:46
[#212]
Re: RTG i Vampire 600 V2
@djpiotrs, post #211
Sprzęt jest coraz szybszy dzięki postępowi technologicznemu i miniaturyzacji tranzystora.
Żeby przyśpieszyć programy trzeba je optymalizować i wynajdywać bardziej efektywne algorytmy. Obecnie tempo przyśpieszania sprzętu jest większe aniżeli produkcji nań oprogramowania. W tych warunkach nie ma możliwości wykorzystania potencjalnej mocy sprzętu. Sprzęt nie jest wykorzystany wystarczająco efektywnie. Amiga to nie jedyny przykład, choć dość szczególny, bo jest mało programistów piszących na Amigę. Ponadto zwykłe kompilowanie programów na dany sprzęt nie wystarczy, trzeba go pod ten sprzęt optymalizować.
Jesteśmy świadkami odwrócenia sytuacji sprzed wielu lat. W początkach informatyki programiści zadziwiali nas możliwościami sprzętu pisząc programy, które nie śniły się konstruktorom tego sprzętu. Dzisiaj stawiają oni coraz wyższe wymagania co do sprzętu, będąc zawiedzionym jego powolnością. Prawda jest taka, że sprzęt potrafi więcej niż śniło się programistom.
Żeby przyśpieszyć programy trzeba je optymalizować i wynajdywać bardziej efektywne algorytmy. Obecnie tempo przyśpieszania sprzętu jest większe aniżeli produkcji nań oprogramowania. W tych warunkach nie ma możliwości wykorzystania potencjalnej mocy sprzętu. Sprzęt nie jest wykorzystany wystarczająco efektywnie. Amiga to nie jedyny przykład, choć dość szczególny, bo jest mało programistów piszących na Amigę. Ponadto zwykłe kompilowanie programów na dany sprzęt nie wystarczy, trzeba go pod ten sprzęt optymalizować.
Jesteśmy świadkami odwrócenia sytuacji sprzed wielu lat. W początkach informatyki programiści zadziwiali nas możliwościami sprzętu pisząc programy, które nie śniły się konstruktorom tego sprzętu. Dzisiaj stawiają oni coraz wyższe wymagania co do sprzętu, będąc zawiedzionym jego powolnością. Prawda jest taka, że sprzęt potrafi więcej niż śniło się programistom.
06.02.2016 18:55
[#213]
Re: RTG i Vampire 600 V2
@sanjyuubi, post #210
aby wykorzystać fuzję instrukcji to musi być taka potrzeba w programie bo kompilator nie zmieni algorytmów, nie poprzestawia algorytmów aby wycisnąć ostatnie soki z procesora. Dobrym przykładem jest Itanium który w teorii wykonuje na raz wiele instrukcji a w praktyce wychodzi to tak sobie bo kompilator cudów nie zrobi. Możliwość wykonania jakichś tam niektórych połączonych instrukcji w okreslonych wypadkach w jednym cyklu jest fajna ale nie spodziewam się żadnych faktycznie widocznych zysków z rekompilacji programów. W Amidze nauczono nas że rekompilacja zawsze dużo daje ale to wynikało z ułomności coraz to kolejnych procesorów z rodziny 68K gdzie Motorola nie mogła poprostu trzymać się pewnego ISA i normalnie implementować wszystkie instrukcje tylko oszczędzali tranzystory kosztem wydajności i kompatybilności co powodowało że bez rekompilacji procesor musiał pewne instrukcje wykonywać przez wyrzucenie wyjątków. Tutaj zysk będzie minimalny.
Poza tym ta super wydajność 3x zegar to wynik Gunnarowego ściemiania. Porównuje jakieś niemozliwe przypadki zapominając że taki Pentium czy tam inne procesory też wykonują po kilka instrukcji na raz jak mają ku temu sprzyjające warunki. To wszystko to jedna wielka marketingowa gunnarowa ściema.
Po co w takie rzeczy wierzyć i potem się rozczarować?
Zapomiałeś co gadał o Natami?
Poza tym ta super wydajność 3x zegar to wynik Gunnarowego ściemiania. Porównuje jakieś niemozliwe przypadki zapominając że taki Pentium czy tam inne procesory też wykonują po kilka instrukcji na raz jak mają ku temu sprzyjające warunki. To wszystko to jedna wielka marketingowa gunnarowa ściema.
Po co w takie rzeczy wierzyć i potem się rozczarować?
Zapomiałeś co gadał o Natami?
06.02.2016 19:19
[#214]
Re: RTG i Vampire 600 V2
@XoR, post #213
Fuzje są dokonywane nie podczas kompilacji, a podczas samego wykonywania, albo jeszcze dokładniej już na etapie tłumaczenia (dwie instrukcje maszynowe są tłumaczone na mikroinstrukcje w ten sposób, że traktowane są jak jedna instrukcja maszynowa)
Itanium to specyficzny przypadek gdzie najwięcej zależy od kompilatora i sposobu pisania programu - to wynika z architektury EPIC (VLIW-like) gdzie masz właśnie bardzo długie słowa (128bitowe) które z kolei są wykonywane przez zestaw 4ALU 32bitowych. Procesor ten nie miał już nawet jak "zoptymalizować" otrzymanego kodu. To jak optymalizacja ułożenia TIRów na autostradzie gdy cały ruch to TIRy. Nie da się. W RISC i CISC procesor może ze swojej strony coś zrobić, bo w RISC TIRy rozdzielane są automatycznie na osobówki (1 mikroinstrukcja na instrukcję asm) i półciężarówki (2 mikroinstrukcje na instrukcję asm), a w CISC taką autostradą jedzie wszystko od motocykla (1uops) po Kamaza z 2 przyczepami (z tego co wiem w teorii nawet kilkanaście uops) ;) Czyli procesor może zoptymalizować "ruch na trasie" tak by wszystko wykonywało się względnie szybko. Wszystko co optymalizuje wykonanie istniejącego kodu bez potrzeby rekompilacji będzie działało ZAWSZE i zazwyczaj będzie przynosiło jakieś zyski. Wszystko co daje nowe rozkazy, nowe tryby wymaga ponownej kompilacji i będzie działać tylko wtedy gdy napisany program z tego skorzysta.
Itanium to specyficzny przypadek gdzie najwięcej zależy od kompilatora i sposobu pisania programu - to wynika z architektury EPIC (VLIW-like) gdzie masz właśnie bardzo długie słowa (128bitowe) które z kolei są wykonywane przez zestaw 4ALU 32bitowych. Procesor ten nie miał już nawet jak "zoptymalizować" otrzymanego kodu. To jak optymalizacja ułożenia TIRów na autostradzie gdy cały ruch to TIRy. Nie da się. W RISC i CISC procesor może ze swojej strony coś zrobić, bo w RISC TIRy rozdzielane są automatycznie na osobówki (1 mikroinstrukcja na instrukcję asm) i półciężarówki (2 mikroinstrukcje na instrukcję asm), a w CISC taką autostradą jedzie wszystko od motocykla (1uops) po Kamaza z 2 przyczepami (z tego co wiem w teorii nawet kilkanaście uops) ;) Czyli procesor może zoptymalizować "ruch na trasie" tak by wszystko wykonywało się względnie szybko. Wszystko co optymalizuje wykonanie istniejącego kodu bez potrzeby rekompilacji będzie działało ZAWSZE i zazwyczaj będzie przynosiło jakieś zyski. Wszystko co daje nowe rozkazy, nowe tryby wymaga ponownej kompilacji i będzie działać tylko wtedy gdy napisany program z tego skorzysta.
06.02.2016 20:11
[#215]
Re: RTG i Vampire 600 V2
@XoR, post #213
Ja akurat o Natami nie czytałem i się nie interesowałem, jedynie byłem ciekaw tego procesora, którego wyobrażałem sobie w różnych Amigach.
Kompilator może sobie poukładać instrukcje tak, aby wykonywały się 3 jednakowo, w zależności od tego czy np. ostatnia instrukcja wymaga np. wyniku z pierwszej czy nie. zapewne pomogą wstawki assemblerowe lub umiejętne pisanie programu tak aby wspomóc takim sytuacjom, ale ja akurat nie wierzę w ciągła wydajność na poziomie pentium 200.
Na razie tylko rozmyślamy, nie ma co się zapędzać z teoriami, póki ktoś nie dostanie tej karty do reki i nie zacznie kodować. wtedy Don_Adan będzie miał w reku narzędzie, które pozwoli mu zweryfikować swoje założenia.
Oczywiście przyznaję, że Gunnar robi kawał świetnej roboty, ze względu na to, że wyciągnął wymarłą rodzinę procesorów na nowy poziom i nie będzie trzeba wydawać 3000zł na jakąś kolekcjonerską kartę. Niektórzy jednak mogą potraktować narzekanie jako bezpośredni atak na Gunnara, podczas gdy tak naprawdę chodzi na ściągnięcie ludzi na ziemię, wielkie oczekiwania niosą za sobą równie wielkie rozczarowania.
Kompilator może sobie poukładać instrukcje tak, aby wykonywały się 3 jednakowo, w zależności od tego czy np. ostatnia instrukcja wymaga np. wyniku z pierwszej czy nie. zapewne pomogą wstawki assemblerowe lub umiejętne pisanie programu tak aby wspomóc takim sytuacjom, ale ja akurat nie wierzę w ciągła wydajność na poziomie pentium 200.
Na razie tylko rozmyślamy, nie ma co się zapędzać z teoriami, póki ktoś nie dostanie tej karty do reki i nie zacznie kodować. wtedy Don_Adan będzie miał w reku narzędzie, które pozwoli mu zweryfikować swoje założenia.
Oczywiście przyznaję, że Gunnar robi kawał świetnej roboty, ze względu na to, że wyciągnął wymarłą rodzinę procesorów na nowy poziom i nie będzie trzeba wydawać 3000zł na jakąś kolekcjonerską kartę. Niektórzy jednak mogą potraktować narzekanie jako bezpośredni atak na Gunnara, podczas gdy tak naprawdę chodzi na ściągnięcie ludzi na ziemię, wielkie oczekiwania niosą za sobą równie wielkie rozczarowania.
06.02.2016 22:49
[#218]
Re: RTG i Vampire 600 V2
@XoR, post #213
To masz tutaj realny benchmark wzgledem 68060, Apollo jest okolo 100% szybszy od 68060, przy tym samym taktowaniu, z poprawka na lepsza pamiec i wyzszy zegar. Jak masz wyniki dla PPC, o ile ADoom jest tez w wersji na PPC, to sobie porownaj.
Quote:
Originally Posted by matthey View Post
My CSMK3 68060@75MHz with 50ns memory only managed 7.9 fps on a RTG screen at 640x480x8 (unplayable). If you are getting 18.6 fps
i upgraded my core to 13x (92mhz),
adoom gives 20,5 fps with a screen of 640x480...
Quote:
Originally Posted by matthey View Post
My CSMK3 68060@75MHz with 50ns memory only managed 7.9 fps on a RTG screen at 640x480x8 (unplayable). If you are getting 18.6 fps
i upgraded my core to 13x (92mhz),
adoom gives 20,5 fps with a screen of 640x480...
06.02.2016 22:54
[#219]
Re: RTG i Vampire 600 V2
@pisklak, post #217
Można też jak najbardziej pytać o nowe rzeczy, najlepiej na przykładzie kodu.
To jest postawione na głowie, w ten sposób Gunnar nie zachęci żadnych programistów. W pełni popieram strima, porządnie zrobiona dokumentacja to podstawa. Nikt nie będzie sobie gitary zawracał łażeniem po ircach i wypytywaniem. Najlepiej byłoby zapoznać się z PDF-em Morotoli na temat CPU32 (to jest taka „uogólniona” definicja serii M68k) i opisać nowe instrukcje w identycznym, czy zbliżonym formacie.
Niemniej, jak nie ma dokumentacji, to nie ma. Można przecież używać istniejących narzędzi, kod dla 68020 czy nawet 68000 też się przecież szybko wykona.
To jest postawione na głowie, w ten sposób Gunnar nie zachęci żadnych programistów. W pełni popieram strima, porządnie zrobiona dokumentacja to podstawa. Nikt nie będzie sobie gitary zawracał łażeniem po ircach i wypytywaniem. Najlepiej byłoby zapoznać się z PDF-em Morotoli na temat CPU32 (to jest taka „uogólniona” definicja serii M68k) i opisać nowe instrukcje w identycznym, czy zbliżonym formacie.
Niemniej, jak nie ma dokumentacji, to nie ma. Można przecież używać istniejących narzędzi, kod dla 68020 czy nawet 68000 też się przecież szybko wykona.
06.02.2016 23:14
[#220]
Re: RTG i Vampire 600 V2
@Krashan, post #219
Z moich internetowych obserwacji wynika że nawet jak olejecie te wodotryski, to poprawny kod pod 020/030/040/060 bez FPU i MMU się wykona na rdzeniu Apollo. A widzę że jest szybko. Więc po co zaajmujecie sobie głowę dodatkowymi instrukcjami. Piszcie soft tradycyjnie jeśli nie chcecie się niczego uczyć. A taki kod zadziała i tak na Vampirku.
Jak ktoś poczuje "zew poznania nowego" to będzie eksperymentował z nowymi instrukcjami.
Pamiętam jak intel promował MMX a AMD - 3D NOW! Okazało się że prawie w ogóle nikt z tego nie korzystał. W intelu przełączanie się między jednostką CPU/FPU a MMX zabierało za dużo czasu i programiści woleli to omijać w inny sposób, przy wykorzystaniu np. jednostki zmiennoprzecinkowej która w intelu zawsze miała podwojony zegar i program szybciej się wykonywał.
Natomiast 64 bity w AMD czy EM64 w intelu to atrapa, sami twórcy o tym pisali że AMD się pośpieszyło i sposób zastosowania 64bitów w x86 nie jest dobry.
Moim zdaniem Gunnar powinien szybko nadrobić z tym FPU/MMU i wszyscy będą zadowoleni.
Jak ktoś poczuje "zew poznania nowego" to będzie eksperymentował z nowymi instrukcjami.
Pamiętam jak intel promował MMX a AMD - 3D NOW! Okazało się że prawie w ogóle nikt z tego nie korzystał. W intelu przełączanie się między jednostką CPU/FPU a MMX zabierało za dużo czasu i programiści woleli to omijać w inny sposób, przy wykorzystaniu np. jednostki zmiennoprzecinkowej która w intelu zawsze miała podwojony zegar i program szybciej się wykonywał.
Natomiast 64 bity w AMD czy EM64 w intelu to atrapa, sami twórcy o tym pisali że AMD się pośpieszyło i sposób zastosowania 64bitów w x86 nie jest dobry.
Moim zdaniem Gunnar powinien szybko nadrobić z tym FPU/MMU i wszyscy będą zadowoleni.
06.02.2016 23:23
[#221]
Re: RTG i Vampire 600 V2
@Krashan, post #219
No z ta dokumentacja to racja jest. Trzeba by ja zrobić. Problem polega na tym że Gunnar wciąż grzebie i udoskonala "zwykłe" rozkazy i nie ma czasu ani jak widać za bardzo chęci przyłożyć się do dokumentacji. No cóż będę nalegał żeby to zrobił ale pewnie jednak nieprędko to nastąpi.
Ale wciąż szukamy chętnego kodera do optymalizacji RIVY. Gdyby ktoś miał ochotę to zapraszamy.
Ale wciąż szukamy chętnego kodera do optymalizacji RIVY. Gdyby ktoś miał ochotę to zapraszamy.
06.02.2016 23:38
[#222]
Re: RTG i Vampire 600 V2
@pisklak, post #221
No dobra, moze oderwe sie od grania w Stilland War i pogadam z meynafem. Macie zrodla czy tylko zgode na modyfikacje? Jesli zrodla to to jest asembler, czy C, czy miks asemblera i C? Jesli asembler to jakim asemblerem byla riva asemblowana?
Ostatnia aktualizacja: 06.02.2016 23:38:43 przez Don_Adan
Ostatnia aktualizacja: 06.02.2016 23:38:43 przez Don_Adan
07.02.2016 09:32
[#226]
Re: RTG i Vampire 600 V2
@madman15, post #225
Racja.
No muszę przyznać że ta sytuacja z dokumentacją jest dla mnie dziwna i niezrozumiała również. No ale cóż nikt nie jest doskonały. A jeśli ktoś naprawdę jest zainteresowany to znajdzie potrzebne info. Mam nadzieję jednak że ta w bólach rodząca się współpraca pomiędzy koderami a Apollo-Team nabierze rumieńców i zdrowej atmosfery w niedalekiej przyszłości. Ja ze swojej strony dołożę wszelkich starań aby tak mogło się stać.
Chociaż rozumiem że sprawa dokumentacji kładzie się cieniem na zaufaniu do Gunnara pomimo działającej chyba nadspodziewanie dobrze Vampire....
No muszę przyznać że ta sytuacja z dokumentacją jest dla mnie dziwna i niezrozumiała również. No ale cóż nikt nie jest doskonały. A jeśli ktoś naprawdę jest zainteresowany to znajdzie potrzebne info. Mam nadzieję jednak że ta w bólach rodząca się współpraca pomiędzy koderami a Apollo-Team nabierze rumieńców i zdrowej atmosfery w niedalekiej przyszłości. Ja ze swojej strony dołożę wszelkich starań aby tak mogło się stać.
Chociaż rozumiem że sprawa dokumentacji kładzie się cieniem na zaufaniu do Gunnara pomimo działającej chyba nadspodziewanie dobrze Vampire....
07.02.2016 10:42
[#227]
Re: RTG i Vampire 600 V2
@pisklak, post #226
Chociaż jedna jaskółka wiosny nie czyni.... http://apollo-core.com/m68k/
07.02.2016 22:14
[#228]
Re: RTG i Vampire 600 V2
@XoR, post #213
Tutaj kolejna "sciema" Gunnara o wydajnosci PPC:
http://apollo-core.com/knowledge.php?b=2¬e=316&z=derD3e
http://apollo-core.com/knowledge.php?b=2¬e=316&z=derD3e
07.02.2016 22:33
[#229]
Re: RTG i Vampire 600 V2
@Don_Adan, post #228
Nie mylmy wydajności pamięci z wydajnością procka!!!
poza tym:
zaorane
Ostatnia aktualizacja: 07.02.2016 22:34:27 przez michal_zukowski
poza tym:
System:MorphOS/C> MemTest Allocated memory at 0x1D066CC0 -> 0x7F814F7F, 1652220608 bytes Writing 0x00000000... 1306 MB/sec. Verifying 0x00000000... 1726 MB/sec. Writing 0xFFFFFFFF... 1191 MB/sec. Verifying 0xFFFFFFFF... 1736 MB/sec. Memory is ok! System:MorphOS/C> MemTest ? VERBOSE/S,QUIET/S,DISABLE/S,EXTENSIVE/S,REVERSE/S,VMEM/S,PUBSCREEN,DELAY/N,LOOPS/N: disable Allocated memory at 0x1D066CC0 -> 0x7F814F7F, 1652220608 bytes Writing and Verifying 0x00000000... Write 1220 MB/sec. Verify 1782 MB/sec. Writing and Verifying 0xFFFFFFFF... Write 1220 MB/sec. Verify 1782 MB/sec. Memory is ok!
zaorane
Ostatnia aktualizacja: 07.02.2016 22:34:27 przez michal_zukowski
07.02.2016 22:48
[#230]
Re: RTG i Vampire 600 V2
@michal_zukowski, post #229
No przecież nikt nie neguje że PPC jest szybszy i ma szybszy dostęp do pamięci.
Jak na Amigę 600 to jest to naprawdę wielki krok do przodu.
Gunnar nie musi nic ściemniać, po co go próbujecie deklasować. I tak robi świetną robotę.
Jątrzenie to specjalizacja amiświatka...
Jak na Amigę 600 to jest to naprawdę wielki krok do przodu.
Gunnar nie musi nic ściemniać, po co go próbujecie deklasować. I tak robi świetną robotę.
Jątrzenie to specjalizacja amiświatka...
07.02.2016 23:00
[#232]
Re: RTG i Vampire 600 V2
@michal_zukowski, post #229
Rozumiem, ze to sa wyniki dla jakiegos 300 MHz PPC, bo jezeli dla 1.5 GHz to sa raczej przecietne. Przemnoz wyniki dla 92MHz obecnej wersji Apollo razy 15, i porownaj.
BTW. Na EAB sa juz wyniki dla 99MHz Apollo, oczywiscie sa proporcjonalnie lepsze od wynikow dla wersji 92MHz.
Ostatnia aktualizacja: 07.02.2016 23:11:01 przez Don_Adan
BTW. Na EAB sa juz wyniki dla 99MHz Apollo, oczywiscie sa proporcjonalnie lepsze od wynikow dla wersji 92MHz.
Ostatnia aktualizacja: 07.02.2016 23:11:01 przez Don_Adan
07.02.2016 23:28
[#234]
Re: RTG i Vampire 600 V2
@recedent, post #231
http://apollo-core.com/knowledge.php?b=2¬e=316&z=derD3e
ciekawe, bo w krotkim poscie pod podanym linkiem nie moge doczytac sie twierdzenia, ze a600 ma szybszy dostep do pamieci niz ppc. pada natomiast slowo "porownanie", ale moze moja znajomosc angielskiego jest niewystarczajaca do odcyfrowania jakichs oczywistych podtekstow.
Ależ neguje. Gunnar w przytoczonym linku (co prawda link nie działa, trzeba go wklejać do przeglądarki, no ale nie wszyscy umieją wklejać linki) podaje, że jego A600 ma szybszy dostęp do pamięci od sprzętów z PowerPC. Niestety, zamiast zaorać zrobił samozaor.
ciekawe, bo w krotkim poscie pod podanym linkiem nie moge doczytac sie twierdzenia, ze a600 ma szybszy dostep do pamieci niz ppc. pada natomiast slowo "porownanie", ale moze moja znajomosc angielskiego jest niewystarczajaca do odcyfrowania jakichs oczywistych podtekstow.
07.02.2016 23:36
[#235]
Re: RTG i Vampire 600 V2
@wawrzon, post #234
Gunnar zrobił testy z dupy. Uruchomił dwa różne programy więc nawet nie wiemy czy te wyniki da się porównywać. Poza tym uruchomił test na OS4, który jak wiadomo jest dość wolny sam z siebie. Sorry, ale jak patrze na 146 MB/Sec //peg2 i sobie przypominam, że Peg2 na MorphOSie mial coś ponad 3 raza wiecej to myśle, że albo Ragemem jest lipny albo OS4. Kuriozalne są także wyniki z Sama, który ma DDR2. Gunnar powinien wiedzieć, że coś z tymi wynikami jest nie tak, skoro prędkość pamięci jest wolniejsza niż prędkość np. szyny PCI.
taki maly link do forum gdzie Gunnar lata temu robil testy dla Pegasosa2. Pewnie biedak zapomnial o nich :).
link
Ostatnia aktualizacja: 07.02.2016 23:41:56 przez michal_zukowski
taki maly link do forum gdzie Gunnar lata temu robil testy dla Pegasosa2. Pewnie biedak zapomnial o nich :).
link
Ostatnia aktualizacja: 07.02.2016 23:41:56 przez michal_zukowski
07.02.2016 23:49
[#236]
Re: RTG i Vampire 600 V2
@michal_zukowski, post #235
faktem jest ze benchmark jest niezbyt miarodajny, bo przy pomocy roznych narzedzi, a wiec raczej orientacyjny, dlatego "porownanie". tym niemniej kazdy moze sobie sam wyciagnac konkluzje, a czy pamiec pod os4 czy morphosem nie wyciaga ileby teoretycznie mogla, to chyba inna sprawa.
Ostatnia aktualizacja: 07.02.2016 23:50:18 przez wawrzon
Ostatnia aktualizacja: 07.02.2016 23:50:54 przez wawrzon
Ostatnia aktualizacja: 07.02.2016 23:50:18 przez wawrzon
Ostatnia aktualizacja: 07.02.2016 23:50:54 przez wawrzon
08.02.2016 02:00
[#238]
Re: RTG i Vampire 600 V2
@Don_Adan, post #228
360MB/s to normalny wynik dla taktowania 92MHz, ale wydaje mi się ciut zawyżony o kilka MB (92x4 = 372MB w teorii, niemożliwe w praktyce), zastanawiam się czy procek Gunnara robi po 16 cykli burst z tej pamięci, bo straty na przygotowanie transferu wyglądają na minimalne.
08.02.2016 08:56
[#240]
Re: RTG i Vampire 600 V2
@Don_Adan, post #239
Panowie może faktycznie test jest niemiarodajny ( dwa różne programy) ale jeśli się nie mylę to niektóre z naszych cudownych PPC miały trochę skopane właśnie obsługę pamięci. Więc być może dlatego biedna a600 z Vampirką (która nie używa pamięci ddr2 jeśli dobrze pamiętam - nie znam się na tym ale jest chyba jakiś "mobilny SDRAM") może osiągać podobną lub nawet większą przepustowość niż np Peg z 1GHz PPC. No i effika /Sam a1-xe też jakoś nie zachwycają wydajnością przepływu pamięci w odniesieniu do ich zegara. No mogę się mylić ekspertem nie jestem ale myślę że 1GHz procek powinien wyciągać "lekko" więcej niż 300 MB/s racja ?