en welke benchmarks heb je dan op de M1? Want behalve een Cinebench (ben ik niets mee) vindt je weinig.
Gewoon hele standaard benchmarks zoals
SPECint. Zie daar de performance van de M1 in vergelijking met een Ryzen 9 5950x met een TDP van 105W en een veel hogere klokfrequentie.
De M1 hoge IPC? ja natuurlijk, met minimale instructies dat bijna niets doen (…) A propos, x86 doet dat ook, het decode in micro-ops en dat reorderen en zoveel meer. Dus feitelijk wordt de CISC in RISC vertaald, en dan wordt hetzelfde gedaan... oeps.
Mooi dat je eerst zegt dat de M1 minder doet per instructie en daarna dat x86 precies hetzelfde werkt..
En CISC wordt niet in RISC vertaald, RISC/CISC gaat over de instructieset, niet over hoe deze geïmplementeerd is, µops zijn niet vergelijkbaar met RISC instructies.
Het gaat hier dus om micro-ops, niet op macro-ops. De decoder decodeert macro-ops naar micro-ops, vanaf dat punt werken de CPU’s op vergelijkbare manier, alleen in het geval van een x86 met een veel kleinere ROB vanwege de decode bottleneck (352 entries in sunny cove). De M1 kan altijd 8 macro-ops tegelijk decoderen, hoeveel µops dit per macro-op zijn ligt natuurlijk aan de instructies, maar dit zullen er inderdaad minder zijn van voor een complexe x86 instructie. De x86 kan echter alleen het meest optimale geval 4 instructies tegelijk decoderen. De pre-decoder werkt met een buffer van 16 bytes en vult deze pas aan als ie helemaal leeg is. De pre-decoder verwerkt maximaal 6 instructies per kloktik. Als er dus 7 instructies in de buffer staan dan kost het 2 tikken om deze alle 7 te verwerken, en aangezien x86 instructies tot 15 bytes lang kunnen zijn kan het ook zijn dat er maar 1 instructie tegelijk in past. De typische decode throughput is dan ook maar 2.5 macro-ops per kloktik (bron: wikichip).
Het klopt dat RISC cpu’s meer macro-ops nodig hebben om hetzelfde te bereiken, maar je kan natuurlijk 1 enorme macro-op in x86 niet direct vergelijken met een 1 kleinere macro-op in ARM. Zo’n complexe macro-op emit natuurlijk meer µops dan 1 simpelere RISC macro-op, maar neemt ook veel meer geheugenruimte (en plek in de decoder buffer) in. Om het meest extreme geval te nemen: een Intel CPU kan maar 1 hele complexe 15-byte instructie per kloktik decoderen, in dezelfde kloktik doet de M1 8 macro-ops. Daarnaast heeft de x86 ook nog verschillende decoders: meerdere decoders voor simpele en 1 voor complexere instructies. Dus als er toevallig 2 complexe instructies in de buffer zitten kan ie die niet tegelijk in 1 kloktik decoderen.
Het complexe design van x86 maakt dus dat de daadwerkelijke throughput (in µops) nogal afhangt van de specifieke code die er gerund wordt. In een RISC processor zal dit veel consistenter zijn.
Waar CISC wel een voordeel heeft (had?), is in de totale grootte van de code. Hoewel de M1 dus meer macro-ops per kloktik kan verwerken, nemen deze wel flink wat meer ruimte in dan vergelijkbare x86 code. 8 ARM macro-ops nemen altijd 32 bytes in. Een RISC processor is dus meer afhankelijk van geheugenbandbreedte dan een CISC processor. Dit was vooral vroegen een issue omdat cache geheugen erg duur was, tegenwoordig is het veel minder een probleem: RISC processoren zijn nu voorzien van vrij grote L1/L2 caches.
Een intel/AMD kan je ook zonder koeling gebruiken, maar moet je dan gewoon undervolten/underclocken... werkt gewoon.
Alleen performed een M1 met nauwelijks koeling en stroomverbruik bijna net zo goed als de stroom zuipende heethoofdjes van Intel en AMD. Ja, je kan een Intel of AMD CPU underclocken en undervolten, en intel heeft ook een aantal van dat soort SKU’s. Het hele artikel waar deze discussie mee begon gaat over nu net over zo’n CPU van Intel, waar ze na een jaar al mee stoppen omdat niemand zit te wachten op zo’n slecht presterende CPU.
En over Chris Lattner... die heeft veel andere dan Apple dingen gedaan. Hij was trouwens niet alleen voor LLVM. En LLVM is van 5 jaar *voor* hij bij Apple werkte. Oeps.
Hij begon aan LLVM voordat ie bij Apple kwam, inderdaad, maar LLVM was toen meer een research projectje en geen volledige compiler. Hij heeft de Clang C/C++ compiler (op basis van LLVM) gebouwd toen ie bij Apple werkte.
Weet je nog dat Apple ook gewoon PowerPC gedaan heeft? Da's toch ook RISC, dus zou het perfect efficient moeten zijn?
PowerPC was van IBM, en is een wat uitgeklede versie van de POWER architectuur, Met die architectuur is op zich niks mis, maar IBM was echter vooral geïnteresseerd in het gebruik van POWER voor zware servers. Deze architectuur is dus met een heel ander doel ontwikkeld, en deze terugschalen naar een desktop/laptop CPU werkte gewoon niet.
Een RISC processor hoeft niet per see super efficient te zijn, Een van de oorspronkelijke ideeen achter RISC was juist dat door het simpel maken van de CPU (ten koste van performance) je de kloksnelheid enorm kan verhogen en zo de lagere performance compenseren.
Again, RISC of CISC zegt niets over hoe een CPU geïmplementeerd is, het is maar een deel van het plaatje. RISC maakt hele efficiënte superscalar CPUs zoals de M1 mogelijk, maar dat wil niet zeggen dat je geen andere kanten op kan met RISC.
Vraag eens de Playstation3... En zijn ze dan niet daarna terug naar Intel gegaan, wegens performance en efficientie?
Dat heeft echt helemaal niets met dit verhaal te maken. Ja, er zat toevallig ook een PPC core in de Cell processor (omdat het ding nu eenmaal van IBM was dus logisch dat ze hun eigen cores gebruikten), maar dat was niet waar de rekenkracht van de Cell vandaan moest komen.