[bogdan]

Idézet: hvuk - Dátum: 2006. ápr. 11., kedd - 14:11

A legtöbb program esetében egyáltalán nem könnyû a párhuzamosítás, különösen nem 4+ threadre. A dual processzorok kihasználása még várható a közeljövõben, de ennél több processzoré az elkövetkezõ 3-4 évben biztosan nem.

nem tudok egyeterteni! az elso lepes a legnehezebb, utana az, hogy 2 vagy 128 szalam van mar tulajdonkeppen lenyegtelen. persze a skalazodas egyaltalan nem az, es rossz programozas kovetkezteben bebukik nagyon hamar a teljesitmeny, de ettol meg noni fog szigoru monoton a magok szamaval. (ebben a nagysagrendben!) ehhez kepest az altalad hozott anti-threading nem latom hol lenne ertelmes.
raadasul a problema elvi jellegu: bizonyos problemakat nagyon nehez, vagy -- legalabbis a mai tudasunk szerint -- lehetetlen parhuzamositani. de akkor ha a programozo nem kepes ra, akkor hogy lenne kepes ra egy elore bedrotozott hardware? nem tartod furcsanak ezt az allitast? mert en igen.

Idézet

Mellesleg azt nem hiszem, hgoy bármelyikõnk is itt olyan szinten állna tudásban, hogy el tudná dönteni, hogy vajon az Itanium Foxton megoldása a bonyolultabb technológia kivitelezés szempontjából vagy az erõforrásmegosztás.

en nem a Foxtont hoztam peldanak. az biztos, hogy sokkal egyszerubb, mivelhogy nem architekturalis kerdes, hanem mernoki alapvetoen. azon belul persze a legmagasabb szintu, de magara a mukodesre nem nagyon lehet hatassal. ez egy alma-korte kerdes: nincs sok ertelme vitazni rajta.

Idézet

Viszont jól látszik, hogy egyik általam vázolt esetben sem egy CPU-t kapunk, hanem továbbra is 4 van

ebben egyetertunk: ergo ennek semmi koze az altalad idezettekhez amire en azt mondtam, hogy mesebeszed!

[SFIJ]

Idézet: hvuk - Dátum: 2006. ápr. 11., kedd - 14:11

Jobban belegondolva, szerintem mellesleg inkább valami olyasmi lehet mögötte, hogy lennének olyan erõforrások, amik dinamikusan lehetnének hozzárendelve az egyes processzorokhoz, azaz azok használhatnák, akiknek éppen szükségük van rá. Itt olyasmire gondolok, hogy lenne a processzorban egy nagyon gyors, de relatíve bonyolult egység (valamiféle koprocesszor-szerûség) amit a 4 mag közösen megosztva használva. Ennek speciális esete egy nagyon erõs megosztott FP egység. Ez könnyen elképzelhetõ és különösebben meglepõ nincs benne. Ráadásul összhangban van azzal, hogy a dekstop/mobil processzort az AMD-sek úgy írták le, mint ami elõtérbe helyezi a fogyasztást. Ekkor persze a 4 CPU-ban nem lenne FPU, csak a közös, de ez már ugyanaz a megoldás lenne mint ami a Niagarában is van, így nem lenne újdonság.

Érdekesebb elképzelés, hogy esetleg a processzor bizonyos részei közösen vannak kivitelezve és ezek szabadon particionálhatóak. Tehát pl. a fenti példánál maradva, minden processzor rendelkezik bizonyos számú fix FP mûveletvégzõ egységgel, de vannak központi egységek is amiket magához kérhet, így megnövelve az FP mûveletvégzõ képességet. Persze nem feltétlenül csak FP egységekrõl lehet szó, de szerintem azt a legértelmesebb megosztani (az int egységeket nincs sok értelme). Így ezzel a módszerrel ha egy processzor vonja magához az összes egységet a központból, akkor lényegesen erõsebb FPU teljesítménnyel rendelkezne, mint ... na, ezt nem tudom, mondjuk mint a mai FPU teljesítménye.

