x86 processzor pipeline hosszanak megmerese

Nos ugy gondoltam e hetvegi ugykodesem melto arra, hogy elso blogbejegyzesem targya legyen.

Ebben a threadben felmerult, hogy meg kene merni a core 2 processzor pipelinejanak hosszat. Erre a legkezenfekvobb modszer a jol megjosolt es a rosszul megjosolt fuggvenyhivasok kozti idokulonbseg kimerese. Mert hogy mit is jelent ez? Mint tudjuk a modernebb processzorokban van ugynevezet branch prediction, amikor is a processzor a feltetles es indirekt ugrasokrol megprobalja kitalalni, hogy hova erkeznek. Igy nem kell megvarnia amig pipelineban eltoltott sok orajel alatt kiertekelodik az ugroutasitas es kiderul, hogy hol folytatodik a program az ugras utan, hanem a joslat szerint folyamatosan tolti be a tippelt helyrol az epp kovetkezo utasitasokat a pipelineba. Ha jol tippelt a proci akkor az ugras nulla idokiesest jelent, ha azonban rosszul, akkor amikor a tevedes kiderul (az ugroutasitas teljesen kiertekelodik) el kell dobni a pipeline teljes tartalmat, es az ugras utan ujra kell feltolteni. Szoval ha rosszul tippelte az ugrast a proci, akkor egy pipeline hossznyi idokiesest jelent az ugras.

Na itten van a program, ami megmeri a pipeline hosszat. Linux alatt "gcc -O0 -o pipeline pipeline.c"-vel kell forditani. Az eredmeny nyilvan nem halal pontos, de remelhetoleg aranylag kozel van a valosaghoz. Ja es futtatasnal a cpu throttling-ot ki kell kapcsolni, mert amugy (meg nagyobb) marhasagot mer.

Nalam, (65nm Core 2 Quad) ezt adja (az idoadatok orajelben ertendoek):
max exec time 112
execution time for predicted branch 67.025346
execution time for mispredicted branch 82.359082
estimated pipeline length 15.333736

Ha esetleg valaki kiprobalna, a kimenetet meg a procija tipusat legyen olyan jo ide postolni, mert erdekel!

( trey | 2009. 03. 22., v – 23:30 )

Intel(R) Pentium(R) Dual CPU T2310 @ 1.46GHz

./pipeline
max exec time 173
execution time for predicted branch 122.854277
execution time for mispredicted branch 150.641903
estimated pipeline length 27.787626

--
trey @ gépház

kosz! de ugy latom van egy kis gond, lehet at kellene irni a progiban a 150-et mondjuk 200-ra (gondoltam a 150 tuti eleg lesz). Ennek a procinak elvileg ugyanakkora a pipelineja mint az enyem, a program meg tok mast ir ... hajjaj

Amugy a cpu throttling ki volt kapcsolva (azaz max orajelen ment a proci), mert az is okozhat rossz merest?

szerk: szoval valoszinusegi sorrendben a problema :
1.) nem max orajelen ment a proci
2.) kicsi a 150 es 200 kell a kodban (a 7. sorban)
3.) buta a programom, es neznie kene, hogy milyen sebesseggel megy a timestamp counter

- Use the Source Luke ! -

( biboka v | 2009. 03. 22., v – 23:44 )

AMD Opteron 1210 (HP Proliant ML115-ben):

./pipeline
max exec time 53
execution time for predicted branch 10.000602
execution time for mispredicted branch 23.458871
estimated pipeline length 13.458269

( efbijn | 2009. 03. 22., v – 23:47 )

AMD Athlon64 X2 4400+

./pipeline
max exec time 53
execution time for predicted branch 10.003654
execution time for mispredicted branch 23.333863
estimated pipeline length 13.330209

@@
"You can hide a semi truck in 300 lines of C."
Debian Squezee 2.6.26-1-amd64

( pinyo_villany | 2009. 03. 22., v – 23:49 )

q9300 


[oliver@oliverp ~/foo]$ for((i=0;i<10;i++)) do time ./a.out; done
max exec time 76
execution time for predicted branch 36.013698
execution time for mispredicted branch 46.001428
estimated pipeline length 9.987730

real    0m0.310s
user    0m0.310s
sys     0m0.000s
max exec time 75
execution time for predicted branch 36.021294
execution time for mispredicted branch 46.009074
estimated pipeline length 9.987780

real    0m0.310s
user    0m0.310s
sys     0m0.000s
max exec time 76
execution time for predicted branch 35.991202
execution time for mispredicted branch 45.998030
estimated pipeline length 10.006828

real    0m0.312s
user    0m0.312s
sys     0m0.000s
max exec time 75
execution time for predicted branch 35.958896
execution time for mispredicted branch 46.008064
estimated pipeline length 10.049167

real    0m0.325s
user    0m0.325s
sys     0m0.000s
max exec time 76
execution time for predicted branch 35.971118
execution time for mispredicted branch 46.004198
estimated pipeline length 10.033080

real    0m0.325s
user    0m0.325s
sys     0m0.002s
max exec time 75
execution time for predicted branch 35.973306
execution time for mispredicted branch 46.002272
estimated pipeline length 10.028966

real    0m0.317s
user    0m0.317s
sys     0m0.000s
max exec time 76
execution time for predicted branch 36.025616
execution time for mispredicted branch 45.994708
estimated pipeline length 9.969092

real    0m0.310s
user    0m0.309s
sys     0m0.000s
max exec time 75
execution time for predicted branch 36.019232
execution time for mispredicted branch 45.962988
estimated pipeline length 9.943756

real    0m0.310s
user    0m0.309s
sys     0m0.000s
max exec time 75
execution time for predicted branch 35.952307
execution time for mispredicted branch 46.008590
estimated pipeline length 10.056283

real    0m0.322s
user    0m0.321s
sys     0m0.000s
max exec time 76
execution time for predicted branch 35.958072
execution time for mispredicted branch 46.008700
estimated pipeline length 10.050628

real    0m0.325s
user    0m0.325s
sys     0m0.000s

___
info

Intel Celeron (Mendocino) 367.528 MHz:
max exec time 75
execution time for predicted branch 35.001226
execution time for mispredicted branch 45.166812
estimated pipeline length 10.165586

Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz:
max exec time 112
execution time for predicted branch 67.003564
execution time for mispredicted branch 82.201384
estimated pipeline length 15.197820

( NagyZ v | 2009. 03. 22., v – 23:54 )

model name : Intel(R) Xeon(R) CPU X3220 @ 2.40GHz

[nagyz@x10 ~]$ ./pipeline
max exec time 117
execution time for predicted branch 67.000512
execution time for mispredicted branch 82.482231
estimated pipeline length 15.481719
[nagyz@x10 ~]$

( hadace | 2009. 03. 22., v – 23:56 )

Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz

max exec time 73
execution time for predicted branch 33.461527
execution time for mispredicted branch 42.942511
estimated pipeline length 9.480983

( jantyik | 2009. 03. 22., v – 23:58 )

Intel Celeron M520 (merom)

max exec time 112
execution time for predicted branch 67.010848
execution time for mispredicted branch 82.012832
estimated pipeline length 15.001984

( mstr | 2009. 03. 23., h – 00:17 )

./pipeline
max exec time 46
execution time for predicted branch 16.001758
execution time for mispredicted branch 16.001608
estimated pipeline length -0.000150

:( azenprocim olyanmint a moricka aki megfordult hogy sulibamenjen, mert kettotcsuszotthatra? :)
btw eztcsak a poen kedveer' kuldombe, amugy ez egy K6-2

( BaT | 2009. 03. 23., h – 00:17 )

AMD Athlon(tm) XP 1800+

./pipeline
max exec time 58
execution time for predicted branch 15.002592
execution time for mispredicted branch 28.375105
estimated pipeline length 13.372514

( bervi | 2009. 03. 23., h – 00:30 )

