Ależ ma pojęcie tylko trochę miesza. Nowe instrukcje bądź poszerzenie możliwości starych oczywiście wymaga przekompilowania źródeł by skorzystać z nowych instrukcji - inaczej procek dostanie dokładnie takie instrukcje jakie wypluł kompilator te 10-20 lat temu - czyli standardowe 020/030/040/060 :) Co innego bajerki typu "fuzje" które są na poziomie samego rdzenia robione (czyt. tam gdzie pary instrukcji standardowych 68k mogą być połączone w jedną i w 1 cyklu wykonane). Jeszcze inaczej wygląda jak aplikacja korzysta z bibliotek matematycznych, wtedy wystarczy samą bibliotekę uaktualnić i soft automatycznie skorzysta z nowych bajerów.
Natomiast uruchomienie drugiego rdzenia jest z pewnością trudniejsze niż doklejenie obsługi nowych instrukcji, bo o ile nowe instrukcje właśnie można przez rekompilację czy biblioteki dodać do systemu to multicore musi być obsługa w systemie od początku, inaczej konieczna będzie raczej kosztowna proteza bez zadowalającego rezultatu.

Wykorzystanie drugiego rdzenia jest o wiele trudniejsze niż wykorzystanie nowych instrukcji. Musisz rozpisać algorytm tak, aby pracował równolegle.

wykorzystanie nowych instrukcji jest o wiele trudniejsze, bo musisz naprawde napisac od zera caly program, w asm!, nie licz szybko na optymalny kompilator, w przypadku bloku instrukcji simd, nie licz kiedykolwiek. Zdecydowana wiekszosc algorytmow daje sie b.dobrze zrownoleglic, jezeli masz juz napisany taki kawalek kodu w 68k lub C, to sie nie zmienia, nie kodujesz od poczatku tego algorytmu...

Kolejne rdzenie bez solidnego wsparcia systemu operacyjnego nie dają wielkiego przyrostu wydajności (chyba że aplikacja specjalnie jest zoptymalizowana pod kilka rdzeni, ale to są wyjątki), zresztą przy wsparciu też ten przyrost nie jest zbyt imponujący.

mam odmienne zdanie, dla mnie o wiele latwiej przejsc na kolejne rdzenie niz na zupelnie nowe instrukcje, przejscie na zupelnie nowe instrukcje porownac moge do przejscia na zupelnie nowy procesor, a i tak ucieczki od wielordzeniowosci w fpga nie ma, bo w duze Mhz o wiele trudniej wejsc niz w wielordzeniowosc, w fpga o wiele szybciej rosna zasoby niz Mhz, dla duzo wiekszych Mhz trzeba na nowo wiekszosc projektowac... Nie sadze nawet zeby to byle warte swieczki, zamiast dodawac nowe instrukcje, w to miejsce lepiej np: zwiekszyc cache, dodac kolejne ALU, nowy rdzen itp. Zreszta, jakie nowe instrukcje mozna dodac do 68k ktore dalyby np: 95% wzrost wydajnosci, jak w przypadku kolejnego rdzenia ?. Nawet, zamiast dodawac nowe instrukcje do 68k, lepiej dodac nowa funkcjonalnosc do SAGA.

A z innej beczki, jak sobie wyobrażasz obsługę drugiego rdzenia przez AmigaOS?

Nie bedzie, jak wiesz. Kolejne rdzenie sa dla nowych programow 68k. Stare programy tez moglyby skorzystac, ale to wymaga dostepu do zrodel AOS3, czyli mowiac krotko, nie skorzystaja, tak samo zreszta jak nie skorzystaja z nowych instrukcji czy planowanych rozszerzen, jedynie z optymalizacji :)

Ostatnia edycja: 02.05.11 21:46:32

wykorzystanie nowych instrukcji jest o wiele trudniejsze, bo musisz naprawde napisac od zera caly program, w asm!,

Dlaczego musisz? Jakos nikt nie musial przepisywac programow pod PPC od zera, zeby skorzystac z AltiVec-a. Nikt nie musial przepisywac programow pod x86 od zera, zeby skorzystac z MMX/3DNow!/SSE. Wystarczylo zmodyfikowac programy przez dodanie odpowiednich wstawek w assemblerze. Wstawek, nie calych programow.

Jeszcze raz powtorze. Dlaczego musisz przepisac caly program od zera zeby skorzystac z nowych instrukcji. Dlaczego nikt nie musial przepisywac calego programu, zeby skorzystac z FPU?

Zreszta, jakie nowe instrukcje mozna dodac do 68k ktore dalyby np: 95% wzrost wydajnosci, jak w przypadku kolejnego rdzenia ?

Instrukcje SIMD, na przyklad takie jak w jednostce AltiVec lub SSE. Chociaz akurat SSE jest o wiele gorsze.

Czyli bedzie taka sama sytuacja jak w OS4? Dwurdzeniowy CPU z tym, ze wykorzystywany jest tylko i wylacznie jeden rdzen? Dla mnie jest to marnowanie zasobow.

zauwaz, ze nowe instrukcje tez nic nie zmieniaja, bez dostepu do zrodle AOS3 niewiele mozna zrobic, takze to nie jest alternatywa. Tu rozpatrujemy inny przypadek, co dalej, nowe instrukcje, czy kolejny rdzen, wg. mnie, kolejny rdzen N68k :)

