@szuler, post #150
@wali7, post #148
Wykorzystanie drugiego rdzenia jest o wiele trudniejsze niż wykorzystanie nowych instrukcji. Musisz rozpisać algorytm tak, aby pracował równolegle.
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.
A z innej beczki, jak sobie wyobrażasz obsługę drugiego rdzenia przez AmigaOS?
@1989, post #152
wykorzystanie nowych instrukcji jest o wiele trudniejsze, bo musisz naprawde napisac od zera caly program, w asm!,
Zreszta, jakie nowe instrukcje mozna dodac do 68k ktore dalyby np: 95% wzrost wydajnosci, jak w przypadku kolejnego rdzenia ?
@szuler, post #149
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.
No i? Czy po przejsciu z 68000 na 68030 + FPU programisci musieli przepisac od nowa wszystkie programy?
@1989, post #154
zauwaz, ze nowe instrukcje tez nic nie zmieniaja, bez dostepu do zrodle AOS3 niewiele mozna zrobic, takze to nie jest alternatywa.
tak, dla asm trzeba przepisac w calosci,
@szuler, post #153
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.
Instrukcje SIMD, na przyklad takie jak w jednostce AltiVec lub SSE. Chociaz akurat SSE jest o wiele gorsze.
@szuler, post #155
Sam OS3 nie musi korzystac z nowych instrukcji.
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.
@1989, post #152
wykorzystanie nowych instrukcji jest o wiele trudniejsze, bo musisz naprawde napisac od zera caly program
przejscie na zupelnie nowe instrukcje porownac moge do przejscia na zupelnie nowy procesor
bo w duze Mhz o wiele trudniej wejsc niz w wielordzeniowosc
zamiast dodawac nowe instrukcje, w to miejsce lepiej
Zreszta, jakie nowe instrukcje mozna dodac do 68k ktore dalyby np: 95% wzrost wydajnosci
zamiast dodawac nowe instrukcje do 68k, lepiej dodac nowa funkcjonalnosc do SAGA
Kolejne rdzenie sa dla nowych programow 68k
@abcdef, post #159
Tutaj jak napisałem wystarcza właśnie uaktualnienie bibliotek i automagicznie wszystkie programy z nich korzystające dostają wsparcie do nowych ficzerów.
Bzdura, PPC co generację ma nowe instrukcje
Natomiast obsługa dual core już musiała być od początku do systemu dodana.
Rzecz w tym, że dodawanie nowych instrukcji nie kosztuje tak wiele w FPGA jak dodawanie nowych ALU pipeline
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.
Oh, aż dziw bierze, że nie dołączyłeś do projektu... widać tam sami amatorzy są co nie wiedzą co jest lepsze
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
@1989, post #160
to nie jest ani optymalne, ani wydajne. z nowych instrukcji trzeba korzystac bezposrednio, inaczej traca swoj atut
Najlepiej przyspieszyc dodajac nowe funkcje do SAGA
Za pomoca nowych instrukcji SIMD niewiele mozna zdzialac
To jest dosc zlozony program
A co bedzie jak taki program korzysta z wielowatkowosci w systemie
kolejny rdzen ma taka przewage nad nowymi instrukcjami, ze nawet stare programy moga skorzystac
ezeli napisales optymalna procedure 68k FPU obliczajaca macierz, w dowolnym jezyku, to latwiej bedzie uruchomic to samo na kolejnym rdzeniu
@abcdef, post #161
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?
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 zbudować API do tego, bo samo z siebie nie zadziała.
że jak będzie możliwy do zagospodarowania kawałek FPGA to można dać DSP i/lub SIMD
A gdzie masz ten amigowy system dla 68k?
Nie skorzystają inaczej niż stare programy z PC na dual core.
Automagicznie się podzieli procesor obowiązkami? Nie. Aplikacja MUSI być przepisana
@1989, post #162
musi miec tylko dopisany fragemnt kodu ktory pozwala posiadane juz fragemnty kodu uruchamiac na kolejnych rdzeniach
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.
@1989, post #162
@abcdef, post #163
I do tego troszkę zmieniony kompiler by to połatał razem
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
@1989, post #165
@wali7, post #164
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.
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,
Implementacja obsługi wielu rdzeni wymaga poważnych zmian w systemie operacyjnym. I bardzo rzadko przyspieszenie będzie wieksze niż 50%.
Altivec uzywany jest do części bardziej obciążających zadań
@1989, post #167
Altivec powstal zeby akcelerowac obliczenia FPU - szczegolnie w grach, przetwarzaniu multimediow etc
@abcdef, post #166
Kolego 1989 radzę zaznajomić się z icc czy gcc i autowektoryzacją. Wtedy porozmawiamy jak to kompilator traktuje SSE jak zwykłe FPU
obić mnóstwo różnych rzeczy SPECJALNIE by program działał jako wielowątkowy
Tylko to NIE przyspiesza programu, bo nadal jesteś ograniczony wydajnością jednego rdzenia, czy to do ciebie nie dociera?
@abcdef, post #168
Zatem nie taki zamiennik FPU jak to sugerujesz.
@1989, post #169
Nie musisz miec nawet zrodel, bo mozesz rownie dobrze uruchomic binarki 68k na kolejnych rdzeniach
majac kilka rdzeni, mozesz sobie podzielic zadanie na kilka mniejszych zadan wykonywanych rownolegle, co przyspieszy program.
gdybym nie wiedzial jak to naprawde beznadziejnie dziala
jak chcesz napisac optymalny kod dla SSE, musisz zrobic to w asemblerze lub stosowac sie scisle do wytycznych projektantow kompilatora C
W tym czasie zasoby FPGA wzrosna na tyle, zeby umiescic 4 rdzenie 68k
zanim powstanie na N68k taki nieudolny kompilator to mina dluuugie lata
@1989, post #156
nowy rdzen ma jeszcze taka przewage nad nowymi instrukcjami, ze jak system zaczalby uzywac kolejnych rdzeni, odczujesz to w przypadku nawet starych programow...
@abcdef, post #172
To się lekko zastanów co komentujesz i jak.
jest dość wyraźna różnica w działaniu
Trzymanie się dobrych reguł nikogo nie zaboli
W NatAmi nie trzeba więcej rdzeni, trzeba za to b. szybki procek i b. szybką grafikę.
Nie no, żeby mieć pokemona za 6k którego wgniatać w ziemię będzie G4 w Pegasosie :]
Zanim na AOS3.x powstanie jakaś proteza na multicore to miną dłuuugie lata.
@1989, post #175
a co w tym do zastanwiania. rdzenie sa blizniaczymi kopiami
@abcdef, post #178
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.
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)
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.