hmm, kár, hogy vs (nekem) nem eszi meg,

#define FUNC(num) \
void test_func ## num(){\
__asm volatile("rdtsc \n\t"\
: "=a" (b));\
__asm volatile("cpuid \n\t");\
}\
void (*func ## num)()=test_func ## num ;

ekörül fáj neki valami

akit érdekel, mingw build: pipeline.exe
esetleg érdekes lehet ugyanazon gépen megnézni winen és linuxon/egyében is

AMD Athlon64 5600+ Windsor @ WS2003 x86:

max exec time 53
execution time for predicted branch 10.000534
execution time for mispredicted branch 23.167313
estimated pipeline length 13.166779

( Huncraft v | 2009. 03. 23., h – 00:44 )

huncraft@klotild:/mnt/data$ cat /proc/cpuinfo |grep "model name"
model name : AMD Athlon(tm) 64 Processor 3200+
huncraft@klotild:/mnt/data$ ./pipeline
max exec time 53
execution time for predicted branch 10.001034
execution time for mispredicted branch 23.333479
estimated pipeline length 13.332445

Debian Lenny

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( sartek | 2009. 03. 23., h – 01:22 )

model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz @haver

max exec time 76
execution time for predicted branch 36.003276
execution time for mispredicted branch 45.993706
estimated pipeline length 9.990430

AMD Sempron(tm) 2500+ Socket-A

$ ./pipelinesunc
max exec time 59
execution time for predicted branch 15.001748
execution time for mispredicted branch 29.167044
estimated pipeline length 14.165296
$ ./pipelinegcc433
max exec time 58
execution time for predicted branch 15.002640
execution time for mispredicted branch 28.292008
estimated pipeline length 13.289368
$ ./pipelinegcc343
max exec time 58
execution time for predicted branch 15.002690
execution time for mispredicted branch 29.000554
estimated pipeline length 13.997864
$

--
HUP@Steam

( Zaivaldi | 2009. 03. 23., h – 06:41 )

model name : Intel(R) Pentium(R) M processor 1.70GHz

max exec time 88
execution time for predicted branch 45.503000
execution time for mispredicted branch 58.334010
estimated pipeline length 12.831010

model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz

max exec time 112
execution time for predicted branch 67.008744
execution time for mispredicted branch 82.166836
estimated pipeline length 15.158092

model name : AMD Athlon(tm) XP 2000+

max exec time 58
execution time for predicted branch 15.002480
execution time for mispredicted branch 28.666771
estimated pipeline length 13.664291

model name : Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz

max exec time 112
execution time for predicted branch 67.006142
execution time for mispredicted branch 82.170958
estimated pipeline length 15.164816

( f0xhu v | 2009. 03. 23., h – 08:13 )

AMD Phenom X4 9550 @ 2.20GHz
+ Vista Ultimate SP1 x64 


pipeline.exe
max exec time 168
execution time for predicted branch 120.019166
execution time for mispredicted branch 120.364158
estimated pipeline length 0.344992

Többször futtatva olyan 17-18 környékére jön ki. :)

+ Kubuntu 8.10 x86_64 


./pipeline
max exec time 139
execution time for predicted branch 69.698751
execution time for mispredicted branch 78.706566
estimated pipeline length 9.007815

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( Mico v | 2009. 03. 23., h – 08:06 )

[mico@mikloss-macbook ~/Documents]% ./pipeline
zsh: segmentation fault ./pipeline

gcc version 4.0.1 (Apple Inc. build 5465)

( Oscon | 2009. 03. 23., h – 08:39 )

oscon@osconsfortress:~$ pipeline ;cat /proc/cpuinfo | grep name
max exec time 55
execution time for predicted branch 10.000394
execution time for mispredicted branch 25.333558
estimated pipeline length 15.333164
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
oscon@osconsfortress:~$

----------------------------

r=1 vagyok, de ugatok...

( zdesigner | 2009. 03. 23., h – 11:13 )

max exec time 58
execution time for predicted branch 15.007346
execution time for mispredicted branch 28.667799
estimated pipeline length 13.660453

