AmigaOS 4.0 - natywne RTG

Discord (online: ) «»

Online: 13

AmiKit
Archi-TECH
b...
Cizar
Dobrowit
Heng
IMPBot
Janusz82
juen
Laubzega
m...
Patu
spazma

dołącz do kanału »

michalsc
konto zablokowane
lub usunięte
Czytelnik

komentarz #1 wysłany: 2004-07-08 19:39

a to wszystko w czystym C, na razie bez jakichkolwiek optymalizacji w asemblerze.

Na dzien dzisiejszy kompilatory sa na tyle dobre, ze w przypadku podsystemu RTG optymalizacje w assemblerze sa delikatnie mowiac bezsensowne. Nawet takie altivec czy tam SSE da sie programowac bez potrzeby wciskania wszedzie asm().

Odpowiedz

Konrad Bielski
Redaktor

komentarz #2 wysłany: 2004-07-08 20:03 w odpowiedzi na komentarz #1

Na dzien dzisiejszy kompilatory sa na tyle dobre

Twierdzenie generalnie prawdziwe, ale nie oddaje do końca istoty problemu.

Jeśli rzeczywiście kompilatory, jak mówisz, są już tak perfekcyjne, to nie byłoby potrzeby ich dalszego rozwijania. A jednak w dalszym ciągu powstają nowe wersje, które generują o wiele lepszy kod niż wersje poprzednie. Najlepszym przykładem niech będzie GCC. Wersja 3.4.1 w porównaniu z wersją 2.95.xx daje lepsze rezultaty. A założe się, że kolejne wersje GCC będą generować jeszcze lepszy kod, więc w dalszym ciągu pozostaje gdzieś miejsce na poprawki.

Właśnie tę lukę można uzupełniać wstawkami w asemblerze. W systemie AmigaOS 4.0 niektóre elementy (np. kernel) posiadają takie wstawki. Nie byłoby to robione, gdyby nie dawało wymiernych efektów.

Nawet takie altivec czy tam SSE da sie programowac bez potrzeby wciskania wszedzie asm().

To prawda. Ponoć GCC 3.4.x ma taką zaletę, że prawie automatycznie generuje kod wykorzystujący AltiVeca.

Odpowiedz

Konrad Bielski
Redaktor

komentarz #3 wysłany: 2004-07-08 20:17 w odpowiedzi na komentarz #2

Jeszcze jedno. AmigaOS 4.0 ma wbudowane narzędzia do profilingu, więc dosyć dobrze widać w którym miejscu można próbować optymalizacji w ASM.

Odpowiedz

michalsc
konto zablokowane
lub usunięte
Czytelnik

komentarz #4 wysłany: 2004-07-08 20:37 w odpowiedzi na komentarz #2

Jeśli rzeczywiście kompilatory, jak mówisz, są już tak perfekcyjne, to nie byłoby potrzeby ich dalszego rozwijania. A jednak w dalszym ciągu powstają nowe wersje

Jesli uzawzasz, ze rozwijanie kompilatorow sprowadza sie tylko i wylacznie do poprawiania jakosci kodu generowanego przez nie, to strasznie mocno sie mylisz. Owszem, jakosc generowanego kodu sie poprawia, ale po pierwsze, kompilatory coraz bardziej zblizaja sie do standardow jezyka C i C++, po drugie wprowadzane sa usprawnienia w narzedziu jako takim, po trzecie czwarte i piate mozna wymienic mnostwo powodow ciaglego rozwoju. Jak i zreszta w wypadku kazdego typu oprogramowania.

Wersja 3.4.1 w porównaniu z wersją 2.95.xx daje lepsze rezultaty.

rodzina 2.95.xx jest jak na dzien dzisiejszy juz bardzo stara i porownanie jest kiepskie.

A założe się, że kolejne wersje GCC będą generować jeszcze lepszy kod, więc w dalszym ciągu pozostaje gdzieś miejsce na poprawki.