No i? Czy po przejsciu z 68000 na 68030 + FPU programisci musieli przepisac od nowa wszystkie programy?

tak, dla asm trzeba przepisac w calosci, w C sprawe zalatwil kompilator C - std. jezyka C zaklada uzycie FPU (nawet tam gdzie FPU nie ma), ten kompilator FPU jednak ktos musial napisac, ALE jezyk C juz nie zaklada istnienia SIMD, wiec w tym przypadku trzeba przepisac program od nowa i jeszcze napisac do tego odpwiedni kompilator, a dla asm trzeba oczywiscie przepisac w calosci.

zauwaz, ze nowe instrukcje tez nic nie zmieniaja, bez dostepu do zrodle AOS3 niewiele mozna zrobic, takze to nie jest alternatywa.

Bez dostepu do zrodel OS3 mozna duzo zrobic. W przypadku nowych rejestrow ktore musza byc zachowane przy przelaczaniu taskow wystarczy podmiana kilku funkcji w exec.library. Sam OS3 nie musi korzystac z nowych instrukcji.

tak, dla asm trzeba przepisac w calosci,

Kiedy mialem jeszcze Amige pisalem tylko i wylacznie w assemblerze. Mozesz mi wierzyc albo nie, ale nie musialem przepisywac programow od zera tylko po to, zeby skorzystac z fpu.

Dlaczego musisz? Jakos nikt nie musial przepisywac programow pod PPC od zera, zeby skorzystac z AltiVec-a. Nikt nie musial przepisywac programow pod x86 od zera, zeby skorzystac z MMX/3DNow!/SSE. Wystarczylo zmodyfikowac programy przez dodanie odpowiednich wstawek w assemblerze. Wstawek, nie calych programow.

w zadnym przypadku nie trzeba przepisywac tych czesci programu do ktorych nie ma nowych instrukcji. przepisujesz tam, do czego zostaly powolane nowe instrukcje, prawda. niektore programy beda praktycznie w calosci, niektore w jakims tylko ulamku. w przypadku kolejnego rdzenia, nic takiego nie robisz, masz optymalna procedure, takiej samej uzywasz na kolejnym rdzeniu itd. itp. oczywiscie zdaje sobie sprawe, ze nie dt. to kazdego algorytmu, szczegolnie takiego gdzie nie mozna przetwarzac danych w malych porcjach itd.

nowy rdzen ma jeszcze taka przewage nad nowymi instrukcjami, ze jak system zaczalby uzywac kolejnych rdzeni, odczujesz to w przypadku nawet starych programow... nowy rdzen jest uniwersalny, nowe instrukcje akceleruja tylko operacje do ktorych zostaly powolane...

Instrukcje SIMD, na przyklad takie jak w jednostce AltiVec lub SSE. Chociaz akurat SSE jest o wiele gorsze.

to co sprawdza sie na x86 czy PPC, nie musi sprawdzic sie na 68k, to po pierwsze, po drugie, naprawde nalezy przeanalizowac sensownosc takiego bloku instrukcji w 68k. instrukcje sse sa ogolnie przereklamowane, jak skompilujesz program na sse, to instrukcje sse beda uzywane tak jakby to byl fpu, wzrost wydajnosci wynika z faktu, ze analogiczne instrukcje fpu sa np: 10x razy wolniejsze niz sse, podobnie jest na AVX. fpu n68k bedzie znaczaco wydajniejszy, wiec simd nie dokona imponujacego wzrostu :). Uwazam nawet, ze w takim przypdku zamiast dodawac blok nowych instrukcji, wystarczy jedynie dodac kilka rozszerzen do FPU, przezroczysta dla programistow fuzja, kolejne rejestry... czy tak nie jest latwiej ?:)

Sam OS3 nie musi korzystac z nowych instrukcji.

dokladnie, wiec dla AOS3 nowe instrukcje nie maja znaczenia, dla rozwoju OS, nowy rdzen jak najbardziej.

Kiedy mialem jeszcze Amige pisalem tylko i wylacznie w assemblerze. Mozesz mi wierzyc albo nie, ale nie musialem przepisywac programow od zera tylko po to, zeby skorzystac z fpu.

automagicznie sie wstawily, czy wiedziales o ich istnieniu np: uzyles makr ?. mogles skorzystac z bibliotek, no tak, potem wystarczylo napisac OD NOWA! (od zera) biblioteki i juz uzywa fpu,simd i bog wie co jeszcze moze byc :)

Ostatnia edycja: 02.05.11 23:02:50

errata, "podobnie jest na AVX" - VMX

wykorzystanie nowych instrukcji jest o wiele trudniejsze, bo musisz naprawde napisac od zera caly program

Zależy o jakich instrukcjach mowa. Biblioteki matematyczne mają dać prosty dostęp do szeregu uniwersalnych procedur w obliczeniach dla różnorakich konfiguracji sprzętowych (by nie musieć zastanawiać się jaki jest FPU, czy w ogóle jest FPU itp.). Tutaj jak napisałem wystarcza właśnie uaktualnienie bibliotek i automagicznie wszystkie programy z nich korzystające dostają wsparcie do nowych ficzerów. A jednak raczej sporo softu z libsów używa. Druga sprawa - jak wyobrażasz sobie dodanie obsługi drugiego rdzenia? Toż musisz przepisać całe jądro systemu do tego, a program I TAK nie skorzysta z obu rdzeni naraz (co najwyżej część uruchomionych programów będzie na jednym rdzeniu, a część na drugim) bo na to jak na SIMD nie masz automagicznej formułki w kompilatorze. To gdzie niby ta "prostota"?