AMD Athlon(tm) XP 2600+

( sj | 2009. 03. 23., h – 11:26 )

Ez valid?

$./pipeline
max exec time 130
execution time for predicted branch 100.000096
execution time for mispredicted branch 100.002918
estimated pipeline length 0.002822
$./pipeline
max exec time 129
execution time for predicted branch 99.999260
execution time for mispredicted branch 100.009250
estimated pipeline length 0.009990
$./pipeline
max exec time 130
execution time for predicted branch 100.000134
execution time for mispredicted branch 99.999656
estimated pipeline length -0.000478
$uname -a
Linux thorium 2.6.27.10-grsec #1 Mon Dec 29 09:36:53 CET 2008 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux

SPAMtelenul - POP3 spamszuro szolgaltatas

sajnos nem valid, az a problema, hogy a "predicted branch" is mispredicted, mert butabb a branch prediction mint core 2-n. erre nem gondoltam, pedig a pentium 4 lett volna a legerdekesebb, mert annak kb. 40-50 hosszu a pipelineja.
Lehetseges, hogy a tobbi esetben is amikor 0-t mer (amd k6-2) ez a problema. Na holnapra esetleg megprobalok egy uj verziot krealni, ami pentium 4-re jot mer.

- Use the Source Luke ! -

Latom nagyon kened vagod a temat.

Nos igen, tevedtem, a pentium 4-en az rdtsc szerializalo utasitas, es valahogy a ket rdtsc elfedi a misprediction penaltyt, tehat a 100 orajel pusztan a ket rdtsc futasi ideje. Ha az elso rdtsc utan berak az ember pl. 128 "nop"-ot akkor mar van kulonbseg, mondjuk akkor meg 100 feletti pipeline hosszok jottek ki nekem (igaz windowson), ami szinten nem tunik jonak.

- Use the Source Luke ! -

( szalonna | 2009. 03. 23., h – 11:34 )

Intel(R) Core(TM)2 Duo CPU T5850 @ 2.16GHz

max exec time 112
execution time for predicted branch 67.008076
execution time for mispredicted branch 82.159255
estimated pipeline length 15.151179

---
hack the planet

( MetaMorfoziS | 2009. 03. 23., h – 15:33 )

Alap(nem tudom melyik):
max exec time 79
execution time for predicted branch 34.149264
execution time for mispredicted branch 49.739006
estimated pipeline length 15.589742

n=0:
max exec time 79
execution time for predicted branch 34.887940
execution time for mispredicted branch 49.683367
estimated pipeline length 14.795427

n=1:
max exec time 80
execution time for predicted branch 35.977968
execution time for mispredicted branch 50.362325
estimated pipeline length 14.384357

n=2:
max exec time 80
execution time for predicted branch 35.117148
execution time for mispredicted branch 50.259255
estimated pipeline length 15.142107

Intel(R) Atom(TM) CPU N270 @ 1.60GHz (eee 1000h)

(Ahol n a /proc/acpi/asus/cpufv-be echozott ertek, sorban ilyesmit jelent: performance,normal,powersave)

A tesztek alatt
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
és
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
"performance" volt.
________________________________________
2B or not 2B, that is FF. *̡͌l̡*̡̡ ̴̡ı̴̴̡ ̡̡͡|̲̲̲͡͡͡ ̲▫̲͡ ̲̲̲͡͡π̲̲͡͡ ̲̲͡▫̲̲͡͡ ̲|̡̡̡ ̡ ̴̡ı̴̡̡ *̡͌l̡*

( tr3w v | 2009. 03. 23., h – 19:27 )

Szerintem ezzel nem a pipeline hosszát méred.

Átírtam Visual Studio baráttá:
http://pastebin.com/f28a2bcf6

Tettem ezt 2 okból:
a) Összehasonlítani a MinGW-s eredménnyel:
AMD64 3000+

Gcc (MinGW):
max exec time 52
execution time for predicted branch 9.000570
execution time for mispredicted branch 22.166826
estimated pipeline length 13.166256

MSVC:
max exec time 95
execution time for predicted branch 54.001020
execution time for mispredicted branch 65.333773
estimated pipeline length 11.332753

Látszik, hogy nem egyezik.

b) Le akartam futtatni az AMD CodeAnalyst-jával, amiből nekem csak a win-es van telepítve, az meg nem szereti a gcc-s futtathatókat.
(Ha kedved van, kipróbálhatod te is, Intelnek VTune néven fut a hasonló szoftvere. Azt hiszem az is ingyenes.)
Itt indítottam egy pipeline simulation-t.

Itt gyönyörűen látszik hogy "br misprdct" után 5 teljes órajelen át nem történik semmi, pedig az előző utasítás már kitűnt a pipeline-ból.
Gondolom cache elérés történik, meg takarítás.
Ha viszont nincs mispredict, akkor func kódjának decode része már jóval a cpuid előtt elindul. Tehát hiába bástyáztad körül cpuid-vel a mérést, a decode részt eleve nem tudod megmérni.

Ez a mérés maximum azt méri, hogy átlagosan hány órajelet fizetsz egy mispredictért.

Mondjuk eleve nem értem, hogy lehetne a pipeline hosszát megmérni.
Főleg, mivel pl egy integer művelet egész más utat jár be, mint egy lebegőpontos.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Ez a mérés maximum azt méri, hogy átlagosan hány órajelet fizetsz egy mispredictért.

Igen, pontosan ezt szerettem volna megmerni. Ugyanis ez erosen korrelal (azt nem mondom, hogy egyenlo) a pipeline hosszaval. Mert ugye mispredictelt branch utan meg kell varni amig a kovetkezo utasitas vegig utazik az eppen kiuritett pipelineon, tehat amennyit utazik az utasitas a pipelineban, annyi az idokieses. Egy pillanatig nem allitottam, hogy ez 100%-os pontossagu dolog - mert az amd es intel mernokok is nyilvan trukkok szazait vetettek be - de legalabb meg egy paraszt van az intel-nel aki hasonloan gondolja mint en mert ilyeneket irnak az ia32 optimization manualban, hogy "The length of the pipeline in intel microarchitecture (Nehalem) is two cycles longer than its predecessor in 45nm Intel Core 2 processor family, as measured by branch misprediction delay." (mas kerdes, hogy a programomnak ezt pont nem sikerult kimernie valamiert, na de mindegy).

Most te kedves tr3w mester akkor elmagyarazhatnad, hogy miert sulyos tevedes ilyen korrelacio megleteben hinni, es, hogy miert nem lehet egyaltalan (par orajel elteres pontossaggal) kovetkeztetni a pipeline hosszara a misprediction penaltybol.

Mondjuk eleve nem értem, hogy lehetne a pipeline hosszát megmérni.
Főleg, mivel pl egy integer művelet egész más utat jár be, mint egy lebegőpontos.

Nyilvan az ugras utani utasitas(ok) altal bejart utat merjuk, es nem az Altalanos Pipeline Hosszt, igy van, koszonjuk az eszrevetelt.

Ha viszont nincs mispredict, akkor func kódjának decode része már jóval a cpuid előtt elindul. Tehát hiába bástyáztad körül cpuid-vel a mérést, a decode részt eleve nem tudod megmérni.[i]

melyik cpuid, nem ertem? de mondom, a cpu eleg trukkos szerkezet, ezert a meresben (mint mar utaltam ra) van hiba.

[i] /Gcc vs msvc/... Látszik, hogy nem egyezik.

Igen, az - velhetoen total mas - assembly output ismereteben esetleg az okokat is megkiserelhetnenk megvilagitani, igy viszont guzsba vannak kotve karjaink (de el ne kuldd az msvc kimenetet, mert annyira nem erdekel). Az erdekes, hogy mas pipeline hosszt is mer, de tok mas a kod, es akar a memoriaban az utasitasok alignmentjenek a megvaltozasa is okozhat elterest vagy barmi mas - mint mondtam a meres nem tokeletes, de becslesnek szerintem jo.

- Use the Source Luke ! -

Marhára nem értem a személyes sértődöttséged okát, de ha neked így jobb, legyen.

"miert sulyos tevedes ilyen korrelacio megleteben hinni, es, hogy miert nem lehet egyaltalan (par orajel elteres pontossaggal) kovetkeztetni a pipeline hosszara a misprediction penaltybol."

Ezért: "Nyilvan az ugras utani utasitas(ok) altal bejart utat merjuk"
Plusz még mérünk némi cache elérést, stb. (A korreláció kérdését lásd később)

"melyik cpuid, nem ertem?"

Na most te írtad a kódot, vagy én írtam a kódot?
Kb ez történik: 


   cpuid
   rdtsc
   mov EAX,[akarmi]
   mov EDX,[akarmi+4] ;; Ez eddig ay rdtsc eredményének mentése
   call [akarmi2]  ;; Ez meg a funcX hívás

A cpuid azért kell mert az egy serialization utasítás, azaz ami előtte elindult, az kitakarodik a pipelineból.
Én csak azt bátorkodtam észrevételezni, hogy a "call" decode-ja már elindult a cpuid előtt, tehát a decode részt eleve nem mérjük.

Még egyszer leírom mit gondolok a témáról, és ha ezen te megsértődsz, hát istenem...

A kódod a misprediction penality-t méri. Te a pipeline hosszát akartad mérni, de azt így nem lehet (szerintem egyébként sehogy).

Mi a gond a hosszú pipeline-nal? Hogy drágább a pipeline kiürítése.
Ami legtöbbször misprediction miatt kell.
Ezért érdemes mérni a mispred.-et, és ezért örül az intel mérnök, hogy csak 2 órajellel fizet többet.

Összefoglalva:
A kódod semmit nem mond a pipeline konkrét hosszáról, viszont jó összehasonlítási alapot nyújthatna a különböző procik pipeline hosszának arányairól.
Tehát az esetleg kijöhetne, hogy a P4-gyel tényleg 2x annyit fizetünk a mispred.-ért.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Én csak azt bátorkodtam észrevételezni, hogy a "call" decode-ja már elindult a cpuid előtt, tehát a decode részt eleve nem mérjük.

de nem is azt akarjuk merni, hanem egy sokkal kesobbi dolgot, amikor a call utan tortenik egy pipeline urites (ha mispredicted a branch), es utana ujra fel kell tolteni a pipeline-t - ennek a feltoltesnek az idejet merjuk ki. A cpuid-k azert kellenek, hogy a ket rdtsc kozott az ugrason kivul mas mar azert ne nagyon tortenjen (out-of-order), mert az nem is volna tul determinisztikus.

Plusz még mérünk némi cache elérést, stb.

hat csak ez elvileg egy igen rovid ido, vagy gondolod pusztan az utasitas kiolvasasa a memoriabol (L1 cachebol idealis esetben) mindig 5-10 orajel? De ha igy is van (kizart), akkor ez a pipeline resze, hogy mindig olvasunk a cachebol 5-10 orajelen at. Hogy mit rajzolt ki az AMD toolja az elso futasra, kulonosebben nem hat meg.

A kódod semmit nem mond a pipeline konkrét hosszáról

dehogynem. vagy gondolod a pipeline 15 orajel hosszu de a misprediction penalty 1 orajel? Esetleg forditva? Ha ez igy lenne a pipeline hosszok aranyarol sem mondana semmit a program (ami mellett te magad is olyan szepen hitet tettel az elobb).

- Use the Source Luke ! -

"de nem is azt akarjuk merni, hanem egy sokkal kesobbi dolgot, amikor a call utan tortenik egy pipeline urites (ha mispredicted a branch), es utana ujra fel kell tolteni a pipeline-t - ennek a feltoltesnek az idejet merjuk ki."

