143
-
Imre84 #143 Sziasztok!
Csak annyit szeretnék kérdezni, h az amd-néknél az x2 jelzés automatikusan dual magot jelent? Mert úgy hallottam h nem biztos. -
And01 #142 Igen müködik a 32biten is viszont kevesebb memóriát kezel /használ/
az oprendszer {ha jól tudom 3gb maximum,de ebből lejön a videókártya memóriája is}
-
nfr #141 Hello!
Ha 64 bites processzorom van, akkor muszáj 64 bites oprendszert föltelepíteni hozzá ha használni akarok, vagy elég a 32 bites is? (nem arról van szó, hogy ki akarom-e használni a 64 bites lehetőségeket, hanem hogy működik-e) -
#140
Mégis mihez képest?...valószinusitem sose fogod kihasználni az erőforrásait teljes egészében..... -
#139
Hello!
Azt szeretném kérdezni hogy szerintetek milyen erős lenne ez a gép?:
Proci: AMD sAM2 Athlon 64 X2 3800+ Box
Alaplap: ASUS M2N-E Socket AM2 NVIDIA nForce 570 Ultra MCP ATX AMD Motherboard
VGA: ATI Radeon X1600Pro 512Mb Sapphire
Memoria: DDR2 1024MB 667MHz CORSAIR ValueSelect
Lécci segítsetek! -
#138
te hülye vagy. -
#136
egészen pontosan erről beszltem. azért a CRAY nem gyárt szemetet.
ezzel sztem az AMD megkapta azt a kis hátszelet, amire szüksége volt.
az AMDvel kapcsolatos hangulat alapból eléggé pozitív volt, már csak ha arra hondolunk is, hogy amikor bejelentették ennek az utolsó télleg elég pocsék negyedévnek az eredményeit, 25%ot emelkedett az árfolyam(vagy most 1 hete) csak a vezetők ígéreteinek hatására, most meg ez a CRAY ügylet is dobott az értékén 26%ot... hát AMD részvénytulajdonosnak szerintem soha jobban nem érte meg lenni, mint az elmúlt 1 hétban... több, mint 65%ot emlkedtek a részvények, és felfelé mennek. -
Rive #135 Amíg a marketing (és a konferenciákra szóló kedvezményes jegyek) mondják meg a cégvezetésnek a rendszer típusát, addig nem lesz megszorítva az MS.
Az IBM és a SUN támogatása nagyon sokat jelent a Linuxnak, de ne felejtsük el, hogy a mostani fellendülés észlelése után hogy összekapta magát az MS... Igaz, hogy pár évnek el kell telnie, mire a kitűzött céljaikat megvalósítják, de utána - talán - valóban egyenrangú lesz a két rendszer.
Azt remélni, hogy az MS-t ki lehet irtani a számítástechnikából, csak álom. Én már azzal is megelégednék, ha valóban minőségi és igényes munkát végeznének, kompetitív piacon.
-
Rive #133 Megfelelő meghajtókkal miért ne menne? Pláne, hogy már eleve többféle sebességre tervezték, és eleve nem kapcsolat-, hanem üzenet alapú rendszer.
A sebessége ilyen esetben biztosan nem lesz akkora, mint egy PCB-n belül, de a jelenleg használt megoldások sebességét el lehet vele érni...
SUN, IBM: AZ MS-t egyenlőre nem lehet megkerülni. Erős a marketingjük, és az IT piac fellendülése miatt túl sok klikkelgetős rendszergazda szabadult a világra: a csicsás asztalt még sokáig el lehet majd adni.
A jelenlegi SUN, IBM rendszerekből SZVSZ nem sok fog egy az egyben átkerülni open-source-ba: ez legalább akkora bonyodalmakat kavarna, mint ha az MS hozná nyilvánosságra a source-ot :)
Inkább arról lesz szó, hogy 'kölcsönadnak' néhány programozót, és azok majd jól belefejlesztenek a Linux-ba - véletlenül éppen a saját OS-ük tudása alapján :D -
#132
RIVE:
igazad van, az ethernet kicsit hülyeség volt, csak arra akartam célozni, hogy a HT semmiképpen sem megy át 1 nyákról egy másikra.
szted mi lesz a SUN és az IBM nagy linuxtámogatásából,
a SOLARISBAN, meg az AIXban iszonyatos technológiák vannak, amik ha belekerülnének a linuxba, akkor az MSnek nem maradna hely a szerverpiacon... meg az IBM és a SUN kénytelen lenne egy levegőt szívni, sé az elég snassz lenne...
de szted mit fognak kiadni a rendszerükből open-source-nak? -
Rive #131 Ne téveszd össze az alapvetően szoftveres alapokon nyugvó clustereket a szorosan csatolt memóriamodellel működő multiprocesszoros gépekkel. A hálókártyás megoldás csak a clustereknél dívik, a komoly gépeken a processorok összekapcsolására kis késleltetésű célhardvereket használnak. Ca. olyanokat, mint a HT. Ha picit nagyobb a távolság, akkor néhány spec. vonalmeghajtóval és jelhelyreállítóval megfejelve.
A távoli, lassabb elérésű memóriák kezelésére természetesen dolgoztak ki megoldásokat, hiszen ez a probléma nagyobb gépeknél már régebben is felmerült: azonban ezek a megoldások nem PC szintűek, és az áruk is igen borsos.
Pl.: a SUN Solaris a processzorok számának növelésével közelítőleg lineárisan skálázódik, és állítólag valami hasonlót tud az MS-féle '2000 Datacenter Server is...
Ez utóbbinak az árát nézd meg :D -
Rive #129 Az a 48 bit elég érdekes dolog. Ennyit tudtak a régi 32 bites processzorok is, mármint ami a logikai címteret illeti. Ez tehát inkább a teljes elérhető globális címtérre vonatkozó adat lesz, nem pedig az egyes processzorokhoz kapcsolható lokális fizikai memória maximális mérete, ami az integrált memória-vezérlő képességeitől függ.
A globális címtér már sokkal érdekesebb dolog. Ott lehet szép dolgokat művelni :D
A következőkre még nem találtam semmi világos leírást, ugyhogy ezek egyike sem _biztos_, csak nagyon valószínűnek és logikusnak érzem - majd kiderül, ha jönnek a többprocesszoros Hammer-alapú rendszerek...
Szóval: a HT csomópontok felépítése számomra nagyon gyanús: 3 HT link, plusz saját címtér. Ez valamiféle asszociatív módon vezérelt útválasztásra utal, message-passing alapokon. Azaz: ha befutott egy memóriaelérési igény a csomópontba, akkor az megnézi, hogy merre kell továbbítania, vagy éppenséggel helyileg kiszolgálható-e.
Ha így működik a dolog (ismétlem: ez egyenlőre találgatás, bár logikusnak és egyszerűen megvalósíthatónak tűnik), akkor semmi akadálya, hogy két Hammer-oktetet speciális HT csomópont segítségével közös címtérbe integráljunk. Azaz teljességgel felesleges mindenféle hálókártya, a HT önmagában biztosítja a fürtök összekötését.
Ami ezzel az elrendezéssel gond: a távoli memóriák elérése a processzorok számának növekedésével arányosan lassul, és túl sok processzorra kiterjesztett címtér esetén dugók alakulhatnak ki a csomópontokban. Ezt elég jól ki lehet küszöbölni, ha az operációs rendszer figyel arra, hogy pl. minden reentráns kód ugyanazon a processzoron fusson, a saját adatterületeivel egy fizikai memóriában...
Ez azonban egyáltalán nem triviális feladat, a PC kategória oprendszerei között nem tudok olyat, amin ez megfelelő módon implementálva lenne: eddig nem volt rá szükség. Linuxon viszonylag könnyen menne, de eddig az igénye se merült fel a dolognak, az eddigi PC-s SMP-k főleg közös fizikai memóriával működtek.
Valószínűleg emiatt nem forszírozzák a Hammerek n>8 processzoros összekapcsolását: ekkora méretekben a probléma még nem okoz jelentős lassulást, pláne, hogy először csak a ClawHammer jön ki a maga dual-képességeivel. Mikorra pedig eljutnak a többprocesszoros rendszerekig, már meglesz hozzá a támogatás is, meg a HT2... -
Supergamer #127 "Ugyanígy jártak az IDE csatoló címzési lehetőségeivel: már nem tudom számon tartani, hány változtatás volt a szabványban a nagyobb elérhető lemezterület érdekében."
Itt az utso 2
Ata - 100 137GB
Ata - 133 144PB (Petabyte) -
Rive #126 Az abszolut freki fejlődése az elmúlt év elején/közepén volt _igazán_ gyors: amikor az AMD a piacon is megszorította az Intelt az 1.4-es Tbirddel. Ha az akkori pár hónap alatti gyorsulást vetíted ki az említett időszakra, akkor már nem is olyan gyors az a 400-ról 2200-ra :D
Sajnos (?) a gyártók észbekaptak, hogy ez nekik nem jó: le is lassult a dolog, az Intel sem jött ki olyan gyorsulással, mint amekkorára lehetősége lett volna... (Ezidőtájban ők - elméletileg - minden gond nélkül ki tudták volna adni a mai .18-as p4-ek csúcsprocesszorait - de nem tették).
Memória: a CPU címterébe a PCI-n ülő kártyák saját memóriájának is bele kell férnie, valamint a swapfile-nek is. Ez így együtt már ma bőven elérheti a 4G+-t, bár egy részének elegendő a jóval nagyobb logikai címtér. Többprocesszoros rendszer esetén nagyobb a memória is: ha bejön a Hammer, akkor fel kell készülni extrém esetekre is: pl. 8 hammer egy címtérben, darabonként 1G memóriával, plusz swap, plusz PCI :D
Mivel egyre inkább az a tendencia (és a gépek teljesítménye már lehetővé teszi), hogy az asztali PC-kben is szerverekhez való oprendszereket futtatnak, a processzoroknak fel kell készülniük a nagy címtér kezelésére.
A másik ok, hogy a gyártók előre terveznek: a jövő szabványai a mai gépekben jelennek meg először. Amikor a 386-ban kialakították a 4G memória-címteret, mindenki csak legyintett. Mára már néha szűk :D
Ugyanígy jártak az IDE csatoló címzési lehetőségeivel: már nem tudom számon tartani, hány változtatás volt a szabványban a nagyobb elérhető lemezterület érdekében. És eddig majd' mindegyiket kinőtték pár év alatt... -
#125
enterprise:
jött 1 döntő momentum, ami eddig még csak halovány reménysugár volt, de most, mintha egyre erősebben világítana:
talán a SUN fog low-end szerver piacra, oda, ahová az itanium is készül HAMMER alapú gépeket árulni a sajátja helyett, és lehet, hogy PC!!!ket is fogy majd gyártani. és ha SUN ottvan a HAMMER mellett, akor valóban döntő szerephez juthat a teljesítmény, mert a SUN név elég lesz az AMDnek,(megkockáztanám, hogy jelen pillanatban a SUN kb. akkora név, mint az IBM, vagy talán nagyobb is) és akkor valóban előjöhet a 8itanium vs. 8 SledgeHAMMER előny, és az HAMMER is betörhet a szerverpiacra. -
#123
enterprise:
talán olvasgass angol siteokon, mert az AMD BEMUTATTA, AZAZ ÉLŐBEN MINDENKI ÁKLTAL KIPRÓBÁLHATÓ FORMBÁAN KIÁLLÍTOTT 10 DB COMPAQ GÉPET 2.2 GHZ AZAZ 2800+ FREKVENCIÁVAL!!! ez nem ígéret/nemígéret, ez a valóség. és ez még csak az 1. stepping próbagyártása, még erre jönnek későbbi steppingek, és még jön a SOI, és akkor jön a HAMMER...
ja, és a 10 gép teljesen szabványos compaq gép volt, még csak extra venti sem volt bennük.
4 Gbyte+memória:
nagyon sok olyan doog van, amihez nem kell nagy CPU, de sok memória igen. pl. adatbáziskezelés. lehet, hogy van olyan hely, ahol kevés a tranzakció de nagyonnagy az adatállomány, és akkor máris jól jön a 4 Gbyte... ja, és azt sem kell belepakolni, csak belelehet... mert mint tudjuk, az intel is elkezdte eröltetni a 8 Gbyteos P4eseket... és vannak, akik veszik... hiába sokkal lassabb, mint 1 sima 4 Gbyte-os(a 36bites címzés és a 64bites adatbusz esete miatt) mégis veszik, mert kellhet a 8 Gbyte, erős CPU nélkül is. -
#120
enterprise:
ha esetleg nem lenne új windows:
akkor is ki lehet használni a HAMMERek által támogatott max. 16 Gbyte memóriát, mert a windowsok 36bitig, azaz 64 Gbyte-ig támogatják a memóriacímzést. a nagy különbség ott lesz, hogy ugyan a mai pentiumok is támogatják a 36bitet, de 1 36bites cím lefoglalja az egész 64bites adatbuszt. a Clawhammernél meg átmegy egyszerre 2 36bites cím is a 64bites buszon, a SLEDGEhammernél is átmegy 4!!! és ugyanez vonatkozik az utasítás-vezérlőbitekre, tehát ha 32bites módban használjuk a procit, akkor is tudunk mindent használni, ami kell. arról meg nem is beszélve, hogy a program olyan részeit, amikben nincsenek rendszerhívások, lehet 64bitesre fordítani, még 32bites oprendszer alatt is. csak itt nem lehet dinamikus helyfoglalást alkalmazni.(azaz a te kedvedért: pl. a new parancs a c++ban nem használható) (na azért ennyire em egyszerű a dolog, csak te eléggé programozókinézetű vagy(nem sértés volt) így tudtam neked a legjobban elmagyarázni)
tehát ez sem gond
és el kell ismerni, hogy az AMD most nagyot hasított a 2.2 Ghz-s throughbred magos athlonnal... 2.2 Ghz 0.13 mikronon... ez majdnem annyi, mnt a mostani p4esekből kifacsarható max. , ami most 2.4 Ghz. és ez a 2.2 Ghz-s athlon áprilistól kapható lesz. ja, és gondolom, nem vitás, hogy a [email protected] Ghz-s P4eseket is halomba veri... -
Rive #119 Mir: _természetesen_ függ még mástól is: viszont ez a megközelítés kiforrott rendszerek esetében elegendően pontos. Sokan az eddigieket se fogták fel, én meg nem akarom hosszas magyarázatokkal elfedni a mondanivalóm lényegét, mint ahogy ez másoknál szokás.
Egyébb: a piac kéri ugyan a gyorsabb processzorokat, de a kormányrúd a chipgyártók kezében van. Ha őnekik nem éri meg túl nagy ugrásokkal haladni, akkor nem sietnek: a sietség drága. Sietni csak akkor éri meg, ha muszáj, pl. erős a konkurrencia.
Azt írod, 4 évvel ezelőtt a 200/400 volt az arány.
Akkor mi változott? Az arány ma is stimmel, és a RISC-ek ma is gyorsabbak, mint a CISC-féleségek. A CISC-ek 'gyors' fejlődésének ellenére :D
-
#116
XXL:
az intel valóban bemutatott 1 3.5 ghz-s P4et tavaj, csak nitróval ment.
idén bemutatott 1 3Ghzs- P4et, léghűtéssel... csak mondjuk 2 táp volt a házban, és az egyik csak a 16 ventit táplálta, és az a 16 ventillátor 1 olyan csövön át kapta a levegőt, amelyek feltehetőleg hideg levegőt szolgáltatott neki. bemutatott 1 4Ghz-s P4est is, csak az megint nitrós volt... ennyi az intelről.
azt nevetségesnek tartom, hogy valaki össze akarja mérni a p4es, és a POWER4est... mondjuk úgy, hogy nem lenne fair... mint 1 Mazda 323 1 F-55össel szemben... lehet, hogy az órajel magasabb, de a power4esnek(nem vagyok benne biztos, nem igazán vagyok PPC szakértő, de mintha ilyesmit olvastam volna) van 8integer, 8 FP, és 2 IF-unitja...(1 magban... és 1 prociban 2 mag van...) ezt még jóindulattal sem nevezném P4 versenyképesnek(2 int, ami effektíve 4, meg 1 FPU, meg 1 MMX, meg 1 SSE... de azok SIMD egységek, kevés dologra lehet igazán jól használni őket) tehát ez nem 1 okos dolog.
RIVE:
nem szeretnéklek kritizálni, mert nálam 1 kicwsit sokkal jobban otthonvagy a témában, de az, hogy az órajel adott csíkszélességen csak a pipeline hosszától függ, nekem 1 kicsit durva kijelentésnek tűnik. pl.:
ITANIUM I 11lépcsővel 833 Mhz
ITANIUM II(alias McKinly) 7lépcsővel 1.2 Ghz-en kezd... szintén 0.18 mikronon.
na mind1.
enterprise : "A Microsoft soha semmit nem fejlesztett bejelentes nelkul, es legallab .5 vagy 1 evel elobb bejelenti a dolgokat, az x86-64 "...
hát te biztosan nagy M$ fan vagy, ha ekjkora faszságot van képed mindenkinek a képébe hazudni... nem emléxel??? a .NET 3 évig titok volt... -
Rive #115 Még egyszer: technikai akadálya nincs, hogy megtervezzenek egy 2+ GHz-s, 64 bites RISC procit. Az ok egészen pontosan ugyanaz, ami az Intelt megakadályozza a gyorsabb procik kiadásában: csak és kizárólag a piac. Ha az Intel kiadná a gyorsabb processzorait, akkor pillanatnyilag biztosíthatná ugyan a dominanciáját - azonban annak az időszaknak a profitját kidobná az ablakon, amig a jelenlegi ütemmel eléri ugyanazt az órajelet.
Ha nagy lépésekkel gyorsítanák az iramot, akkor a közbenső lépésekért beszedhető profittól elesnek.
Viszont, ha csak kisebb lépésekkel haladnak, akkor az adott architektúrából eladott mennyiség a profittal együtt magasabb lesz: a tervezési költségek nagyobb darabszámon oszlanak meg.
Teljesen ugyanezek a jelenségek működnek a 64 bites piacon is. A már bejáratott árukkal rendelkező szereplők egymással szinkronban dobják piacra az ujabb termékeiket. Amikor megjelenik az Intel az Itanium-féleségekkel, és bevallottan ki akarja szorítani a többit, akkor az 'öregek' hirtelen áttervezik a procikat, jön egy többlépcsős pipe - és ma a 6-7-800 MHz-es architektúra komolyabb újítások nélkül rögtön 1.2 GHz-vel megy.
Ez a sebesség jelenleg több, mint elegendő az Intel IA-64 processzoraival szemben: és .09-ig elég is lesz.
Gyakorlati oldal: egy RISC ütemezőnek teljesen tökmindegy, hogy 64 bites regisztereket vezérel, vagy 8 biteseket. Az ALU órajele ismét csak a pipeline hosszától függ.
Az összes mai gyors CISC belsőleg RISC - az ottani ütemezők minimális változtatással alkalmazhatók lennének 64 bitre. Ezt használta ki az AMD, valamint megspékelte egy igazán ütős memória-kezeléssel.
Más: Szerintem hagyd abba. Az AMD jelenleg jobban tartja magát az ütemtervéhez, mint az Intel, és az sem semmi, hogy a Hammer első legyártott példányai képesek voltak oprendszer bootolására. Az első tesztek megérkezése valószínűleg már csak hónapok kérdése - majd utána döntsd el, hogy mi lehetséges, és mi nem.
-
Rive #113 Hoppá, nem jelentkeztem be. De az előző hozzászólás az enyém. -
Rive #110 Ha egy mai RISC 1GHz-n tud annyit, mint a P4 2+ -on, akkor mi szükségük lenne extra gyorsításra? Megmondom: semmi.
Egyébként: a CISC futószalagok fele azzal foglalkozik, hogy a túlbonyolított utsításkészletet kibogozza, meg az ezerféle címzési módnak megfelelően alőbányássza a hivatkozott adatot. Emiatt késett éveket a tisztességes HW prefetch és a többszálúság támogatása a CISC procikban, míg a RISC-ekben ezek már régen használt technikák.
Az X86 abból él, amit a RISC berkekben már kidolgoztak. Amint elegendő tranzisztort rá tudnak zsúfolni a lapkára, azonnal megpróbálják alkalmazni a RISC megoldásokat: de az X86 fejlesztések eddig csak minimális hozzájárulást adtak a processzor-technikához. Az AMD-féle integrált memóriavezérlő+HT talán az első ilyen.
Még egyszer: a működési frekvencia adott vonalvastagságnál csak a pipeline hosszától (valamint az egy lépcsőre jutó feladattól) függ. Ha valaki lenne olyan hülye, hogy egy US procit megtervez 20 lépcsős pipeline-val, akkor az a proci menne 2+ GHz-n.
Szerencsére nincs ekkora barom a földön, vagy legalábbis nem bíznak rá procitervezést: a K7-es sorozat azért tudja kisebb órajelen produkálni a P4 teljesítményét, mert például rövidebb a pipe.
Egyébbiránt tele a tököm az elvadult szoftveresekkel, akik az első sikerrel összetákolt program után azt hiszik, hogy értenek a processzorok fizikai architektúrájához is, és nekiálnak olyanokkal vitatkozni, akik HW tervezéssel (is) foglalkoznak. -
Supergamer #107 Megyeszer megkerlek sulinetes baratom, hogy jatszal massal.Ha mar egyszer a nevemet hasznalaod akkor a stilusodon valtoztass egy kicsit.
az 106-tol es a 103-tol ismetelten elhatarolodom es elnezest ezert a szerencsetlen emberert.. -
Supergamer #106 Hogy mered az én azonosítómat használni ! Takarodj innen faszkalap ! -
Supergamer #105 Hat ide is idetalaltal, te szerencsetlen.Ennyire kisebbsegerzeted van, hogy nem mersz a sajat nevedben irogatni?Bar amilyen jellemtelen vagy ezen meg se lepodom.
Megoldhato lenne ennek a hibanak a kijavitasa?Vagy legalabb egy kulon resz minden hozzaszolas utan, hogy melyiktol haratolom el magam.Mint pl most az 103tol. -
Supergamer #104 "a minősítgetéssel meg illene legalább az első teszteket megvárni"
Nekem annyi is eleg lenne amennyit mondanak, + 30% az azonos orjelu XPkel szemben.Plusz egy normalisabb 64 bit.(memoy controlle, northbrdige)
Persze nem kell vilagcsodat varni, de kezdetnek szerintem ez eleg is lesz mindenkinek.. foleg ha ehhez tenyleg normalis ar is tarsul. -
Supergamer #103 A lényeg hogy a tuti az Itanium. Mindenki ilyet akar venni csak még drága. Fél év múlva ilyen lesz az otthoni gépembe, bibííííííííííí -
Rive #102 Természetesen lehet 64 bites architektúrát úgy megvalósítani, hogy az 2+ GHz-n menjen. Az elérhető maximális frekvencia ugyanis a pipeline hosszától függ (illetve a gyártástechnológiától is, de azt most hagyjuk: ha .13-on maradunk, akkor csak a pipeline a meghatározó). A többi 64 bites proci RISC alapokra épül, ahol a megkívánt teljesítményt kisebb frekvenciával is el lehetett érni: nem növelték az egekbe a futószalag hosszát.
A hammer az első CISC alapú 64 bites proci: a minősítgetéssel meg illene legalább az első teszteket megvárni, még a keményfejű Intel-fanoknak is. -
#98
"A Hammer fnatasztikus 32 bites proci lessz, de a 64 bites resze nem lessz kihasznalva es el fog veszni a piacon - roviden 32 biten fogjak hasznalni 99%."
na most nem tudom, de ha a 64bit-es mód használata számítási teljesítményt okoz akkor bíztos, hogy sokkal több program készül... -
Supergamer #96 "és az AMD talán nem egy p100 as teljesítményével (x86-on) eggyez? processzort fog
kiadni."
Ez igy is van, a marketing duma es a hirlevelek alapjan 30%-ot ver a sajat procijaira x86-on azonos orajelen az AMD.Ez (szerintem) elismeresre melto, ismerve a proci amugy sem gyenge szamitasi teljesitmenyet. -
Turmoil #93 Csak egy apró megjegyzés, hogy melyik cégnek milyen tapasztalata van/lehet.
Pld. az M$ az NT kernelt nem sajat tapasztalatából fejlesztette, hanem valahogy begyűjtött egy-két jó arcot, akik megcsinálták. Talán ismeretes, hogy a fő ideológus korábban egy VMS nevű oprendszer fejlesztésének volt meghatározó alakja.
Az AMD is vett egyrészt busz-licenszt (EV6, ha jól emlékszem, ezt használják az Athlonok/Duronok), és hasonló módon tudást is szerzett a megfelelő agyak begyűjtésével. Megjegyzésem ezzel kapcsolatban: jól csinálták ők is.
Szóval felejtendő az a ki nem mondott, de a hozzászólásokból kiolvasható általános vélemény, hogy a cégek (AMD, Intel, IBM, stb...) konstans fejlesztőgárdával dolgoznak.
-
Rive #91 >> de lenyegeben, nem hiszem el azt a reszt ami a 19 MB/s rol szol
Az a rész arról szól, hogy ha egy osztott buszra felpakolsz annyi procit, akkor a processzoronkénti sávszélesség ennyi. Ezt kerülik meg az egyébként általad is említett módszerrel ('particionálás', vagy ahogy én mondtam, 'fürtözés'): a processzorokból csak keveset pakolnak egy buszra (így viszonylag elfogadható sávszélesség az eredmény), majd a fürtöket külön elektronikával kötik össze. Ennek már több köze van a lazán csatolt rendszerekhez: akár egy cluster, csak sokkal gyorsabb (és HW-támogatott) összeköttetésekkel. Ugyanerre viszont a Hammer is képes...
Egyébként maga a technológia nem az AMD-nél merült fel először: csak ők voltak az elsők, akik szilíciumba rakták az oprendszer helyett. Ez sem semmi, nemde?
Az utolsó mondatoddal nagyon egyet tudok érteni - a Hammer _most_ üt, az Itanium meg hosszú távon erős - egyenlőre semmi esélyünk, hogy a meccs végkimenetelét megjósoljuk... -
Rive #89 1. A clustereknél a feladat szinkronizálása, az egyes taszkok kiosztása egy, a gépenként különálló operációs rendszer fölött futó alkalmazás feladata. Igy aztán egy cluster maximum user-szinten tekinthető multiprocessing-nek.
2. A valódi multiprocessing-nél a processzorok mindegyike látja a teljes memóriát: ez a szorosan csatolt rendszerek lényege. Ilyen a Hammer-család is, bár a hardver megvalósításnak van némi köze a lazán csatolt rendszerekhez.
A 2. esetben a legtöbb gondot az okozza, hogy hardver-szinten biztosítani kell a memória-validációt. Ez azt jelenti, hogy mivel több processzor lokális cache-memóriájában is előfordulhat ugyanaz az adat, ezeknek meg kell egyezniük, különben baj van. Ennek a biztosítására külön protokollokat dolgoztak ki megosztott buszra: közös jellemzőjük, hogy amikor azonos memóriaterületről dolgozik a két (több) proci, akkor cefetül lelassítják a buszt. Valamint: a központi memória sávszélességén osztozik az összes processzor. Ezt a vonalat erőlteti az Intel: szimplán, mert nem olyan egyszerű kidolgozni más típusú megoldásokat. Ebben bizony az AMD nagyot dobott. Ugyanakkor az IA64-nél az 512 processzor parasztvakítás: 23M/sec jut egy processzorra, de ebből még lejön a validációra és a busz-kiosztásra forduló sávszélesség is, ami igen tetemes. Jó, ha 10 M/sec jut egy procira... Mint egy 486SX... De az is csak azért, mert maga a proci jobb. Az ennyi processzort tartalmazó gépeknél máshogy fürtözik a processzorokat: nyolcnál többet nem raknak egy buszra - véletlenül éppen ennyi Hammert lehet egymás mellé tenni...
AMD, Hammer: minden processzornak különálló memória-tere van, dedikált sávszélességgel. Mindegyik processzor számára lehetőség van a többi processzorhoz kapcsolt memóriaterületek elérésére, de ez a HT linken keresztül történik, pont-pont átvitellel, lassabban, mint a saját memória kezelése. A HT linkeken csak a memória-validációs adatok utaznak, így nem befolyásolják a saját memória elérését. Azaz: a rendszer HW a legalsó szinten lazán csatoltnak tűnik, de a SW számára szorosan csatolt rendszerfelépítést biztosít. Az effektív memória-sávszélesség egyenes arányban nől a processzorok számával, és a validáció sem lassítja számottevően a rendszert. Meg tudták csinálni, ráadásul eleve gondoltak az adatutak optimalizációjára is.
A 'miért pont az AMD'-féle érveknek igazából nincs súlyuk. Miért pont az IBM? Vagy az Intel? Vagy az MS? Mert valakinek a cégnél eszébe jutott, és megcsinálta. Ennyi.
Igen, a 32 bites Win fut rajta. Ha teljes sebességgel beindul a verda, akkor 3400+ jelzést kap majd a proci. Fizikailag talán 2.4-2.6 GHz, nem tudom. Ehhez mérten már a 64-bites pluginek is csak extrának számítanak... A vadiúj megoldásokat felvonultató ugrás-előrejelzésről, és a branch-miss recovery-ről már ne is beszéljünk...
A vonalvastagság és az órajel között messze nem lineáris az összefüggés. Egy kevesebb lipeline-stage-t tartalmazó processzor kisebb órajelen megy, viszont nagyobb párhuzamossággal, kisebb latency-vel.
-
Rive #87 Multiprocesszoros működés != szuperskalár felépítés. _Nagyon_ nem egyenlő a kettő.
Ai Itanium-féleségek osztott rendszerbuszt használnak, aminél a processzorokra jutó sávszélesség a processzorok számával arányosan csökken. A Hammer-féleségeknél a processzoroknak dedikált sávszélességük van a memória felé, a rendszer össz-sávszélessége a processzorok számával arányosan _növekszik_.
A Hammer magfelülete ca. 110 mm2, .13-as technológiával. Fut rajta windows, legalábbis az anadtech által közölt felvételek alapján. -
Rive #85 >> az IA-64 / x86-64 rol!
Az nekem elég egyszerűnek tűnik. A Hammer nagyon ütős, mind architektúrájában, mind a lehetőségeiben: Sokkal ütősebb, mint a jelenlegi ia64-ek. Mind az Itanium, mind a McKinley erősen (víz-)fej-nehéz: nagy core (-> nagy selejtarány, drága), gyenge multiprocesszoros működés. Az architektúra előre láthatóan akkor válik majd kiforrottá, ha .09-re lemennek a csíkmérettel: azon a méreten a jelenlegi AMD processzorok magmérete kezelhetetlenül kicsi lesz, ugyanakkor az Intel-féle már megfelelő. Ha a PPro esetét nézzük, annak is kellett 1-2 áttervezés, hogy igazán bejöjjön.
Sokkal nagyobb gond az, hogy a szerver-piacon a vasak forgási ideje nem egy-két év, mint a PC-szegmensben: 3-4-5 éves vasak is üzemben vannak, ráadásul (minő pimaszság :D) jól teljesítenek. A szerverek tervezői nagyon idegenkednek a kiforratlan megoldásoktól, a tiszavirág-életű processzoroktól: egyenlőre pedig az ia64 annak számít.
A másik oldal viszont éppen elérte azt a szintet, ahol már számolni kell vele. Sok MP megy low-end szerverekben, valamint mérnöki munkaállomásként is üt: gyűlik a tapasztalat, szűnik az idegenkedés.
Azaz: jelen pillanatban akkora a bizonytalanság, hogy egyszerűen értelmetlen jóslásokba bocsátkozni.
Emiatt aztán az MS voksa sem sokat ér: _mindkét_ rendszert támogatni fogja, mert ők sem tudják, melyik lesz a befutó. -
Rive #83 No!
Nono!
Az a 16-32 bit átállás pont az MS által gyártott szoftverekre fennálló kompatibilitási követelmények miatt volt annyira nehéz. UNIX-alapú rendszereknél ilyen gond nincs, ott az egész rendszermag (ez ugye az egyetlen, aminek dolga van a proci architektúrájával) eleve _csak_ 32 bitesre van írva: az alkalmazások pedig futhatnak a 32 bites részen. Ugyanakkor az _igazán_ nagy szerverek között nem arat az MS láz...
-
Supergamer #78 Ha abbahangynak vegre a nicklopast annak nagyon orulnek 62, 63 rol ismet elatarolodnek.A mondat masodik fele egy csomo helyen lemaradt.
Nem lehetne a nicklopas ellen mar valamit tenni SG?
Enterprise:"M$ hivatalosan is bejelentette az x86-64-es windows fejlesztését. "
ezt en is csak alatamasztani tudom... sok helyen olvastam.
Mir: a P4rol meg annyit, hogy a marketingszoveg (bar inkabb eredeti inteles forras) szerint szimplan a magmeret csokkentesevel mindenfele pipeline modositassal el lehet erni a 10GHZ-t.En ennyit akartam mondani, de a mondat fele lemarad, lopjak a nicketeket....stb.. -
#77
fOTEL:
A 64bit nem kihasználatlan, pont ott van, ahol annak lennie kell(memóriacímzés) és a HAMMERnek közel sem csak a 64bit a legfőbb újítása, ottvan még az int. memóriavezérlő, SSE/SSE2(16 regiszterrel) meg még csomó minden, amitől nagy proci lehet. ezt a 64 bitet nem kell azért túllihegni, ez csak valami olyasmi, mint anno a 386osok. (amikor azok kijöttek, 1985ben, azután még 9!!! évet kellett várni arra, hogy házilag is elterjedt 32bites oprendszer jöjjön ki. és még akkor is csak a félig 32bites szar jött...(ala W95...)
Enterprise : te még mindíg nem fogtad fel, legalábbis én úgy látom:a M$ hivatalosan is bejelentette az x86-64-es windows fejlesztését. de ha meggondolta volna magát, az sem lenne baj, mert a windows 2000/XP tud 36bites címzést is(ami 64 Gbyte memória) és a HAMMER pedig már értelmesen támogatja a 32bitesnél nagyobb memóriacímeket(nem úgy, mint a Pentium3, és 4, hogy 1 36bites memóriacím lefoglalja az egész 64bites adatbuszt) tehát még ha váletlenül nem lenne új windows, az sem lenne gond.
ja, és 1 nagyon fontos dolgot kihagytál: az AMd otthoni fronton az utóbbi 3 évben 15%ot hozott fel!!! és ez a tendencia valós, ez van. erre csak 1 lapát lesz, ha még a gépek dobozára rá lehet ragasztani, hogy "64 bits inside" vagy azt, hogy "8th generation 64bits processor for YOU" vagy ilyesmi... ezek scak mégjobban növelni fogják az eladásokat. az AMd eddig sem a szerverpiacból élt, tehát ha esetleg 1 %ot sem tudna szerezni, még akkor sem esne ki semi jöveselme, mert nem költött olyan sokat a SLEDGEHAMMERre, mint az intel az itanium sorozatra. persze az, hogy nem tud részesedést szerezni elég valósztínűtlen. Ugyanis a SUN kijelentette, hogyha PCalapú szervert fog csinálni, akkor is csak az AMD jöhet szóba, az INTEL semmiképp. és a SUN az nagy név... -
#76
Nos én nem vagyok egy nagy szakértő de azért követem a dolgoka és élvezem a tényeket! Márpedig a tények azok, hogy az Athlon és Duron prociai az AMD-nek rendesen odavág az Intel 32Bit-es fejlesztéseinek! (Duron-om van)
Egyébként ezen utobbi írásodból egyértelmüen látható, hogy milyen hatások alatt mondod, hogy a Hammer egy halott fejlesztés!
Amúgy szerintem az Intel legfeljebb a szerver piacon érhet el valamit is a McKinley-vel mert ott valóban nem kell a WinAmp meg a többi, de az asztali gépeknél nem nyerő. S az asztali gépeknél meg ne mondja nekem senki, hogy a 32Bit bőven elég?! Annak idelyén a Microsoft a 64kb-ra mejd a 640Kb rendszer memóriára is azt mondta, hogy ez mindenre elég lessz... márpedig ha kevés lessz a 32Bit akkor csakis egy átvezető proci révén lehet zökkenő mentesen átálni 64Bit-re, s ez a Hammer.
Egyébként miért van az a kényszerkpzete minden Intel Fan-nak, hogy a AMD 64Bit-es rendszerekbe csak annyit tud nyujtani amennyit a Hammer nyujtani tud? Az AMD-nek a Hammer egy átvezető proci s az ezt követő fejlesztései lesznek a valodi, csak és kizárólag 64Bites rendszerei.... -
#74
elágazásbecslésben az intelt csak az nem nyomja le, aki nem akarja(AMD, intel SUN... ezek mind jobbak e téren)
????????????
MIR - egyébként minek venne valaki olyan 64bites procit amiben felesleges a 64bit?