kategorie: A600, Programy, Sprzęt
[#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 .
[#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.
[#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?
[#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.
[#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.
[#216] Re: RTG i Vampire 600 V2

@sanjyuubi, post #215

Dobrze Panowie (i Panie) - jeśli ktoś poda jakiś krótki kod do optymalizacji pod Apollo (normalny kod 68k) Gunnar powiedział że zwrotnie da zoptymalizowany kod z opisem optymalizacji. Jacyś ochotnicy ?
[#217] Re: RTG i Vampire 600 V2

@pisklak, post #216

Można też jak najbardziej pytać o nowe rzeczy, najlepiej na przykładzie kodu.
[#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...
[#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.
[#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. OK
[#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.
[#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
[#223] Re: RTG i Vampire 600 V2

@Don_Adan, post #222

Mamy źródła i zgodę autora na optymalizacje. Zdaje się że kod assembluje się pod Devpakiem jak dobrze pamiętam. Czysty kod ASM68k.
Podaj mi proszę Swój adres mailowy na priva to dogadamy szczegóły.

Ostatnia aktualizacja: 07.02.2016 00:06:28 przez pisklak
[#224] Re: RTG i Vampire 600 V2

@pisklak, post #223

Moj adres jest publiczny donadan@wp.pl.
[#225] Re: RTG i Vampire 600 V2

@Voyox, post #220

Piszcie soft tradycyjnie jeśli nie chcecie się niczego uczyć


Ależ tutaj widzę że ludzie chcą się uczyć, niemniej nie mają z czego.
[#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....
[#227] Re: RTG i Vampire 600 V2

@pisklak, post #226

Chociaż jedna jaskółka wiosny nie czyni.... http://apollo-core.com/m68k/
[#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&note=316&z=derD3e
[#229] Re: RTG i Vampire 600 V2

@Don_Adan, post #228

Nie mylmy wydajności pamięci z wydajnością procka!!!

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
[#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...
[#231] Re: RTG i Vampire 600 V2

@Voyox, post #230

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.
[#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
[#233] Re: RTG i Vampire 600 V2

@recedent, post #231

Ja nie umiem wkleic wciskam ten wezyk i nic sie nie dzieje, moze to wina tableta, albo wezyk za maly na moje palce.
No i troche sie mylisz, szybszy dostep do pamieci to jedna sprawa, ale bez odpowiedniej szybkosci procesora wyniki bylyby slabe.
[#234] Re: RTG i Vampire 600 V2

@recedent, post #231

http://apollo-core.com/knowledge.php?b=2&note=316&z=derD3e
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.
[#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
[#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
[#237] Re: RTG i Vampire 600 V2

@Don_Adan, post #233

[ url ] link [ / url ]
[#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.
[#239] Re: RTG i Vampire 600 V2

@sanjyuubi, post #238

Bardzo szybki dostep do pamieci to byl jego konik, o ile dobrze pamietam to co dawno temu pisal na forum Natami.
Jezeli chodzi o szybkosc to w trybie 64 bitowym powinien byc 2x lepszy wynik.

Ostatnia aktualizacja: 08.02.2016 04:51:01 przez Don_Adan
[#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 ?
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem