Øker til 1333FSB

[invariant]

Som jeg allerede har sagt, er det ikke godt å si hva CPUID sjekken gjør, men siden den er helt unødvendig, synes du ikke det er litt rart at Intel forandrer på den slik at det skal være vanskeligere å patche den bort, de drifter da en helt unødvendig kode?

5229671[/snapback]

Nå er jeg også noe skeptisk til _hvordan_ Intel kompilatorene foretar sjekk av features på en CPU, men _hvorfor_ en sjekker for features er vel ikke så rart? En vil jo ikke risikere at en måker SSE kode inn i en CPU som ikke støtter dette og dermed kan forårsaka alskens snåle feilsituasjoner. Ergo er det ikke en unødvendig kode, men den er jo så absolutt ikke tilpasset hensiktsmessig bruk av andre prossessorer en de levert fra Intel.

5229750[/snapback]

 

Denne kritikken støtter jeg fullt ut. Her burde Intel ha tenkt seg litt bedre om. Det jeg har hørt er at det skal ha noe med HT å gjøre, dvs. AMD har jo ikke HT å da er det ikke så lurt å bruke det, dvs. HT kan aktiveres med /Qparalell samt diverse openmp triks.

 

Invariant.

[Anders Jensen]

Siden dette går på Ace's også:

 

http://www.aceshardware.com/forums/read_po...47329&forumid=1

 

"Just use the 64bit icc. It doesn't generate any CPUID checks for SSE2

because SSE2 is standard on 64bit. It might for SSE3. SSE3 is

relatively obscure though and not that important." Av ingen ringere enn Andi Kleen.

[invariant]

Som jeg allerede har sagt, er det ikke godt å si hva CPUID sjekken gjør, men siden den er helt unødvendig, synes du ikke det er litt rart at Intel forandrer på den slik at det skal være vanskeligere å patche den bort, de drifter da en helt unødvendig kode?

5229671[/snapback]

De har altså to "code paths" eller hva det nå enn heter. En optimalisert og en som er garantert å kjøre på "alt" av hardware. Basert på CPUID sjekken så velges en av de to.

5229750[/snapback]

 

Hei.

 

Fint at du nevner dette, for på dette punktet er dokumentasjonen noe uklar.

Her er en oppklaring.

 

Man kan enten lage kode bare for SSE2 (som eksempel), eller kode for SSE2 som også kjører uten SSE2, dvs. to "code paths". Sistnevnte har jeg sett at gir en god del tregere kode, og i overgangsperioden mellom x87 og SSE2 (perioden 2000 - 2004), valgte vi derfor isteden å selge to versjoner av koden, en med SSE2 og en uten.

 

Altså har vi (f.eks.) opsjonene:

 

/QaxN - lager kode for SSE2 men kjører også andre steder: to "code paths".

/QxN - Lager kode bare for SSE2.

 

Så, er du sikker på at hardwaren din støtter SSE2, så bør du ligge unne opsjonene /QaxW, /QaxN,/QaxP osv. bruk heller /QxW, /QxN,/QxP. OBS: siste opsjon /QxP krever SSE3, men det er jo også vanlig på de nyeste AMD Opteron etterhvert. Ellers bør man ligge unna opsjonen /fast for det er aldri godt å vite hva den inneholder, f.eks. innebærer den bl.a. /QxP nå, og det er ikke så mange platformer med SSE3 foreløpig.

 

Dermed kan man trygt bruke /QxN (SSE2 en "code path") og /QxP (SSE3 en "code path") på AMD-64, så lenge hovedprogrammet (PROGRAM,main) kompileres med /QxW.

 

Typisk bra code får en vet å bruke /O2 (evt. /O3) og /Qip (evt. /Qipo) sammen med /QxN (SSE2) eller /QxP (SSE3).

 

 

Invariant.

Endret 30. november 2005 av invariant

[invariant]

Siden dette går på Ace's også:

 

http://www.aceshardware.com/forums/read_po...47329&forumid=1

 

"Just use the 64bit icc. It doesn't generate any CPUID checks for SSE2

because SSE2 is standard on 64bit. It might for SSE3. SSE3 is

relatively obscure though and not that important." Av ingen ringere enn Andi Kleen.

5229869[/snapback]

 

Riktig. Kleen har helt rett:

 

Just use the 64bit icc. It doesn't generate any CPUID checks for SSE2

because SSE2 is standard on 64bit. It might for SSE3. SSE3 is

relatively obscure though and not that important.

 

SSE3 er klart obskurt med mindre man holder mye på med komplekse tall ol.

Dermed kan vi unngå testen både på Windows (min workaround) og på Linux-64 (ingen test).

 

Invariant.

[invariant]

Når du først bruker begrepet invariant som nick, synes jeg i det minste du kunne sette deg inn i betydningen av begrepet, binær filer fra IFC/ICC er ikke invariant mhp. platform.

5229671[/snapback]

 

Hei Del!

 

Det jeg skrev var:

 

Dersom en kompilerer hovedprogrammet med /QxW, så kjører koden fint på alle platformer.

 

Dette er ingen overdrivelse, for Intel leverer nøyaktig samme kompilator til Win32, Win-64, Linux-32 og Linux-64.

 

Det som er kjekt da er at man å utvikle kode i Microsoft sitt brukervennlige debugger-miljø (her er vel ingen lika bra!) på Windows, for deretter å rekompilere koden med nøyaktig samme Makefile, opsjoner osv. på de 4 over nevnte platformer. Bedre invarians er ikke mulig slik jeg ser det (bortsett fra Java da). Og, jo, alle Intel kompilatorer og kompilatoropsjoner osv. helt identiske på de ulike platformene, vi har til å med sett at .asm koden til resulterende executable blir den samme.

 

Invariant.

Endret 8. desember 2005 av invariant

[snorreh]

Man kan enten lage kode bare for SSE2 (som eksempel), eller kode for SSE2 som også kjører uten SSE2, dvs. to "code paths". Sistnevnte har jeg sett at gir en god del tregere kode, og i overgangsperioden mellom x87 og SSE2 (perioden 2000 - 2004), valgte vi derfor isteden å selge to versjoner av koden, en med SSE2 og en uten.

 

Altså har vi (f.eks.) opsjonene:

 

  /QaxN - lager kode for SSE2 men kjører også andre steder: to "code paths".

  /QxN - Lager kode bare for SSE2.

 

Så, er du nogelunder sikker på at hardwaren din støtter SSE2, så bør du ligge unne opsjonene /QaxW, /QaxN,/QaxP osv. bruk heller /QxW, /QxN,/QxP. OBS: siste opsjon /QxP krever SSE3, men det er jo også vanlig på de nyeste AMD Opteron etterhvert. Ellers bør man ligge unna opsjonen /fast for det er aldri godt å vite hva den inneholder, f.eks. innebærer den bl.a. /QxP nå, og det er ikke så mange platformer med SSE3 foreløpig.

 

Dermed kan man trygt bruke /QxN (SSE2 en "code path") og /QxP (SSE3 en "code path")  på AMD-64, så lenge hovedprogrammet (PROGRAM,main) kompileres med /QxW.

5229953[/snapback]

Dette er jo nettopp dette som Mark Mackey har sjekket nøye her:

http://www.swallowtail.org/naughty-intel.html

The -xK flag to the 'ifc' compiler specifies that SSE instructions should be used (the equivalent to gcc's -fpmath=sse). If we compiled with -axK (produce both normal 386 code and SSE code and decide at runtime which to use), then all was OK. So, it looked like some sort of bug with the SSE code emitted by the compiler, so I was tempted simply to downgrade again and wait for the next version, which hopefully would have fixed the bug.

 

I cast a final eye over the last run on the compute farm, and noticed that while most of the machines segfaulted on the -ax code, a few didn't. Interestingly, the ones on which the code worked were all single-processor Pentium 4s, which the ones on which it crashed were all dual-processor Athlon MPs. Hmmm. It's either an SMP bug or an AMD bug, and I was interested enough to try and work out which.

[...]

So, it looks like Intel did indeed address the bug of code compiled with -xK crashing on Athlon machines due to their nobbled CPUID check. However, they didn't fix it by removing the CPUID check, they fixed it by removing the 'is SSE available?' check. Note that nobody is going to release production code compiled with -xK, as even in the new version it will indeed crash if run on an old Pentium with no SSE support. Production code will be compiled with the -ax flags, and this won't even attempt to use any SSE/SSE2 instructions on non-Intel chips.

[...]

It is a shame that the Intel compiler, which use to be almost the no-brainer choice if your primary concern was fast code, is now being coerced into being a marketing tool. Crippling the output for non-Intel chips may mean that some published benchmarks may end up bogusly favouring Intel over AMD, but the cost is that if you want to release fast production code I can't recommend the (unpatched) compiler. There are an awful lot of AMD machines out there!

 

To Intel: there is a standard mechanism out there (invented by you!) for questioning a CPU as to its capabilities. You should be using that, not checking for the presence of your trademark. I don't expect Intel to support AMD-specific extensions, and I also don't expect Intel to have to test its compiler on AMD CPUs. However, if a CPU states that it can do SSE3 or whatever then I expect the code produced by the Intel compiler to use SSE3 instructions rather than to check first if the chip was made by Intel. It was not acceptable for Microsoft to go out and deliberately cripple Windows under DR-DOS, and likewise it isn't acceptable for you to cripple a product that you sell for not inconsequential sums of money so that it won't perform properly on competitors' hardware.

el-asso: /QxW (Fortran) er det samme som -xW (C/C++).

Endret 30. november 2005 av snorreh

[snorreh]

Stemmer ikke. Lag en knøttliten fil med PROGRAM (Fortran) eller main (C/C++), kompiler denne med /QxW (Fortran) eller -xW (C/C++). Inne i PROGRAM eller main kaller du en subrutine i en annen fil som refererer til resten av koden din som du kan kompilere akkurat sånn som du vil, dvs. pass på SSE2/SSE3 som vanlig. Vi bruker /QxN (dvs. -xN i C/C++) slik at vi får SSE2. Faktisk kan du selv sjekke i .exe fila med et program som "strings" at teksten "Fatal Error : This program was not built to run on the processor in your system." er BORTEVEKK!

 

Slik kode kjører meget effektivt på både Opteron og AMD-64, noen ganger også raskere enn tilsvarende Xeon/Pentium 4/D. For noen problemstillinger er nemlig AMD bedre, også med Intel kompilator.

5228840[/snapback]

Tja, jeg sendte dette over til Mark Mackey for å se hva han hadde å si og dette er svaret jeg fikk fra ham:

Yes, that's correct. However, there are two problems:

 

1) Code build with this flag will segfault on a PIII or an Athlon Thunderbird or any earlier CPU, so those flags are useless for code which you're going to distribute

 

2) Although the code that you compile is forced to use SSE2, if you use any vectorised math functions then these still have the CPUID check

 

i.e. mysub() is compiled to use SSE2 instructions, but it uses the exp() function. The Intel Math Library linked into your code checks the CPUID and calls VmlsExp4.W (the SSE2 routine) on Intel chips, and VmlsExp4.I (a non-vectorised exponential routine) on AMD chips. If your code uses a lot of the match primitives this can have a big effect on performance. You can see that from the performance table in my web page (http://www.swallowtail.org/naughty-intel.html): the -axW code has a huge performance change on AMD chips if the  Intel CPUID check is patched out. The -xW code has a much smaller change, but there is still a difference of 5%  between the patched and unpatched code, and in some of out other code (which relies very heavily on vectorised exp() calls) the difference can be 25% even with -xW.

 

So, this is a partial fix, but Intel's CPUID check will still hurt performance on AMD chips.

 

Mark.

Endret 30. november 2005 av snorreh

[invariant]

1) Code build with this flag will segfault on a PIII or an Athlon Thunderbird or any earlier CPU, so those flags are useless for code which you're going to distribute

 

Mark.

 

 

Sant nok, men dette er en overmåte konservativ approach. Hvorfor ikke lage kode som er bakoverkompatibel helt til Intel 4004 som kom 3 Qtr, 1971? Hvor skal man sette grensen? Vi har som sagt to versjoner, en med SSE2 og en uten. Den uten har ikke vært forespurt siden 2004.

 

Er andre kompilatorer noe bedre her? Lager man SSE2, med en hvilken som helst kompilator, så går den jo ikke på en PC uten SSE2.

 

2) Although the code that you compile is forced to use SSE2, if you use any vectorised math functions then these still have the CPUID check

 

Dump av mycode.obj ser (bl.a.) slik ut:

 

0000003E: movapd xmm0,xmmword ptr .bss[esi]

00000046: movapd xmm1,xmmword ptr .bss[esi+20h]

0000004E: call _vmldPow2

00000053: movapd xmmword ptr .bss[esi+40h],xmm0

 

Hvor en kaller _vmldPow2. Alle de variantene jeg fant av _vmldPow2 i biblioteket inneholder kun gode effektive SSE2 instruksjoner. Jeg tror Mark har blandet sammen SSE med SSE2 på dette punktet.

 

Under er dump av _vmldPow2 variantene (tok dette bort, det var jo så mange linjer og de fleste har vel fått dette med seg). Bare flotte effektive SSE2-instruksjoner.

 

Invariant.

 

Endret 30. november 2005 av invariant

[invariant]

i.e. mysub() is compiled to use SSE2 instructions, but it uses the exp() function. The Intel Math Library linked into your code checks the CPUID and calls VmlsExp4.W (the SSE2 routine) on Intel chips, and VmlsExp4.I (a non-vectorised exponential routine) on AMD chips.

 

Mark er jo litt unøyaktig i sine antagelser. Har han Intel kompilator? To feil i utsagnet over.

 

1. Det er ikke kall til exp(), men et kall til pow().

2. Det er ikke single presisjon slik han indikerer "VmlsExp4.W", s her betyr float = 32 bit. Det er double precision = 64 bit.

 

Så det er ikke VmlsExp4.W som kalles her men derimot vmldPow2.

Forskjellen er at VmlsExp4.W regner ut exp() til 4 float i parallell, mens vmldPow2 regner ut pow() til 2 double i parallell.

 

Invariant.

Endret 30. november 2005 av invariant

[Del]

Dette er veldig interessant, godt å endelig få belyst CPUID sjekken, dette har plaget meg i noe tid. Når det gjelder Snorre og invariant regner jeg med at bias er rimelig jevnt fordelt. Takk til Snorre for å ha nøstet opp, og takk til invariant for konstruktiv angrepsvinkel med spesifikk kode, på denne måten kan man jo faktisk lære en god del.

 

Anders, jeg er enig i kommentarene dine rundt CPUID sjekken, men poenget her er at Vendor ikke burde være interessant, dersom CPU rapporterer at den støtter SSE/SSE2 burde det være nok.

 

Nå ser det ut for meg som om Mark har vært rimelig spesifikk, og identifisert en SSE2 rutine/bibliotek kall, exp(), som forsåvidt er veldig viktig bl.a. ved prosessering av seismikk. Jeg kan ikke se at du har denne i din snutt invariant. Dersom dette virkelig er tilfelle synes jeg det er meget graverende for Intel, for dette har de i såfall gjort meget bevisst. Dette er noe jeg forsåvidt kan sjekke helt på egen hånd, men om noen kan bekrefte Marks påstander er jeg lutter øre.

 

Er det slik å forstå at du testet dette på et AMD system som du har tilgjengelig? En ting til, invariant, jeg tror vi ser poenget uten å se alle kallene...

 

Tips: wikipedia har en god definisjon av begrepet invariant.

[invariant]

Nå ser det ut for meg som om Mark har vært rimelig spesifikk, og identifisert en SSE2 rutine/bibliotek kall, exp(), som forsåvidt er veldig viktig bl.a. ved prosessering av seismikk. Jeg kan ikke se at du har denne i din snutt invariant.

5230671[/snapback]

 

Grunnen til at jeg ikke har med exp() er at a**b ikke er exp() men derimot pow(). Så her har Mark feilet.

 

La oss anta at jeg isteden hadde skrevet a=exp(b). Da ville vi fått et kall til _vmldExp2. Et slikt kall vil også innebære kun SSE2 double precision (64 bit) calculations. Tror ikke jeg legger ved .asm koden for den også (veldig mange linjer).

 

Nei jeg er uenig i konklusjonen din Del. Med min metode blir det ikke lagt ut noen snubletråder for AMD.

 

 

Invariant.

[Del]

Jeg stusset litt på det, men en blings på et funksjonskall betyr ikke all verden, det er uansett fullt mulig å sjekke om det virkelig er lagt inn snubletråd på exp().

 

Vet ikke helt hvilken konklusjon jeg hadde som du er uenig i?

 

Bare for å være på den sikre siden, spør jeg en gang til: var det et AMD system du brukte?

[invariant]

Jeg stusset litt på det, men en blings på et funksjonskall betyr ikke all verden, det er uansett fullt mulig å sjekke om det virkelig er lagt inn snubletråd på exp().

 

Vet ikke helt hvilken konklusjon jeg hadde som du er uenig i?

 

Bare for å være på den sikre siden, spør jeg en gang til: var det et AMD system du brukte?

5230926[/snapback]

 

Hei Del.

 

Det er ikke noen snubletråd i exp(), _vmldExp2 heller. Sjekket det akkurat.

 

Jeg forstår at du prøver å være nøytral, men siden jeg er tester ting selv, og ikke bare tar obskure linker på nettet for god fisk, burde du ikke tillegge "synserne" like stor vekt synes jeg. På vektskålen bør en faktisk test veie mye tyngre enn noe man har lest, jeg er uenig i at du tilegger "synserne" så stor vekt i utsagnet " bias er rimelig jevnt fordelt". Klart jeg har bias, men ikke på dette punktet.

 

Ja. Koden er kompilert på Intel og kjører så det hviner på AMD.

 

Invariant.

Endret 30. november 2005 av invariant

[invariant]

So, this is a partial fix, but Intel's CPUID check will still hurt performance on AMD chips.

Mark.

 

Hello Mark,

 

I cannot see that this is true. Files compiled with -xN when linked with main program compiled with -xW, have full SSE2 versions of the SVML functions.

 

Best Regards,

 

Invariant

Endret 30. november 2005 av invariant

[Del]

Ser fram til å høre Mark sitt svar. På dette tidspunktet tror jeg det kan være fornuftig a oppsummere litt.

 

Invariant, du la subrutinen utenfor hovedprogrammet, er dette nødvendig for å få SSE2 støtte? Hadde vært fint om du kunne forklart hvorfor hvilke begrensinger hvis noen, som ligger i å ha koden i hovedprogrammet. Virker som om du allerede vet svaret, og det vil spare meg for masse testing.

 

Dernest, er det slik at uten både -xW på hovedprogram og -xN på subrutine, så kan man ikke regne med å få full SSE2 støtte på AMD prosessorer, gjelder tilsvarende for SSE?

 

Er knepet ditt godt forklart i dokumentasjonen til IFC/ICC (igjen virker det som om du allerede vet svaret, så det vil spare meg en god del tid)?

[invariant]

Invariant, du la subrutinen utenfor hovedprogrammet, er dette nødvendig for å få SSE2 støtte? Hadde vært fint om du kunne forklart hvorfor hvilke begrensinger hvis noen, som ligger i å ha koden i hovedprogrammet. Virker som om du allerede vet svaret, og det vil spare meg for masse testing.

 

JA. Ikke bare utenfor hovedprogrammet, men i en egen fil er nødvendig. Det går ikke an å ha forskjellige kompilator-opsjoner for rutiner i samme fil.

 

Dernest, er det slik at uten både -xW på hovedprogram og -xN på subrutine, så kan man ikke regne med å få full SSE2 støtte på AMD prosessorer, gjelder tilsvarende for SSE?

 

Vil generelt ikke anbefale float (SSE) dersom man holder på med FP, for stor avrundingsfeil.

 

Er knepet ditt godt forklart i dokumentasjonen til IFC/ICC (igjen virker det som om du allerede vet svaret, så det vil spare meg en god del tid)?

 

JA. Fra dokumentasjonen (http://cache-www.intel.com/cd/00/00/21/92/...ptimization.pdf):

 

In the Intel Compilers version 8.x and above, the

/Qx{N, B, P} (-x{N, B, P} on Linux) options generate

an error message if the application is run on an

incompatible processor:

 

“Fatal Error: This program was not built to

run on the processor in your system.”

 

For this check to be effective, ensure that the main

program or the main module of a dynamic library is

compiled with the options.

 

Sukk.

 

Hadde bare noen tatt seg tid til å lese Intel sine dokumentasjon isteden for å lese web-sider skrevet av Intel sine "fiender".

 

Flott invariant link du hadde. Helt enig med det som sto der.

 

Invariant.

[Del]

Takker, men du svarte bare på halvparten av spørsmålene?

[invariant]

Takker, men du svarte bare på halvparten av spørsmålene?

5232487[/snapback]

 

Hei Del,

 

Hvis du leser min utskrift fra dokumentasjonen så har Intel lagt inn en test i hovedprogrammet (main module) slik at en unngår å kjøre på prosessorer som ikke støtter instruksjonsettet i executablen. For AMD slår denne testen av og til litt uheldig ut, og en må passe på å bruke /QxW evt -xW her, antatt at en vet hva en gjør, dvs. pass på SSE2 og SSE3 som vanlig.

 

De fleste velger å hoppe rett fra x87 til SSE2. Grunnen er at SSE var et litt uferdig instruksjons-sett siden det ikke støttet double precision. Så når du spør om det samme gjelder for SSE, så vet jeg ikke svaret, har aldri brukt SSE. SSE faller litt mellom to stoler, enten bruker man x87 eller så bruker man SSE2, for mange applikasjoner er jo x87 tilstrekkelig, hvis ikke hopp rett til SSE2.

 

Hvis det er noen mer du lurer på, er du fri til å presisere gamle evt. komme med nye spørsmål.

 

Invariant.

Endret 30. november 2005 av invariant

[Del]

Igjen takk, så snart jeg får anledning, skal ta en runde og sjekke ut dette. Det blir dessverre ikke i kveld. Ingen flere spørsmål for øyeblikket...

[Del]

Fikk endelig litt tid til rådighet, dog altfor lite til å gjøre noe grundig. Brukte IFC versjon 9.0 på enkel float kode (ingen if-statment, endel løkker på SSE2 funksjoner, matriseoperasjoner med stadig større matriser). Problemene tok typisk drøyt ti sekunder, hadde dessverre ikke absoft eller pathscale for hånden, det får bli en annen gang.

 

Når det gjelder cache miss hadde PGO ingen signifikant effekt på min kode, selv ved matrisemultiplikasjon med store matriser, et problem som er høyst relevant, og burde være mulig å forutsi hva som bør ligge i cache, på denne biten var Opteron mye raskere. Men nå var koden meget enkel, slik jeg fikk ikke sjekket dårlig skrevet kode. Første gang jeg selv sjekker mer detaljert (ned på enkeltoperasjoner) hva Xeon er kjappest på, og hva Opteron er kjappest på (med ifc vel og merke), meget interessant, men også meget tidkrevende hvis en skal analysere hvorfor. På min kode (alt kompilert med SSE2, alle float med double precision) hadde patchen til Mark kun den effekten at jeg kunne velge kompilatoropsjoner helt fritt, uten noen work-around, ytelsen var lik den med -xW og alt i hovedprogrammet, så det virker som om de funksjonene jeg sjekket ut (exp, log, sin, pow) vektoriseres, selv om Xeon virker å yte veldig godt på noen av disse, så her får jeg ta en sjekk med alternativ kompilator ved leilighet. Nå skal det sies at benchmarkene til Mark var på versjon 8.1, så det kan virke som om Intel har gjort et grep her, vi får håpe Mark kommer på banen igjen, slik at vi kan få vite litt mer.

 

Så til det litt mer generelle. Når det gjelder din work-around, invariant, skal du legge rimelig mye godvilje til for å si at denne er godt beskrevet i dokumentasjonen, ut fra dokumentasjonen vil den intetanende konkludere med at AMD chippen ikke støtter SSE2. Litt tidligere i samme dokument som du linket opp står det dessuten en klar anbefaling om å bruke tilsvarende optimaliseringer på hovedprogrammet dersom en ønsker optimal ytelse. Hadde IFC/ICC vært ansett som Intel-only kompilator hadde dette i grunnen vært greit. Problemet er at kompilatoren har en enormt sterk markedsposisjon (les: monopollignende tilstand), og veldig få utviklere rundt omkring er klar over at det er noe favorisering av Intel. At GenuineIntel sjekken ikke er fjernet ennå finner jeg meget graverende, siden den i det minste er en snubletråd for utviklere som ønsker å sjekke ut kompilator-opsjoner. Kildekoden er skjult, så all den tid sjekken er der, er det umulig for oss dødelige å vite nøyaktig hva den gjør. Kan du garantere at det ikke er noen konsekvenser på ytelsesnivå på noen kode av sjekken? Isåfall vil jeg gjerne vite hva i all verden sjekken er der for.

 

Anders, interessant Bensley test, med noen litt merkelige resultater. Når du angir prosenttall burde det vel også føyes til at Bensley plattformen har dobbelt så mange kjerner, og at applikasjonene var rimelig parallelle.