AMD Ry­zen vs In­tel Co­re

AMD Ry­zen, de con­cur­ren­tie, CPU2006 en de nieuw­ste Win­dows-com­pi­ler

C’t Magazine - - Inhoud - And­re­as Stil­ler

Komt dat even mooi uit: kort na de lan­ce­ring van AMD’s Ry­zen brach­ten zo­wel Mi­cro­soft als In­tel nieu­we ver­sies van hun Win­dows-com­pi­lers uit. Daar­mee voel­den we AMD's vlag­gen­schip R1800X, zijn voor­gan­ger Ex­ca­va­tor en en­ke­le con­cur­ren­ten ste­vig aan de tand. En na­tuur­lijk met de klas­sie­ker SPEC CPU2006 en 'strui­kel­blok' Flops.

AMD's Ry­zen is in eer­ste in­stan­tie be­doeld voor desktop­ge­bruik en daar­om rich­ten we ons voor­al op de daar­voor gang­ba­re Win­dows 10-om­ge­ving. On­der Win­dows wordt de Vi­su­al Stu­dio-com­pi­ler van Mi­cro­soft met af­stand het meest ge­bruikt om co­de te ge­ne­re­ren. Vol­gens on­ze ana­ly­se wordt ruim 90 pro­cent van de gang­ba­re Win­dows-soft­wa­re met (un­ma­na­ged) MSVC-C/++ ge­maakt. De In­tel-com­pi­ler die voor HPC-toe­pas­sin­gen bij Li­nux te­recht zo po­pu­lair is, kom je bij Win­dows slechts in­ci­den­teel te­gen, maar bij­voor­beeld wel bij Pho­to­shop CC en de Ci­ne­bench-ben­ch­mark.

On­ze toets­steen is de CPU2006-sui­te van de Sy­s­tem Per­for­man­ce Eva­lu­a­ti­on Cor­po­ra­ti­on (SPEC). Die is even­min al­leen op eso­te­ri­sche HPC-toe­pas­sin­gen ge­richt en test de in­te­ger­per­for­man­ce met tal­lo­ze gang­ba­re desktop­toe­pas­sin­gen als Go en scha­ken, com­pri­me­ren, beeld­her­ken­ning, H.264 (de)co­de­ren, ge­si­mu­leer­de da­ta­over­dracht, com­pi­ler­ben­ch­marks, Perl, XML en­zo­voorts. Zo­als je aan de naam ziet be­staat de sui­te al wat lan­ger, maar dit jaar moet de op­vol­ger toch echt uit­ko­men, ver­tel­de SPEC Open Sy­s­tem Group-ma­na­ger Jef­fry Reil­ley ons. Om­dat de vol­le­di­ge bron­co­de van de CPU2006-soft­wa­re be­schik­baar is, kan die al­tijd met de nieuw­ste com­pi­lers voor de nieuw­ste ar­chi­tec­tuur ge­com­pi­leerd wor­den. Van de In­tel- en Mi­cro­soft-com­pi­lers zijn sinds dit voor­jaar de de­fi­ni­tie­ve 2017-ver­sies be­schik­baar. Voor de In­tel-Com­po­ser 2017 met C/C++ en For­tran is dat al de twee­de up­da­te. Die heeft bo­ven­dien de run­ti­me-om­ge­ving van Vi­su­al Stu­dio no­dig. Hij is ech­ter nog niet af­ge­stemd op Vi­su­al Stu­dio 2017, maar gaat uit van de voor­gan­ger Vi­su­al Stu­dio 2015.

De nieu­we Vi­su­al Stu­dio 2017 houdt meer re­ke­ning met Li­nux. Hij kent cma­ke en kan mak­ke­lijk als ont­wik­kelom­ge­ving voor Li­nux-pro­gram­ma’s wor­den in­ge­zet. Om on­na­volg­ba­re re­de­nen kan de Mi­cro­soft-com­pi­ler ech­ter nog steeds niet over­weg met C99, dat in de bron­co­de van een van de CPU2006-ben­ch­marks wordt ge­bruikt (de kwan­tum­com­pu­ter­si­mu­la­tie 426.li­b­quan­tum). Met en­ke­le aan­pas­sin­gen aan de C(99)-bron­co­de kan die wor­den om­ge­zet naar C++ en toch ge­com­pi­leerd wor­den. Der­ge­lij­ke aan­pas­sin­gen gaan ech­ter te­gen de Run Ru­les van SPEC in, daar­om

staat in de ta­bel­len ver­der­op het la­bel (ong.) voor 'on­ge­veer'.

Li­b­quan­tum is so­wie­so een spe­ci­aal ge­val om­dat de In­tel-com­pi­ler die co­de au­to­ma­tisch enorm kan op­ti­ma­li­se­ren. Dat leidt na­tuur­lijk tot een mooi re­sul­taat, maar geen goe­de af­spie­ge­ling van de prak­tijk. We ver­mel­den al­le re­sul­ta­ten daar­om ook apart als SPECint-C/C++ zon­der Li­b­quan­tum.

De flo­a­ting­point-sui­te van CPU2006 be­vat hoofd­za­ke­lijk For­tran-pro­gram­ma’s, maar ook ze­ven we­ten­schap­pe­lij­ke C/ C++-pro­gram­ma’s. Zo­als ge­woon­lijk tes­ten we uit­slui­tend met 64-bit co­de, zon­der au­to­ma­ti­sche pa­ral­lel­li­sa­tie en zon­der spe­ci­a­le com­mer­ci­ë­le He­ap-bi­bli­o­the­ken. Bij au­to­ma­ti­sche pa­ral­lel­li­sa­tie krijg je na­me­lijk geen bruik­ba­re waar­den voor sin­gle-th­reads en juist die ge­ven in­zicht in het aan­tal 'In­struc­ti­ons per Clock' (IPC). We wil­len juist ant­woord op de vraag of Ry­zen daad­wer­ke­lijk 52 pro­cent meer in­struc­ties per klok­tik ver­werkt dan voor­gan­ger Ex­ca­va­tor. En hoe doen Broad­well-E en Ka­by La­ke het? Dat tes­ten we met de Mi­cro­soft­com­pi­ler.

De Mi­cro­soft Vi­su­al Stu­dio-ver­sies 2015 en 2017 on­der­steu­nen AVX2 en heb­ben ook ru­di­men­tai­re vec­to­ri­sa­tie. Bo­ven­dien kun je een ar­chi­tec­tuur voor­trek­ken (/fa­vor:In­tel of /fa­vor:AMD), al ont­breekt die op­tie in het me­nu van Vi­su­al Stu­dio. De AMD-op­ti­ma­li­sa­tie schijnt al­leen be­trek­king te heb­ben op Bull­do­zer, maar ook bij de 4e ge­ne­ra­tie daar­van (Ex­ca­va­tor/Bris­tol Rid­ge) ont­dek­ten we geen ver­schil met de stan­daard­ver­sie. Het­zelf­de geldt voor de twee hier ge­tes­te In­tel-sys­te­men, de di­rec­te con­cur­rent Broad­well-E (oc­ta­co­re Co­re i7-6900K) en de quad­co­re Ka­by La­ke Co­re i7 7700K.

SPECint en IPC

De re­sul­ta­ten van de Sin­gle Th­read-tests: SPECint komt bij een test met de Ry­zen R1800X op 3,6 GHz (4,0 GHz Boost) met AVX2-ge­op­ti­ma­li­seer­de co­de van MSVC 2017 tot een sco­re van (ong.) 35,4 pun­ten. De Ex­ca­va­tor (3,8 Ghz met 4,2 GHz Tur­bo) scoort slechts 21,2 pun­ten. Als je re­ke­ning houdt met het ver­schil in klok­fre­quen­tie, is de winst maar liefst 76 pro­cent. Ge­bruik je geen DDR4-2600-mo­du­les bij het Ry­zen-sys­teem maar DDR4-2400, dan valt de sco­re 3 pro­cent la­ger uit. De voor­sprong bij IPC is dan nog steeds meer dan 70 pro­cent.

In­tels Co­re i7 6900K is met 38,8 pun­ten on­ge­veer 10 pro­cent snel­ler. Bij een klok­fre­quen­tie van 3,2/3,7 GHz be­te­kent dat een 20 pro­cent ho­ge­re IPC. De winst gaat dank­zij de ho­ge fre­quen­ties van 4,2/4,5 GHz naar de Ka­by La­ke Co­re i7 7700K met een SPECint 1T-waar­de van 47,2. Dat is ech­ter al­leen qua ab­so­lu­te sco­re, want als je re­ke­ning houdt met de klok­snel­heid ligt de ÌPC-waar­de cir­ca 7 pro­cent on­der de Broad­well-E.

In­tel-com­pi­ler voor Ry­zen

De In­tel-com­pi­ler kun je nor­maal ge­brui­ken voor AMD-pro­ces­sors, maar die biedt ook een spe­ci­a­le op­tie met AVX-tu­ning: / arch:AVX. De AVX-op­ti­ma­li­sa­tie le­vert ech­ter niet al­tijd snel­le­re co­de op door de daar­aan ge­kop­pel­de la­ge­re klok­snel­heid.

Met 44,2 (zon­der) en 46,5 (met AVX) is de SPECint-co­de maar liefst zo’n 32 pro­cent snel­ler dan met de Mi­cro­soft-com­pi­ler. Als je de pro­ble­ma­ti­sche ben­ch­mark Li­b­quan­tum ech­ter uit­sluit, wordt de voor­sprong be­perkt tot 19 pro­cent. Bij SPECfp pakt de AVX-op­ti­ma­li­sa­tie ne­ga­tief uit: voor­al bij 459.GemFDTD daalt de per­for­man­ce met meer dan 40 pro­cent. Al­les bij el­kaar ge­no­men komt de Ry­zen tot een SPECf­p_2006_ ba­se-waar­de van 59,9 met AVX en 61,7 zon­der AVX.

Dat maak­te ons nieuws­gie­rig. We wil­den uit­zoe­ken waar­om de AMD-pro­ces­sors met een op­ti­ma­li­sa­tie van de In­tel-com­pi­ler slech­te­re sco­res be­haal­den. Een klei­ne patch op de juis­te plek deed won­de­ren en al snel draai­den de AMD-pro­ces­sors zon­der merk­ba­re pro­ble­men met de ge­op­ti­ma­li­seer­de In­tel-co­de. Bij de SPECint-sui­te werd het ver­schil ver­oor­zaakt door een en­ke­le ben­ch­mark, na­me­lijk de eer­der ge­noem­de ben­ch­mark 462.li­b­quan­tum. Die ging van 211 (Blend-SSE3) en 291 (Blend-AVX) naar 409, waar­door de al­ge­he­le SPECint-waar­de steeg naar 47,4. Dat was pre­cies de waar­de die con­cur­rent Broad­well-E haal­de zon­der AVX-op­ti­ma­li­sa­tie. Met vol­le­di­ge op­ti­ma­li­sa­tie kwam die tot 55,1 SPECint-pun­ten.

Bij SPECfp pro­fi­te­ren voor­al drie ben­ch­marks van de 'spe­ci­a­le op­ti­ma­li­sa­tie', hoe­wel de winst wat be­schei­de­ner is: cir­ca 12 tot 42 pro­cent, ter­wijl 459. GemFDTD juist zo’n 25 pro­cent ver­liest. In to­taal stijgt SPECfp daar­mee met 5 pro­cent naar 65 pun­ten. Dat is ten op­zich­te van de Ex­ca­va­tor een stij­ging van 50 (SPECint) tot 63 pro­cent (SPECfp). Nog span­nen­der is ech­ter het re­sul­taat in ver­ge­lij­king met de Broad­well E, want die ver­liest daar door zijn la­ge­re klok­snel­heid (waar­bij de vier ge­heu­gen­ka­na­len geen voor­deel op­le­ve­ren). Hij scoort slechts 57,8 SPECf­p_2006_­ba­se, een 12 pro­cent la­ge­re sco­re dan de Ry­zen. De Ka­by La­ke met zijn ho­ge klok­snel­heid sprint hier naar 83,1 SPECfp-pun­ten.