byc moze, ale kompilatory daza tylko asymptotycznie do tego co oferuja procesory. Dlatego powiedzialem, ze "na dzien dzisiejszy" nie ma juz sensu wciskanie wstawek assemblerowych. Nie ma juz zbyt duzo miejsca na kolejne wyciskanie sokow, a dodatkowo stale wzrastajaca zlozonosc procesorow powoduje, ze kod ktory dla programisty piszacego w assemblerze wydaje sie byc najoptymalniejszy, w rzeczywistosc jest duzo gorszy niz ten stworzony przez kompilator. Zdazaja sie wyjatki, ale to jest gra warta swieczki w intrach czy demkach, a nie w podsystemie grafiki.

Jesli zas kod w C jest niewydajny, czestokroc o wiele efektywniejsze bedzie znalezienie porzadniejszego algorytmu niz zerwanie z przenosnoscia kodu i wklepanie czegos w assemblerze.

Właśnie tę lukę można uzupełniać wstawkami w asemblerze. W systemie AmigaOS 4.0 niektóre elementy (np. kernel) posiadają takie wstawki. Nie byłoby to robione, gdyby nie dawało wymiernych efektów.

Konrad, jak zwykle wypowiadasz sie w kwestiach, w ktorych nie to ze nie jestes ekspertem (tych jest malo), ale nawet nie masz wiekszego pojecia. Piszac kernel systemu operacyjnego nie da sie wszystkiego zrobic w C. I nie chodzi tutaj bynajmniej o optymalizacje i wyciskanie potu z procesora. Po prostu czasem nawet najwspanialszy na swiecie kompilator nie bedzie potrafil wygenerowac czegos co w danym momencie jest konieczne. Wezmy na przyklad taki handler obslugujacy wyjatki zglaszane przez ppc. W momencie w ktorym jest wolany, nie moze korzystac ze stosu, dopoki sobie odpowiedniego nie przygotuje. Nie moze korzystac do woli z rejestrow, bo musi zachowac zawartosc doslownie wszystkich, a taki na przyklad kompilator C zalozy z gory ze ma do dostepu stos, ma garsc tzw. scratch registers, ktorych zawartosci nie musi zachowywac, bedzie wiedzial, ze procedurke konczy sie przez blr i pomyli sie w jeszcze wielu innyc aspektach.

Widzis, praktycznie kazdy system operacyjny ma swoje krytyczne fragmenty kernela napisane w asseblerze, niezaleznie od tego, czy to AmigaOS (ktorykolwiek) czy Pegasos, czy Windows, czy Linux, czy BSD czy AROS czy cokolwiek innego. I to nie dlatego, ze tak jest szybciej, a dlatego, ze inaczej sie nie da.

To prawda. Ponoć GCC 3.4.x ma taką zaletę, że prawie automatycznie generuje kod wykorzystujący AltiVeca.

A po co automatycznie, o wiele sensowniej jest wykorzystac cale mnostwo niby-funkcji wbudowanych w samo gcc, dzieki ktorym mozna z altivec'a korzystac w pelni swiadomie.

Odpowiedz

michalsc
konto zablokowane
lub usunięte
Czytelnik

komentarz #5 wysłany: 2004-07-08 20:38 w odpowiedzi na komentarz #3

Jeszcze jedno. AmigaOS 4.0 ma wbudowane narzędzia do profilingu, więc dosyć dobrze widać w którym miejscu można próbować optymalizacji w ASM.

Wbudowanego narzedzia do profilingu gratuluje. Ale szczerze powiedziawszy profiling dostarcza informacji o tym, gdzie poprawic algorytm a nie o tym, gdzie wcisnac kod w assemblerze.

Odpowiedz

Konrad Bielski
Redaktor

komentarz #6 wysłany: 2004-07-08 21:15 w odpowiedzi na komentarz #5

Owszem, jakosc generowanego kodu sie poprawia

Cieszy mnie, że temu twierdzeniu (ważnemu dla naszej dyskusji) nie przeczysz.

rodzina 2.95.xx jest jak na dzien dzisiejszy juz bardzo stara i porownanie jest kiepskie.

Porównałem z 2.95.xx, bo to w dalszym ciągu popularna wersja w amigowym świecie.

Jesli zas kod w C jest niewydajny, czestokroc o wiele efektywniejsze bedzie znalezienie porzadniejszego algorytmu niz zerwanie z przenosnoscia kodu i wklepanie czegos w assemblerze.

Truizm, no ale porozmawiajmy.

Nie tak dawno Rupprecht zmieniał algorytm dla funkcji BitMapScale() - rezultat oszołamiający. Gdyby optymalizował stary algorytm, to żeby nie wiem jak się starał, i ile wstawek w ASM robił to nie zbliżyłby się do osiągów funkcji korzystającej z nowego algorytmu. O tym jednak nie będziemy dalej dyskutować, bo wiadomo, że lepiej zastosować wydajniejszy czasowo algorytm niż optymalizować gorszy.

Rozmawiamy o możliwości optymalizacji tego samego algorytmu poprzez wstawki w asemblerze. Zgadzam się z Tobą, że kompilatory są coraz lepsze i coraz rzadziej człowiek jest w stanie "ręcznie" je poprawiać. Niemniej w dalszym ciągu istnieją takie możliwości.

Piszac kernel systemu operacyjnego nie da sie wszystkiego zrobic w C.

Ja pisałem o optymalizacji, a nie o tym, że coś musi być w ASM z konieczności. To samo dotyczy optymalizacji podsystemu RTG. Na pewno do niektórych jego części systemowi developerzy dodadzą kod w asemblerze i wierzę, podobnie jak oni, że przyniesie to pewne korzyści.

Wbudowanego narzedzia do profilingu gratuluje. Ale szczerze powiedziawszy profiling dostarcza informacji o tym, gdzie poprawic algorytm a nie o tym, gdzie wcisnac kod w assemblerze.

Jak zapewne wiesz, niektórych algorytmów poprawić się nie da, gdyż zwyczajnie lepszych już nie ma. I co wtedy? A może warto spróbować asemblera, skoro nie mamy nic do stracenia?

Utrata przenośności, o której pisałeś, także nie wchodzi w grę, gdyż na CVS i tak pozostaje ten sam kod w wersji bez optymalizacji w ASM, gotowy w każdej chwili do ponownego wykorzystania.

Odpowiedz

michalsc
konto zablokowane
lub usunięte
Czytelnik

komentarz #7 wysłany: 2004-07-08 21:42 w odpowiedzi na komentarz #6

Porównałem z 2.95.xx, bo to w dalszym ciągu popularna wersja w amigowym świecie.

Wiem. Trudno na to cos poradzic. Zreszta, czesc projektow jest napisana na tyle "bylejak" albo tez odstaje od obecnych standardow, ze nic innego poza 2.95.x ich nie skompiluje.

Rozmawiamy o możliwości optymalizacji tego samego algorytmu poprzez wstawki w asemblerze. Zgadzam się z Tobą, że kompilatory są coraz lepsze i coraz rzadziej człowiek jest w stanie "ręcznie" je poprawiać. Niemniej w dalszym ciągu istnieją takie możliwości.

Piszac kernel systemu operacyjnego nie da sie wszystkiego zrobic w C
Ja pisałem o optymalizacji, a nie o tym, że coś musi być w ASM z konieczności.

Ehm... Pokaz mi w ktorym miejscu kernel (osmiele sie przypomniec, ze jako przyklad podales kernel) wymaga az wstawek w assemblerze w celu zwiekszenia wydajnosci a nie w celu umozliwienia napisaniem pewnych fragmentow systemu tak, jak powinno sie je napisac? Ze co? Zoptymalizowali CopyMemQuick?

To samo dotyczy optymalizacji podsystemu RTG. Na pewno do niektórych jego części systemowi developerzy dodadzą kod w asemblerze i wierzę, podobnie jak oni, że przyniesie to pewne korzyści.

No owszem. Patrzac na strone, ktora podales, byc moze zoptymalizuja blity miedzy bitmapami czy tez konwersje pomiedzy roznymi przestrzeniami kolorow. Tylko po jakiego diabla, skoko obie te rzeczy doskonale wykonac potrafi pierwszy lepszy GPU karty graficznej?

Jak zapewne wiesz, niektórych algorytmów poprawić się nie da, gdyż zwyczajnie lepszych już nie ma. I co wtedy? A może warto spróbować asemblera, skoro nie mamy nic do stracenia?

O wybacz. Jest cholernie duzo do stacenia. Zamiast rozwijac w systemie to, co jest potrzebne programisci beda sie bawic w optymalizacje w assemblerze? Przy takiej zabawie nie masz nic do stracenia jesli programowanie to twoje hobby i ani nikt ci za twoja prace nie placi ani nie ma calej bandy uzytkownikow chcacych kompletnego systemu. A taka zabawa, to zupelnie jak kiedys pisanie scenowych dem? Kazdy cylk procesora na wage zlota, a uzytkownicy niech sobie czekaja? Hmm. A na koniec po tygodniu meczacej walki z optymalizacja kodu pod RISC'a krzykna - huuuura, skrocilismy czas dzalania funkcji o 0.1%.

Konrad, nie zrozum mnie zle. Ja nie szykuje tutaj Jihadu na biednych developerow AmigaOS. CO wiecej, ciesze sie, ze AmigaOS4 (tak ja i zreszta MorphOS) zyje i rozwija sie. Po prostu jak dla mnie przechwalki w stylu: graphics.library przyspiesza od 2 do 10 razy, a jeszcze nie optymalizowalismy w assemblerze to po prostu glodne kawalki rzucane w strone amigowcow, ktorzy pamietajac stare czasy (C jest do dupy i w ogole be, a assembler to wszystko co najlepsze) zaczna skakac z radosci jak male dziecko ktore dostalo lizaka. Nic wiecej.

Odpowiedz

Konrad Bielski
Redaktor

komentarz #8 wysłany: 2004-07-08 23:14 w odpowiedzi na komentarz #7

Pokaz mi w ktorym miejscu kernel (osmiele sie przypomniec, ze jako przyklad podales kernel)

A może źródła kernela mam Ci jeszcze podesłać?

Wybacz ten sarkazm, ale piszesz do mnie "pokaż mi w którym miejscu" chociaż dobrze wiesz, że system o którym mówimy jest komercyjny, a nie typu Open Source i nic Ci pokazać nie mogę, choćbym miał dobre chęci.

Tylko patrzeć jak znęcony zapachem krwi przyfrunie tu jakiś Mądraliński i w następnym komentarzu przeczytamy: "ci cholerni betamuszkieterzy jak zwykle zasłaniają się NDA i nawet głupich źródeł kernela nie chcą nam wszystkim pokazać, co bez wątpienia dowodzi, że DMA w A1 nie działa". Mnie to śmieszy, ale są tacy, których tego typu teksty bulwersują, a stąd już tylko jeden krok do kolejnej długiej i bezsensownej dyskusji.

No owszem. Patrzac na strone, ktora podales, byc moze zoptymalizuja blity miedzy bitmapami czy tez konwersje pomiedzy roznymi przestrzeniami kolorow.

Być może - na pewno spróbują, skoro tak napisali.

Tylko po jakiego diabla, skoko obie te rzeczy doskonale wykonac potrafi pierwszy lepszy GPU karty graficznej?

Proszę, proszę od stanowczego stwierdzenia "optymalizacje w assemblerze sa delikatnie mowiac bezsensowne", przechodzimy do pytania "po jakiego diabła" to robić? Już tłumaczę, może się tak zdarzyć, że CPU w komputerze będzie mocne, a GPU słabe lub tak bardziej ogólnie, że lepiej mieć system zoptymalizowany.

Zamiast rozwijac w systemie to, co jest potrzebne programisci beda sie bawic w optymalizacje w assemblerze?

Programiści z natury są leniwi. Uwierz mi, że nie będą się bawić w optymalizacje w asemblerze, jeśli uznają, że nie ma takiej potrzeby lub że przyrost prędkości będzie znikomy.

Po prostu jak dla mnie przechwalki w stylu: graphics.library przyspiesza od 2 do 10 razy, a jeszcze nie optymalizowalismy w assemblerze to po prostu glodne kawalki rzucane w strone amigowcow, ktorzy pamietajac stare czasy (C jest do dupy i w ogole be, a assembler to wszystko co najlepsze) zaczna skakac z radosci jak male dziecko ktore dostalo lizaka. Nic wiecej.

Jak zwykle na końcu wychodzi to, co rozmówca miał na myśli pisząc swój pierwszy komentarz. Natywny system RTG w AmigaOS 4.0 jest już w tej chwili bardzo szybki. Niektóre funkcje będą jeszcze zmieniane, choć na tym etapie nie jest to optymalizacja w asemblerze, lecz szukanie optymalnych algorytmów.

