[cx.core]

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

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

De nezz csak eggyel feljebb, igaza van Balala-nak. A kicsivel is fejlettebb branch predictorok azt a 0101 mintat megeszik uzsonnara.
http://www.x86.org/a...hprediction.htm

[SFIJ]

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

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.

ezt kifejten reszletesebben? nem valtoztattam meg a kodot.

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

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.

ezen mondandod ertelmezhetetlen

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

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.

a meresem cafolja az allitasod de nem baj.

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

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.

ez igaz, csak nemsok kapcsolata van a megfigyelheto jelenseggel. mondhatni offtopik.

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

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.

pedig van buntetes. szandekosan kicsi az alpblokk, hogy a hatas fellepjen. ha az agak merteke kelloen hosszu lenne, akkor a reorder buffer mar kicsive valna ahhoz, hogy mindket agat feldolgozo 'szeles' modban mukodjon, ilyenkor lep fel az a 'mukodes' amit preferalsz. emellett a veszteseg az, hogy egy komplett VE-t lekotunk a 'semmi' kiszamolasara, mert eldobasra kerul a vegeredmeny.

[SFIJ]

Idézet: cx.core - Dátum: 2006. jún. 21., szerda - 15:04

De nezz csak eggyel feljebb, igaza van Balala-nak. A kicsivel is fejlettebb branch predictorok azt a 0101 mintat megeszik uzsonnara.
http://www.x86.org/a...hprediction.htm

a kepet arnylaja kisse az lrand48()-as futasi eredmeny, gondolom

szerk: helyesiras

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

[hvuk]

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

ezt kifejten reszletesebben? nem valtoztattam meg a kodot.

If nélküli kódban:
"j = i/2;
acc += j;"

if-es kódban:
" j = i/2;
acc += i;
}
      else
{
j = i/2;
acc += 0;"

Itt nem j-t használsz, hanem i-t. Némileg helyesebb kód lenne az alábbi, bár ez sem tökéletes:
if nélküli:
"j = i/3;
acc += j;"

ifes:
j = i/3;
acc += j;
}
      else
{
j = i/5;
acc += j;
}

Persze még ez sem tökéletes, hiszen az értékeadást kiemelheti az if utánra.

Idézet

ezen mondandod ertelmezhetetlen

Akkor a nagyon gyengék kedvéért értelmezem. Abból, hogy reorder és szuperskalár nem következik az, hogy az if mindkét ágát kielemzi. Abból annyi következik, hogy az utasításokat átrendezheti és egy idõben többet is tud fetchelni.

Ha az elsõ mondatra utaltál, akkor sajnos nincs igazad. Ha a neten egyetlen forrás sem található, ami igazolna téged, ellenben többet is találok, ami engem igazol (illetve csak olyat találok), akkor azt hiszem nyugodtan használhatok általános alanyt. Te viszont semmiképpen sem, hiszen egyetlen forrást sem tudtál hozni, ami az állításod igazolta volna.

Idézet

a meresem cafolja az allitasod de nem baj.

A mérésed még a legnagyobb jóindulattal sem nevezhetõ annak. A teszprogramodban számtalan probléma van, mint arra már többen is rámutattak. Bár tény, hogy mérni véltél valamit.

Idézet

pedig van buntetes. szandekosan kicsi az alpblokk, hogy a hatas fellepjen. ha az agak merteke kelloen hosszu lenne, akkor a reorder buffer mar kicsive valna ahhoz, hogy mindket agat feldolgozo 'szeles' modban mukodjon, ilyenkor lep fel az a 'mukodes' amit preferalsz. emellett a veszteseg az, hogy egy komplett VE-t lekotunk a 'semmi' kiszamolasara, mert eldobasra kerul a vegeredmeny.

A komplett VE lekötése mindig fennál, nem csak akkior, amikor rossz volt az elágazásbecslés. Ha nem volt rossz, akkor is fennáll, hiszen mindkét ágat végigszámolja, érdektelen, hogy jó volt-e az elõrejelzés vagy sem.

Igazából a te koncepciódban az elágazásbecslésnek nincs semmi szerepe(*). Elágazáshoz érünk, van A és B ág. A proci megbecsüli, hogy melyik ág lesz valószínûbb, majd elkezdi mindkét ágat feldolgozni (szerinted). Feldolgozza A1/B1 utasításokat, majd sorban a többit (amíg nem telik be a ROB), bár persze nem biztos, hogy adott idõ alatt pont ugyanannyival végez a két ágon. Amikor feloldja az eredeti if-et, akkor eldobja az egyik ágat és megtartja a másikat. De mire szolgál az elágazásbecslés ebben az esetben?