Bij de SPECRa­te-waar­den met 16 th­reads blinkt de Broad­well-E daar­en­te­gen uit met zijn vier ge­heu­gen­ka­na­len. Hij ver­slaat met de zwaar ge­op­ti­ma­li­seer­de In­tel-co­de de Ry­zen dui­de­lijk met 385/286 te­gen­over 305/228 SPECint/fp_ ra­te_­ba­se2006. De quad­co­re Ka­by La­ke (229/180) kan daar niet mee­ko­men en de Ex­ca­va­tor (71,8/75,5) speelt in een he­le an­de­re di­vi­sie. De sco­res zijn cir­ca 50 pro­cent ho­ger dan SPECint_ra­te_­ba­se2006 (ong.) met Mi­cro­soft-co­de: 204 pun­ten bij Ry­zen en 255 bij Broad­well-E. Dat klinkt dra­ma­ti­scher dan het in de prak­tijk is, want zon­der Li­b­quan­tum is het ver­schil nog maar iets meer dan 20 pro­cent.

De sin­gle-th­read-ben­ch­marks heb­ben we bij de Ry­zen RX1800X uit­ge­voerd met door AMD ge­le­ver­de 8GB-DRAM-mo­du­les met DDR4-2600. Dat ging gro­ten­deels zon­der pro­ble­men, maar bij vol­le be­las­ting met 16 th­reads en 32 gi­ga­by­te ge­heu­gen klaag­de de sui­te re­la­tief vaak over 'mis­com­pa­res'. Het sys­teem door­liep daar geen com­ple­te test mee, zo­dat we moesten over­stap­pen op DDR4-2400 mo­du­les.

To­po­lo­gie-men­gel­moes

Van de ge­heu­gen­ben­ch­mark Stream van Jo­hn McCal­pin (ge­schre­ven in pu­re C met OpenMP 2.0) heb­ben we de meest re­cen­te ver­sie 5.10 ge­bruikt. Bij het com­pi­le­ren moet je de ma­trix­groot­te zo kie­zen dat

die steeds mi­ni­maal het vier­vou­di­ge is van de L3-ca­che­groot­te. De ben­ch­mark is ge­schikt voor zwaar­de­re ser­ver­pro­ces­sors en ge­bruikt 300 MB per ma­trix. Voor de per­for­man­ce komt het er­op aan dat je de juis­te com­pi­ler ge­bruikt en het juis­te aan­tal th­reads aan de ver­schil­len­de co­res toe­wijst. Maar wat is de juis­te com­pi­ler? Voor Stream-Triad is dat on­ge­twij­feld de In­tel C/ C++-com­pi­ler. Zo­wel MSVC 2017 als GCC 6.2 on­der Li­nux pres­te­ren dui­de­lijk min­der. Die wer­ken niet op­ti­maal met pre­fet­ching om de drie streams in stand te hou­den.

Het juis­te aan­tal th­reads en de toe­wij­zing ont­dek je door te ex­pe­ri­men­te­ren. Het is daar­bij han­dig als je weet hoe de fy­sie­ke en lo­gi­sche co­res op­ge­bouwd zijn. Dat is bij Ry­zen geen kin­der­spel. Aan­van­ke­lijk werd de Win­dows 10-sche­du­ler zelfs ver­we­ten de toe­wij­zing niet goed af te han­de­len. Die sche­du­ler ge­droeg zich in­der­daad wel een beet­je vreemd, maar dat is een an­de­re kwes­tie. Win­dows 10 be­nut de lo­gi­sche co­res wel cor­rect, zo­als het uit­le­zen van GetLo­gi­calPro­ces­sorIn­for­ma­ti­on() laat zien.

Er zijn ech­ter tal­lo­ze pro­gram­ma’s die niet op Win­dows ver­trou­wen en zelf de to­po­lo­gie wil­len her­ken­nen. Dat gaat bij Ry­zen vaak mis. Het pro­bleem zit hem in de ge­bruik­te al­go­rit­men voor het her­ken­nen van de to­po­lo­gie. De zo­wel door In­tel als lan­ge tijd door AMD ge­bruik­te 'Pro­ces­sor and Co­re Enu­me­ra­ti­on Using CPUID' leidt bij Ry­zen tot een ver­keer­de her­ken­ning en daar­door vaak slech­te op­ti­ma­li­sa­tie. Zelfs AMD's ei­gen tool enum.c uit 2013 her­kent Ry­zen ver­keerd, net als In­tels OpenMP: de een ziet 16 fy­sie­ke co­res, de an­der een en­ke­le co­re met 16 th­reads …