Nikt nie twierdzi, że asembler to cudowne panaceum na wszelkie dolegliwości związane z brakiem szybkości. Pamiętaj jednak o jakim systemie mówimy, to jest AmigaOS - tu się bardziej ceni, jeśli coś zostanie zoptymalizowane, niż gdyby w wymaganiach systemu stało "kup sobie szybszy komputer".

Odpowiedz

michalsc
konto zablokowane
lub usunięte
Czytelnik

komentarz #9 wysłany: 2004-07-09 07:55 w odpowiedzi na komentarz #8

Wybacz ten sarkazm, ale piszesz do mnie "pokaż mi w którym miejscu" chociaż dobrze wiesz, że system o którym mówimy jest komercyjny, a nie typu Open Source i nic Ci pokazać nie mogę, choćbym miał dobre chęci.

Wystarczylo by mi, gdybys powiedzial ogolnie co zostalo zoptymalizowane w assemblerze. Wybacz Konrad, ale tak samo jak i ja nie masz wgladu do zrodel systemu, gdyz jestes betatesterem a nie developerem. Dlatego tez uwazam, ze palnales glupote podajac jako przyklad miejsca optymalizowanego kernel, a kiedy dowiedziales sie, dlaczego niektore czesci kazdego kernela sa pisane w assemblerze, probujesz delikatnie sie wycofac.

Wyjasnienie, ze ktorys z developerow Ci to powiedzial tez bedzie nijakie, bo developerzy tlumacza swiatu zewnetrznemu wszystko tak, aby bylo to zrozumiale.

Tylko patrzeć jak znęcony zapachem krwi przyfrunie tu jakiś Mądraliński i w następnym komentarzu przeczytamy: [...]. Mnie to śmieszy, ale są tacy, których tego typu teksty bulwersują, a stąd już tylko jeden krok do kolejnej długiej i bezsensownej dyskusji.

Ok, to inaczej. Powiedz, skad wiesz ze pewne fragmenty kernela napisane sa w assemblerze nie z koniecznosci, a w celach optymalizacji

Tylko po jakiego diabla, skoko obie te rzeczy doskonale wykonac potrafi pierwszy lepszy GPU karty graficznej?
Proszę, proszę od stanowczego stwierdzenia "optymalizacje w assemblerze sa delikatnie mowiac bezsensowne", przechodzimy do pytania "po jakiego diabła" to robić?

Ogolny sens, mimo innego pytania, pozostaje. Jesli uwazam, ze w dzisiejszych czasach optymalizacje w assemblerze sa bezsensowne, to i glupim wydaje mi sie ich wciskanie na sile. Dlatego pytam "po jakiego diabla". Nie rozumiem, dlaczego az tak sie zdziwiles.

Już tłumaczę, może się tak zdarzyć, że CPU w komputerze będzie mocne, a GPU słabe lub tak bardziej ogólnie, że lepiej mieć system zoptymalizowany.

Juz tlumacze. Transfer pomiedzy pamiecia RAM a pamiecia karty graficznej jest na tyle malo wydajny, ze nie zmieni to sytuacji. To, co byc moze szybciej policzy procesor, bedzie sie dlawilo przepychane przez AGP. Tak dla przykladu ze swiata pecetowego i AROSa. Driver robiacy wszystko softwarowo (sterownik vesa) wydawal byc sie strasznie szybki na Athlonie XP 2000+, dopoki nie zabralem sie za pisanie sterownika do nvidii siedzacej w tym komputerze. I nie wazne, czy kopiowanie bitmap, skalowanie czy cokolwiek innego - driver do nvidii byl praktycznie zawsze szybszy. Tylko w jednym tescie byly sobie rowne - PutPixel, gdyz to trudno zoptymalizowac (gdyz jak to powiedziales, uzywa sie najlepszego dostepnego algorytmu), a do assemblera przenosic tego nie ma sensu, gdyz policzenie adresu pod ktory ma sie cos wyslac to cos okolo 0.001% calej operacji.

