Apples A12 slår i7-4790K och R7-1800X i enkeltrådprestanda...

Trädvy Permalänk
Medlem
Registrerad
Jul 2017
Skrivet av Yoshman:

Projektet gick under namnet K12 och är endera nedlagt eller ligger i alla fall i malpåse.

Finns rykten om att en orsak till att Keller slutade var att han inte var överens med AMDs ledning kring satsningen på ARM. Tanken från början var att mikroarkitekturen i Zen skulle användas på för x86 och ARM64, "enda" som behövs är två olika front-end implementationer.

Jämför man Apples Swift (som jag är rätt säker Keller jobbade på under sin tid på Apple) och Zen så finns rätt mycket likheter! Hade varit väldigt kul att se K12 och Zen sida vid sida. K12 hade med 100 % säkerhet presterat bättre, frågan är bara hur mycket bättre.

Intressant tanke: Vad är det som hindrar att en processor (kanske en Zen, kanske en Intel) skulle ha två olika frontends samtidigt? Som det går att växla mellan. Ungefär som att växla mellan 32-bitars och 64-bitars läge. Alltså, något man skulle göra på processnivå i operativsystemet.

Du skulle alltså kunna kompilera om ett program till en ARM-binär och plötsligt så skulle du kunna köra ARM-program snabbare än motsvarande x86 eller x64-program utan att för den sakens skull vara långsammare på x86/x64?

För bäst hjälp, försök att svara på alla frågor som ställs i ett inlägg. Då slipper vi fråga om samma sak fler gånger, och du får hjälp snabbare.

Trädvy Permalänk
Medlem
Plats
Skåne
Registrerad
Apr 2009

Ja Apples SoC är sannerligen imponerande och de gör utan tvekan den bästa ARM baserade SoC:en på marknaden. Om nu ARM ska slå ut x86 så måste det däremot finnas produkter med ARM för att det ska hända och OEM tillverkarna verkar inte så intresserade av det än. Det räcker med att titta på always connected pc kategorin som inte verkar ha fått något större genomslag än. Det krävs nog att Apple ger upp x86 helt och går över till sina egna kretsar eller att Microsoft släpper en Surface med Snapdragon SoC för att det ska börja hända saker.

Speldator: AMD Ryzen 7 2700 I Sapphire R9 270X DualX I 8GB I Kingston SSDNOW V300 120 GB I Crucial BX100 500GB I 320GB 640GB I W10
Acer B1 770 I LG G3 I Nvidia Shield TV V2 I PS4 PS3 & X360 I 2DS DS PSP I Canon EOS M I Raspberry Pi 2

Trädvy Permalänk
Medlem
Plats
Mariefred
Registrerad
Jul 2011
Skrivet av WaspCustoms:

ja det var ju faktiskt rätt sjukt! 50x mindre effekt men fan så mycket högre IPC är rätt grymt!

Håller med snacka om att tekniken har gått framåt med dessa cpuer i mobilerna på bara 5 år

╔ Corsair 32GB DDR4 CL15 3000Mhz VENGEANCE RGB ■
╠ ASUS-ROG-MAXIMUS-X-HERO ■ ASUS-ROG-STRIX-GTX1080TI-OC ■ i7 8700K
╠ DeepCool Captain 280EX RGB ■ 2x Samsung 970 EVO 500GB■
╠ Deepcool NEW ARK 90 Electro Limited Edition NR58 ■ XFX PRO1000W Limited Black Edition
╚ Samsung SE790C 34" Ultrawide 3440x1440@75Hz

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av pv2b:

Intressant tanke: Vad är det som hindrar att en processor (kanske en Zen, kanske en Intel) skulle ha två olika frontends samtidigt? Som det går att växla mellan. Ungefär som att växla mellan 32-bitars och 64-bitars läge. Alltså, något man skulle göra på processnivå i operativsystemet.