In­tels OpenMP kun je toch ge­brui­ken als je de toe­wij­zing via de om­ge­vings­va­ri­a­be­le KMP_AFFINITY ex­pli­ciet re­gelt. OpenMP van­af ver­sie 4.0 biedt daar ook OMP_PROC_BIND en OMP_PLACES voor. Maar he­laas, Mi­cro­soft on­der­steunt al­leen het 15 jaar ou­de OMP 2.0 uit 2002.

DDR4-2400 biedt per ka­naal een the­o­re­ti­sche band­breed­te van 19,2 GB/s. Stream-Triad ge­bruikt ech­ter twee streams te­ge­lij­ker­tijd voor het le­zen en een en­ke­le voor schrij­ven, waar­door de prak­tijk­re­sul­ta­ten wat be­schei­de­ner zijn. De R1800X ver­deelt de da­ta ook bij slechts een en­ke­le th­read ef­fi­ci­ënt en komt daar­mee tot 28,6 GB/s. De Ex­ca­va­tor op het Bris­tol Rid­ge­plat­form zou vol­gens de do­cu­men­ta­tie ook een du­al-chan­nel DDR4-ge­heu­gen­con­trol­ler heb­ben, maar in ons test­sys­teem Asus M320-C haalt hij met een en­ke­le th­read slechts 12 GB/s. Zelfs met al­le vier de co­res komt hij niet ver­der dan 18,6 GB/s.

Bij Ry­zen zijn twee th­reads vol­doen­de voor de vol­le­di­ge band­breed­te. Als die draai­en als SMT-duo op de­zelf­de co­re, ha­len ze 29,6 GB/s, ver­deeld over twee co­res in het­zelf­de co­re­com­plex (CCX) wordt dat 32,4 GB/s. Het beste re­sul­taat krijg je als de twee th­reads over de twee CCX'en ver­deeld zijn. Dan komt het re­sul­taat op 33,8 GB/s. Zet je al­le 16 th­reads aan het werk, dan daalt de per­for­man­ce met cir­ca 10 pro­cent tot 30,5 GB/s.

Een ver­ge­lijk­baar beeld zien we bij de Ka­by La­ke Co­re i7-7700K. Met een en­ke­le th­read loopt de stream met 28,5 GB/s. Dat loopt op tot 29,5 GB/s (2 th­reads) en daalt daar­na lang­zaam tot 27,8 GB/s (acht th­reads).

De Broad­well-E is rij­ke­lijk voor­zien van vier ge­heu­gen­ka­na­len, maar komt bij een en­ke­le th­read lang­zaam op gang met slechts 21,1 GB/s. Het is dus geen won­der dat de sin­gle-th­read-per­for­man­ce re­la­tief zwak is. Met twee th­reads streamt hij ech­ter al met 38 GB/s. En bij vier th­reads, op­ti­maal ver­deeld over de fy­sie­ke co­res, komt hij pas echt op gang tot hij zijn maxi­mum be­reikt van bij­na 55 GB/s. De ge­vol­gen daar­van zie je ook te­rug bij SPECra­te.

De op HPC-ge­bied zo po­pu­lai­re Lin­pack-ben­ch­mark heb­ben we ach­ter­we­ge ge­la­ten om­dat die in eer­ste in­stan­tie af­han­ke­lijk is van de kwa­li­teit van de BLAS-li­bra­ry. Zo­lang AMD op dat ge­bied niets fat­soen­lijks heeft, is een ver­ge­lij­king zin­loos. We kre­gen de zwaar ge­op­ti­ma­li­seer­de In­tel-AVX2-Lin­pack-ver­sie via een Patch wel gro­ten­deels aan de praat op Ry­zen, maar de re­sul­ta­ten we­ken te veel af van wat the­o­re­tisch haal­baar is.

Flops in plaats van Lin­pack

De SMP Lin­pack-sco­re be­rust gro­ten­deels op de ma­trix­ver­me­nig­vul­di­ging DGEMM.