przejscie na zupelnie nowe instrukcje porownac moge do przejscia na zupelnie nowy procesor

Bzdura, PPC co generację ma nowe instrukcje i nigdy to nie było problemem dla systemu (np. obsługa AltiVec pod MorphOS). Natomiast obsługa dual core już musiała być od początku do systemu dodana.

bo w duze Mhz o wiele trudniej wejsc niz w wielordzeniowosc

Przyjrzyj się 050 - 1 integer pipeline. Kto każe na jednym potoku robić nie wiadomo ile MHz? Przecież konstruktorzy już zapowiedzieli, że jest to po prostu młodszy brat 070, który "ma działać" bo takie a nie inne FPGA były dostępne jak zaczęli. Nowsze FPGA = dużo lepsze softcore. Superscalar. Ale...

zamiast dodawac nowe instrukcje, w to miejsce lepiej

Rzecz w tym, że dodawanie nowych instrukcji nie kosztuje tak wiele w FPGA jak dodawanie nowych ALU pipeline, za to można lepiej wykorzystać to co już jest w sofcore.

Zreszta, jakie nowe instrukcje mozna dodac do 68k ktore dalyby np: 95% wzrost wydajnosci

Pokaż mi jak zrobiłbyś Quake by działał na 2 rdzeniach z 195% wydajności więcej...bo przepisanie źródeł na korzystanie z nowego, lepszego FPU to akurat będzie pikuś w porównaniu z wykorzystaniem dual core.

zamiast dodawac nowe instrukcje do 68k, lepiej dodac nowa funkcjonalnosc do SAGA

Oh, aż dziw bierze, że nie dołączyłeś do projektu... widać tam sami amatorzy są co nie wiedzą co jest lepsze ;)

Kolejne rdzenie sa dla nowych programow 68k

Tak jak i nowe rozkazy, tyle że nowe rozkazy są łatwiejsze do zaimplementowania. Jeśli nie wierzysz to weź zrób program mnożący elementy 2 macierzy 128x128 w double i załącz raz optymalizacje SSE, a za drugim razem spróbuj to samo na dual core zrobić. Zobaczymy co prostsze :P

Tutaj jak napisałem wystarcza właśnie uaktualnienie bibliotek i automagicznie wszystkie programy z nich korzystające dostają wsparcie do nowych ficzerów.

to nie jest ani optymalne, ani wydajne. z nowych instrukcji trzeba korzystac bezposrednio, inaczej traca swoj atut.

Bzdura, PPC co generację ma nowe instrukcje

piszemy o 68k, a nie ppc. co jest dobre dla ppc, moze byc zle dla 68k - szczegolnie n68k w fpga. chyba wszyscy nie chcemy bezsensownej komplikacji listy rozkazow z skad inad udanego 68k. mamy dla 68k swietne asemblery, dosc dobre kompilatory C i innych jezykow, mnostwo innych programow itd.. nie mamy tylko systemu korzystajacego z smp, ale to jest tysiac razy latwiejsze niz wszystko pozostale.. :)

Natomiast obsługa dual core już musiała być od początku do systemu dodana.

nie musi byc. bylaby mile widziana i pozadane.

Rzecz w tym, że dodawanie nowych instrukcji nie kosztuje tak wiele w FPGA jak dodawanie nowych ALU pipeline

w architekturze rozkazow 68k dwie jednostki ALU wlasciwie powinny wystarczyc. natomiast nowe instrukcje, takie jak sse operujace na 128/256 bitowych kosztuja bardzo duzo zasobow fpga - nawet tyle co kolejny CPU, bez sensu marnowac zasoby, ktore tylko ladnie wygladaja na papierze i moze beda w szesciu bibliotekach napisanych od zera, z ktorych korzysta setka programow, ktore dzieku temu cudownemu poswieceniu przyspiesza o cale 5% - optymistycznie :)

Pokaż mi jak zrobiłbyś Quake by działał na 2 rdzeniach z 195% wydajności więcej...bo przepisanie źródeł na korzystanie z nowego, lepszego FPU to akurat będzie pikuś w porównaniu z wykorzystaniem dual core.

Quake ?. Najlepiej przyspieszyc dodajac nowe funkcje do SAGA :). Samo np: teksturowanie przyspieszy dzialanie gry x razy. Za pomoca nowych instrukcji SIMD niewiele mozna zdzialac. To jest dosc zlozony program, musielibysmy podejsc do kazdego fragmentu tego programu osobno. Tak sie akurat sklada, ze wszelkie masive operacje w grach 3D nadaja sie do przetwarzania rownoleglego... ALE dajmy na to, zostaly dodane instrukcje simd bedace odpowiednikiem sse, o ile mozna przyspieszyc dzialanie takiej gry - 5% wyglada dosc optymistycznie, pod warunkiem calkowitego przepisania tych fragmentow programu do ktorych mozna uzyc nowych instrukcji.. Zalozmy jednak moja opcje, czyli kolejny rdzen, praktycznie da sie przyspieszyc wiekszosc fragmentow programu, bez przpisywania kodu programu od zera - wystraczy podzielic... :) - 5% to trzeba byc naprawde kulawym programista, wiec moze byc to 50%, wiecej, mozliwe, wszystko zalezy od rodzaju programu :). A co bedzie jak taki program korzysta z wielowatkowosci w systemie, to w samym programie nic nie trzeba zmieniac... :)