Viszont jól látszik, hogy egyik általam vázolt esetben sem egy CPU-t kapunk, hanem továbbra is 4 van, csak az egyik ideiglenes lényegesen nagyobb teljesítményû lett mint a többi. Szeritnem ez az a rész amit a cikkíró félreérthetett, itt gondolt arra, hogy csak összességében egy CPU-t lát az egész rendszer. Aztán persez lehet, hogy hatalmasat koppanunk 1-2 év múlva, bár erre azért kicsi az esély.

ezek az otletelesek az intel hyper threadingtol a niagaraig terjednek. hat nemtom. mindket arch nagzon specializalt es ra optimakolt kodot igenyel. altcelu esetben a teljeseitmeny-tobbletuk nem egyertelmu.

[SFIJ]

Idézet: bogdan - Dátum: 2006. ápr. 11., kedd - 15:38

nem tudok egyeterteni! az elso lepes a legnehezebb, utana az, hogy 2 vagy 128 szalam van mar tulajdonkeppen lenyegtelen.

volt egy nagyon ko kis cikk arrol, hogy mamar tudnak a programzok pthreads-os proggikat irni, de meg erosen ki vagyon hasznalva, hogy azok a szalak ugyanazo a core-on futnak. a kovetkezo nagy bukofordulo az az, amikor az Mt alakalazas MP/MC rendszerre kerul...

[hvuk]

Idézet: bogdan - Dátum: 2006. ápr. 11., kedd - 15:38

nem tudok egyeterteni! az elso lepes a legnehezebb, utana az, hogy 2 vagy 128 szalam van mar tulajdonkeppen lenyegtelen. persze a skalazodas egyaltalan nem az, es rossz programozas kovetkezteben bebukik nagyon hamar a teljesitmeny, de ettol meg noni fog szigoru monoton a magok szamaval. (ebben a nagysagrendben!) ehhez kepest az altalad hozott anti-threading nem latom hol lenne ertelmes.
raadasul a problema elvi jellegu: bizonyos problemakat nagyon nehez, vagy -- legalabbis a mai tudasunk szerint -- lehetetlen parhuzamositani. de akkor ha a programozo nem kepes ra, akkor hogy lenne kepes ra egy elore bedrotozott hardware? nem tartod furcsanak ezt az allitast? mert en igen.

Ez ugye nem igaz. Vegyünk például egy játékprogramot. Ezt relatíve egyszerû párhuzamosítani 2 szálra. Külön szálba szedjük az MI részt és külön szálba a többi részt. Van még esély 3 szálra is, bár ez már lényegesen nehezebb. Egyszerûen nem igaz az, hogy a 2 szálra bontás a legnehezebb és onnan a többi már gyerekjáték.

Idézet

en nem a Foxtont hoztam peldanak. az biztos, hogy sokkal egyszerubb, mivelhogy nem architekturalis kerdes, hanem mernoki alapvetoen. azon belul persze a legmagasabb szintu, de magara a mukodesre nem nagyon lehet hatassal. ez egy alma-korte kerdes: nincs sok ertelme vitazni rajta.

Az Itaniumot hoztad, az Itanium esetén meg nem tudom milyen problémára gondoltál. Nem biztos, hogy egy mérnöki probléma egyszerûbb mint egy architekturális. Én kicsit kevésbé magabiztosan nyilatkoznék errõl a kérdésrõl a helyedben. Én sem tudom mellesleg, hogy melyik bonyolultabb.

[hvuk]

Idézet: SFIJ - Dátum: 2006. ápr. 11., kedd - 16:27

ezek az otletelesek az intel hyper threadingtol a niagaraig terjednek. hat nemtom. mindket arch nagzon specializalt es ra optimakolt kodot igenyel. altcelu esetben a teljeseitmeny-tobbletuk nem egyertelmu.

Hyperthreadingrõl nem volt szó az ötleteim között. Mire gondolsz?

[hajsza]

Idézet: hvuk - Dátum: 2006. ápr. 12., szerda - 9:30

Az Itaniumot hoztad, az Itanium esetén meg nem tudom milyen problémára gondoltál. Nem biztos, hogy egy mérnöki probléma egyszerûbb mint egy architekturális. Én kicsit kevésbé magabiztosan nyilatkoznék errõl a kérdésrõl a helyedben. Én sem tudom mellesleg, hogy melyik bonyolultabb.

Pedig szerintem ki lehetett találni, elvégre szoftver optimalizálásról is szó volt, az Itanium compiler nehézségei pedig tavaly slágertéma volt. Le merném fogadni, hogy a Foxton helyett erre gondolt.

[bogdan]

Idézet: hvuk - Dátum: 2006. ápr. 12., szerda - 8:30

Ez ugye nem igaz. Vegyünk például egy játékprogramot. Ezt relatíve egyszerû párhuzamosítani 2 szálra. Külön szálba szedjük az MI részt és külön szálba a többi részt.

igen, termeszetesen ebben igazad van. en nem vettem figyelembe, mert ez nem algoritmikai szintu parhuzamositas, nem is hozhatja meg azt az elonyt, amit az algoritmikai szintu adna. mert ugye igy a ket szal total kiegyensulyozatlan lenne, mondjuk (jo esetben) az egyik a masik felenek eroforrasat igenyelne, igy (az overhead miatt) 30-40% elonye lehetne a DC-nek. egy algoritmikai szintu parhuzamositas meg ugye joval tobbet hoz a "konyhara". raadasul annak mar valoban legtobbszor mindegy, hogy hany szal lesz ra, csak az overhead miatt lesz egyre kisebb aranyban hatekony. ezt probaltam kifejteni.

Idézet

Az Itaniumot hoztad, az Itanium esetén meg nem tudom milyen problémára gondoltál.

bocsanat, azt hittem egyertelmu, hogy a parhuzamosan tobb utasitas vegrehajtasa es az ebbol kovetkezo elore optimalizacio kerdeskorerol (utasitasok atrendezeserol) van szo. az ugyanugy algoritmikai problema, mint az, hogy rejtett tobbszalusagot vinni a kivulrol egyszalunak latszo magba.

(es persze igaz, hogy eros nehezsegekrol nyilatkozni igy beledumalva, de ha az ember nehez matematikai problemat lat valahol, akkor a sokeves tapasztalata azt mondatja vele, hogy ennel nehezebb mas problema nem lehet, es a mernoki problema ehhez kepest "csak" a megvalositas. van sajnos egy nem tul elfogadhato nezopontom a mernokok iranyaban. elore is bocsanat minden mernoktol! )

[hvuk]

Idézet: hajsza - Dátum: 2006. ápr. 12., szerda - 10:12

Pedig szerintem ki lehetett találni, elvégre szoftver optimalizálásról is szó volt, az Itanium compiler nehézségei pedig tavaly slágertéma volt. Le merném fogadni, hogy a Foxton helyett erre gondolt.

De itt épp az lenne a lényeg, hogy nincs szükség szoftver optimalizációra! Épp ezért nem jó az Itanium példája.

Mondjuk a csóka szerintem is félreértett valamit és nincs szó arról, hogy tényleg kevesebb, de erõsebb processzornak látná a rendszer. Ha tényleg errõl van szó, akkor az azért baromi nagy dobás lenne, de hát erre kicsi az esély.

[hvuk]

Idézet: bogdan - Dátum: 2006. ápr. 12., szerda - 10:15

igen, termeszetesen ebben igazad van. en nem vettem figyelembe, mert ez nem algoritmikai szintu parhuzamositas, nem is hozhatja meg azt az elonyt, amit az algoritmikai szintu adna. mert ugye igy a ket szal total kiegyensulyozatlan lenne, mondjuk (jo esetben) az egyik a masik felenek eroforrasat igenyelne, igy (az overhead miatt) 30-40% elonye lehetne a DC-nek. egy algoritmikai szintu parhuzamositas meg ugye joval tobbet hoz a "konyhara". raadasul annak mar valoban legtobbszor mindegy, hogy hany szal lesz ra, csak az overhead miatt lesz egyre kisebb aranyban hatekony. ezt probaltam kifejteni.

De épp errõl van szó, hogy komplex programok esetén ez egyáltalán nem triviális feladat. Sõt, a legtöbb esetben a gyakorlatban reménytelen. Thread jellegû programok esetén lehetséges a problémák ilyen megoldása, de nagyon sok program nem ilyen.

[bogdan]

Idézet: hvuk - Dátum: 2006. ápr. 12., szerda - 12:52

De itt épp az lenne a lényeg, hogy nincs szükség szoftver optimalizációra! Épp ezért nem jó az Itanium példája.

mindket esetben egy hagyomanyos programozoi paradigma szerint megfogalmazott programot kell egy masik paradigma szerinti "nyelvre"/mukodesi mechanizmusra atforditani. az Itanium eseteben ezt off-line, sok eroforrassal rendelkezo compiler teszi -- nem tul nagy sikerrel; ebben az esetben meg a processzoron beluli on-line layer tenne. az osszevetesem ennyibol allt. persze nem feltetlenul relevans, de szerintem jol ramutat a problema jellegere, nehezsegere -- miszerint amit kezzel, esszel meg lehet csinalni, az a mesterseges intelligencianak ma meg neha kemeny dio.

************************************
hogy a komplex programokban "gyakorlatilag remenytelen" lenne a tobbszalusag azt nem latom. nehez feladat, ezert eddig nem is foglalkoztak vele. most kenytelenek lesznek, mert minden szinten bejott a tobbszalusag (a konzolon is!), igy kenytelenek lesznek uj paradigmaban gondolkodni. ha ezt elkezdik (es en ugy hiszem, hogy el fogjak nagyon hamar), akkor ha nem is tul hatekonyan, de gyakorlatilag a programok tulnyomo tobbsege ki fogja ezt hasznalni. es nem csak a 2 szalat. az altalad emlitett 2 szalba szetszedes csak egy atmeneti lepes lehet, mint ilyen tortenelmi szempontbol irrelevans.

[hajsza]

Idézet: hvuk - Dátum: 2006. ápr. 12., szerda - 13:52

De itt épp az lenne a lényeg, hogy nincs szükség szoftver optimalizációra! Épp ezért nem jó az Itanium példája.

Az tökmindegy, hogy egy problémát szofveresen vagy szilíciumba öntve próbálnak megoldani. A probléma bonyolultsága az érdekes. És ez az optimalizáció rendkívül kemény dió, ráadásul hasonló jellegû, mint az Itanium compiler-é. Emiatt nem hiszem én sem abban, hogy az általad felvázolt architektúra megvalósul.

[hvuk]

Továbbra sincs köze az Itaniumnak ehhez. Teljesen más a szoftver és a hardvermegoldás. A mai processzorokban már benne van idõtlen idõk óta a párhuzamosítás, a K8 például 3 issue, a Conroe meg 4 issue. A gond a pipelineok etetése, épp ezért nincs ennél több issue architektúra (még), ennek sok oka van (memórialatency, utasítások párhuzamosítása, elágazásbecslés hibája, ...). Tehát a sok ok közül csak az egyik az elvi párhuzamosítási nehézség.

Az Itanium esetén 3 utasítás van összefogva egybe, így ott 3 utasítást kell párhuzamosítani a compilernek. Mégis eléggé nehezen halad a munkával. De az õ gondja nagy részben más mint amit a hardver végez.

Ja igen, azért sem ugyanaz a probléma, mert a szoftveres megoldás esetén a szoftvernek nincsen birtokában run-time információ, ellentétben a hardveres megoldással.

Szerkesztette: hvuk 2006. 04. 12. 15:03 -kor

[hvuk]

Az AMD közzétette 1. negyedéves eredményét. A forgalom teljesen megfelelt a várakozásoknak, 1.33 milliárd USD volt, a nyereség azonban lényegesen felülmúlta a 30 centes részvényenkénti várakozásokat a 38 centes eredménnyel, ami 259 milliós "operation income"-ot (ez hogy van magyarul?), illetve 185 milliós tiszta nyereséget jelent.

A differencia a megnövekedett ASP-nek köszönhetõ, mind a desktop, mind a mobil chipek ASP-je nõtt, ami ráadásul a nagyon erõs Opteronos eladásokkal párosult. Az AMD tehát vélhetõleg a szûk kapacitások miatt nem tudta kielégíteni a keresletet, így a jövedelmezõbb chipekre koncentrált. A "gross margin" 58.5% volt, 2005 Q4-ben 57.3%, egy évvel ezelõtt pedig 52.7%. Ez kb. az Intel erre a negyedévre várt gross marginja körül lehet, sõt talán még egy kicsivel magasabb is. Az Intel 1 hét múlva teszi közzé az eredményét.

Két dolog is érdekes. Az egyik, hogy az Intel árcsökkentéseinek nem igazán volt hatása az AMD-re, ez mellesleg várható is volt, mivel egy ilyen húzás nem igazán hat egy olyan konurensre, aki amúgy sem tudja kielégíteni a keresletet. Neki ugyanis csak kevéssé (vagy egyáltalán) nem kell csökkenteni az árait (a tervezetthez képest) ahhoz, hogy fentartsa a keresletet, hiszen egy kis keresletcsökkenés még semmiféle hatással nincs rá (hiszen így sem tudja kielégíteni az igényeket). A másik érdekesség, hogy az AMD pénzügyi negyedéve március 26-án ért véget, tehát egy teljes hét kimaradt a márciusból. Vélhetõleg az Intel esetén a pénzügyi negyedév hónap végéig tart, legalábbis a pénzügyi jelentés egy héttel késöbbi kihozatala erre utal.

[Asker]

vhol olvastam ,hogy az amd gyára 150 percentel üzemel :Ð
de most tényleg?

Szerkesztette: Asker 2006. 04. 12. 22:03 -kor

[hvuk]

Idézet: Asker - Dátum: 2006. ápr. 12., szerda - 22:03

vhol olvastam ,hogy az amd gyára 150 percentel üzemel :Ð
de most tényleg?

Tényleg. Bár a hír nem így igaz teljesen, hanem úgy, hogy az eredetileg tervezett kapacitás 150%-án, 20 ezer helyett 30 ezer ostyát dolgoznak fel havonta (vagy hetente, ez nem egyértelmû).

Szerkesztette: hvuk 2006. 04. 12. 23:01 -kor

[hvuk]

Két további info az AMD negyedévérõl és kilátásairól. Az egyik állítólag egy Prudential analízisbõl való, de linket nem tudtak adni hozzá.

Idézet

HIGHLIGHTS
* We believe that AMD is in the early stages of its ASP growth story. We are forecasting AMD MPU ASPs to increase from $85 in '05 to $100 in '07 driven by: 1) increased corporate penetration, 2) increased sales of higher ASP notebook and server MPUs, and 3) richer mix of performance MPUs.
* We believe AMD only has 12% of the corporate market, and expect AMD to double its corporate SKUs in '06. We estimate that corporate MPUs sell at a 60% premium to consumer MPUs.
* After gaining 1,700 and 600 bps of share in servers and notebooks in '05, we expect AMD to gain another 700 bps and 300 bps of share by the end of ’06, respectively, driven by its dual core Opteron and Turion product cycles.
* Separately, our checks indicate that Intel is selectively cutting pricing by 30%-50%, but that it is not impacting neither AMD's share nor pricing. Our sources indicate AMD is actually raising ASPs in some high end products, and is scheduled to cut pricing in May by only 2% in some low-end desktop MPUs. We think that concerns about a "price war" from Intel are overblown.
* We continue to believe that consensus estimates for AMD are too low. We are forecasting '06 and '07 pro forma EPS of $1.77 and $2.51, which are $0.35 and $0.71 above the Street, respectively. AMD remains our top pick. Reiterate Overweight rating and $55 price target.

A másik a telefonos konferencia rövid kivonata:

Idézet

* End of this year, 90 % of all server CPUs sold will be dual core, single cores offerings will remain though
* AMD today employs three times as many R&D engineers as they did three years ago. That means today AMD employs three times more than those who developed A64
* AMD will present more information on future products and technology in their June technology analyst meeting
* AMD is not affected by Intel price cuts at all and don't expect Q2 to change that either
* Europe was the region where sales were not as good as expected
* FAB36 yields are excellent from day 1 (90 nm now)
* FAB30 was written off in 5 years, FAB36 will be in 6 years due to having a much larger production capacity that will have a longer life span
* AMD inventory is 55 days, very lean, and will remain so, except for Q3 to Q4 as Q4 sales are generally much higher
* AMD is focusing on the corporate market and growth there. Many OEMs have already significantly increased product offerings in that area
* I think I heard AMD say they "increased the dollar market share in Q1". Does that mean they lost unit market share?