I zeby nie bylo nieporozumien - niezaleznie od szybkosci procesora, roznica w dzialaniu obu driverow byla bardzo mocno widoczna nawet na najstarszych kartach nvidii (pomijajac Rive128, bo jej driver po prostu nie obsluguje).

Jesli powiesz, ze byc moze ktos bedzie w AmigaOne uzywal karty graficznej jeszcze wolniejszej i bardziej zacofanej niz powiedzmy jakas tam RivaTNT, spiesze z odpowiedzia - ze jeszcze starszym kartom liczenie wszystkiego przez PPC nie pomoze, gdyz waskie gardlo jakim sa transfery danych po szynie PCI w ich wypadku jest jeszcze wezsze.

Programiści z natury są leniwi.

Doprawdy? Skad masz takie rewelacje?

Uwierz mi, że nie będą się bawić w optymalizacje w asemblerze, jeśli uznają, że nie ma takiej potrzeby lub że przyrost prędkości będzie znikomy.

Jak na razie ton optymistycznych wypowiedzi na stronie, do ktorej link podales, sugeruje, ze z radoscia sie za to zabiora. A co z reszta systemu? Poczeka?

Jak zwykle na końcu wychodzi to, co rozmówca miał na myśli pisząc swój pierwszy komentarz.

Slucham?

Natywny system RTG w AmigaOS 4.0 jest już w tej chwili bardzo szybki. Niektóre funkcje będą jeszcze zmieniane, choć na tym etapie nie jest to optymalizacja w asemblerze, lecz szukanie optymalnych algorytmów.

Alez panie Konradzie Bielski! Ja sie z tego bardzo ciesze. Szkoda mi, a owszem, ze swiat amigowcow coraz bardziej rozrywa sie na kawalki, ale rozwoj AmigaOS - niezaleznie czy jesto to Morphos, ktorego sympatia nie dazysz, czy tez AmigaOS4, ktorego uwielbiasz, czy AROS, ktory cie po prostu nie interesuje, taki rozwoj zawsze mnie cieszy. Wyrazilem tylko swoje zdanie co do optymalizacji w assemblerze, nie dorabiaj do tego zadnej teorii spiskowej prosze.

Nikt nie twierdzi, że asembler to cudowne panaceum na wszelkie dolegliwości związane z brakiem szybkości.

Niestety wyglada na to, ze wielu amigowcow tak uwaza. Stara milosc to TrashOne czy DevPac'a nie zdzewieje

Pamiętaj jednak o jakim systemie mówimy, to jest AmigaOS - tu się bardziej ceni, jeśli coś zostanie zoptymalizowane, niż gdyby w wymaganiach systemu stało "kup sobie szybszy komputer".

Przy obecnych systemach takie wymagania (szybszy komputer) stawiaja zwykle tylko firmy produkujace coraz to bardziej zlozone gry. Ale w tym wypadku nawet przepisanie calego systemu operacyjnego (mowie ogolnie, nie zabij mnie) do assemblera nic nie pomoze.

Odpowiedz

Mariusz Barczyk
Czytelnik

komentarz #10 wysłany: 2004-07-09 10:12 w odpowiedzi na komentarz #9

Programiôci z natury sâ leniwi.

Doprawdy? Skad masz takie rewelacje?

Ja moge powiedziec w czym sie lenistwo objawia. Chce im sie cos napisac, ale w bardzo wielu przypadkach nie chce im sie swojego dziela puscic do ludzi. Ja tez to mam.

Odpowiedz

MDW
Czytelnik

komentarz #11 wysłany: 2004-07-09 10:26 w odpowiedzi na komentarz #6

Porównałem z 2.95.xx, bo to w dalszym ciągu popularna wersja w amigowym świecie.

Oj tak tak. Na przyklad w swiecie MorphOSowym niestety.

Odpowiedz

Albert Jasiński
Czytelnik

komentarz #12 wysłany: 2004-07-14 01:29 w odpowiedzi na komentarz #11

Ja tylko 3 grosze dorzuce

1. Konrad się troche zapędził i w ferworze walki brakło mu argumentów za sensem przenoszenia elementów do assemblera. Ja jednak jako beta-muszkieter spieszę mu z pomocą i przypominam wszystkim że AmigaOS4 będzie też wydany na amigi klasyczne z procesorami 603e i 604e. Będzie to też wersja komercyjna, programiści są więc w pewnym sensie zobowiązani do tego aby i wersja dla tych procesorów była odpowiednio szybka. Inaczej by było gdyby OS4 był wydany tylko w jednej , ogólnej wersji PPC.... i tylko (zupełnie przypadkowo) działał na starych amigach. Wtedy programiści mogli by napisać na pudełku że wymaga się 603e ale zaleca się G3 lub G4. 2. Również moim zdaniem, przenoszenie elementów systemu do assemblera to nieporozumienie. Zyskana prędkość nie rekompensuje moim zdaniem utraty przejżystości źródeł i portowalności. Konrad, proszę nie pisz że na CVS są w dalszym ciągu źródła w czystym C, nie wierzę żeby programiści przepisując coś do ASM nie unikneli wprowadzenia pewnych niekompatybilności z wersją C. Dlaczego ? Bo jak sam napisałeś, programiści są leniwi i mając wersję kodu w ASM nie będą tego kodu w kolejnych wersjach przenosić do C. 3. Podstawową wadą amigowców a w szczególności programistów jest dążenie do owego wyciśnięcia wszystkich soków z procesora. Właśnie z tego powodu zarówno OS4 jak i MOS zostały napisane na PPC. Poprostu programistów bolało to że przez "problem" z endianami system nie byłby odpowiednio szybki w stosunku do możliwości sprzętu. A szkoda .... bo pewnie na kolejnych prockach x86 taki emulowany Amithlon będzie jako emulator działał szybciej niż natywny OS4 czy MOS na G4. Jasne ... procki PPC też się rozwijają ... ale powiedzmy sobie szczerze ... jakie mamy szanse że ktoś zaprojektuje, wyprodukuje i będzie sprzedawał płyty główne z G5 czy czymś tam jeszcze ? .... i ile one będą kosztować? Amithlona można znacznie przyspieszyć dokładając niewielkie pieniądze .... przy PPC już nie jest tak różowo. Jak zapewne wiecie ... już teraz niektóre programy napisane "natywnie" na amithlona są szybsze niż nartywne wersje dla MOS na najszybszyn pegazie, a przecież procesory kilkakrotnie szybsze od obecnych ... ukazują się może nie z dnia na dzień ale z miesiąca na miesiąc. No ale skoro "mądrzy" programiści nam wtłukli do głowy to "PPC rulez", a myśmy się na to zgodzili z powodu jakiejś chorej nienawiści do procesorów x86, nienawiści która jest zupełnie niewytłumaczalna bo większość amigowców (szczególnie programistów) i tak używa PCtów, oczywiście tłumaczą to koniecznością... ale nie można w to wierzyć. Oni poprostu są świadomi obecnej wyższości tych komputerów i z tego kożystają ... a biednych szaraczków amigowców namawiają do PPC ...

Odpowiedz

Kornel Lesinski
Czytelnik

komentarz #13 wysłany: 2004-07-23 17:53

A moje 3 grosze:
Nowe wersje kompilatorow wypuszczane sa np. by obslugiwaly nowopowstale procesory. Poprawia sie nieustannie tez wysokopoziomowa interpretacje jezyka (zgodnosc ze standardem i obsluga roznych dziwadel, ktorych szczegolnie duzo w C++).

Ale ciekawostka jest ze im nowsze procesory tym mniejsza szansa, zeby czlowiek recznie mogl napisac asm lepszy od kompilatora(!).
Nowoczesne procesory wykonuja kod w innej kolejnosci niz jest on napisany, uzywajac kilku roznie powiazanych ze soba jednostek obliczeniowych, na to wszystko ma wplyw czasem skomplikowany cache, przewidywanie skokow, i wiele innych... to wszystko jest nieporownywalnie trudniejsze niz liczenie taktow dla m68k.
W trywialnych przypadkach jak "copy mem quick" kompilatory juz maja metody na zrobienie najlepszego kodu, a w pogmatwanych przypadkach czlowiek nie da rady napisac 10,000 linii asm lepiej od kompilatora (ale freidenowie sa nadludzcy

Odpowiedz

eXec - magazyn użytkowników komputerów Amiga

AmigaOS 4.0 - natywne RTG