Oh, aż dziw bierze, że nie dołączyłeś do projektu... widać tam sami amatorzy są co nie wiedzą co jest lepsze

nie wydaje mi sie zeby planowali simd, moze kiedys, jak juz nie beda miec nic lepszego do dodania i beda wolne zasoby :).

Tak jak i nowe rozkazy, tyle że nowe rozkazy są łatwiejsze do zaimplementowania.

oczywiscie, wiec po co komplikowac liste rozkazow 68k. kolejny rdzen ma taka przewage nad nowymi instrukcjami, ze nawet stare programy moga skorzystac - wystarczy nowy OS.

Jeśli nie wierzysz to weź zrób program mnożący elementy 2 macierzy 128x128 w double i załącz raz optymalizacje SSE, a za drugim razem spróbuj to samo na dual core zrobić. Zobaczymy co prostsze

prostsze jest to co juz masz, jezeli napisales optymalna procedure 68k FPU obliczajaca macierz, w dowolnym jezyku, to latwiej bedzie uruchomic to samo na kolejnym rdzeniu...

Ostatnia edycja: 03.05.11 14:36:49

to nie jest ani optymalne, ani wydajne. z nowych instrukcji trzeba korzystac bezposrednio, inaczej traca swoj atut

I dlatego wiele poważnych programów (np. matlab) korzysta z bibliotek matematycznych algebry liniowej (BLAS) ;) Bo to jest niewydajne i nieoptymalne :] A to, że bez zmiany choćby bajtu programu można wykorzystać akcelerację CUDA czy przystosować AVX to co? :> No nie, do każdego proca, do każdej listy rozkazów będą execa budować ^^ Gdyby każdy program miał działać maksymalnie wydajnie to programiści musieliby zostać przy C i ASM :P

Najlepiej przyspieszyc dodajac nowe funkcje do SAGA

I zbudować API do tego, bo samo z siebie nie zadziała.

Za pomoca nowych instrukcji SIMD niewiele mozna zdzialac

Ja nie wymyśliłem instrukcji SIMD, to wymyślili twórcy (że jak będzie możliwy do zagospodarowania kawałek FPGA to można dać DSP i/lub SIMD).

To jest dosc zlozony program

Tak, natomiast fragmenty krytyczne na PC były pisane w ASM, tutaj i tak aż się prosi o przepisanie na native 68k+ rozszerzenia softcore. I będzie to szybciej niż próba przepisania gry zupełnie nieprzystosowanej do dualcore właśnie na 2 rdzenie. I tak z każdą klasyczną aplikacją.

A co bedzie jak taki program korzysta z wielowatkowosci w systemie

A gdzie masz ten amigowy system dla 68k?

kolejny rdzen ma taka przewage nad nowymi instrukcjami, ze nawet stare programy moga skorzystac

Nie skorzystają inaczej niż stare programy z PC na dual core... czyli jeśli wymusisz uruchomienie quake3 na jednym rdzeniu i będzie crash to system na drugim rdzeniu nawet tego nie odczuje. Dla aplikacji jako tako bez różnicy.

ezeli napisales optymalna procedure 68k FPU obliczajaca macierz, w dowolnym jezyku, to latwiej bedzie uruchomic to samo na kolejnym rdzeniu

O RLY? A jak to niby zrobisz? :> Automagicznie się podzieli procesor obowiązkami? Nie. Aplikacja MUSI być przepisana :) Gdyby wszystko było takie proste to na PC dawno byłoby multum aplikacji korzystających z 4 rdzeni, a tymczasem appsy korzystają zasadniczo z 1 w pełni, a każdego kolejnego coraz gorzej. Są oczywiście wyjątki...

I dlatego wiele poważnych programów (np. matlab) korzysta z bibliotek matematycznych algebry liniowej (BLAS) Bo to jest niewydajne i nieoptymalne

uprzednio programy zostaly przystowane, zostaly praktycznie przepisane. biblioteki matematyczne w AOS sa zbyt proste zeby daly wiecej niz kilka procent.

A to, że bez zmiany choćby bajtu programu można wykorzystać akcelerację CUDA czy przystosować AVX to co?

zeby wykorzystac CUDA czy AVX, dany fragment programy trzeba przepisac w calosci, od nowa spojrzec na to i napisac od zera, uprzednio nauczyc sie tego...

Tak, natomiast fragmenty krytyczne na PC były pisane w ASM, tutaj i tak aż się prosi o przepisanie na native 68k+ rozszerzenia softcore.

jak juz masz napisany fragment np: w C, rozbijasz na kilka watkow. mniej pracy to kosztuje niz przepisanie na nowe instrukcje simd ala sse.

