[hvuk]

Idézet: SFIJ - Dátum: 2006. jún. 20., kedd - 23:33

hogy rad jellemzo szofordulattal eljek: HAZUDSZ!

vs.

Idézet

persze ezis levan irva egy masik inteles paperben. kivetelesen ennek felkutatasat most a nyajas olvasora bizzuk

Szerkesztette: hvuk 2006. 06. 20. 22:40 -kor

[hvuk]

A továbbiakban befejeztem a veled való társalgást. Majd ha nem vádaskodsz állandóan, ha képes vagy elismerni, ha igaza van a másiknak, ha nem ferdítesz, ha nem használod a dupla-gondol technikát, ha nem másítod meg a mondandód percenként, ha alátámasztod az állításod, akkor majd megint beszélek veled. Addig ágyõ.

És elnézést kérek a topicok többi olvasójától ezen rendkívûl alacsony szintû vitáért.

Szerkesztette: hvuk 2006. 06. 20. 22:42 -kor

[SFIJ]

Idézet: SFIJ - Dátum: 2006. jún. 20., kedd - 22:33

hogy rad jellemzo szofordulattal eljek: HAZUDSZ!

es mert is nem vagyok ezen meglepodve...
quod, erat demonstrandum... HAZUDSZ:

/porc/cpuinfo:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel® Pentium® M processor 1500MHz
stepping        : 5
cpu MHz         : 1495.242
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe tm2 est
bogomips        : 2965.50

#include <stdio.h>
int main(void)
{
   unsigned long i,j;
   unsigned long acc =0; 
   for (i = 0; i < 1000000000; i++)
       if ( i % 2 == 0)
  {
    j = i/2;
    acc += i;
  }
       else
  {
    j = i/2;
    acc += 0;
  }
   printf("%lu\n", acc);

}

real    0m7.513s
user    0m7.278s
sys     0m0.003s

#include <stdio.h>
int main(void)
{
   unsigned long i,j;
   unsigned long acc =0; 
   for (i = 0; i < 1000000000; i++)
     {
       j = i/2;
       acc += j;
     }
   printf("%lu\n", acc);
}

real    0m8.095s
user    0m7.797s
sys     0m0.003s

Szerkesztette: SFIJ 2006. 06. 20. 23:31 -kor

[SFIJ]

Idézet: hvuk - Dátum: 2006. jún. 20., kedd - 22:40

vs.

Idézet

persze ezis levan irva egy masik inteles paperben. kivetelesen ennek felkutatasat most a nyajas olvasora bizzuk

(1) teveszmeid voltak arrol, hogy a P6-ban mi a spekulativ vegrehajtas. ez a mondat arra vonatkozott. de mar ugyis mindegy, programfutasi ido alapjan K.O. kispajtas

[hvuk]

Idézet: SFIJ - Dátum: 2006. jún. 21., szerda - 0:29

real    0m7.513s
user    0m7.278s
sys  0m0.003s

...

real    0m8.095s
user    0m7.797s
sys  0m0.003s

Hoppá, egy érv! Nicsak!

Ezzel az a baj, hogy az elágazásos kód kevesebb idõ alatt futott le, mint az elágzás nélküli. Erõsen compiler optimalizációra gyanakszik ilyenkor az ember. Ezt meg lehet próbálni kiszûrni úgy, hogy nem 0-val növeled az acc-t. Még így sem garantált, hogy a fordító nem optimalizálja ki a dolgot, mert ugye a j=i/2 kielemhetõ helybõl (és ki is emeli az if elé). Az acc += 0-t meg egyszerûen figyelmen kívül hagyja. De még a  j=i/2-t is figyelmen kívül hagyhatja, hiszen j értékére sehol sem hivatkozol. De ez asszem a fordító beállításaitól függ. Ennél trükkösebb példa kell a probléma eldöntésére.

De szerintem egyszerûbb, ha beidézed az ide vonatkozó részt valami Intel doksiból.

Upd: persze mostantól is csak az érvekre válaszolok. Épp ezért hagytam ki a bevezetõ megjegyzésre a választ.

Szerkesztette: hvuk 2006. 06. 21. 00:04 -kor

[SFIJ]

Idézet: hvuk - Dátum: 2006. jún. 21., szerda - 0:03

Hoppá, egy érv! Nicsak!

Ezzel az a baj, hogy az elágazásos kód kevesebb idõ alatt futott le, mint az elágzás nélküli. Erõsen compiler optimalizációra gyanakszik ilyenkor az ember.

-O 0 az opcio, ez trivialis ha ezt a hatast akarunk kimerni. eredendo rosszindulat targya barmi mast feltetelezni.

ott haltal meg, hogy a branchinges kodnak kene lassabnak lenni, sokkalta lassabnak az "allitolagos pipeline trashing miatt", ami ugye egyertelmu, merthat nem hozatam 'szamodra kielegito forrast".

Szerkesztette: SFIJ 2006. 06. 21. 00:15 -kor

[hvuk]

Idézet: SFIJ - Dátum: 2006. jún. 21., szerda - 1:12

-O 0 az opcio, ez trivialis ha ezt a hatast akarunk kimerni. eredendo rosszindulat targya barmi mast feltetelezni.

ott haltal meg, hogy a branchinges kodnak kene lassabnak lenni, sokkalta lassabnak az "allitolagos pipeline trashing miatt", ami ugye egyertelmu, merthat nem hozatam 'szamodra kielegito forrast".

De mitõl lett gyorsabb az if-es kód, ha a fordító semmit sem optimalizált? Ha azonos idõ alatt futott volna le mindkét kód vagy kicsit lassabb lett volna az "if"-es, az érthetõ lenne, de mitõl futott le gyorsabban? Gyorsabb nem lehetett volna, ha semmiféle optimalizáció nem lenne, hiszen még ha a két ágat tök egyszerre hajtja végre és így semmit sem veszít idõben, ráadásul az elágazás is ingyen van, akkor is hasonló idõ alatt kellett volna lefutnia.

Szerintem ettõl még lehet, hogy igazad van, hiszen lehet, hogy pl. az acc += 0-t egyszerûen kihagyja (newm tudom, hogy pontosan miket kapcsol ki ez a kapcsoló), és lehet, hogy az if költsége ugyanannyi és ez a kettõ kb. kioltja egymást. Sajnos ez nekem nem elégséges bizonyíték.

Majd még utánanézek én is, megpróbálom megkeresni valami doksiban vagy cikkben ezt a fícsört. De egy kicsit nehézkesebb arról meggyõzõdni, hogy valami nincs, mint arról, hogy valami van.

Azt ugye tudod, hogy a fícsör megléte még nem igazolja azt, hogy hazudtam volna? Mert ugye az az általad beidézett forrásra vonatkozott, ami sajnos nem támaszotta alá ennek a képességnek a meglétét (csak az elágazás becslésrõl és arról van szó benne, hogy utána az egyik ágat - amelyiket azt elágazásbecslõ kidob - tovább dolgozza, de arról nincs szó benne, hogy mindkettõt tovább csinálná). Tehát azt kellene igazolnod ahhoz, hogy hazudtam, hogy a forrásodban bent van a bizonyíték, de én szándékosan letagadtam. De nincs benne, így persze nem is tagadhattam le.

[vers]

a forosban  valami büdös 12 orajelre jön ki egy ciklus idö, ami nevetséges
egy dissasmot nyomhattál volna ugy okosabbak lennénk

for (i = 0; i < 1000000000; i++)
    {
      j = i/2;
      acc += j;
    }


loop :
        shr j,i,1
        add acc,j,acc
        sub t,i,m
        bnez t,loop
        add i.i.1

na ez emotion enginen 3 orajel ciklusonként tehát a végrehajtási idö kb  10 sec
300 mhz-en ,ha használhatnám a simdet akkor ennek negyede max 3 sec
hát  mit modjak  az x86  trágya volt mindig  és lesz is

Szerkesztette: vers 2006. 06. 21. 01:30 -kor

[SFIJ]

Idézet: hvuk - Dátum: 2006. jún. 21., szerda - 0:35

De mitõl lett gyorsabb az if-es kód, ha a fordító semmit sem optimalizált? Ha azonos idõ alatt futott volna le mindkét kód vagy kicsit lassabb lett volna az "if"-es, az érthetõ lenne, de mitõl futott le gyorsabban? Gyorsabb nem lehetett volna, ha semmiféle optimalizáció nem lenne, hiszen még ha a két ágat tök egyszerre hajtja végre és így semmit sem veszít idõben, ráadásul az elágazás is ingyen van, akkor is hasonló idõ alatt kellett volna lefutnia.

Szerintem ettõl még lehet, hogy igazad van, hiszen lehet, hogy pl. az acc += 0-t egyszerûen kihagyja (newm tudom, hogy pontosan miket kapcsol ki ez a kapcsoló), és lehet, hogy az if költsége ugyanannyi és ez a kettõ kb. kioltja egymást. Sajnos ez nekem nem elégséges bizonyíték.

Majd még utánanézek én is, megpróbálom megkeresni valami doksiban vagy cikkben ezt a fícsört. De egy kicsit nehézkesebb arról meggyõzõdni, hogy valami nincs, mint arról, hogy valami van.

Azt ugye tudod, hogy a fícsör megléte még nem igazolja azt, hogy hazudtam volna? Mert ugye az az általad beidézett forrásra vonatkozott, ami sajnos nem támaszotta alá ennek a képességnek a meglétét (csak az elágazás becslésrõl és arról van szó benne, hogy utána az egyik ágat - amelyiket azt elágazásbecslõ kidob - tovább dolgozza, de arról nincs szó benne, hogy mindkettõt tovább csinálná). Tehát azt kellene igazolnod ahhoz, hogy hazudtam, hogy a forrásodban bent van a bizonyíték, de én szándékosan letagadtam. De nincs benne, így persze nem is tagadhattam le.

mondok egy triviáisat.
az if ágban a 2 mûvelt (j és acc számítása) között nincs adatfüggés, míg az if nélküliben meg van.

azonkívül az egész kód belefér a rorder-bufferbe. amit most írok az pusztán spekuláció, bizonyítani nem tudom, de el bírom képzelni, hogy az "else ág" branch hit-jére észreveszi a proci, hogy az voltaképp egy NOP (persze röptében veszi észre, így belekezd a kiértékelébe, de nem fejezi be)

Szerkesztette: SFIJ 2006. 06. 21. 03:13 -kor

[SFIJ]

Idézet: vers - Dátum: 2006. jún. 21., szerda - 0:48

a forosban  valami büdös 12 orajelre jön ki egy ciklus idö, ami nevetséges
egy dissasmot nyomhattál volna ugy okosabbak lennénk

for (i = 0; i < 1000000000; i++)
    {
      j = i/2;
      acc += j;
    }


loop :
        shr j,i,1
        add acc,j,acc
        sub t,i,m
        bnez t,loop
        add i.i.1

na ez emotion enginen 3 orajel ciklusonként tehát a végrehajtási idö kb  10 sec
300 mhz-en ,ha használhatnám a simdet akkor ennek negyede max 3 sec
hát  mit modjak  az x86  trágya volt mindig  és lesz is

version

1. az x86 2 címes gép, az EE meg 3 címes.
2. a mérés alatt futott az egész os, és az összes app, rengeteg ctxt switch.
3. a kód szándékosan el van baszva, úgyvan leírva hogy jó szar legyen a hatásfoka, + még no optimize. , ergo no register use, minden mûvelet membõl be, membõl ki (ez jelen esetben az L1/L2 cache-t jelenti, de részletkérdés).

nem volt cél hogy gyors és hatékony legyen a kód, hanem az volt a cél, hogy cáfolja hvuk állítását.

[SFIJ]

Idézet: hvuk - Dátum: 2006. jún. 21., szerda - 0:35

Azt ugye tudod, hogy a fícsör megléte még nem igazolja azt, hogy hazudtam volna? Mert ugye az az általad beidézett forrásra vonatkozott, ami sajnos nem támaszotta alá ennek a képességnek a meglétét (csak az elágazás becslésrõl és arról van szó benne, hogy utána az egyik ágat - amelyiket azt elágazásbecslõ kidob - tovább dolgozza, de arról nincs szó benne, hogy mindkettõt tovább csinálná). Tehát azt kellene igazolnod ahhoz, hogy hazudtam, hogy a forrásodban bent van a bizonyíték, de én szándékosan letagadtam. De nincs benne, így persze nem is tagadhattam le.

állításod az volt, hogy x86 ne dolgozhat fel egyidõben 2 feltételes ágat. ha ez igaz lenne, akkor az elsõ kód bármely ifes ágában lesrefutás esetére a számolási részeredménye eldobása miatt idõveszteség -> az ifes ciklusnak lassabbnak kéne lennie, mégsem az.

a "speculative execution" fogalmát a munkahipotézised megvédése érdekében önkényesen és szándékosan szûkítetted.

az üvöltõ tények, mérési eredmények egyértelmûen cáfolnak de te még mindig kapálódzol...

[vers]

Idézet: SFIJ - Dátum: 2006. jún. 21., szerda - 2:26

állításod az volt, hogy x86 ne dolgozhat fel egyidõben 2 feltételes ágat. ha ez igaz lenne, akkor az elsõ kód bármely ifes ágában lesrefutás esetére a számolási részeredménye eldobása miatt idõveszteség -> az ifes ciklusnak lassabbnak kéne lennie, mégsem az.

a "speculative execution" fogalmát a munkahipotézised megvédése érdekében önkényesen és szándékosan szûkítetted.

az üvöltõ tények, mérési eredmények egyértelmûen cáfolnak de te még mindig kapálódzol...

ez igy nem tény, a mérési eredmény sem biztos hogy bizonyiték ,
ezt meg lehet csinálni olyan procival is amelyik a branch predictiont  ugy elemzi hogy egymás után milyen a  2 ág találati aránya , és nem a legtöbbet futattott ágat preferálja
de ez még mindig nem magyarázat arra hogy a foros kod hogy lehet lassabb , ami nonszensz

bocs hogy vitatkozok, de több kell ennél az egyértelmü bizonyitáshoz

[hvuk]

Idézet: SFIJ - Dátum: 2006. jún. 21., szerda - 4:06

mondok egy triviáisat.
az if ágban a 2 mûvelt (j és acc számítása) között nincs adatfüggés, míg az if nélküliben meg van.

azonkívül az egész kód belefér a rorder-bufferbe. amit most írok az pusztán spekuláció, bizonyítani nem tudom, de el bírom képzelni, hogy az "else ág" branch hit-jére észreveszi a proci, hogy az voltaképp egy NOP (persze röptében veszi észre, így belekezd a kiértékelébe, de nem fejezi be)

Vazzeg, tényleg! Ez eddig fel sem tûnt. Az if-esnél 0-val vagy i-vel növeled acc-t, az if nélküliben meg j-vel. De így még kevésbé összehasonlítható a két eredmény, hiszen a két progi még csak nagyságrendileg sem ugyazat csinálja.

Majd gondolkodok én is valami jó kis kódon, ha lesz rá idõm.

[hvuk]

Idézet: SFIJ - Dátum: 2006. jún. 21., szerda - 4:26

állításod az volt, hogy x86 ne dolgozhat fel egyidõben 2 feltételes ágat. ha ez igaz lenne, akkor az elsõ kód bármely ifes ágában lesrefutás esetére a számolási részeredménye eldobása miatt idõveszteség -> az ifes ciklusnak lassabbnak kéne lennie, mégsem az.

...

az üvöltõ tények, mérési eredmények egyértelmûen cáfolnak de te még mindig kapálódzol...

Ez csak akkor igaz, ha a két program azonos programot futtat vagy kb. azonost. Mivel az if-es program egészen más kódot használ (pl. acc-t nem i-vel, hanem j-vel növeled), így logikusan mást is belemérsz, így ahogy vers is írja, ez nem minõsül mérésnek. Ez egyszerûen nem cáfol meg.

Idézet

a "speculative execution" fogalmát a munkahipotézised megvédése érdekében önkényesen és szándékosan szûkítetted.

Nem szûkítettem. Egyszerûen a speculative execution-on nem azt értik, hogy mindkét ágat feldolgozzák. Nem ezt jelenti. Ettõl még az Intel berakhatta a procijába (noha ebben egyre inkább kételkedek), de az biztos, hogy ebbõl a szövegbõl ez nem következik (de a szöveg nem is cáfolja ezt).