*: Az elágazásbecslésnek lehet szerepe, de csak akkor, ha újabb elágazáshoz ér. Ekkor mondhatja azt a proci ebben a verzióban, hogy innentõl csak az egyik ágat számolja tovább, azaz ha mondjuk az A ágon ért elágazáshoz, akkor most az A ágon csak az egyik ágat követi (meg persze még B-t), mert nem akar fát felépíteni. Ez mind szép és jó, de ilyenrõl meg aztán egyáltalán nem olvasni sehol sem. Ez már tényleg sci-fi.

Szerkesztette: hvuk 2006. 06. 21. 16:13 -kor

[SFIJ]

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

If nélküli kódban:
"j = i/2;
acc += j;"

if-es kódban:
" j = i/2;
   acc += i;
}
      else
{
   j = i/2;
   acc += 0;"

Itt nem j-t használsz, hanem i-t. Némileg helyesebb kód lenne az alábbi, bár ez sem tökéletes:
if nélküli:
"j = i/3;
acc += j;"

ifes:
j = i/3;
   acc += j;
}
      else
{
   j = i/5;
   acc += j;
}

Persze még ez sem tökéletes, hiszen az értékeadást kiemelheti az if utánra.

ezt abszolute nem ertem. azt irod megvaltoztattam akodot. ez nem igaz. az akod lett publikalva ami futott. tovabba nem latom be azt, hogy akodod "helyesebb" lenne. plane eleg kicsinyes dolog belekotni abba, hogy hogyan nevezem el a valtozoimat.

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

Akkor a nagyon gyengék kedvéért értelmezem. Abból, hogy reorder és szuperskalár nem következik az, hogy az if mindkét ágát kielemzi.

meressel bizonyitottam, hogy ez a jelenseg elolall

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

Abból annyi következik, hogy az utasításokat átrendezheti és egy idõben többet is tud fetchelni.

pont itt akulcs. csak fatol ne latod az erdot. transzformalta a kodot, ezaltal parhuzamositotta a felteles kodresz teljes kiertekeleset.

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

Ha az elsõ mondatra utaltál, akkor sajnos nincs igazad.

ezt bizonytanod kene.

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

Ha a neten egyetlen forrás sem található, ami igazolna téged, ellenben többet is találok, ami engem igazol (illetve csak olyat találok), akkor azt hiszem nyugodtan használhatok általános alanyt.

mindez nem bizonyit semmit, plane nem igazol semmit. szelktiv irodalomkutatast vegeztel, ennyi.

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

Te viszont semmiképpen sem, hiszen egyetlen forrást sem tudtál hozni, ami az állításod igazolta volna.

ujbol megismetlesre kerul a korabban mar a valosagnak ellentmondo allitas.

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

A mérésed még a legnagyobb jóindulattal sem nevezhetõ annak. A teszprogramodban számtalan probléma van, mint arra már többen is rámutattak. Bár tény, hogy mérni véltél valamit.

persze hogy nem nevezned annak, mert ellentmond a te altal kiagyalt nezetnek. lasd meg kognitiv diszonancia.

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

Igazából a te koncepciódban az elágazásbecslésnek nincs semmi szerepe(*). Elágazáshoz érünk, van A és B ág. A proci megbecsüli, hogy melyik ág lesz valószínûbb, majd elkezdi mindkét ágat feldolgozni (szerinted).

a meresi eredmenyek ezt igazoljak. pont.

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

Feldolgozza A1/B1 utasításokat, majd sorban a többit (amíg nem telik be a ROB), bár persze nem biztos, hogy adott idõ alatt pont ugyanannyival végez a két ágon. Amikor feloldja az eredeti if-et, akkor eldobja az egyik ágat és megtartja a másikat. De mire szolgál az elágazásbecslés ebben az esetben?

rohadt egyszeru.  aprociban van egy adag rename register. az egyik utnak megfelelo VE eredmenye az egyik, mig a masik ag eredmenye egy masik rename regiszterbe kerul. a renam regiszterek taggeltek az elagazas felteteltol fuggoen.

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

Ez mind szép és jó, de ilyenrõl meg aztán egyáltalán nem olvasni sehol sem. Ez már tényleg sci-fi.

szerinted. csak a valosag meg szemberohog

Szerkesztette: SFIJ 2006. 06. 21. 16:55 -kor

[cx.core]

SFIJ, szerintem te az "eager execution"-ra gondolsz.

Idézet: Wikipedia

Though it's seldom referred to as such, eager execution is also a form of speculative execution

http://www.cs.clemso...mark/eager.html
http://www.cs.mtu.edu//html/trs.html

[SFIJ]

Idézet: cx.core - Dátum: 2006. jún. 21., szerda - 18:02

SFIJ, szerintem te az "eager execution"-ra gondolsz.

Idézet: Wikipedia

Though it's seldom referred to as such, eager execution is also a form of speculative execution

http://www.cs.clemso...mark/eager.html
http://www.cs.mtu.edu//html/trs.html

pontosan errol van szo. nem szabad az irodalom gyujteset es feldolgozasat olymertekben fundamentalisan es prekoncepciozusan megtenni, ahogy azt hvuk teszi. nem szabad egy fogalmat ami itt a spekulativ vegrehajtas, szandekosan fogalmilag csonkitani.

[cx.core]

Találtam egy ilyet: http://www.informatik.uni-augsburg.de/~ung...0-01/pr00-9.ppt
Azt sajnos nem tudom, hogy mikor írták, de a nevébõl 2000-re következtetek, amit az is alátámasztana, hogy a NetBurst-rõl már szólnak benne.

Idézet

Eager (Multipath) Execution

• Execution proceeds down both paths of a branch, and no prediction is made.
  When a branch resolves, all operations on the non-taken path are discarded.
  
  
  
• Oracle execution: eager execution with unlimited resources
  gives the same theoretical maximum performance as a perfect  branch prediction
  
  
  
• With limited resources, the eager execution strategy must be employed carefully.
  
  
  
• Mechanism is required that decides when to employ prediction and when eager execution: e.g. a confidence estimator
  
  
  
• Rarely implemented (IBM mainframes) but some research projects:
  Dansoft processor, Polypath architecture, selective dual path execution, simultaneous speculation scheduling, disjoint eager execution

[..]

Branch handling techniques and implementations

[..]
Dynamic prediction:
  1-bit                      DEC Alpha 21064, AMD K5
  2-bit                      PowerPC 604, MIPS R10000,
                          Cyrix 6x86 and M2, NexGen 586
  two-level adaptive      Intel PentiumPro, Pentium II, AMD K6, Athlon
Hybrid prediction            DEC Alpha 21264
Predication                  Intel/HP Merced and most signal processors as e.g.
                          ARM processors, TI TMS320C6201 and many other
Eager execution (limited)    IBM mainframes: IBM 360/91, IBM 3090
Disjoint eager execution  none yet

Hogy azóta mi a helyzet, arról még nem találtam semmi explicitet.

[cx.core]

Találtam egy multipath paper-t (amelyben szó van többek között a fent is említett Polypath-ról). Ez mindenképpen 2003 utánra tehetõ (legutóbbi dátum az irodalomjegyzékében). Ebben a Pentium 4 egyértelmûen unipath besorolást kap.

szerk.: csak a link maradt le
http://www.ele.uri.e...6-multipath.pdf

Szerkesztette: cx.core 2006. 06. 21. 19:56 -kor

[SFIJ]

Idézet: cx.core - Dátum: 2006. jún. 21., szerda - 19:34

Találtam egy ilyet: http://www.informatik.uni-augsburg.de/~ung...0-01/pr00-9.ppt
Azt sajnos nem tudom, hogy mikor írták, de a nevébõl 2000-re következtetek, amit az is alátámasztana, hogy a NetBurst-rõl már szólnak benne.



Hogy azóta mi a helyzet, arról még nem találtam semmi explicitet.

a disjoint egy fejlettebb forma. ez esetben arrol van szo, hogy a branch-hit-tel rendelkezo ag prioritast kap a cpu resource-okert folyo versenyben ugye. nem hiszem hogy ez nagyon implementalt lenne, lehet hogy elric-ek valamit leptek eteren a niagara2-ben

[cx.core]

Hiába keresek, nem találtam még csak utalást sem arra, hogy lenne olyan x86, amely az eager execution valamilyen változatát alkalmazza.
(Arra találtam, hogy a NetBurst nem ilyen, és valószínûleg a P6 sem.)

De gyanús is, hogy egy ekkora buzzword-öt, mint Eager Execution™ (vagy inkább Busy Beaver™? :Ð), akármelyik procigyártó ráragasztana a tokra, ha támogatná.

Szerkesztette: cx.core 2006. 06. 21. 21:09 -kor

[hvuk]

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

ezt abszolute nem ertem. azt irod megvaltoztattam akodot. ez nem igaz. az akod lett publikalva ami futott. tovabba nem latom be azt, hogy akodod "helyesebb" lenne. plane eleg kicsinyes dolog belekotni abba, hogy hogyan nevezem el a valtozoimat.

Valóban azt hiszed, hogy a változó nevével van a bajom? Egyáltalán nem a neve a baj. A kód az if-es és a nem if-es részben változott meg, mégpedig a kapcsos zárójelek közötti rész. Más van a kapcsos zárójelek között, mint a nem if-es részben. És nem csak a += 0 részre gondolok, hanem a másik ágra is. Elmagyarázom.

Az if nélküli kódban az elsõ sorban értéket kap j, a második sorban ezt az értéket adod hozzá acc-hoz. Ergo ez a két sor függ egymástól, a végrehajtás során a processzor nem tudja õket párhuzamosítani, meg kell várni, amíg az elsõ sorral, azza j kiszámításával végez.

Az if-es kódban viszont igaz, hogy elõször kiszámítod j értékét, de utána a második sorban egyik ágban sem használod fel (hiszen mind a nulla, mind i értéke nem függ j-tõl)! Ez azt eredményezi, hogy a második sor nem függ az elsõtõl, ergo kiválóan párhuzamosítható, mivel függetlenek.

Magyarán az történik, hogy az if-es kódrészlet végrehajtása lényegesen gyorsabb, mint az if nélküli esetben, ha kihagyjuk belõle az if-et. Erre gondolok:

Ez:
j = i/2;
acc += i;

gyorsabban lefut ennél:
j = i/2;
acc += j;

Idézet

meressel bizonyitottam, hogy ez a jelenseg elolall

Pont ezt magyarázom, hogy ordas nagy hibák vannak a tesztprogidban. Persze vannak mások is, de ez volt a legsúlyosabb. Ergo nem is biztonyítottál semmit. Ez olyan messze van a bizonyítástól, mint Makó Jeruzsálemtõl.

Idézet

pont itt akulcs. csak fatol ne latod az erdot. transzformalta a kodot, ezaltal parhuzamositotta a felteles kodresz teljes kiertekeleset.

Igen, ezek a módszerek elvileg alkalmasak erre. Lehet olyan implementációja ezeknek, amely tudja ezt. A vita arról folyik, hogy vajon az X86-ban így vannak-e implementálva.

Idézet

mindez nem bizonyit semmit, plane nem igazol semmit. szelktiv irodalomkutatast vegeztel, ennyi.

Értem. Tehát az nem igazol semmit, hogy hozok errõl egy csomó leírást, hozok definíciót, ami köszönõ viszonyban sincs a te értelmezéseddel. Ellenben az, hogy te kijelented, az igazolja. Értem. Köszönöm Mester az iránymutatást!

Mellesleg az alábbi módon kerestem rá erre a témára:
1. Csak az Intel oldalán a "speculative execution" kifejezésre
2. Csak az Intel oldalán, a "speculative execution" kifejezésre + X86-ra, illetve P6-ra
3. Ars technica oldalán a "speculative execution" kifejezésre
4. Aceshardware oldalán a "speculative execution" kifejezésre
5. teljes neten a "speculative execution" kifejezésre
6. teljes neten a "speculative execution" kifejezésre + X86-ra, illetve P6-ra

Mindenhol az elsõ 10-30 eredményt néztem meg, attól függõen, hogy mennyire találtam ígéretesnek az eredményeket. Semmi olyat nem találtam, mint amirõl beszész. Végig a google-t használtam. Mi ebben a szelektív?

Ezért kérek linket egy olyan forrásra, ami a te igazadat támasztja alá. De ha gondolod, akkor csak írd be a keresési kulcskombinációt, ami kidobja a megfelelõ eredményt.

Idézet

ujbol megismetlesre kerul a korabban mar a valosagnak ellentmondo allitas.

A forrásod nem írja egyetlen betüjével sem, hogy mindkét ág feldolgozásra kerül. Nem tagadja azt, de nem is állítja. Bármelyik állítás levezhetõ belõle. Ezért ennek eldöntésére sem alkalmas.

Idézet

persze hogy nem nevezned annak, mert ellentmond a te altal kiagyalt nezetnek. lasd meg kognitiv diszonancia.

Azért a kognitív disszonancia erõsen terád jellemzõ fogalom és nem énrám.

Idézet

a meresi eredmenyek ezt igazoljak. pont.

Vagy nem. De inkább nem. Szar méréssel mindent lehet bizonyítani. Egy olyan programmal meg ami teljes mértékben alkalmatlan a funkciójára még inkább.

Idézet

rohadt egyszeru.  aprociban van egy adag rename register. az egyik utnak megfelelo VE eredmenye az egyik, mig a masik ag eredmenye egy masik rename regiszterbe kerul. a renam regiszterek taggeltek az elagazas felteteltol fuggoen.

Igen, akár mûködhetne így is. Akár mindkét szálat is feldolgozhatná a proci. Na, erre kellene egy korrekt leírás. Arra ugyanis elég sok oldalon van leírás, hogy nem ilyen.

Idézet

szerinted. csak a valosag meg szemberohog 

Esetleg, de tényleg csak esetleg hozhatnál egy olyan leírást, amely kõkeményen alátámasztja ezt az általad valóságnak vélt dolgot.

Szerkesztette: hvuk 2006. 06. 21. 21:20 -kor

[cx.core]

Jajj, banyek, hvuk, most ez miert kellett? Szerintem mar eppen ott tartottunk volna, hogy kulturaltan tisztazzuk, hogy mi a helyzet...

[hvuk]

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

pontosan errol van szo. nem szabad az irodalom gyujteset es feldolgozasat olymertekben fundamentalisan es prekoncepciozusan megtenni, ahogy azt hvuk teszi. nem szabad egy fogalmat ami itt a spekulativ vegrehajtas, szandekosan fogalmilag csonkitani.

Valóban nem szabad. Persze el is kell olvasni azt amit benne írnak. Mint például az elsõ forrásban:

Idézet

First, Dispelling Some Misconceptions

    "The IBM 370/165 employed a branching strategy that fetched two paths, the inline path and the target path [FLO 74]. Two buffers were maintained, the main instruction buffer (MIB) and the auxiliary instruction buffer (AIB). When the effective address of the target instruction stream is known at stage n', the target stream is fetched into the AIB. Both streams are processed until the outcome is known."

    page 77 (emphasis added), Harvey Cragon, Branch Strategy Taxonomy and Performance Models. Los Alamitos, CA: IEEE Computer Society Press, 1992.

Like the passage given above, I've seen it alleged many times that certain commercial processors from the 1960's executed down both paths beyond a branch; but, as far as I'm aware, while some academic papers and designs have proposed this, multiple-path execution has never been done by a commercial processor.

[Conjecture: I think it may be traced to a misreading of the 1984 Lee and Smith IEEE Computer paper. E.g., see Perleberg and Smith.]

What you will find in commercial processors is a combination of these techniques:

    * instruction fetching down both paths after a branch,
    * speculative execution down one path,
    * prefetching of data down one path, and/or
    * preexecution of a subset of the instruction stream (especially in support of prefetching data).

Ezek után elemez néhány IBM nagygépet. X86-ról szó sincs benne mellesleg. De ugye kijelenti azt a bizonyos fenti mondatot.

A második linken ezt írják:

Idézet

Speculative execution, in the form of branch prediction, has become a common feature in superscalar processors and has been shown to be essential in achieving high performance. Eager execution, the fetching, issuing and execution of instructions down both paths of a conditional branch, has the potential to improve performance even more, but suffers from several problems when several successive branches are encountered. In this paper we show that eager prediction, defined to be eager execution to a certain level followed by ordinary branch prediction afterwards, produces performance improvements over pure branch prediction alone when sufficient resources are available; pure prediction still wins on machines with small issue window sizes and few functional units. Given a sufficiently large machine, the marginal cost, in terms of functional unit needs and register and memory bandwidth requirements are shown to be very minimal.

Tehát a normál egyszerû branch prediction egy normál fícsöre lett a szuperskalár processzoroknak, de az eager execution-ról ugyanezt már nem írja.

Tehát egyik sem támasztja alá az állításodat, spt a legelsõ forrás kimondottan megcáfolja (bár persze tévedhet elvileg).

[hvuk]

Idézet: cx.core - Dátum: 2006. jún. 21., szerda - 22:26

Jajj, banyek, hvuk, most ez miert kellett? Szerintem mar eppen ott tartottunk volna, hogy kulturaltan tisztazzuk, hogy mi a helyzet...

Lineárisan olvastam. Kitöröljem szerinted? Semmi durva nincs benne, csak vitázok.

De a cikkeid tényleg tisztába teszik a dolgot (bár még nem végeztem minddel) és alátámasztják, hogy nincs ilyen az X86-os procikban.

[hvuk]

Idézet: cx.core - Dátum: 2006. jún. 21., szerda - 20:34

Találtam egy ilyet:
...
Eager execution (limited)    IBM mainframes: IBM 360/91, IBM 3090
Disjoint eager execution  none yet

Hát igen, ez is, meg a cikkben a szöveg is azt bizonyítja, hogy ez nincs benne az X86-ban.

[SFIJ]

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

Valóban azt hiszed, hogy a változó nevével van a bajom? Egyáltalán nem a neve a baj. A kód az if-es és a nem if-es részben változott meg, mégpedig a kapcsos zárójelek közötti rész.

még mindig nem értem ezt a megváltozást. akód ugyan olyan maradt, ahogy meírtam. tehát ugyan olyan maradt az ifes meg a nem ifes ágban is, mint ahogy megírtam.

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

Pont ezt magyarázom, hogy ordas nagy hibák vannak a tesztprogidban. Persze vannak mások is, de ez volt a legsúlyosabb. Ergo nem is biztonyítottál semmit. Ez olyan messze van a bizonyítástól, mint Makó Jeruzsálemtõl.

én semminemû hibát nem látok benne. lefordul, fut. tekintettel arra, hogy egy add 2 clock cycle, valóban igaz, hogy az adatfügggésmenets rész kicsit gyorsabban fut le. de a te hipotézised szerint az ifes ferziónak 2x olyan lassúnak kéne lennie. ez az extra add timinf miatt legyen csak 75%-kal lassabb az ifes... aztán valahogy mégse..

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

Ergo nem is biztonyítottál semmit.

az állítás hamis. amáérési adatok bizonyítják a beágyazott feltétel párhuzamos kiértékelését. a kételyeket eloszlatandó véletlenszerû branchingra is mértem, ezzel kilõttem azt, hogy a "branch prediction volt okos"

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

A forrásod nem írja egyetlen betüjével sem, hogy mindkét ág feldolgozásra kerül. Nem tagadja azt, de nem is állítja.

a forrásom spekulatív végrehajtásról beszél. te ennek a fogalmat szándékosan, hibásan és doktriner módon leszûkítetted. ezen álláspontod hibáját mérési eredményekkel bizonyítottam.

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

Vagy nem. De inkább nem. Szar méréssel mindent lehet bizonyítani. Egy olyan programmal meg ami teljes mértékben alkalmatlan a funkciójára még inkább.

igen egy dotriner embertõl nemis várok más eredményt, minthogy 1000 légy nem tévedhet. ha mégis - úgy néz ki hogy mégis, akkor nekiáll az objektív tényeket félremagyarázni.

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

hozhatnál egy olyan leírást,

kaptál egy bizonyító erejû mérési eredmeényt a jelenségre. ha neked ez nem elég, akkor semmi sem lesz az. hozzon neked leírást a radai rosseb.

Szerkesztette: SFIJ 2006. 06. 21. 22:25 -kor

[SFIJ]

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

Hát igen, ez is, meg a cikkben a szöveg is azt bizonyítja, hogy ez nincs benne az X86-ban.

ez explicite leírva nincs. pont.

ami érdekes lenne számodra:
" * preexecution of a subset of the instruction stream"
kedves "spekulatívan olvasó barátom"

Szerkesztette: SFIJ 2006. 06. 21. 22:09 -kor

[hvuk]

Hagyjuk SFIJ. Botokkal nincs kedvem vitázni.

[SFIJ]

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

Hagyjuk SFIJ. Botokkal nincs kedvem vitázni.

te nem vitázol, hanem játszmázol.