-
Jak bardzo kosztowna jest pamięć cache? W jakim stopniu zmieniłby się pobór prądu i cena procesora, gdyby pamięci podręcznej byłoby 50 razy więcej? Czy jest to możliwe za jakiś czas?
-
Przejście z architektury 32 bitowej na 64 bitową było konieczne ze względu na problemy z adresowaniem, ale jaki jest sens teraz coś zmieniać, czy jest możliwe, że na domowych komputerach za jakiś czas nie będzie x86?
-
Jeśli ilość pamięci cache bardzo wyraźnie wzrośnie, to czy na takich maszynach języki takie jak C i C++ będą miały sens?
0
1
Ale wiecej cache oznacza, ze przeszukiwanie cache bedzie tez wiecej trwac. Dostepy do cache'u nie sa O(1)* tylko trzeba troche poszukac.
*: w zasadzie dla teoretykow informatyki przeszukanie calego cache'u jest O(1) bo np. 6MB to jest jakas stala. Ale w praktyce nie chcemy zbyt dlugo szukac.
0
leto napisał(a):
- Jeśli ilość pamięci cache bardzo wyraźnie wzrośnie, to czy na takich maszynach języki takie jak C i C++ będą miały sens?
A dlaczego miały by przestać mieć sens? Albo czy teraz na normalnych komputerach C i C++ ma sens? Pytanie tak ogólne że każda odpowiedź jest dobra :(
4
Aktualnie C++ jest kilkadziesiąt razy szybszy od pythona, gdyby pamieć cache była nieograniczona ta różnica by zmalała, pytanie jak bardzo?
Według Benchmarks Game Java jest 3 razy wolniejsza od C i 10 razy szybsza od Pythona. Python jest wolny nie z powodu ograniczonego cache, tylko z powodu dynamicznego typowania. Jemu nic nie pomoże :(
5
Jak bardzo kosztowna jest pamięć cache? W jakim stopniu zmieniłby się pobór prądu i cena procesora, gdyby pamięci podręcznej byłoby 50 razy więcej? Czy jest to możliwe za jakiś czas?
Producenci CPU robią to co się opłaca w większości zastosowań. Pojemność pamięci podręcznej nie jest dominującym czynnikiem determinującym wydajność (chyba, że kastrujemy mocno CPU z pamięci podręcznej). Poza tym pamięci podręcznych jest wiele rodzajów i poziomów. Same poziomy pamięci podręcznej istnieją dlatego, że by zmniejszyć czas dostępu trzeba zmniejszyć pamięć podręczną. Stąd jest L1 o najszybszym dostępie, potem znacznie większe L2 kosztem wyższych opóźnień, a potem czasem i L3 albo nawet i L4. Na pewnym poziomie gigantyczna pamięć podręczna traci sens, bo jej opóźnienia nie są dużo mniejsze od opóźnień systemowego RAMu.
Przejście z architektury 32 bitowej na 64 bitową było konieczne ze względu na problemy z adresowaniem, ale jaki jest sens teraz coś zmieniać, czy jest możliwe, że na domowych komputerach za jakiś czas nie będzie x86?
Możliwe, że przejdziemy na ARM, bo u Intela nastąpiła wieloletnia stagnacja, a samo (niewielkich rozmiarów) AMD niekoniecznie będzie w stanie długofalowo dominować na rynku CPU. Zdobycie licencji na produkowanie własnego CPU opartego o ARM jest znacznie łatwiejsze niż zdobycie licencji x86, stąd nowi gracze tworzą ARMy, a nie x86. ARM jest też mocno ustandaryzowane i ma rozbudowany ekosystem, w przeciwieństwie do np RISC-V.
Kiedyś była wojna Atari vs Amiga. Fanboje z każdej strony obrzucali się obelgami, podobnie jak np dzisiejsi fanboje Intela. Ostatecznie burzliwe dyskusje okazały się bezcelowe, bo zarówno Atari jak i Amiga znikły całkowicie z rynku. Podobnie może być z dowolną inną architekturą. Nie ma sensu bić piany o architektury. Jeśli ktoś pisze w wysokopoziomowym języku (bez niskopoziomowych gimnastyk, wchodzenia w CPU intrinsics, wykorzystywania konstrukcji typu implementation specific czy undefined behavior) to kompilacja na nową architekturę będzie wymagać co najwyżej zmiany jednej flagi kompilatora i tyle. Sporo rzeczy już działa na ARMach: https://www.worksonarm.com/projects/
Jeśli ilość pamięci cache bardzo wyraźnie wzrośnie, to czy na takich maszynach języki takie jak C i C++ będą miały sens?
Aktualnie C++ jest kilkadziesiąt razy szybszy od pythona, gdyby pamieć cache była nieograniczona ta różnica by zmalała, pytanie jak bardzo?
Python (w typowym przypadku) jest odpalany przez interpreter, a to samo w sobie ogranicza mocno wydajność. Cache ma tu niewiele do gadania. Javę też możesz odpalić w trybie interpretera:
$ java -X
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
W trybie interpretera Java traci sporo wydajności.
Według Benchmarks Game Java jest 3 razy wolniejsza od C i 10 razy szybsza od Pythona. Python jest wolny nie z powodu ograniczonego cache, tylko z powodu dynamicznego typowania. Jemu nic nie pomoże :(
Do Pythona są JITy, np PyPy i w zasadzie nic nie stoi na przeszkodzie by osiągnął poziom wydajności Node.jsa, bo JS jest chyba równie dynamicznie typowany co Python.
0
Zdobycie licencji na produkowanie własnego CPU opartego o ARM jest znacznie łatwiejsze niż zdobycie licencji x86
@Wibowit - co masz na myśli pisząc o licencjach? Czy x86 / x64 jest jakoś opatentowane, albo trzeba zdobyć jakieś inne zgody/pozwolenia?
Myślałem zawsze (ale fakt - tematu nie zgłębiałem), że jest to jakiś ogólnodostępny standard opisujący, jak ma się procesor zachowywać, jakie obsługiwać instrukcje itp, żeby spełniał wymogi x86. Coś na zasadzie tego, co napisałeś odnośnie ARM - że jest też mocno ustandaryzowane. Wydawało mi się, że jeśli mam taką fantazję, to mogę sobie nawet wziąć lutownicę i samodzielnie coś takiego zrobić w garażu. Oczywiście - wiem, że to jest skomplikowany proces, mega kosztowny itp, ale co do zasady - nie wiedziałem, że trzeba mieć jakieś pozwolenia na produkcję CPU. Jak możesz to rozwiń myśl, bo mnie zaintrygowało to, co napisałeś.
3
co masz na myśli pisząc o licencjach? Czy x86 / x64 jest jakoś opatentowane, albo trzeba zdobyć jakieś inne zgody/pozwolenia?
Dla przykładu https://en.wikipedia.org/wiki/X86-64#Licensing
x86-64/AMD64 was solely developed by AMD. AMD holds patents on techniques used in AMD64;[89][90][91] those patents must be licensed from AMD in order to implement AMD64. Intel entered into a cross-licensing agreement with AMD, licensing to AMD their patents on existing x86 techniques, and licensing from AMD their patents on techniques used in x86-64.[92] In 2009, AMD and Intel settled several lawsuits and cross-licensing disagreements, extending their cross-licensing agreements.[93][94][95]
W ogólności możesz niby stworzyć swój CPU zgodny z x86, ale tylko z bardzo starymi wersjami, co w zasadzie neguje sensowność takiego przedsięwzięcia. Jeśli chcesz stworzyć coś zgodnego z nowszymi procesorami Intela to musisz go poprosić o pozwolenie, ale dla przykładu nVidii podobno się to nie udało https://en.wikipedia.org/wiki/Project_Denver :
According to Charlie Demerjian, the Project Denver CPU may internally translate the ARM instructions to an internal instruction set, using firmware in the CPU.[19] Also according to Demerjian, Project Denver was originally intended to support both ARM and x86 code using code morphing technology from Transmeta, but was changed to the ARMv8-A 64-bit instruction set because Nvidia could not obtain a license to Intel's patents.[19]
W przypadku ARM sprawa jest prostsza. ARM wprost oferuje https://en.wikipedia.org/wiki/ARM_architecture#Architectural_licence :
Architectural licence
Companies can also obtain an Arm architectural licence for designing their own CPU cores using the Arm instruction sets. These cores must comply fully with the Arm architecture. Companies that have designed cores that implement an Arm architecture include Apple, AppliedMicro, Broadcom, Cavium (now: Marvell), Digital Equipment Corporation, Intel, Nvidia, Qualcomm, and Samsung Electronics.
.
Myślałem zawsze (ale fakt - tematu nie zgłębiałem), że jest to jakiś ogólnodostępny standard opisujący, jak ma się procesor zachowywać, jakie obsługiwać instrukcje itp, żeby spełniał wymogi x86.
Oprócz samego ISA (instruction set architecture) są jeszcze wymogi co do łączenia urządzeń w całe systemy. Teoretycznie możesz zrobić procesor mogący wykonywać instrukcje x86, ale nieobsługujący PCI-[cokolwiek], pamięci DDR itp itd
Jeśli chodzi o standaryzację w kontekście ARM to może nie będę się rozpisywał tylko podam linka do artykułu, który bardzo dobrze sprawę objaśnia: https://nuviainc.com/blog/the-importance-of-standards-on-making-arm-servers-boring
2
- Cache jest szybkie bo jest małe i blisko CPU. Nie da się go dokładać w nieskończoność, bo zwyczajnie stracisz wszystkie jego plusy :)
- Nie wiem co ma cache do szybkości języka za bardzo.
0
Nawiązując do tematu x86 i domowych komputerów, Apple,po tym jak zainwestowali we własne procesory dla urządzeń mobilnych, zdecydowało się na migrację na arm w przypadków swoich nowych laptopów.
Pytanie czy innym dostawcom, którzy nie produkują własnych procesorów i nie trzymają pełnej kontroli nad ekosystemem od sprzętu po aplikacje, takie posuniecie będzie się opłacać.
1
Moim zdaniem migracja Apple na ARM przyspieszy proces portowania i optymalizowania oprogramowania pod ARMy. Obecnie nie ma silnych (a przez to chętnie używanych) platform konsumenckich opartych o ARMy, więc oprogramowanie optymalizuje się powszechnie tylko pod x86, bo takie maszyny mają programiści.
2
Wibowit napisał(a):
Moim zdaniem migracja Apple na ARM przyspieszy proces portowania i optymalizowania oprogramowania pod ARMy. Obecnie nie ma silnych (a przez to chętnie używanych) platform konsumenckich opartych o ARMy, więc oprogramowanie optymalizuje się powszechnie tylko pod x86, bo takie maszyny mają programiści.
Dla mnie to nadmierny optymizm.
Tak samo mówiono o telefonach (w końcu używają ARM), a nadal nie widziałem żeby ktoś używał komputera osobistego z Linux na ARM (można kupić laptopa).
Przeskok na ARM blokowany jest tylko potrzebą wstecznej kompatybilności do najpowszechniej używanej technologii x86.
Strach, przed tym, że coś przestanie działać, a nie ma zastępstwa, podtrzymuje życie pochodnych x86.
Nawet na Linux większość pakietów dostarczana jest jedynie w wersji amd64
ARM będzie rosło w siłę, ale dopóki soft będzie dostarczany jedynie w postaci kodu maszynowego Amd64, to stare x86 będzie miało się dobrze.
Nadzieja to Java i .Net (zakładając, ze MS w końcu uda się dostarczyć Windows dobrze działającego na ARM).
Apple to tylko parę procent rynku konsumenckiego, nie istenieje na innych rynkach, wiec jego sukces Apple z ARM-ami zmieni jedynie nastawienie niektórych firm, ale co z tego potem wyniknie to już inna sprawa.
0
Dla mnie to nadmierny optymizm.
Tak samo mówiono o telefonach (w końcu używają ARM), a nadal nie widziałem żeby ktoś używał komputera osobistego z Linux na ARM (można kupić laptopa).
Smartfony i tablety mają wykastrowany OS, nie odpalisz na nich desktopowego środowiska graficznego, rozbudowanych IDE, standardowego OpenJDK, czy innych platform programistycznych, więc jako sprzęt dla programistów w zasadzie nie istnieją. Już prędzej widziałbym zależność w drugą stronę - emulator iPhone'a na ARMowym MacBooku będzie działał z natywną (pełną) prędkością i dzięki temu na ARMowym MacBooku będzie wygodniej się programowało aplikacje na iPhone'a.
Są zarówno laptopy na ARMach (np PineBook czy Surface) jak i blaszaki (np https://www.anandtech.com/show/15733/ampere-emag-system-a-32core-arm64-workstation ), ale co z tego skoro ostatecznie wydajność jednowątkowa jest słaba (a ta jest bardzo ważna w codziennym użytkowaniu) z różnych powodów, a produkty nieopłacalne (bo za te same pieniądze kupisz lepiej działające maszyny na Intelu czy AMD). W przypadku sprzętu Apple sytuacja jest zupełnie inna, bo jest duża szansa że Apple Silicon będzie mieć najwyższą wydajność jednowątkową (pomijając jakieś niszowe silnie zwektoryzowane programy, ale tych się na laptopach nie odpala) w przypadku uruchamiania kodu natywnego, a jednocześnie MacBooki oparte o ARMy mają być nawet trochę tańsze od tych opartych o x86. Podsumowując: naprawdopodobniej MacBooki na ARMach będą szybsze, tańsze i chłodniejsze od MacBooków na x86, a programiści i tak grzecznie przekompilują swoje programy na ARM tak jak Apple rozkaże. Z drugiej strony mamy ARMowe wersje Windowsa, które były sztucznie ograniczane przez MS, a MS nie wywierał żadnej presji czy zachęty na programistach, by kompilowali swoje programy pod tą wersję Windowsa.
Przeskok na ARM blokowany jest tylko potrzebą wstecznej kompatybilności do najpowszechniej używanej technologii x86.
Strach, przed tym, że coś przestanie działać, a nie ma zastępstwa, podtrzymuje życie pochodnych x86.
Apple niespecjalnie przejmuje się kompatybilnością wsteczną. Niedawno uwalili całkowicie możliwość uruchamiania aplikacji 32-bitowych x86. Jak zaczęli robić własne rdzenie ARM to też bardzo szybko wycięli możliwość uruchamiania aplikacji 32-bitowych. Apple nie jest (i nigdy nie było) dla osób, które czują strach, że coś przestanie działać.
0
A procesory ARM od AWSa kiedy wejdą na rynek konsumencki?
edit.
Nvidia is reportedly in ‘advanced talks’ to buy ARM for more than $32 billion
nooooo grubo