Idézet

Modern pipelined microprocessors use speculative execution to reduce the cost of conditional branch instructions. When a conditional branch instruction is encountered, the processor guesses which way the branch is most likely to go (this is called branch prediction), and immediately starts executing instructions from that point. If the guess later proves to be incorrect, all computation past the branch point is discarded.

Ez a Wikipediáról van. Ebbõl sem következik, hogy az Intel nem csinálhatta meg a bonyolultabb verziót, de furcsa, hogy meg sem említenek egy ilyen nagy eredményt (az általános megoldáshoz képest).

Más forrás.

Idézet

A less sophisticated processor will stall the pipeline until the results are known, hurting performance. More advanced processors will speculatively execute the next instruction anyway, with the hope that it will be able to use the results if the branch goes the way it thinks it will. Still more advanced processors combine this with branch prediction, where the processor can actually predict with fairly good accuracy which way the branch will go based on past history.

Ez a részlet az Ars Technica P4 vs. G4 cikkébõl van. Késõbb sem említik benne, hogy a P4-nek fejlettebb rendszere lenne, olyan ami mindkét ágat végrehajtja.

Idézet

In older processors, the entire processor would just sort of sit idle and wait for the branch condition to be evaluated, a wait that could be quite long if the evaluation involved a complex calculation of some sort. Modern processors use a technique called "speculative execution," which involves making an educated guess at the which direction the branch is going to take and then beginning execution at the new branch target before the branch's conditional is actually evaluated. This educated guess is made using one of a variety of "branch prediction" techniques, which we'll talk more about in a moment. Speculative execution is used to keep the delays associated with evaluating branches from introducing bubbles into the pipeline. (For a more detailed discussion of speculative execution, see my IA-64 preview.)

Ez a részlet pedig az aceshardware egyik cikkébõl való.

Idézet

Now with Merced's prediction, you can get rid of most branches. First let's see how RISC/x86 CPUs handle the typical IF-THEN-ELSE branch:
Take a look at this code example:

if (i==0)
  instruction 1;
else
  instruction 2;

Let us translate this to pseudo-CPU instructions:

1. Compare i to 0
2. Jump to label else if not equal
3. Then: instruction 1
4. Jump to label next
5. Else: instruction 2
6. Next

The CPU must choose whether it takes the ELSE branch or the THEN branch. Look how an EPIC CPU solves this:

1. Compare I to 0
2. Start decoding instruction 1, prediction bits set to address of prediction register P1
3. Start decoding instruction 2, prediction bits set to address of prediction register P2
4. When I = 0, set register P1 to true (1) and register P2 to false (0)
5. Calculate the result of all instructions with prediction bits pointing to the prediction register set to true (P1)

Egyszerûen a neten sehol sem találtam olyan forrást, ami az X86 processzoroknak ezt a tulajdonságát alátámasztaná. Kivétel nélkül mindenhol arról van szó, hogy eldönti a branch prediction, hogy melyik ágat kell végrehajtani, majd azt az egyet elõre végrehajtja (egyes források összevonják a kettõt vagy szinonimaként használják, ami nem teljesen pontos, de azért még elfogadható).

De ha tudsz hozni meggyõzõ forrást, amibõl egyértelmûen kiderül, hgoy az X86 mindkét ágat végrehajtja, akkor meggyõzhetõ vagyok. De szerintem erre nulla az esély.

Érdemes elgondolkodni azon, hgoy ha a CPU mindkét ágat végrehajtja és utána a helyes ágat tartja meg, akkor vajon mi a téves elágazásbecslés büntetése. A P4 épp azért szenvedett sok és nehezen becsülhetõ elágazást tartalmazó kódoknál, mert nagy volt a téves elágazásbecslés büntetése (következménye).

[bogdan]

Idézet: SFIJ - Dátum: 2006. jún. 20., kedd - 23:29

Idézet: SFIJ - Dátum: 2006. jún. 20., kedd - 22:33

hogy rad jellemzo szofordulattal eljek: HAZUDSZ!

es mert is nem vagyok ezen meglepodve...

[hvuk]

Idézet: bogdan - Dátum: 2006. jún. 21., szerda - 11:06

Tényleg, ez fel sem tûnt. LOL

[Balala]

Ezzel max. csak azt bizonyithatod, hogy a 01010101... ugraspatternt kozel 100%-ra tudjak becsulni a procik. Csereld ki valami random-szeru dologra, mindjart mas lesz a kep.
En win alatt neztem, meg a rand() is bekavar, es az asm listabol kiderul, hogy a ket verzio kozott csak
"test al, 1" ill. "test eax, ffffh" csak a kulonbseg, de igy is kb. 10%-kal lassabb az elso verzio egy X2-n...
Sajna a procik csak 1db instruction pointert kepesek nyomonkovetni, meg az Itanium is, ott is csak a predikatumokkal szorakoznak.

#include <stdlib.h>
#include <intrin.h>


int _tmain(int argc, _TCHAR* argv[])
{
	unsigned long i,j;
	unsigned long acc =0;
	srand(0);
	__int64 start = __rdtsc();
	for (i = 0; i < 1000000000; i++)
  if ( (rand() & 0x0001) == 0)
  {
 	 j = i/2;
 	 acc += i;
  }
  else
  {
 	 j = i/2;
 	 acc += 0;
  }
	__int64 end = __rdtsc();
	printf("%lu\n %I64d\n", acc, end - start);

 	 srand(0);
	acc = 0;
	start = __rdtsc();
	for (i = 0; i < 1000000000; i++)
  if ( (rand() & 0xffff) == 0)
  {
 	 j = i/2;
 	 acc += i;
  }
  else
  {
 	 j = i/2;
 	 acc += 0;
  }
	end = __rdtsc();
	printf("%lu\n %I64d\n", acc, end - start);
	return 0;
}

[SFIJ]

Idézet: vers - Dátum: 2006. jún. 21., szerda - 4:58

ez igy nem tény, a mérési eredmény sem biztos hogy bizonyiték ,
ezt meg lehet csinálni olyan procival is amelyik a branch predictiont  ugy elemzi hogy egymás után milyen a  2 ág találati aránya , és nem a legtöbbet futattott ágat preferálja
de ez még mindig nem magyarázat arra hogy a foros kod hogy lehet lassabb , ami nonszensz

bocs hogy vitatkozok, de több kell ennél az egyértelmü bizonyitáshoz

hehe de itt pont az a lenyeg, hogy nehezen predikalhato a brancs.
amugymeg:

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
   unsigned long i,j;
   unsigned long acc =0; 
   for (i = 0; i < 1000000000; i++)
       if ( lrand48() % 2 == 0)
       {
  j = i/2;
  acc += i;
       }
       else
       {
  j = i/2;
  acc += 0;
       }
   printf("%lu\n", acc);
}

az lrnad48()  veletlenszam generator, igy most veletlenszuren dol el hogy melyikag fut majd le.

real    0m8.233s
user    0m8.011s
sys     0m0.006s

a novekedett futasi ido az extra fuggvenyhivas (veletlenszam-generalas) eredmenye.

PS; a futasi idokbol ki lett vonva az lrand48() netto futasi ideje.

Szerkesztette: SFIJ 2006. 06. 21. 15:13 -kor

[SFIJ]

Idézet: hvuk - Dátum: 2006. jún. 21., szerda - 9:05

Ez csak akkor igaz, ha a két program azonos programot futtat vagy kb. azonost. Mivel az if-es program egészen más kódot használ (pl. acc-t nem i-vel, hanem j-vel növeled), így logikusan mást is belemérsz, így ahogy vers is írja, ez nem minõsül mérésnek. Ez egyszerûen nem cáfol meg.

nagyon gyenge kekeckedes persze hogy nem betu szerint azonos a kod, strukturalisan hasonlo, nemis volt cel hogy azonos legyen, de kapaszkoddsz egy fuszalba.

Idézet: hvuk - Dátum: 2006. jún. 21., szerda - 9:05

Nem szûkítettem. Egyszerûen a speculative execution-on nem azt értik, hogy mindkét ágat feldolgozzák. Nem ezt jelenti. Ettõl még az Intel berakhatta a procijába (noha ebben egyre inkább kételkedek), de az biztos, hogy ebbõl a szövegbõl ez nem következik (de a szöveg nem is cáfolja ezt).

ne hasznalj altalanos alanyt. "speculative execution" alatt TE erted ezt. a valosag meg mas. tovabbra is negligalod hogy szuperskalar a proceszzor, reorder bufferrel.

Idézet: hvuk - Dátum: 2006. jún. 21., szerda - 9:05

Egyszerûen a neten sehol sem találtam olyan forrást, ami az X86 processzoroknak ezt a tulajdonságát alátámasztaná. Kivétel nélkül mindenhol arról van szó, hogy eldönti a branch prediction, hogy melyik ágat kell végrehajtani, majd azt az egyet elõre végrehajtja (egyes források összevonják a kettõt vagy szinonimaként használják, ami nem teljesen pontos, de azért még elfogadható).

nem fogom a munkat helyetted elvegezni. szandekosan prekoncepciozusan szelektalsz es magyarazgacc.

Idézet: hvuk - Dátum: 2006. jún. 21., szerda - 9:05

Érdemes elgondolkodni azon, hgoy ha a CPU mindkét ágat végrehajtja és utána a helyes ágat tartja meg, akkor vajon mi a téves elágazásbecslés büntetése. A P4 épp azért szenvedett sok és nehezen becsülhetõ elágazást tartalmazó kódoknál, mert nagy volt a téves elágazásbecslés büntetése (következménye).

a p4-nek az a gondja, hogy mely a pipeline es emeltt VE szegeny, gaykorlatila 2-issue. a dothan steeper pipe es szelesebb gyakorlatilag 4-issue

szerk: hejesiras

Szerkesztette: SFIJ 2006. 06. 21. 14:48 -kor

[hvuk]

Idézet: SFIJ - Dátum: 2006. jún. 21., szerda - 15:41

nagyon gyenge kekeckedesm persze hogy nem betu szerint hazonos a kod, strukturalisan hasonlo, nemis volt cel hogy azonos legyen, de kapaszkoddsz egy fuszalba.

Nem értem miért változtattad meg a kódot az if-es részben. Miért nem volt jó az eredeti verzió? Egyszerûen indokolatlanul különbözik a két kód.

Idézet

ne hasznalj altalanos alanyt. "speculative execution" alatt TE erted ezt. a valosag meg mas. tovabbra is negligalod hogy szuperskalar a proceszzor, reorder bufferrel.

Használhatok általános alanyt, mert egyetlen egy forrást sem találtam, ahol nem ezt értenék rajta. Szuperskalár és reorder bufer mivoltát nem ignorálom, de abból nem következik, hogy mindkét ágat feldolgozza. Az egész iparág ezt érti alatta, kivétel téged. Nyugodtan hozhatsz olyan definíciót, ahol speculative load alatt azt értik, hogy mindkét ágat elõre feldolgozza. Egyelõre nálad a labda: én hoztam egy halom olyan forrást, ahol nem ezt értik alatta.

Idézet

nem fogom a munkat helyetted elvegezni. szandekosan prekoncepciozusan szelektal es magyarazgacc.

Ember, végignyálaztam a google-t, hogy megtaláljam az általad megálmodott fícsört. De ilyen egyszerûen nem létezik a jelenlegi X86 procikban. Sehol nincs róla említés, se az Intel guideline-okban, se a netes forrásokban, sehol sem. Nem elvárható, hogy hozzál egyetlen forrást legalább ami bizonyítja azt amit állítasz? Hozzál egyetlen olyan forrást, ahol teljesen egyértelmûen és tisztán ki van jelentve, hogy mindkét ágat feldolgozzák a P6-tól kezdõdõen!

Idézet

a p4-nek az a gondja, hogy mely a pipeline es emeltt VE szegeny, gaykorlatila 2-issue. a dothan steeper pipe es szelesebb gyakorlatilag 4-issue

De nem csak a P4-nél van büntetése a téves elágazásbecslésnek. Ez minden mai pipeline rendszerû és branch predictiont és speculative executiont használó procinak a sajátja.

Ha mindkét ágat továbbszámolná, akkor nem lenne büntetése a téves elágazásbecslésnek. Hiszen mindkét ágat számolná. De nem számolja.

Szerkesztette: hvuk 2006. 06. 21. 14:58 -kor