Az Intel inventoryja közel 90 nap, elég penetráns különbség az 55 naphoz képest. Éppen ezért nem is tudja gyorsabban felfuttatni az új generációs processzorokat, hiszen a jelenlegi hatalmas raktárkészlettel kell valamit kezdenie.

Érdekes, hogy mindkét forrás szerint is hatástalan volt az Intel árcsökkentése. Mondjuk nem is igazán értem, hogy mit akart elérni vele az Intel, mert azt azért õk is valószínûleg látták, hogy az AMD-re gyakorlatilag semmiféle hatással nem lesz a dolog. Szerintem a raktárkészlet csökkentése volt a cél, nem pedig az AMD megtámadása. Az viszont elég érdekes, hogy az elemzõk rögtön leértékelték emiatt az AMD rövidtávú kilátásait, azaz õk ebbõl semmit sem láttak. Mondjuk a pénzügyi elemzõkrõl eddig is megvolt a véleményem, ez tulajdonképpen azon már nem sokat rontott.

A júniusi technológia meetinget meg már nagyon várom. Kíváncsi vagyok, hogy mit fognak felfedni a terméktervükbõl.

[Valdy]

http://babelfish.altavista.com/babelfish/t...wsd%26nid%3d933

Érdekes...

[Asker]

meg ez is...
Clovertown (2GHZ, 65nm, 2x4MB L2, FB-DIMM) slower than Athlon 64 (2GHZ, socket 939, 512KB L2, DDR)


erre érdemesebb rákattanni:

>>> Conroe performance claim being busted<<<

Idézet

The conclusion is: clock for clock, Athlon 64 will beat Conroe in real application environments that require a working set of larger than 4MB, or in other words, larger than Conroe's 4MB cache.

Szerkesztette: Asker 2006. 04. 18. 10:36 -kor

[hvuk]

Idézet: Asker - Dátum: 2006. ápr. 18., kedd - 10:26

erre érdemesebb rákattanni:

>>> Conroe performance claim being busted<<<

Van azért a cikkben egy-két tévedés. A legdurvább az, hogy a 4 megánál nagyobb "working set" (számomra ez a kifejezés ismeretlen, memory footprint akar lenni?) nem jelenti azt, hogy a 4 mega cache már nem elég. Mert ugye az Anand által tesztelt játékok "working set"-je nagyobb, mint 4 mega (nem is kicsivel), mégis jól elboldogul vele. A példái meg nem igazán jók (FireFox, ...).

[alvaro]

Idézet: Asker - Dátum: 2006. ápr. 18., kedd - 11:26

erre érdemesebb rákattanni:

>>> Conroe performance claim being busted<<<

Biztos, hogy van alapja, de azért erõs csúsztatás (egye fene, legyen tévedés ) a programok által lefoglalt teljes memóriarészt összevetni a cache méretével, sokkal inkább a leggyakrabban egyszerre használt részt kellene nézni szerintem. Amit triviálisan nem a taskmanager fog megmutatni. Tehát szerintem IRL igenis elõ fog jönni a cache,  legföljebb nem annyira, mint egyesek várják (jó kérdés, hogy az Anand-tesz mit is mért végülis).

Idézet

Frankly, I am really disappointed by Intel's decisions. This gimmick of using 4MB cache to get unreasonably good scores on the most simplistic tests is cheap from design point of view but expensive for manufacturing.

Ez viszont szerintem egy rossz vicc. Biztos azért terveztek a conroe-ba 4 mega cache-t, hogy a sciencemarkban irreálisan magas pontszámot kapjanak, amíg még nincs lehetõsége a plebsznek tesztelni az új procit Véletlenül sem azért, hogy segítsen a még mindig magon kívül esõ memóriavezérlõt minél inkább tehermentesíteni.

Szerkesztette: alvaro 2006. 04. 18. 12:41 -kor