I zbudować API do tego, bo samo z siebie nie zadziała.

lub odwolac sie beposrednio do rejestrow. tak czy owak, niewielkie rozszerzenia SAGA predzej przyspiesza x razy Quake niz jakies wielokrotnie wiecej potrzebujce zasobow instrukcje simd ala sse - nadajace sie do kilku raptem fragemntow takiego programu, suma summarum dajac kilka procent przyspieszenia :)

że jak będzie możliwy do zagospodarowania kawałek FPGA to można dać DSP i/lub SIMD

o takim simd mysla raczej w kontekscie saga, a nie 68k. cos na zasadzie wielu niezaleznych procesorow strumieniowych w kartach grafiki. kazdy procesor to kilka prostych instrukcji, kilka rejestrow i wlasna niewielka pamiec cache.

A gdzie masz ten amigowy system dla 68k?

nie ma, na ten czas, tak samo jak nie ma N68k multicore :)

Nie skorzystają inaczej niż stare programy z PC na dual core.

skorzystaja tylko programy wielowatkowe oraz wielozadaniowosc w systemie.

Automagicznie się podzieli procesor obowiązkami? Nie. Aplikacja MUSI być przepisana

nie jest to prawda, musi miec tylko dopisany fragemnt kodu ktory pozwala posiadane juz fragemnty kodu uruchamiac na kolejnych rdzeniach. W przypadku nowych instrukcji trzeba przepisac wszystkie fragmenty kodu w calosci, stworzyc nowe narzedzia od zera etc....

musi miec tylko dopisany fragemnt kodu ktory pozwala posiadane juz fragemnty kodu uruchamiac na kolejnych rdzeniach

Jasne. I do tego troszkę zmieniony kompiler by to połatał razem, a na sam koniec przystosowany system... czyli wracamy do punktu wyjścia:
dual core:
- zmiany w jądrze systemu (AOS - nierealne) lub proteza (procesor+koprocesor jak to tam chyba gdzieś pisali odnośnie hw core 060) niwelująca większość zalet ewentualnego SMP i limitująca użycie drugiego procesora/rdzenia
- zmiany w kompilatorze
- zmiany w programie (jeśli mamy źródło)
nowe instrukcje:
- zmiany w kompilatorze
- zmiany w bibliotekach (co masowo załatwia sprawę wielu starszych programów) - akurat realne do wykonania
- zmiany w programie (jeśli mamy źródło)
A teraz żeby nie pisać wyssanych z palca bzdur nt. łatwości robienia MT apps

Multithreading changes the fundamental architecture of a program. Unlike a single-threaded program that executes in a strictly linear fashion, a multithreaded program executes portions of itself concurrently. Thus, all multithreaded programs include an element of parallelism. Consequently, a major issue in multithreaded programs is managing the interaction of the threads.
As explained earlier, all processes have at least one thread of execution, which is called the main thread. The main thread is created when your program begins. In a multithreaded program, the main thread creates one or more child threads. Thus, each multithreaded process starts with one thread of execution and then creates one or more additional threads. In a properly designed program, each thread represents a single logical unit of activity.

Nie chcę cię zamęczać wszystkimi szczegółami dot. budowania programu wielowątkowego, ale to wcale nie jest "wziąć fragmenty single threaded, wrzucić fragment kodu i voila". Trzeba od początku konsekwentnie budować program wielowątkowy inaczej nici z wydajności. Różnica jest taka, że kompilator potrafi wykryć co można wrzucić do SIMD, ale nie potrafi sam poprawić programu by lepiej działał na wielordzeniowych maszynach.

Czytając Twój ostatni post zrozumiałem dlaczego tak upierasz się przy tym drugim rdzeniu: uważasz, że przy relatywnie niewielkim nakładzie pracy (głównie zespołu projektantów CPU Natami) system bezproblemowo będzie potrafił wykorzystać drugi rdzeń. Ale niestety, wymagałoby to FUNDAMENTALNYCH zmian w systemie.
Zobacz choćby jak wygląda sprawa wywołania funkcji z biblioteki: argumenty przekazywane są za pomocą rejestrów procesora... więc już musisz zadbać o to, aby biblioteka i program wykorzystujący ją były wykonane w tym samym rdzeniu, albo zapewnisz przekazanie argumentów w inny sposób. Tylko że właśnie taki sposób przekazywania argumentów jest jedną z przyczyn "lekkości" AmigaOS. I jednocześnie jedną z podstawowych jego właściwości. Podobna sprawa jest z ochroną zasobów i pamięci - mimo, że sprzęt od dawna pozwala na zrobienie tego (od kiedy mamy MMU w prawie każdej karcie turbo do Ami?), to konstrukcja systemu sprawia, że do AmigaOS4.1 włącznie nikomu nie udało sie zrobić pełnej ochrony pamieci. A wielu próbowało, w tym niektórzy (Hyperion) napisali system prawie od zera.
Implementacja obsługi wielu rdzeni wymaga poważnych zmian w systemie operacyjnym. I bardzo rzadko przyspieszenie będzie wieksze niż 50%.
Obsługa SIMD, czy jakiegokolwiek innego koprocesora wymaga jedynie wzbogacenia programów (lub tylko bibliotek systemowych... przecież to AmigaOS) o ich obsługę. Przecież nie musisz używać SIMD wszędzie, tylko tam, gdzie da się odczuć zysk (np. Morphosie Altivec uzywany jest do części bardziej obciążających zadań).