Du skulle alltså kunna kompilera om ett program till en ARM-binär och plötsligt så skulle du kunna köra ARM-program snabbare än motsvarande x86 eller x64-program utan att för den sakens skull vara långsammare på x86/x64?

Finns flera CPU-modeller med två front-ends. Ett väldigt närliggande exempel är alla ARM modeller som stödjer både 32-bitars ARM och 64-bitars ARM, även om många instruktioner ser snarlika ut i assembler har de inte alls samma binära representation.

Problemet med en CPU med kombinationen x86_64 + ARM64 (egentligen Aarch64) är att front-end på en high-end x86 äter väldigt med transistorer!

Apples A12-systemkrets är runt 80-85 mm², det inkluderar då en relativt kompetent GPU och en kiselmässigt ungefär lika stor "NPU" (network processing unit).

Enligt AnandTechs mätningar i bilden ovan är tar de två Vortex kärnor plus de fyra små kärnorna (Tempest) 12 mm², det inklusive cache. "Små" kärnor är här rätt mycket inom citationstecken då AnandTechs uppföljande artikel konstaterar att dessa har högre IPC än ARM Cortex A73 som i sin tur ligger någonstans mellan dagens Atom och Zen/Skylake (Atom är inte alls var det en gång i tiden var, IPC är numera på Core2 nivå).

Ett CCX tar, enligt AMD, 44 mm². Det är det är alltså fyra kärnor mot Apples kärnor. I båda fallen är CPU-cache inräknat. D.v.s. trots att Apple har en långt bredare front-end och en långt bredare back-end tar det mindre yta än vad ett CCX kommer ta även om det blir "perfekt" skalning (säger inte TSMC upp till 60 % högre densitet för icke SRAM?)

Sedan finns det andra saker. Aldrig tänkt på varför både Intel och AMD stannat på 32 kB L1D$?

Orsaken är att L1D$ är extremt latenskritiskt, om man ser till att varje "grupp" (cache set) i cachen är exakt 4 kB så kan man slå upp i L1D$ parallellt med uppslagningen av virtuell-till-fysisk mappning (cache som kallas TLB).

Man vill inte gärna ha mer än 8 grupper i en L1$ cache, ju fler grupper ju mer ström drar det! Vidare kan man bara göra tricket med parallell uppslagningen om varje grupp är lika stor (eller mindre) än en adress-sida (page), som på x86 är 4 kB i normalfallet. Finns även 2 MB adress-sidor, men det fungerar inte att rent praktiskt att bara köra dessa så man är fast med 4 kB.

ARM stödjer 4 kB, 16 kB samt 64 kB. Apple har droppat stödet för 4 kB, vilket betyder att man kan ha en 8 gruppers L1$ på 128 kB och ändå stödja parallell uppslagning av TLB. Kan bara göras på x86 om man bryter bakåtkompatibilitet.

Vidare: x86 specificerade sin minnesmodell i en tid när multicore knappt fanns. Måste finnas en väldigt exakt definition av vad olika CPU-kärnor kan förvänta sig när det kommer till läsning/skrivning mot RAM. x86 har en extremt "strikt" minneskonsistensmodell -> enkelt för människor att resonera kring, men värdelöst när det kommer till optimeringspotential (något Nvidia Jensen brukar framhålla, GPUer ligger på andra extremen, extremt "lös" minneskonsistensmodell).

64-bitars ARM har en minneskonsistensmodell som är en perfekt match till vad bl.a. C++, Java och C# förväntar sig -> multitrådade program blir mer optimalt. Frågan är hur enkelt/effektivt det skulle bli att designa en back-end som både hanterar ARM och x86.

AMD tänkte ju göra just det med Zen, d.v.s man tänkte designa två CPUer med i princip samma back-end. Det var alltså två separata kretsar, inte en med två front-ends. ARM64 varianten hade kodnamnet K12, men lanserades aldrig. Frågan är om man stötte på tekniska problem eller om man bara insåg att det skulle försämra fokus?

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer