Azarien napisał(a):
Kilka osób w tym wątku zachwalało jaka to zła niedobra jest architektura x86, a ARM taki wspaniały, RISCowy... zastanawiam się czy próbowaliście w ogóle napisać coś w asemblerze ARM?
Bo ja właśnie próbuję, i wiecie co? ARM też jest powalony, tylko w innych miejscach!
Argument w stylu pierwszych programistów taśm perforowanych - to się nie przyjmie skoro nawet najtęższe łby zawodzą przy programowaniu najprostszych rzeczy!
Być może trzeba poczekać na taki procesor RISC-V od Micro Magic Inc.— mała firma zajmująca się projektowaniem elektroniki w Sunnyvale w Kalifornii - wyprodukowała prototypowy procesor, który jest kilkakrotnie bardziej wydajny niż wiodący światowi konkurenci, zachowując jednocześnie rozsądną pierwotną wydajność. W CoreMark procesor Micro Magic RISC-V jest dużo szybszy od procesora Apple M1 i Ryzen 4700U.
https://arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt/
Obiecałem, że coś napiszę nowego w temacie, więc w końcu piszę :)
Jak to możliwe, że mądre głowy z intela/AMD/nvidii (wydajność gpu podobno też ma być niesamowita) przez tyle lat same nie zaoferowały takich układów? Przecież w tych firmach pracuje sztab ludzi głowiący się jak zarobić więcej kasy a Apple nie ma technologii z kosmosu.
Apple ma dużo hajsu i może zatrudniać najlepszych specjalistów z branży. Specjaliści zmieniają pracodawcę tak samo jak "zwykli nie-specjaliści".
Inna kwestia która mnie nurtuje to czy te architektury (chociażby za pośrednictwem benchmarków) można od tak porównywać 1:1?
Każdy benchmark testuje trochę co innego, więc jeśli w benchmarku A procesor X jest szybszy od procesora Y o 20% to nie znaczy, że tak będzie w benchmarku B. Trzeba sprawdzić jakie są zasady w benchmarku, żeby ocenić co jest w ogóle porównywane.
Ważnym elementem jest np. mniej restrykcyjny model pamięci ARM.. powodujący, że w programach niejawnie pisanych pod x86 mogą objawiać teraz różnego rodzaju race conditions. Nie wiem na ile kompilatory C/C++ to łapią... ale w takiej javie można obserwować inny wynik operacji wielowątkowych pod ARM i Intel (!!!). (Oczywiście - o ile program w javie jest niepoprawnie napisany).
Mniej restrykcji oznacza też więcej potencjalnej mocy z punktu widzenia procesora (mniej "synchronizowania cache", więcej możliwości przestawiania kolejności instrukcji na poziomie procesora)
DEC Alpha chyba wygrywało jeśli chodzi o kruczki modelu pamięci: https://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html W czasach świetności byli liderem wydajności.
@sig:
ps coś mi się obiło kiedyś o oczy że rdzenie x86 mają wbudowanego "tłumacza" na zupełnie inną architekturę, bo bez tego nie dało by się dalej zwiększać wydajności. tak więc może się okazać że tam "pod spodem" coś na kształt ARM-a jest.
Wydajne procesory używają https://en.wikipedia.org/wiki/Micro-operation i https://en.wikipedia.org/wiki/CPU_cache#UOP-CACHE . Robią to zarówno x86 jak i ARMy. Np Cortex-A77:
https://en.wikipedia.org/wiki/ARM_Cortex-A77
The Cortex-A77 is a 4-wide decode out-of-order superscalar design with a new 1.5K macro-OP (MOPs) cache.
Jeśli chodzi o wydajność serwerową to:
Jeśli chodzi o oprogramowanie na architekturę ARM64 to moje przepowiednie się sprawdzają. Apple ma wystarczającą siłę przekonywania, by producenci oprogramowania szybko portowali je na nową architekturę. Google Chrome na Apple Silicon M1 pojawiło się bardzo szybko i ma dużo wyższą (prawie 2x) wydajność niż wersja x86 chodząca pod Rosettą 2: https://arstechnica.com/gadgets/2020/11/google-chrome-is-available-as-an-apple-m1-native-app-today/ Microsoft Edge też ma natywną wersją na ARMowe Maki. Adobe już na starcie miało kilka programów natywnie skompilowanych pod Apple M1, a jest ich coraz więcej. Microsoft przeportował Office 365 pod Apple M1: https://www.microsoft.com/en-us/microsoft-365/blog/2020/12/15/4-ways-microsoft-365-is-improving-the-experience-for-mac-users/ IntelliJ IDEA od JetBrainsów też ma wersję specjalnie przygotowaną dla Apple M1.
Jest na forum ktoś kto korzysta ze sprzętu Apple opartego o M1 do programowania?
Do soboty mam czas zdecydować, czy odbieram nowy sprzęt na x86-64 (Ryzen 7 5800H) czy może nie wejść do elektro marketu z kubkiem sojowego latte i nie kupić macbooka pro m1 w wersji z 16GB ram ;)
@RequiredNickname: bierz m1 i się pochwalisz jak to śmiga
wpadnie z 10 łapkuf na forum, co jest bezcenne
Bierz Apple, emulowanie javy na arm to świetny pomysł, będzie pan zadowolony
(...) the implementation of JEP 391: macOS/AArch64 Port. It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64.
Depends JEP 388: Windows/AArch64 Port oraz An AArch64 port already exists for Linux (JEP 237), and work is underway on an AArch64 port for Windows (JEP 388). We expect to reuse existing AArch64 code from these ports by employing conditional compilation Co jeszcze ciekawsze, na https://www.microsoft.com/openjdk widać: Microsoft is proud to have contributed the Windows on Arm port in 2020 as well as having made major contributions to the macOS M1 port.
Ja czekam na ruch ze strony intela i amd. Szczególnie jak okaże się, że apple w M2 pokaże kolejny spory wzrost wydajności.
Jak na mnie to intel i amd już nie za wiele mogą zrobić z tym co mają. W zasadzie to żeby tworzyć coś wydajnego to trzeba korzystać z SIMD, enkoderów i innych rzeczy. Dla przeciętnego programisty pozostają biblioteki, które są optymalizowane do obliczeń na danej architekturze, albo liczenie na automatyczne optymalizacje kompilatora.
Ktoś wspominał o problemach jakie pojawiają się przy Machine Learningu. W mojej opinii jeśli mamy jakieś z definicji równoległe zadanie do wykonania to warto je wykonywać na równoległej architekturze, czyli np. na gpu. Daje to często spore przyrosty wydajności, a praktycznie zawsze daje to spadek użycia energii na to samo zadanie. Procesor z natury jest stworzony do zadań sekwencyjnych.
Każdy zdaje sobie sprawę, że architektura x86 ma swoje ograniczenia. Co nie znaczy, że teraz wszyscy rzucą się na arm, zwłaszcza że jak na razie to może oprócz mniejszego poboru mocy, to żaden arm niczym się nie wyróżnił na plus.
Jeju... Jak to czytam to mam wrażenie że nikt nie wie o czym pisze. X86 to CISC - czyli długie rozkazy, których jest od groma do wszystkiego. Tysiące opcodow. Rozkaz może trwać kilka cykli zegara jak złożona funkcja i powstaje nawet maszynowo implementowany mikrokod do tworzenia takich instrukcji. Pamięć nie jest za to bardzo obciążana. RISC to krótkie instrukcje mieszczące się w słowie maszynowym (64b) i przetworzenie ich zajmuje 1 cykl zegara. Tutaj jest nastawienie na optymalizacje przez kompilatory w postaci używania krótkich instrukcji. Zużycie ramu jest większe. ARM to skrót od Advanced RISC Machine. Czyli ARM to RISC. Przez to ze mniej implementuje - raptem garść jednocyklowych rozkazów jest prostszy w konstrukcji i zużywa mniej energi. Kto robił cis w bramkach TTL ten wie ile tranzystorów jest potrzebne do zrobienia parsera,instrukcji warunkowych czy maszyny stanów a x86 wiele implementuje sprzetowo. Ci co mówią o hybrydach... no ale to już jest - Intel Core ma w środku rdzenie RISC i ABI CISC czyli de facto Intel mistrzowsko emuluje x86 i tak już. Teraz mogli by iść w udostępnienie ABI RISC ale maja tyle tałatajstwa, ze fizycznie staje się do skomplikowane . x86 ma w sobie sprzętowa kartę sieciowa, klienta DHCP i w zasadzie może połączyć się z siecią z pominięciem systemu hosta. Co więcej ma jakieś układy fpga i maszynę wirtualna w środku i kawałki kodu Minixa - teoretycznie do zarządzania flotą maszyn w technologii Intel Pro. Nie wiadomo co będzie z ARM jak dołożą takie fajerwerki ale pytanie czy dołożą? Jeśli laptop pracuje dobę na baterii to jest to fenomenalne.To, że świat idzie z CISC na RISC to fakt, a nie opinia czy uczucia religijne - już przepowiedziane ponad dekadę temu przez mojego profesora od architektury komputerów.
Sam mam m1 i w pracy codziennej pracuje lepiej niż i5 w Macu. Do większych obliczeń zawsze są serwery developerski i chmura - pytanie po co więcej mocy lokalnie? Podejrzewam, ze zobaczymy maszynę z 16rdzeniami, 64GB ram i 4TB dysku i to do developerski starczy - przecież nie potrzeba mocy podczas procesu developerskiego a profilowanie i tak odbywa się na środowiskach 1-1 produkcyjnych. Coraz mniej tez zależy id wydajności CPU a od zaprojektowania przepływu w mikroserwisach i wąskich gardeł tam.
pragmaticdev napisał(a):
Jeju... Jak to czytam to mam wrażenie że nikt nie wie o czym pisze. X86 to CISC - czyli długie rozkazy, których jest od groma do wszystkiego. Tysiące opcodow. Rozkaz może trwać kilka cykli zegara jak złożona funkcja i powstaje nawet maszynowo implementowany mikrokod do tworzenia takich instrukcji. Pamięć nie jest za to bardzo obciążana. RISC to krótkie instrukcje mieszczące się w słowie maszynowym (64b) i przetworzenie ich zajmuje 1 cykl zegara. Tutaj jest nastawienie na optymalizacje przez kompilatory w postaci używania krótkich instrukcji. Zużycie ramu jest większe. ARM to skrót od Advanced RISC Machine. Czyli ARM to RISC. Przez to ze mniej implementuje - raptem garść jednocyklowych rozkazów jest prostszy w konstrukcji i zużywa mniej energi.
To brzmi jak jakieś mity i legendy. ARM ISA to garść jednocyklowych rozkazów? Hmm, popatrzmy co Arm Armv9-A A64 Instruction Set Architecture nam oferuje: https://developer.arm.com/documentation/ddi0602/latest . Ja tam widzę masę instrukcji (chyba setki, jeśli połączyć wszystkie ich rodzaje), włącznie z dzieleniem i to nawet wektorowym dzieleniem liczb całkowitych (o ile dobrze rozumiem). Nawet x86 tego nie ma. Jeśli to jest "garść jednocyklowych rozkazów" to szacun dla Arma.
https://developer.arm.com/documentation/ddi0602/latest/SVE-Instructions/UDIV--Unsigned-divide--predicated--?lang=en
https://developer.arm.com/documentation/ddi0602/latest/SVE-Instructions/SDIV--Signed-divide--predicated--?lang=en
Obecnie główne różnice między ARM, a x86 to nie liczba instrukcji (w obu architekturach jest masa instrukcji), a raczej kodowanie instrukcji (x86 ma skomplikowane kodowanie ze względów historycznych) czy model pamięci (x86 ma silniejsze gwarancje dotyczące widoczności modyfikacji pamięci, ARM potrzebuje większej liczby memory barriers).
O ile dobrze zrozumiałem artykuły o ARMie to Scalable Vector Extension (SVE) ma swoje korzenie w superkomputerach. Fujitsu produkuje superkomputery, które do niedawna były oparte o architekturę SPARC (od Suna, a później Oracle), dla której Fujitsu rozwijało rozszerzenia wektorowe. Niedawno Oracle zarzuciło całkowicie rozwój SPARCa i Fujitsu przeniosło się na ARMa, przenosząc przy okazji swoje mechanizmy obliczeń wektorowych. Dokładniej rzecz biorąc to SVE nie jest własnościowym rozszerzeniem Fujitsu tylko zostało we współpracy z Armem włączone do standardowej ARM ISA.
Co do ARMów w serwerowniach/ chmurach obliczeniowych, to sztandarowym przykładem sukcesu jest AWS Graviton:
Z innych ciekawostek, to procki ARMowe też mają dekodery instrukcji i tłumaczą z RISC na RISC. Cortex-A77 i późniejsze (obok pamięci podręcznej dla niezdekodowanych instrukcji) mają pamięć podręczną dla zdekodowanych instrukcji (micro-op cache, analogicznie jak w x86). Procki ARMowe potrafią nawet kompresować instrukcje, by zwiększyć efektywną pojemność wewnętrznych buforów procesora:
https://www.anandtech.com/show/16693/arm-announces-mobile-armv9-cpu-microarchitectures-cortexx2-cortexa710-cortexa510/2
The core also increases its out-of-order capabilities, increasing the ROB (reorder buffer) by 30% from 224 entries to 288 entries this generation. The effective figure is actually a little bit higher still, as in cases of compression and instruction bundling there are essentially more than 288 entries being stored. Arm says there’s also more instruction fusion cases being facilitated this generation.
(notabene: Intel Skylake ma ROB o rozmiarze 224, a u Apple M1 pojemność ROB to podobno ponad 600)
Dokładnie jak @Wibowit mówi. Największą zaletą ARMa nie jest to, że instrukcje są "jednocyklowe" (bo nie są), a to, że mają ustaloną długość przez co dekoder jest zdecydowanie prostszy (i jego zrównoleglona implementacja jest zdecydowanie prostsza, bo nie trzeba "zgadywać" długości instrukcji). To jest po prawdzie główne źródło oszczędności zarówno prądu jak i powierzchni krzemu. Tego problemu w x86 nie da się rozwiązać bez zrywania kompatybilności wstecz z czym ARM nie ma większego problemu.
Przy okazji, jest ich w manualach dużo nie tylko dla tego, że ARM faktycznie ma ich dużo, co z tego powodu, że wiele mnemonik to aliasy na inne polecenia, a polecenia procesora opisują więcej niż 1 rzecz. To trochę jak w Vimie składasz je z poszczególnych elementów (podstawa, rejestry, skok warunkowy, przesunięcie, wartość, etc.). Przykładowo:
MOV X2, X1
To to samo co:
ADD.AL X2, X1, #0 LSL #0
Czyli bezwarunkowe dodanie wartości X1 do 0 (przesuniętego o 0 bitów w lewo) i zapisanie wyniku w X2. Więc nawet jak mamy sporo mnemonik, to część z nich jest po prostu inną nazwą na te same instrukcje (bo zobaczmy, że instrukcja ADD wyżej może zostać użyta również do implementacji - JMP, wszelkie skoki warunkowe, rotacje, przypisania warunkowe, etc.). Więc mając jedną instrukcję możemy zrobić wiele rzeczy na raz (prawie jak MOV w x86-64).
EDIT: Tutaj można zobaczyć jak wiele jest jeszcze miejsca w przestrzeni instrukcji A64:
Źródło - https://weinholt.se/articles/arm-a64-instruction-set/
Back on the decoder, Intel supports on-demand decode which stores a history of previous decodes in the instruction cache and if recent misses are recalled at the decode stage, the on-demand stream will pull directly from the instruction cache instead, saving time – if the prefetch/decode works, the content in the instruction cache is updated, however if it is doing poorly then the scope is ‘re-enabled for general fetches’ to get a better...
...understanding of the instruction flow. This almost sounds like a micro-op cache without having a physical cache, but is more to do about instruction streaming. Either way, the decoders can push up to six uops into the second half of the front end. - strasznie enigmatycznie opisane moim zdaniem. W przyszłości pewnie będą lepsze opracowania tego tematu. Sam mechanizm jest tylko w tzw. małych rdzeniach (Intel idzie w kierunku podobnym do ARMowego big.LITTLE).
Apple prawdopodobnie wypuści nowe wersje Maca Pro z procesorami Intela, więc może z tym zmiataniem z planszy wszystkiego przez ich własne procesory nie jest jeszcze tak różowo. ;)
https://www.notebookcheck.net/Evidence-of-a-refreshed-Apple-Mac-Pro-with-Intel-Ice-Lake-processors-emerges.544549.0.html
O ile dobrze pamiętam to jest to zgodnie z planem, tzn zapowiedziami Apple'a na samym początku, że jeszcze przez 2 lata od premiery Apple Silicon będą wydawać nowe modele komputerów opartych o procesory Intela.
Jest to ukłon w stronę ludzi, którzy bardzo chcą używać oprogramowania od producentów ociągających się z portowaniem oprogramowania na Apple Silicon natywnie. Dzięki temu ci użytkownicy nie są skazani na lewiznę typu emulacja x86 po Rosettą 2.
Ktoś ma japko z arm m1 i sprawdzał jak parallels z visual studio działa? Mam 2 projekty legacy które muszę jeszcze ze 2-3 lata utrzymywać w net framework (jeden jakieś asp, drugi winforms) i się zastanawiam czy by to poszło na macu z arm czy bym musiał nadal w podróży z rdp lecieć.
Właśnie oficjalnie wyszła Java 17 z natywnym wsparciem dla macOS+ARM64: https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11
Prawdopodobnie będzie szybko i (jak to przy informatycznych debiutach bywa) z okazjonalnymi błędami :]
goto akurat unsigned może być przydatne
Przydałoby się nowe porównanie z procesorami Ryzen 6xxx od AMD. Zintegrowany Radeon 680M potrafi nawet odpalić Cyberpunka w 30 fps na niskich detalach w full HD bez funkcji od obniżania jakości grafiki i podwyższania fps jak np. dlss od Nvidii. To byłoby ciekawe porównanie.
loza_wykletychloza_wykletychloza_wykletych