Ostatnia edycja: 03.05.11 18:15:59

I do tego troszkę zmieniony kompiler by to połatał razem

zmiany w kompilatorze nie sa potrzebne. potrzebne sa tylko ew. zmiany w programie, zeby uruchomic wykonywanie danego fragmentu na kolejnym rdzeniu.

Trzeba od początku konsekwentnie budować program wielowątkowy inaczej nici z wydajności.

zeby wycisnac maksimum, tak, ale masz do tego wszystkie narzedzia, kompilatory, asemblery etc.

Różnica jest taka, że kompilator potrafi wykryć co można wrzucić do SIMD

kompilatory nie radza sobie z instrukcjami SIMD - SSE traktuja jak zwykle FPU, czyli wystarczy FPU. Zeby uzywac instrukcji SSE, trzeba stosowac nowe typy danych, stosowac wlasciwie operatory etc... krotko mowiac, trzeba wszystko napisac od poczatku, pod warunkiem, ze jest kompilator, bo ja nie ma, to pozostaje tylko asembler, a jak nie ma asemblera, to kod maszynowy :)

W przypadku programu wielowatkowego nic takiego nie robisz. Nie musisz miec nawet zrodel, bo mozesz rownie dobrze uruchomic binarki 68k na kolejnych rdzeniach.

Kolego 1989 radzę zaznajomić się z icc czy gcc i autowektoryzacją. Wtedy porozmawiamy jak to kompilator traktuje SSE jak zwykłe FPU :)
"Zeby uzywac instrukcji SSE, trzeba stosowac nowe typy danych"
Nie trzeba.
"stosowac wlasciwie operatory"
Nie trzeba.
Trzeba tylko pozwolić optymalizacjom kompilatora zadziałać.
"bo mozesz rownie dobrze uruchomic binarki 68k na kolejnych rdzeniach."
Tylko to NIE przyspiesza programu, bo nadal jesteś ograniczony wydajnością jednego rdzenia, czy to do ciebie nie dociera?
"W przypadku programu wielowatkowego nic takiego nie robisz"
Nie. Tylko musisz mieć całą obsługę multicore w systemie, w programie odpowiednio wywoływać (ręcznie) kolejne wątki, dbać o spójność i synchronizację danych między wątkami itp. itd. Czyli robić mnóstwo różnych rzeczy SPECJALNIE by program działał jako wielowątkowy.

uważasz, że przy relatywnie niewielkim nakładzie pracy (głównie zespołu projektantów CPU Natami) system bezproblemowo będzie potrafił wykorzystać drugi rdzeń. Ale niestety, wymagałoby to FUNDAMENTALNYCH zmian w systemie.

dodanie obslugi smp do systemu nie jest proscizna. fundamentalne zmiany, to lekka przesada.

argumenty przekazywane są za pomocą rejestrów procesora... więc już musisz zadbać o to, aby biblioteka i program wykorzystujący ją były wykonane w tym samym rdzeniu,

o co dbac, jak wywolana funkcja wykonuje sie na tym samym rdzeniu ?.

Implementacja obsługi wielu rdzeni wymaga poważnych zmian w systemie operacyjnym. I bardzo rzadko przyspieszenie będzie wieksze niż 50%.

malo kiedy bedzie ponizej 50% :)

--
cos takiego jak simd sprawdzi sie jako dodatkowa jednostka w SAGA - taki copper posiada wlasne instrukcje, a wiec byloby to wlasciwym rozwinieciem koncepcji ukladow SAGA :). 68k powinien rozwijac sie tylko jako jednostka wielordzeniowa. Takie rozwiazanie sprawdzi to tu, to tam, nie tylko w obliczeniach, ale chocby innym przetwarzaniu danych, poczynajac od kompresji, konczac na wzglednie prostym sortowaniu, przeszukiwaniu itp. danych. W koncu to uniwersalny procesor, bardzo dobrze znany i oprogramowany. Drobne rozszerzenia beda niezbedne, ale bez przesady, to nie blok kilkudziesieciu instrukcji, zupelnie nowych rejestrow itd...

Altivec uzywany jest do części bardziej obciążających zadań

Altivec powstal zeby akcelerowac obliczenia FPU - szczegolnie w grach, przetwarzaniu multimediow etc. W czasach kiedy uklady grafiki maja swoje wlasne procesory simd - nawet setki taki procesorow, korzystanie z Altivec ma jakis sens ?. Po co popelniac bledy przeszlosci, mozna od razu zaadoptowac najlepsze rozwiazania, implementujac w SAGA takie microCUDA.

Altivec powstal zeby akcelerowac obliczenia FPU - szczegolnie w grach, przetwarzaniu multimediow etc

Gdyby tak było po co w nim tak doskonała obsługa intów?
http://www.mactech.com/articles/mactech/Vol.15/15.07/AltiVecRevealed/
Gdyby zaś inty były tylko na doklejkę to jak wytłumaczysz rewelacyjne zyski z altivec w kryptografii? (głownie int, bit shift i logiczne). Obliczenia FPU to obliczenia zmiennoprzecinkowe, SIMD to nie obliczenia zmiennoprzecinkowe tylko obliczenia na wektorach, czy elementy wektora będą int, float, double - wszystko jedno. Ważne, żeby były wektory. Zatem nie taki zamiennik FPU jak to sugerujesz.