Die maakt bij nieu­we­re pro­ces­sors weer ge­bruik van de ge­com­bi­neer­de ver­me­nig­vul­di­ging/op­tel-in­struc­tie (FMA) van de AVX-units. De daad­wer­ke­lijk be­haal­de pu­re FMA-sco­re is een in­di­ca­tie voor wat bij Lin­pack haal­baar is. Je moet daar min­stens 90 pro­cent van ha­len als de ben­ch­mark echt goed ge­com­pi­leerd is. Het Flops-pro­gram­ma van Goog­le-pro­gram­meur Alex Yee doet exact dat soort FMA-ben­ch­marks. Hij was ook ver­ant­woor­de­lijk voor het be­ken­de y-crun­cher, waar­mee Pi en e tot op een bil­joen de­ci­ma­len be­re­kend kun­nen wor­den. Het Flops-pro­gram­ma leid­de tot gro­te pro­ble­men om­dat Ry­zen bij duur­be­las­ting met FMA-in­struc­ties van 3 ope­ran­den (FMA3) crash­te. Ons gi­ga­by­te-test­sys­teem is ech­ter voor­zien van een nieu­wer BIOS en nieu­we mi­cro­co­de (0x80000111c), waar­door het Flops-pro­bleem ver­le­den tijd is. Het pro­bleem deed zich trou­wens niet met al­le ge­com­pi­leer­de co­de voor, al­leen als daad­wer­ke­lijk FMA-in­struc­ties zon­der eni­ge tus­sen­pau­ze ge­ge­ne­reerd wer­den. Dat was het ge­val bij Mi­cro­soft MSVC 2015 en 2017.

Yee ge­bruikt zo­ge­he­ten in­trin­sics, een soort in C be­schik­ba­re as­sem­bler-in­struc­ties. Daar­door zou je kun­nen den­ken dat de re­su­la­ten com­pi­leron­af­han­ke­lijk zijn, maar dat is niet het ge­val. De com­pi­ler moet ook de re­gis­ters be­he­ren en dat heeft Mi­cro­soft dui­de­lijk beter voor el­kaar dan In­tel. Bij­zon­der dui­de­lijk is dat bij Flops-ben­ch­marks met ge­schei­den ver­me­nig­vul­di­gen en de­len. Bij het dis­as­sem­ble­ren van de In­tel-co­de zie je daar­bij tal­lo­ze ge­heu­gen­aan­roe­pen, ter­wijl die bij Mi­cro­soft nau­we­lijks no­dig zijn. Daar­door loopt de Mi­cro­soft-co­de ruim 50 pro­cent snel­ler. Bij FMA3 zijn ze on­ge­veer even snel. Ry­zen on­der­steunt net als Ex­ca­va­tor en Pi­le­dri­ver ook FMA4, waar­bij geen bron­re­gis­ter over­schre­ven wordt. Daar biedt ech­ter al­leen de Mi­cro­soft-com­pi­ler in­trin­sics voor. FMA4 is zo'n twee pro­cent tra­ger dan FMA3. Zo­als be­kend heeft Ry­zen slechts een 128-bit bus­breed­te en AVX-een­he­den, waar­door de per­for­man­ce per co­re bij die ben­ch­marks niet kan con­cur­re­ren met In­tel. Bij 256-bit FMA3 (DP) ha­len de acht fy­sie­ke co­res 236 GFlops, ter­wijl Broad­well E met 440 GFlops aan kop gaat. Ka­by La­ke haalt 282 GFlops en Ex­ca­va­tor schom­melt rond de 64 GFlops.

Con­clu­sie

Ry­zen houdt goed stand bij CPU2006 en Stream. De veel duur­de­re Broad­well-E springt er al­leen uit als hij zijn vier ge­heu­gen­ka­na­len echt kan be­nut­ten. Bij sin­gleth­read-ge­bruik scoort hij vaak la­ger, zelfs bij het voor AVX-ge­op­ti­ma­li­seer­de SPECfp. In­tels com­pi­ler uit de Com­po­ser-sui­te 2017 le­vert door­gaans snel­le­re co­de op In­tel-en AMD-sys­te­men dan die van Mi­cro­soft Vi­su­al Stu­dio 2017. Als je de pro­ble­ma­ti­sche ben­ch­mark 462.li­b­quan­tum ech­ter weg­laat, is het ver­schil nog maar zo'n 10 tot 20 pro­cent. Soms del­ven de In­tel-com­pi­lers ech­ter ook het on­der­spit, zo­als bij som­mi­ge me­tin­gen van de Flops-ben­ch­mark. (mdt)

Newspapers in Dutch

Newspapers from Netherlands

© PressReader. All rights reserved.