06.02.2016 10:50
[#181]
Re: RTG i Vampire 600 V2
@Voyox, post #154
tia, już Natami miało godzić wszystko a skończyło jak skończyło tj. nijak, jako koncept
wydajność tego Vampira jest pi razy drzwi 22-23 lata za mainstreamem
FPGA jest fajne że wychodzą nowe fajne układy FPGA, stare z roku na rok tanieją, będzie się dało wydawać coraz to nowsze karty przez następne dziesięciolecia jak zajdzie taka potrzeba. Ba, nawet dzisiaj jak będą robić turbo do A1200 nie muszą brać śmulaka Cyclone III tylko nowszy nawet Cyclone V i tam ten sam design osiągnie większy maksymalny zegar. Jednak żadnych 1GHz i wyżej nie będzie, przynajmniej nie w najbliższym dziesięcioleciu. Wydajność będzie zawsze 20 lat do tyłu i tego się już nie przeskoczy.
ASIC jest zbyt drogi w produkcji a i sam design trzeba by optymalizować pod ASIC. Od tego trzeba specjalistów którzy zawodowo się tym zajmują. Robiąc to byle jak może się okazać że albo układ nie będzie działał jako ASIC albo uzyskana wydajność (maksymalny zegar przy jakim design działa prawidłowo) jest biedna i trzeba wszystko zmieniać, wrzucając w to coraz to większą ilość gotówki która tutaj nie ma prawa się zwrócić.
wydajność tego Vampira jest pi razy drzwi 22-23 lata za mainstreamem
FPGA jest fajne że wychodzą nowe fajne układy FPGA, stare z roku na rok tanieją, będzie się dało wydawać coraz to nowsze karty przez następne dziesięciolecia jak zajdzie taka potrzeba. Ba, nawet dzisiaj jak będą robić turbo do A1200 nie muszą brać śmulaka Cyclone III tylko nowszy nawet Cyclone V i tam ten sam design osiągnie większy maksymalny zegar. Jednak żadnych 1GHz i wyżej nie będzie, przynajmniej nie w najbliższym dziesięcioleciu. Wydajność będzie zawsze 20 lat do tyłu i tego się już nie przeskoczy.
ASIC jest zbyt drogi w produkcji a i sam design trzeba by optymalizować pod ASIC. Od tego trzeba specjalistów którzy zawodowo się tym zajmują. Robiąc to byle jak może się okazać że albo układ nie będzie działał jako ASIC albo uzyskana wydajność (maksymalny zegar przy jakim design działa prawidłowo) jest biedna i trzeba wszystko zmieniać, wrzucając w to coraz to większą ilość gotówki która tutaj nie ma prawa się zwrócić.
06.02.2016 11:23
[#183]
Re: RTG i Vampire 600 V2
@Hexmage960, post #177
Myślę, że karta Vampire V2 nie przyczyni się do wzrostu oprogramowania. Bo komputery AmigaONE ścigają PC-ty, a mimo to oprogramowania jak na lekarstwo.
AmigaOne, nawet X1000 to przy PC jak C64 przy Amidze 1200
X1000 ma procesor wolniejszy od mainstreamu 10 lat temu a oprogramowanie sprawia że komputer ten działa jak mainstream sprzed 13-15 lat
za kilkaset złotych kupujesz tablet z Atomem i Windowsem 10 i jest dużo wydajniejszy od najszybszej AmigiOne zarówno procesor jak i grafika 3d która na tym tablecie obsługuje shadery i inne szmery bajery, akcelerację odtwarzania fimów w 4K vs. wielki problem odtworzyć trailer prometeusza ściągnięty z YT( czyli z niskim bitrate) na X1000
gdzie ty tu widzisz jakieś ściganie się?
06.02.2016 11:41
[#184]
Re: RTG i Vampire 600 V2
@XoR, post #183
Nie chodzi mi o porównywanie z aktualnym mainstreamem, tylko ogólnie - wydajność X1000, a teraz X5000 jest coraz większa. I, mimo że jest coraz większa, nowe oprogramowanie nie powstaje prawie w ogóle. A jeśli już, to w bólach.
Do tego dawniej ludzie pisali na Amigę Glooma, Breathless. Na takim X5000 mogliby zrobić podobne i bardziej zaawansowane gry. Mimo to, powstają jakieś porty setnej wersji Quake o prędkości 5 FPS. O co tu chodzi? Programistom brakuje motywacji by robić takie gry.
Vampire V2 raczej czeka ten sam los jeśli chodzi o oprogramowanie i ubolewam nad tym. A bierze się to stąd, że ludzie używają komputerów "trochę" niezgodnie z ich przeznaczeniem bądź filozofią. Ja nie chcę np. YouTube na Amidze, wolę natywne odtwarzacze, a nie jakieś webowe molochy.
Ostatnia aktualizacja: 06.02.2016 11:43:58 przez Hexmage960
Do tego dawniej ludzie pisali na Amigę Glooma, Breathless. Na takim X5000 mogliby zrobić podobne i bardziej zaawansowane gry. Mimo to, powstają jakieś porty setnej wersji Quake o prędkości 5 FPS. O co tu chodzi? Programistom brakuje motywacji by robić takie gry.
Vampire V2 raczej czeka ten sam los jeśli chodzi o oprogramowanie i ubolewam nad tym. A bierze się to stąd, że ludzie używają komputerów "trochę" niezgodnie z ich przeznaczeniem bądź filozofią. Ja nie chcę np. YouTube na Amidze, wolę natywne odtwarzacze, a nie jakieś webowe molochy.
Ostatnia aktualizacja: 06.02.2016 11:43:58 przez Hexmage960
06.02.2016 11:56
[#185]
Re: RTG i Vampire 600 V2
@Hexmage960, post #184
Na takim X5000 mogliby zrobić podobne i bardziej zaawansowane gry. Mimo to, powstają jakieś porty setnej wersji Quake o prędkości 5 FPS. O co tu chodzi? Programistom brakuje motywacji by robić takie gry.
Oj, Miniat, Ty tak na serio? Zrobienie od podstaw w miarę nowoczesnej gry (na poziomie powiedzmy roku 2000) to tysiące godzin roboty całego zespołu ludzi..."Programista" to może sobie ustrugać jakiś port, ewentualnie prościutką grę indie w dzisiejszych czasach.
Nikt nie zrobi gry, której produkcja pochłonie tysiące roboczogodzin, dla funu. Pomijając fakt, że i tak nie będzie miała szans z konkurencją nawet starych gier przygotowanych przez profesjonalne studia.
Sam engine to raptem 1% gry i nawet gdyby na neoAmigach była dostępność Unity czy Unreal Engine wątpliwe by cokolwiek to zmieniło w tym temacie.
No i jeszcze raz - robienie gier to przede wszystkim praca zespołu artystów, era programistów już dawno się w tym temacie skończyła (co nie znaczy, że ich rola jest nieistotna dzisiaj/niepotrzebna)
06.02.2016 12:15
[#187]
Re: RTG i Vampire 600 V2
@recedent, post #186
Generalnie chodziło mi o gry 3D.
Tutaj linki do komentarzy, gdzie możemy poczytać o prędkości rozgrywki. Oba porty są z 2014 roku i są autorstwa BSzili.
Speed Dreams
Multi Races
Taka prędkość zakrawa o absurd.
Jeśli chodzi o nowe gry przykładowo na AmigęOne X5000 to mnie chodzi wyłącznie o to, że programistom nie chce się już pisać nowych gier typu Gloom, Breathless, które były domeną Amigi i z czego jesteśmy dumni. Tak jakby już nie dało się nikogo zaskoczyć możliwościami Amigi (AmigiOne).
Zdaję sobie sprawę, że gry komercyjne na PC/konsole dziś to masa pracy i wiele zaangażowanych osób. Dlatego pewnie programiści NG spasowali.
Ostatnia aktualizacja: 06.02.2016 12:30:50 przez Hexmage960
Tutaj linki do komentarzy, gdzie możemy poczytać o prędkości rozgrywki. Oba porty są z 2014 roku i są autorstwa BSzili.
Speed Dreams
Multi Races
Taka prędkość zakrawa o absurd.
Jeśli chodzi o nowe gry przykładowo na AmigęOne X5000 to mnie chodzi wyłącznie o to, że programistom nie chce się już pisać nowych gier typu Gloom, Breathless, które były domeną Amigi i z czego jesteśmy dumni. Tak jakby już nie dało się nikogo zaskoczyć możliwościami Amigi (AmigiOne).
Zdaję sobie sprawę, że gry komercyjne na PC/konsole dziś to masa pracy i wiele zaangażowanych osób. Dlatego pewnie programiści NG spasowali.
Ostatnia aktualizacja: 06.02.2016 12:30:50 przez Hexmage960
06.02.2016 13:15
[#189]
Re: RTG i Vampire 600 V2
@twardy, post #188
Ja zarówno świetnego Cannon Fodder, SWOS jak i Glooma i Breathless zaliczam do kanonu gier tylko na Amigę. Gry z PSX mnie guzik obchodzą szczerze mówiąc. W tamtym okresie (po bankructwie Commodore) wspierałem bardzo Amigę, co staram się czynić po dziś dzień.
Ostatnia aktualizacja: 06.02.2016 13:16:07 przez Hexmage960
Ostatnia aktualizacja: 06.02.2016 13:16:07 przez Hexmage960
06.02.2016 13:18
[#191]
Re: RTG i Vampire 600 V2
@Hexmage960, post #187
MultiRacer chodzi świetnie na moim Miniaczu (zapraszam na Amigowisko, przekonasz się osobiście), na X5000 powinien zrywać głowę razem z kaskiem. Jeśli osiąga na OS4 5 FPS (w co osobiście wątpię) to sprzęt ten jest żałośnie słabo oprogramowany.
Swoją drogą - ciekawe ile MultiRacer FPSów wyciągnie na Vampire 600 V2 :)
Ostatnia aktualizacja: 06.02.2016 13:24:44 przez recedent
Swoją drogą - ciekawe ile MultiRacer FPSów wyciągnie na Vampire 600 V2 :)
Ostatnia aktualizacja: 06.02.2016 13:24:44 przez recedent
06.02.2016 13:27
[#193]
Re: RTG i Vampire 600 V2
@recedent, post #191
Ale jaki jest sens kupować X5000 jeśli Speed Dreams lub Multi Racer osiągnie chociaż grywalny poziom. Na komputerze Leona Speed Dreams wyciąga 1/6 FPS.
Chciałem zobrazować rozdźwięk między wymaganiami, sprzętem, możliwościami. Dla jednego A500 to może być raj na ziemi, bo ma Speedballa 2, czy WolfChild, dla innego to piekło bo nie działa przeglądarka, albo kanapka się rozkleja.
Wbrew pozorom ma to dużo wspólnego z Vampire 2.
Dodane:
No i tutaj jest pułapka, o której mówię...
Ja jestem zwolennikiem teorii, że oprogramowanie należy przyśpieszać, a nie wymieniać sprzęt na szybszy.
Najczęściej jednak panuje przekonanie odwrotne.
Ostatnia aktualizacja: 06.02.2016 13:44:22 przez Hexmage960
Chciałem zobrazować rozdźwięk między wymaganiami, sprzętem, możliwościami. Dla jednego A500 to może być raj na ziemi, bo ma Speedballa 2, czy WolfChild, dla innego to piekło bo nie działa przeglądarka, albo kanapka się rozkleja.
Wbrew pozorom ma to dużo wspólnego z Vampire 2.
Dodane:
Swoją drogą - ciekawe ile MultiRacer FPSów wyciągnie na Vampire 600 V2 :)
No i tutaj jest pułapka, o której mówię...
Ja jestem zwolennikiem teorii, że oprogramowanie należy przyśpieszać, a nie wymieniać sprzęt na szybszy.
Najczęściej jednak panuje przekonanie odwrotne.
Ostatnia aktualizacja: 06.02.2016 13:44:22 przez Hexmage960
06.02.2016 13:43
[#194]
Re: RTG i Vampire 600 V2
@abcdef, post #160
Widze, ze nie rozumiesz na czym to polega. Nowe instrukcje 64bitowe wymagaja innych opcode, ale niektore stare instrukcje 16/32 bitowe moga byc traktowane jako instrukcje 64 bitowe, po to zeby szybciej dzialaly. Np. movep.l jest na 68000 instrukcja 16 bitowa wykonywana 4 razy (4 odczyty lub zapisy). W przypadku Apollo ta instrukcja jest traktowana jako instrukcja 64 bitowa (1 odczyt i zapis). Dlaczego implementacja movep miala spowalniac dzialanie calego FPGA, tego nie wiem. Spytaj sie Gunnara albo kogos kto programuje w VHDL. No i jako ekspert pewnie wiesz, ze 68000 (32 bitowy procesor wedlug mnie) wewnetrznie dziala jako 16 bitowy. A tutaj Apollo dziala jako 64 bit wewnetrznie. I juz ci tlumaczylem, ze instrukcja 32 bitowa movem.l (A0),D0/D1, moze byc traktowana jako instrukcja 64 bitowa. Zadne niwe opcode nie jest tez potrzebne, jak tego nie ogarniasz to trudno. Sam Gunnar podal inny przyklad 2 instrukcji 32 bitowych, dzialajacych jak jedna 64 bitowa, konkretnie to bylo:
move.l (a0)+,(a1)+
move.l (a0)+,(a1)+
Co do klocuszkow to sie pytaj Gunnara, Apollo w Cyclone III ma coraz wiecej mozliwosci, a jego predkosc jest wedlug mnie taka sama co przed paru lat, czyli okolo 85 MHz. A podobno po optymalizacji ma byc okolo 30% szybciej. FPGA to nie moja dzialka, ale wiem ze niekazdy potrafi dobrze programowac, niezaleznie czy w asemblerze, C, Amosie czy VHDL.
move.l (a0)+,(a1)+
move.l (a0)+,(a1)+
Co do klocuszkow to sie pytaj Gunnara, Apollo w Cyclone III ma coraz wiecej mozliwosci, a jego predkosc jest wedlug mnie taka sama co przed paru lat, czyli okolo 85 MHz. A podobno po optymalizacji ma byc okolo 30% szybciej. FPGA to nie moja dzialka, ale wiem ze niekazdy potrafi dobrze programowac, niezaleznie czy w asemblerze, C, Amosie czy VHDL.
06.02.2016 13:52
[#196]
Re: RTG i Vampire 600 V2
@Don_Adan, post #194
Żeby nie było żadnych wątpliwości - żaden ze mnie ekspert czy to w dziedzinie 68k czy FPGA. Przykro mi ale ja po prostu nie mam wiedzy żeby Ci udzielić dobrej odpowiedzi na Twoje pytania. Oczywiście mogę zapytać Gunnara ale myślę że dużo lepsza była by wasza rozmowa "w cztery oczy" . A co do tych 85 MHz... to jest ograniczenie bezpośrednio wynikające z a) jakości kodu i b) użytego układu FPGA. No a jeśli już koniecznie chcesz porównywać prędkość wsadu sprzed kilku lat a nowego... Zgadnij który jest szybszy pomimo podobnej częstotliwości taktowania ?
Powtarzam jeszcze raz - nie jestem żadnym ekspertem i prosze mnie tak nie traktować.
A pytania przekażę do Gunnara.
Powtarzam jeszcze raz - nie jestem żadnym ekspertem i prosze mnie tak nie traktować.
A pytania przekażę do Gunnara.
06.02.2016 13:54
[#197]
Re: RTG i Vampire 600 V2
@twardy, post #195
Nie jest tak źle z Breathless mimo stosunkowo prostego silnika. Kody to kwestia gustu i upodobań.
Jeśli ktoś ma słabą konfigurację ma Glooma Classic, który działa bardzo szybko. Albo Fears.
Dla wymagających - Alien Breed 3D II.
Dla każdego coś miłego.
Ostatnia aktualizacja: 06.02.2016 13:56:13 przez Hexmage960
Jeśli ktoś ma słabą konfigurację ma Glooma Classic, który działa bardzo szybko. Albo Fears.
Dla wymagających - Alien Breed 3D II.
Dla każdego coś miłego.
Ostatnia aktualizacja: 06.02.2016 13:56:13 przez Hexmage960
06.02.2016 14:11
[#198]
Re: RTG i Vampire 600 V2
@Hexmage960, post #197
Porównywanie amigowych eFPeeSow do DOOMA ma się jak porównywanie malucha do Ferrari Italia. Nie ma czego porownywac.
Swoją drogą tutaj ciekawy film o amigowych "doomach" a tu o tym dlaczego DOOM wyprzedził epokę i jak nieodwracalne zmienił branże gier video (i nie tylko)
Swoją drogą tutaj ciekawy film o amigowych "doomach" a tu o tym dlaczego DOOM wyprzedził epokę i jak nieodwracalne zmienił branże gier video (i nie tylko)
06.02.2016 14:18
[#199]
Re: RTG i Vampire 600 V2
@pisklak, post #196
Dodam od siebie jedno. Żadne Neo Amigi nie wzbudziły we mnie entuzjazmu takiego jak to maleństwo FPGA. Jaką bibliotekę oprogramowamia dorobiły się neoamigi? Kto tam tak szaleje z pisaniem oprogramowania? BiSzili i paru innych, Krashan z DigiBosterem, pare portów starych gierek i sxrgx czy jakoś tak.
Puste dyski w neoamigach. A w klasyku teraz jest szansa na napisanie czegoś więcej i tylko kwiczenie troglodytow słychać.
Jeżeli projekt się przyjmie to dobrze, nie można tego porównać z NatAmi bo ten projekt już trafia do klientów.
Czekam na wersje V1200. I byłoby dobrze jakby Gunar zrobił 2 edycję, szybsze FPGA droższe i standardowe.
Kiełkuje w mnie myśl aby zacząć naukę programowania, a jestem znany z zawzietosci, więc cel do realizacji.
Jakich programów ją oczekuję?
Na pewno coś da się normalnego stworzyć na Ami w normalnych rozdzielczościach. Znika definitywnie bariera dla gierek/portów typu Setlers 2, Heroes 3 itd...
Jedno na pewno się dzieje teraz. Zagrożone czują się Neo systemy. Jedyną szansą dla nich aby pokazywały się w większej ilości programy i porty gier. A tam posucha niestety....
Puste dyski w neoamigach. A w klasyku teraz jest szansa na napisanie czegoś więcej i tylko kwiczenie troglodytow słychać.
Jeżeli projekt się przyjmie to dobrze, nie można tego porównać z NatAmi bo ten projekt już trafia do klientów.
Czekam na wersje V1200. I byłoby dobrze jakby Gunar zrobił 2 edycję, szybsze FPGA droższe i standardowe.
Kiełkuje w mnie myśl aby zacząć naukę programowania, a jestem znany z zawzietosci, więc cel do realizacji.
Jakich programów ją oczekuję?
Na pewno coś da się normalnego stworzyć na Ami w normalnych rozdzielczościach. Znika definitywnie bariera dla gierek/portów typu Setlers 2, Heroes 3 itd...
Jedno na pewno się dzieje teraz. Zagrożone czują się Neo systemy. Jedyną szansą dla nich aby pokazywały się w większej ilości programy i porty gier. A tam posucha niestety....
06.02.2016 14:48
[#200]
Re: RTG i Vampire 600 V2
@Voyox, post #199
Myślę, że zagrożenia dla Next-Genów nie ma. Co więcej - jest szansa. Jeśli faktycznie ktoś zechce zrobić jakieś nowe oprogramowanie (oh rly?) to z dużym prawdopodobieństwem będzie to działać pod systemem i RTG, więc tym bardziej pod NG. A apetyt rośnie w marę jedzenia... Choć nie stawiałbym na jakiś nagły atak oprogramowania.
Voyox, naprawdę tak mało tego oprogramowania jest pod MorphOSem? Myślę, że za bardzo jesteś rozpieszczony. Weź na klasyku znajdź na przykład dobrą i szybką odpalarkę zdjęć (choćby z idiotenkamery) z funkcją filemanagera i prostej edycji. I co, nie ma? Oj...
Voyox, naprawdę tak mało tego oprogramowania jest pod MorphOSem? Myślę, że za bardzo jesteś rozpieszczony. Weź na klasyku znajdź na przykład dobrą i szybką odpalarkę zdjęć (choćby z idiotenkamery) z funkcją filemanagera i prostej edycji. I co, nie ma? Oj...
06.02.2016 15:38
[#202]
Re: RTG i Vampire 600 V2
@Voyox, post #199
No zle nie jest powstaja fajne aplikacje pokazujące moc systemu takie jak SoundBankster ;)
No i nie należy zapominać że w toku są prace nad portem PageStrem 5 dla MorphOS-a
Kto wie co będzie jak kiero skończy shadery wtedy będzie moża też wykonać pare fajnych portów gier ;)
To tyle w temacie bo nie tego dotyczy ten wątek ;)
Ostatnia aktualizacja: 06.02.2016 15:40:27 przez Drako^BB
No i nie należy zapominać że w toku są prace nad portem PageStrem 5 dla MorphOS-a
Kto wie co będzie jak kiero skończy shadery wtedy będzie moża też wykonać pare fajnych portów gier ;)
To tyle w temacie bo nie tego dotyczy ten wątek ;)
Ostatnia aktualizacja: 06.02.2016 15:40:27 przez Drako^BB
06.02.2016 15:40
[#203]
Re: RTG i Vampire 600 V2
@XoR, post #181
Czy Pentium II to byl mainstreamowy procesor?
Bo jezeli tak, to jest z on 1997 roku, a Apollo przy okolo 85 MHz ma wieksza wydajnosc niz Pentium II 233 MHz.
http://apollo-core.com/knowledge.php?b=2¬e=38
Tak wiec te drzwi musza byc dosc szerokie.
A jak sie porowna przy tym samym taktowaniu to juz tych drzwi tam nie ma.
No wiec to juz teraz jest duzo mniej niz 20 lat, a bedzie jeszcze mniej, gdyz mainstreamowe procesory doszly juz raczej do sciany jesli chodzi o ich taktowanie przy obecnej technologii.
Bo jezeli tak, to jest z on 1997 roku, a Apollo przy okolo 85 MHz ma wieksza wydajnosc niz Pentium II 233 MHz.
http://apollo-core.com/knowledge.php?b=2¬e=38
Tak wiec te drzwi musza byc dosc szerokie.
A jak sie porowna przy tym samym taktowaniu to juz tych drzwi tam nie ma.
No wiec to juz teraz jest duzo mniej niz 20 lat, a bedzie jeszcze mniej, gdyz mainstreamowe procesory doszly juz raczej do sciany jesli chodzi o ich taktowanie przy obecnej technologii.
06.02.2016 15:43
[#204]
Re: RTG i Vampire 600 V2
@Don_Adan, post #194
I juz ci tlumaczylem, ze instrukcja 32 bitowa movem.l (A0),D0/D1, moze byc traktowana jako instrukcja 64 bitowa.A ja też dokładnie opisałem dokładnie jakie zagrożenia niesie takie a nie inne implementowanie 64b więc może warto zacząć od tego jak to w rzeczywistości Gunnar robi.
Zadne niwe opcode nie jest tez potrzebne
Tylko w tym przypadku to nadal jest instrukcja 32bitowa. Operandy też są 32bitowe. Jedyne co się zmienia to wewnętrzna organizacja i zamiast 2 transferów 32b (lub czterech 16bit) masz jeden 64b. To coś zupełnie innego. W końcu i Pentium 2 miał (uwaga, uwaga) szynę danych 64b! Tak, FSB to było 64b! Interfejs z mostka do pamięci też 64b. W 32b athlonie xp mostki nvidia obsługiwały nawet interfejs i transfery 128b (dual channel). Jak to się ma do 64bitowych trybów i instrukcji to nie mam pojęcia. Ja tylko i wyłącznie jestem pesymistycznie nastawiony do rozszerzenia 64bitowego (czyli coś a'la AMD64 w świecie x86) a nie poprawienia wewnętrznej konstrukcji procesora.
Ostatnia aktualizacja: 06.02.2016 15:46:07 przez abcdef
06.02.2016 16:15
[#206]
Re: RTG i Vampire 600 V2
@pisklak, post #161
Dlatego, że sam AROS ma wolne źródła i możesz wszystko poprawić samodzielne a nawet zaprząc do pomocy innych programistów, wystarczy nowy kompilator i masz AROSA skompilowanego całkowicie pod Vampire. Jak sobie wyobrażasz hackowanie całego AOS3.1, aby wykorzystać nowe instrukcje? Zapaleńcy się znajdą, ale będzie to trwało, ale ile czasu?
Wraz z pojawieniem się SIMD, pojawiły się gry i programy z tego korzystające, z tym akurat nie było najmniejszego problemu, bo na PC pojawiało się coraz więcej gier, a programistów miałeś pod dostatkiem. Jakie są plany wykorzystania nowych instrukcji w Vampire prócz drobnych poprawek, które wprowadzi Don Adan do bibliotek?
Przecież przedmówcy nie po to mówią, czego potrzebują teraz, aby zgnębić Gunnara, tylko, że akurat w TYM KONKRETNYM MOMENCIE nie potrzebujemy niczego innego jak szybkiej 68040. Wiem, że 68040 jest jedynie fragmentem wielkiej wizji Gunnara, ale powinien się własnie skupić nad wyszlifowaniem tego fragmentu, aby ludzie mogli się już cieszyc, a potem przystąpić do rozszerzenia projektu i zainteresowania kogoś, kto wyda kompilator wykorzystujący pełen potencjał tego procesora (oczywiście koderzy będą mogli zacząć robić to wcześniej gdy dostaną dokumentację).
To nie tak, ze ktoś mnie zmusza do korzystania z nowinek, ale nie ma jak z nich skorzystać.
Wraz z pojawieniem się SIMD, pojawiły się gry i programy z tego korzystające, z tym akurat nie było najmniejszego problemu, bo na PC pojawiało się coraz więcej gier, a programistów miałeś pod dostatkiem. Jakie są plany wykorzystania nowych instrukcji w Vampire prócz drobnych poprawek, które wprowadzi Don Adan do bibliotek?
Przecież przedmówcy nie po to mówią, czego potrzebują teraz, aby zgnębić Gunnara, tylko, że akurat w TYM KONKRETNYM MOMENCIE nie potrzebujemy niczego innego jak szybkiej 68040. Wiem, że 68040 jest jedynie fragmentem wielkiej wizji Gunnara, ale powinien się własnie skupić nad wyszlifowaniem tego fragmentu, aby ludzie mogli się już cieszyc, a potem przystąpić do rozszerzenia projektu i zainteresowania kogoś, kto wyda kompilator wykorzystujący pełen potencjał tego procesora (oczywiście koderzy będą mogli zacząć robić to wcześniej gdy dostaną dokumentację).
To nie tak, ze ktoś mnie zmusza do korzystania z nowinek, ale nie ma jak z nich skorzystać.
06.02.2016 16:37
[#207]
Re: RTG i Vampire 600 V2
@abcdef, post #204
64b i 128b prawdopodobnie były podłączone do modułu cache, stad inna liczba bitów procesora i pamięci (w 68040/60 rozmiar linii cache to 128bitów i moduł ten robi zawsze 4 32-bitowe cykle odczytu burst, ale gdybyś miał szynę 128bit to byłby tylko jeden cykl).
W każdym bądź razie, znając działanie danych instrukcji, można sobie każą z osobna zoptymalizować nawet do 256bitów jeśli trzeba, w 68000 o wewnętrznym mechanizmie decydowały koszty, w Vampire nie ma takich ograniczeń, dlatego Gunnar pozwolił sobie na 64-bitowe rejestry. Tylko jak vampire rozpoznaje, które instrukcje są 32, a ktoóre 64-bit? No bo przecież PC załaduje pełne 64bit, czyli dwie instrukcje na raz. Co się stanie jeśli, pod adresem 0 będzie instrukcja, a pod 4 zwykła dana procesor wywali wyjątek, bo nie rozpoznał instrukcji?
W każdym bądź razie, znając działanie danych instrukcji, można sobie każą z osobna zoptymalizować nawet do 256bitów jeśli trzeba, w 68000 o wewnętrznym mechanizmie decydowały koszty, w Vampire nie ma takich ograniczeń, dlatego Gunnar pozwolił sobie na 64-bitowe rejestry. Tylko jak vampire rozpoznaje, które instrukcje są 32, a ktoóre 64-bit? No bo przecież PC załaduje pełne 64bit, czyli dwie instrukcje na raz. Co się stanie jeśli, pod adresem 0 będzie instrukcja, a pod 4 zwykła dana procesor wywali wyjątek, bo nie rozpoznał instrukcji?
06.02.2016 17:02
[#208]
Re: RTG i Vampire 600 V2
@sanjyuubi, post #207
Ja wiem, sam nie jestem ekspertem, ale jest różnica między instrukcją 64bitową, a instrukcją z operandem 64bitowym. Procesory Intela i AMD obecnie mają 256bitowe magistrale danych wewnętrznie po to by móc w jednym cyklu załadować całego AVXa. Niemniej architektura jest 64 bitowa. Baa. Już w czasach pentium III były datapath 128b by załadować SSE, podczas gdy architektura była wyłącznie 32 bitowa (w tym FPU x87 up to 80bit). Ja widzę sens szerszych magistrali w środku, fuzji instrukcji, polepszonego działania istniejących instrukcji. Nie widzę sensu sztucznego poszerzania samego ISA o instrukcje 64 bitowe. Rozumiem MUL który 32x32=64 robił w kilku cyklach bo zwyczajnie musiał na 32bitowych ALU wynik transferować 32bitowymi magistralami do docelowych rejestrów. Teraz można to zrobić w cyklu albo dwóch. To ma sens. Dodanie rozkazu który zrobi 64x64=128 już nie ma. W tym wypadku lepiej dodać instrukcję SIMD, która zrobi to samo, albo np. 2 mnożenia dla liczb 32bitowych, albo 4 dodawania. Bo przy przekompilowaniu pod to bibliotek matematycznych część softu OD RAZU z tego skorzysta i to z pozytywnym skutkiem. Sztuczne rozszerzenie ISA do 64b będzie wykorzystane rzadko (z kompatybilnym kompilerem - tylko gdy użyjemy long long int).
06.02.2016 17:28
[#209]
Re: RTG i Vampire 600 V2
@Don_Adan, post #203
wg. DNETC to G4 jest wydajniejszy na zegar od Core i7 więc ten test można włożyć między bajki. Zawsze pokazywał silną preferencję do big endian. Tutaj Apollo jest ledwie 14% wydajniejszy od 060 80MHz czyli pokazuje to podobny stopień zaawansowania czyli dalej to poziom Penituma 1. Te ~22 lata temu można było spokojnie taką wydajność uzyskać. Tanio nie tanio, dało się.
Gunnar to znany benchmarkowy hype-maister. Jak taki jest cwany to dlaczego nie dał porównania do PPC 603/604?
Zasypuje nas jakimiś specyficznymi testami pokazującymi że jakiś tam szczególik dopracował, a to prędkość pamięci (przy DDR2 to nie dziwota...) a to wydajność jednej instrukcji jak się wykona ich kilka na raz i testy pod to specjalnie są zrobione... Takie testy są bezużyteczne i tylko mieszają w głowie.
Najlepiej to będzie widać jak wszystko wyjdzie, dopracują i wydadzą FPU i zrobi się porządne testy i porównania w Doomach, Quake'ach itp. jak to z wydajnością faktycznie jest zarówno porównując do 060, PowerPC jak i Pentiumów. Może jakby dali w Vampire dla A1200 dużo lepszy FPGA to zegarem by się dało podciągnąć i pokonać PowerPC/Penitumy >200MHz a na Vampire V2 to tego nie widzę.
Gunnar to znany benchmarkowy hype-maister. Jak taki jest cwany to dlaczego nie dał porównania do PPC 603/604?
Zasypuje nas jakimiś specyficznymi testami pokazującymi że jakiś tam szczególik dopracował, a to prędkość pamięci (przy DDR2 to nie dziwota...) a to wydajność jednej instrukcji jak się wykona ich kilka na raz i testy pod to specjalnie są zrobione... Takie testy są bezużyteczne i tylko mieszają w głowie.
Najlepiej to będzie widać jak wszystko wyjdzie, dopracują i wydadzą FPU i zrobi się porządne testy i porównania w Doomach, Quake'ach itp. jak to z wydajnością faktycznie jest zarówno porównując do 060, PowerPC jak i Pentiumów. Może jakby dali w Vampire dla A1200 dużo lepszy FPGA to zegarem by się dało podciągnąć i pokonać PowerPC/Penitumy >200MHz a na Vampire V2 to tego nie widzę.
06.02.2016 18:11
[#210]
Re: RTG i Vampire 600 V2
@XoR, post #209
Zapewne Don_Adan pisał o maksymalnej wydajności tego procesora, przy umiejętnym napisaniu kodu, który umożliwia wykonanie 3 instrukcji na raz (80 x 3 = 240MHz), tylko, że nie zawsze warunki będą pozwalały na takie zachowanie, więc wydajność kodu będzie oscylować czasami pomiędzy pentium 200, a 68060 80MHz, ale przeważnie powinno być szybciej niż wolniej.
Testy Quake'ów i Doom'ów nie ma co robić bez rekompilacji pod wspomniane mechanizmy, bo wyjdzie prawdopodobnie prędkość 68060 + 20% (jest szansa, że będzie szybciej ze względu na szybki dostęp do pamięci RTG). A jeżeli są to porty napisane w assemblerze, to chyba nie prędko ktoś to dostosuje.
Ostatnia aktualizacja: 06.02.2016 18:13:39 przez sanjyuubi
Testy Quake'ów i Doom'ów nie ma co robić bez rekompilacji pod wspomniane mechanizmy, bo wyjdzie prawdopodobnie prędkość 68060 + 20% (jest szansa, że będzie szybciej ze względu na szybki dostęp do pamięci RTG). A jeżeli są to porty napisane w assemblerze, to chyba nie prędko ktoś to dostosuje.
Ostatnia aktualizacja: 06.02.2016 18:13:39 przez sanjyuubi