Kolego 1989 radzę zaznajomić się z icc czy gcc i autowektoryzacją. Wtedy porozmawiamy jak to kompilator traktuje SSE jak zwykłe FPU

autowektoryzacja gdybym nie wiedzial jak to naprawde beznadziejnie dziala, moze dalbym sie nabrac. jak chcesz napisac optymalny kod dla SSE, musisz zrobic to w asemblerze lub stosowac sie scisle do wytycznych projektantow kompilatora C.

zanim powstanie na N68k taki nieudolny kompilator to mina dluuugie lata, wiec wszyscy beda skazani w najlepszym razie na asembler, jezeli nie na kod maszynowy :). Nie mowiac o tym, ze opracowanie takich instrukcji do 68k to tez ze dwa lata ciezkiej pracy. Bezsensowne marnotrastwo czasu, zasobow i srodkow.. Na koncu lipa. W tym czasie zasoby FPGA wzrosna na tyle, zeby umiescic 4 rdzenie 68k (070):) i 16 rdzeni microCUDOw w SAGA - nazywa sie to tutaj chyba Robi :)

obić mnóstwo różnych rzeczy SPECJALNIE by program działał jako wielowątkowy

programowanie wspolbiezne rzadzi sie swoimi zasadami, jezeli chcesz to powiedziec, to ameryki nie odkryles :). nie widze jednak lepszej alternatywy w rozwoju 68k. pomimo jednak pewnych zasad takiego programwania, jest latwiejsze w uzyciu niz cokolwiek innego.

Tylko to NIE przyspiesza programu, bo nadal jesteś ograniczony wydajnością jednego rdzenia, czy to do ciebie nie dociera?

majac kilka rdzeni, mozesz sobie podzielic zadanie na kilka mniejszych zadan wykonywanych rownolegle, co przyspieszy program.

Zatem nie taki zamiennik FPU jak to sugerujesz.

historia simd na x86 zaczela sie od mmx - liczby calkowite. to nie stanowi alternatywy dla wielu rdzeni 68k (nawet juz dwoch), wiec sugeruje fpu.

rewelacyjne zyski altivec to sa na tle std. zestawu instrukcji ppc. w 68k byloby juz inaczej, miejmy nadzieje, nie bedzie.

majac kilka rdzeni, mozesz sobie podzielic zadanie na kilka mniejszych zadan wykonywanych rownolegle, co przyspieszy program.

co oznacza napisanie programu od nowa....

Nie musisz miec nawet zrodel, bo mozesz rownie dobrze uruchomic binarki 68k na kolejnych rdzeniach

A tu potem

majac kilka rdzeni, mozesz sobie podzielic zadanie na kilka mniejszych zadan wykonywanych rownolegle, co przyspieszy program.

To się lekko zastanów co komentujesz i jak.

gdybym nie wiedzial jak to naprawde beznadziejnie dziala

Tak się składa, że ja też wiem jak działa FEMM bez optymalek, a jak z O3 (i autowektoryzacją). Na gęstym mesh jest dość wyraźna różnica w działaniu.

jak chcesz napisac optymalny kod dla SSE, musisz zrobic to w asemblerze lub stosowac sie scisle do wytycznych projektantow kompilatora C

Trzymanie się dobrych reguł nikogo nie zaboli, nawet jak SSE się nie będzie wykorzystywało. A jak już program nabierze struktury dobrej do SSE to i będzie zysk przy AVX256, a później 512 tylko dzięki rekompilacji. W NatAmi nie trzeba więcej rdzeni, trzeba za to b. szybki procek i b. szybką grafikę.

W tym czasie zasoby FPGA wzrosna na tyle, zeby umiescic 4 rdzenie 68k

Nie no, żeby mieć pokemona za 6k którego wgniatać w ziemię będzie G4 w Pegasosie :] Albo w nieco wyższej cenie PWRficient z Amigi X1000 (^^). Natami ultradźwiękowy klasyk (z wszystkim co najważniejsze w sobie - LAN, dźwięk, dużo szybsza grafika i najszybszy 68k jaki się dało wcisnąć w fpga), a nie nowa ścieżka rozwoju amigi :) Teraz jeszcze coś...

zanim powstanie na N68k taki nieudolny kompilator to mina dluuugie lata

Zanim na AOS3.x powstanie jakaś proteza na multicore to miną dłuuugie lata.
Dobranoc.

co oznacza napisanie programu od nowa....

nieprawda, bo jak masz juz popisane funkcje, to juz takie zostaja.

nowy rdzen ma jeszcze taka przewage nad nowymi instrukcjami, ze jak system zaczalby uzywac kolejnych rdzeni, odczujesz to w przypadku nawet starych programow...

Pozwol, ze zacytuje: "to co sprawdza sie na x86 czy PPC, nie musi sprawdzic sie na 68k".

Dalsza dyskusja nie ma sensu. zegnam.

To się lekko zastanów co komentujesz i jak.

a co w tym do zastanwiania. rdzenie sa blizniaczymi kopiami.