Te valójában a mispredict és a normál futás közti különbséget szeretnéd mérni, de _normál futásnál_ a decode elindul hamarabb. Tehát emiatt sem lesz a mérés pontos.

"hat csak ez elvileg egy igen rovid ido, vagy gondolod pusztan az utasitas kiolvasasa a memoriabol (L1 cachebol idealis esetben) mindig 5-10 orajel?"
Konkrétan az L1 cache latency Prescott mag esetében 3 órajel (amd adatot nem találtam hirtelen).
A szimuláció konzekvensen 5-ös várakozást mutat (10-et sose írtam), lehet, hogy történik még más is, erre vonatkozott az "stb".
Arról nem is beszélve, hogy a konkrét futtatásnál cache miss is szóbajön (L2, vagy normál memória elérés), egyrészt a cache asszociativitása miatt, másrészt meg az OS mérés közben közbeszólhat egy taskváltással.

"De ha igy is van (kizart), akkor ez a pipeline resze, hogy mindig olvasunk a cachebol 5-10 orajelen at."
Nem, ez nem a pipeline része. A pipeline egy elég jól definiált dolog...

"Hogy mit rajzolt ki az AMD toolja az elso futasra, kulonosebben nem hat meg."
Egyrészt nem első futtatásra, másrész tetszik vagy sem, a pipeline szimuláció a legjobb módja annak, hogy nyomonkövesd mi történik a prociban. Ehhez képest "különösebben nem hat meg", hogy egy eléggé mű benchmark, ami forítótól és OS-től függően más eredményt ad, mit mond.

"vagy gondolod a pipeline 15 orajel hosszu de a misprediction penalty 1 orajel?"
Egészen biztos vagyok benne, hogy a pipeline 20-25 órajel hosszú (vagy több), eközben a misprediction penalty 10-15 órajel (átlagosan).

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Te valójában a mispredict és a normál futás közti különbséget szeretnéd mérni, de _normál futásnál_ a decode elindul hamarabb. Tehát emiatt sem lesz a mérés pontos.

a test_func-ban levo parancsok elindulnak a cpuid elott (nem a call, az nem erdekel) normal futasnal? Ha igen az pech, ez bizony valoban kis pontatlansag.

másrészt meg az OS mérés közben közbeszólhat egy taskváltással.

rigorozus elemzesed soran ugy latom nem tunt fel, hogy a task valtast szurjuk a meresbol. Cache miss lehet, csak szerintem marhara nem valoszinu, mert itt egy igen primitiv feladat ele van allitva a cache alrendszer (utasitas cache kell, meg van meg 10 valtozo).

"De ha igy is van (kizart), akkor ez a pipeline resze, hogy mindig olvasunk a cachebol 5-10 orajelen at."
Nem, ez nem a pipeline része. A pipeline egy elég jól definiált dolog...

marpedig a pipeline idobeli hosszaba bele szamit, hogy valamelyik stageben mindig var az L1 cache-re x orajelet, szoval ez nem baj ha resze a meresnek - igy ertettem.

Egészen biztos vagyok benne, hogy a pipeline 20-25 órajel hosszú (vagy több), eközben a misprediction penalty 10-15 órajel (átlagosan).

Oke, vegre kaptam egy ertheto magyarazatot mi a gondod a meressel. Mar csak azt szeretnem megtudni, hogy ez az adat honnan van? A sok eves tapasztalat mondatja veled, vagy ez valahol le is van irva? (amugy ertem, hogy atlagosan, de pl. az altalad fent emlitett prescotnal az intel szerint a minimalis misprediction penalty 20 orajel (de en ennek mindig tobbszoroseit mertem))

- Use the Source Luke ! -

"Oke, vegre kaptam egy ertheto magyarazatot mi a gondod a meressel."

Pedig ezt magyarázom már az első hozzászólásom óta. Ha nem vetted volna személyes támadásnak, tán előbb észreveszed.

"Mar csak azt szeretnem megtudni, hogy ez az adat honnan van? A sok eves tapasztalat mondatja veled, vagy ez valahol le is van irva?"