jest dość wyraźna różnica w działaniu

na kilku rdzeniach rowniez bedzie wyrazna roznica w dzialaniu.

Trzymanie się dobrych reguł nikogo nie zaboli

czyli przyznajesz, ze trzeba przepisywac cale fragmenty od nowa itd. a na koncu wyjdzie przyspieszenie 5% programu

W NatAmi nie trzeba więcej rdzeni, trzeba za to b. szybki procek i b. szybką grafikę.

potrzeba wielu rdzeni, zeby tak bylo :)

Nie no, żeby mieć pokemona za 6k którego wgniatać w ziemię będzie G4 w Pegasosie :]

Taki G4 nie nadazy za kilkurdzeniowym 68k. Zasoby FPGA rosna, ceny spadaja. PPC konczy sie na desktopach.

Zanim na AOS3.x powstanie jakaś proteza na multicore to miną dłuuugie lata.

watpie :)

Masz zdrowie ;) bo mnie już by się nie chciało - podziwiam

Dalsza dyskusja nie ma sensu.

to zdanie bylo w kontekscie wielu roznic miedzy tymi procesorami, jezeli uwazasz, ze ich nie ma, to jestes w bledzie. jezeli uwazasz, ze sa takie same, to rzeczywiscie nie ma sensu co piszesz.

a co w tym do zastanwiania. rdzenie sa blizniaczymi kopiami

Tak, ale nie do końca... przede wszystkim NIE mają tego samego w L1, trzeba zadbać by nie nadpisywały sobie danych, trzeba zadbać by jeden rdzeń nie musiał nie wiadomo ile czekać na wynik obliczeń drugiego... itp. itd. Ogółem jeśli jesteś taki cwany to POKAŻ jak to powinni zrobić, a nie pisz bzdur. Raz piszesz, że każda aplikacja zyska, drugi raz że tylko te pisane jako wielowątkowe (czyli praktycznie nic sensownego na klasyka), później że nic w kompilatorze nie trzeba zmieniać, jeszcze gdzie indziej że nowe instrukcje to więcej roboty niż kilka rdzeni. Tylko NIC NIGDZIE twoich śmiałych tez nie potwierdza. Jeśli jesteś taki pewien swoich racji to zamiast włączać -O3 może weź i dopisz ten "fragment kodu" do FEMM 4.2 który pozwoli działać jakże szybko na 2 rdzeniach? Nie? Aaa... no i wszystko jasne.

Tak, ale nie do końca... przede wszystkim NIE mają tego samego w L1, trzeba zadbać by nie nadpisywały sobie danych, trzeba zadbać by jeden rdzeń nie musiał nie wiadomo ile czekać na wynik obliczeń drugiego... itp. itd.

to nie pochlania wielu zasobow fpga, a taki simd z 256bitowymi rejestrami, to pewnie potrzebuje wiecej zasobow niz caly N68k w swojej najbardziej wypasionej wersji (070) :)

POKAŻ jak to powinni zrobić, a nie pisz bzdur.

pewnie wiedza jak maja to zrobic. a wielordzeniowe procesory istnieja od dawna, wiec to zadne novum.

Raz piszesz, że każda aplikacja zyska, drugi raz że tylko te pisane jako wielowątkowe (czyli praktycznie nic sensownego na klasyka)

kazda aplikacja zyska ?, nic takiego nie napisalem.

Tylko NIC NIGDZIE twoich śmiałych tez nie potwierdza.

potwierdza wszystko. skonstruowanie nowego zestawu instrukcji to mnostwo pracy na wiele lat. uzycie nie jest latwe bez odpowiednich narzedzi, nawet z narzedziami do latwych nie nalezy. dodanie kolejnego rdzenia, nie wymaga juz tak duzo pracy, a uzycie jest duzo latwiejsze, bo to dobrze kazdemu znany i lubiany 68k :).

Jakos mam przekonanie graniczace z pewnoscia, ze wiekszosc koderow i programistow amigowych woli nauczyc sie programowac wspolbieznie na 68k, niz na nowo optymalizowac to co juz maja, na jakis kolejny (po PPC) nowy egzotyczny zestaw instrukcji.

Jeśli jesteś taki pewien swoich racji to zamiast włączać -O3 może weź i dopisz ten "fragment kodu" do FEMM 4.2 który pozwoli działać jakże szybko na 2 rdzeniach? Nie? Aaa... no i wszystko jasne.

przez kompilatory instrukcje SSE najczesciej traktowane sa tak jak instrukcje FPU - autowektoryzacje przemilczmy... duzo roboty przy przepisywaniu zeby to wygladalo sensownie. Na tym polega trik, ze wykonanie takiej samej operacji na rejestrach FPU jest wolniejsze niz na rejestrach SSE (nawet do kilkudziesieciu razy), podobnie jest na wielu PPC. Na N68k nic takiego nie bedzie mialo miejsca, wiec jak nie dokona sie optymalizacji dla macierzy, szybciej od tak po prostu nie bedzie - to moze byc/nie musi 1-2% przyrost predkosci na N68k, gdzie pewna kombinacja instrukcji 68k, zostanie zastapiona jedna nowa, oczywiscie dopiero po jakis zmianach w kompilatorze.