A pipeline hosszt különböző leírásokban találtam. Itt egyébként azt hiszem, hogy elkövettem egy hibát, az egyik leírás alapján (amit most nem találok persze) azt gondoltam, hogy a decode részt nem számolják hozzá. Tehát mindenhol írt x86-os pipeline hosszok: 12-14 + 8 a decode miatt. Így jött ki. Istenem, ezt benézetm.

A "misprediction penalty 10-15 órajel (átlagosan)." pedig a fenti hozzászólások alapján alakult ki bennem, azaz lényegében ezek a te méréseid.

De akkor nézzünk egy konkrét példát:
A Core 2 integer pipeline hossza 14 több leírás alapján. (A lebegőpontos 17). Itt mindenféle mérés volt 9-től 15-ig.
Ami azért is érdekes, mert abban is megegyeztünk, hogy itt a misprediction utáni első utasítás késését méred, ami ebben az esetben biztosan nem a leghosszabb integer utasítás (ami a szorzás lenne talán...).

Tehát mégegyszer a véleményem (ezúttal utoljára):
Ez a mérés a misprediction penality-t méri, ami nyilvánvalóan függ a pipeline hosszától, de a mérésből nem tudod meg a pipeline konkrét hosszát.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

de a mérésből nem tudod meg a pipeline konkrét hosszát

de kapsz ra egy jo becslest. amiket eddig irtal nem gyoztek meg ennek ellenkezojerol, mint mar leirtam. de plusz meg eszembe jutott, hogy amit irtal, hogy a cpuid elott elkezdenek dekodolodni az ugras utani utasitasok (nem ezt irtad, hanem a call-ra irtad, de tegyuk fel utana levo utasitasokra is igaz), nos akkor a predicted esetben kevesebbet fog merni, a mispredicted esetben meg tobbet, tehat nagyobb lesz a pipeline hossz becsles - te meg azt mondtad hosszabb a pipeline mint a becsles (bar ha jol ertem revidealtad ezt az allaspontodat). tovabba nyilvan benne van a pipeline hossz becslesben a decode fazis, leven, hogy mispredictelt esetben azt is ujra kell csinalni az ugras utani utasitasra, nem lehet kihagyni - kivetel ez alol a pentium 4 ugye, mert ott a trace cacheben mar a uop-ok vannak (de a pentium 4-en elve hulyeseget mer a program, masreszt meg igy is a pentium 4 -nek lenne a leghosszabb a mert pipeline, ha mukodne ra a program).

A Core 2 integer pipeline hossza 14 több leírás alapján. (A lebegőpontos 17). Itt mindenféle mérés volt 9-től 15-ig.
Ami azért is érdekes, mert abban is megegyeztünk, hogy itt a misprediction utáni első utasítás késését méred, ami ebben az esetben biztosan nem a leghosszabb integer utasítás (ami a szorzás lenne talán...).

Na orulok, hogy legalabb valamiben megegyeztunk. Gcc -O0 eseten az elso utasitas egy "push rbp", ami szerintem egy eleg osszetett utasitas, de nincs errol konkret adatom (hacsak az nem, hogy a latency-je nagy). Mindenesetre lehet, hogy ezt az utasitast beoptimalizaltak az ujabb core 2-n (45nm) , es innen a kulonbseg - de nem tudom, csak hangosan gondolkodom.

ugyhogy szerintem pipeline hossz becslesnek tokeletes a mispredict penalty, de persze nem teljesen pontos.

- Use the Source Luke ! -

Én továbbra is azt mondom, hogy a pipeline hosszának becslésére nem, de két proci pipeline hosszának arányára jó lehet ez a mérés.

Persze az szívás, hogy pont P4-re nem kaptunk eredményt...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( PcDocky | 2009. 04. 09., cs – 06:11 )

$ cat /proc/cpuinfo |grep 'model name' ;./pipeline
model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
max exec time 112
execution time for predicted branch 67.001024
execution time for mispredicted branch 82.333187
estimated pipeline length 15.332163