Intel, AMD: 64 bites mikroprocesszorok

Oldal 1 / 3Következő →

Jelentkezz be a hozzászóláshoz.

#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.
#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}
#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)
bociub
#140
Mégis mihez képest?...valószinusitem sose fogod kihasználni az erõforrásait teljes egészében.....

AntiCamper
#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!

www.richardburns.atw.hu (I. RBR Bajnokság)

mir
#138
te hülye vagy.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#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.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

#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.
#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 😄
mir
#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?

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

#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 😄
#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 😄

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...
#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)
#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 😄
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 😄

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 😄
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...
mir
#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.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#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.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#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...

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

#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 😄

mir
#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...

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

#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.

#113
Hoppá, nem jelentkeztem be. De az elõzõ hozzászólás az enyém.
#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.
#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..
#106
Hogy mered az én azonosítómat használni ! Takarodj innen faszkalap !
#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.
#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.
#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ííííííííííí
#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.
Tomcat.no1
#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...
#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.
#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.


#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...
#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.

#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.
#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 😄) 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ó.
#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...
#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..
mir
#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...

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

Tomcat.no1
#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....
fotel
#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?
fotel
#73
Elbrus2k - ultra poci tavajra ígrve az oroszoktól
mir
#72
mint mondottam, a 64piac eddig nem azért volt olyan zárt, mert aki csak 32bites gépet vett, az nem akart 64bites gépet, hanem azért, mert annak, aki 32bites gépet vett, nem volt pénze 64bites gépre. mivel a HAMMER 64bites, és olcsó, valószínűleg meglehetősen ki fogja bővíteni a 64bites piacot. nem csak a régi vevők lesznek, hanem az újak is, akiknek jól fog jönni az a 64bites rendszer, de mondjuk eddig nem volt pénzük 1 komolyabb pSERIES gépre. erre nem reagáltál, csak azt mondtad, hogy annak, akinek eddig is volt 64bites rendszere, annak ezután sem hammer lesz. bár ebben sem lennék biztos.
arra sem reagáltál, hogy 8 hammer mellet 8 McKinly magos itaniumII minden valószínűség szerint elbújhat majd a gazba.(csak annyit mondtál, hogy valóban a 8+ procis épek dominálnak a szerverpiacon, de ezzel senkinek semmi újat nem mondtál...)
nem lesznek 8procis hammer alapú gépek???
hamer alapú gépet gyárt majd a compaq, az IBM, a Gateway, és még talán a SUN(!!!!!!!!!!) is. ezt nem nevezném senkinek sem. az IBMnek 8procis verziója is lesz, az biztos.
várom a válaszod.

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#69
az AMD nem érdekel senkit???
tudod ha van 2 vaci új rendszer, akkor azok között nem csak a név számít, hanem az is, hogy az egyikre van 100000000000 program, a másikra meg vagy 100, meg hogy az egyik 10*annyiba kerül.
és arra még mindíg nem válaszoltál, hogy mit gondolsz a 8 McKinly vs. 8 HAMMER kérdésről, pedig nagyon érdekelne, hogy ebbe hogyan tudod belemagyarázni, hogy az osztott rendszerbusz az egyetlen út, mert az osztott rendszerbuszon kívül nincs is más megoldás, mert az osztott rendszerbusz überkirály, mert intel.
a POWER4et nem nagyon kellene összwehasonlítani a McKinlyvel, mert a McKinly akármennyire is jó, a POWER4 azért még mindíg gyorsabb. meg ha olyan nagy koponya vagy, akkor azzal is tisztában leenél, hogy a teljesítmény nem egyenesen arányos az órajellel.
bár te biztos jobban tudod.
az AMD mitkereshet az ulttrakonzervatív 64bites piacon?
kik voltak eddig a 64bites piac??? akiknek volt rá pénzük. azzal, hogy az AMD olcsóbban is elérhetővé teszi a 64bites megoládását, nem a mostani 64bites piacra akar betörni, hanem kibővíti azt a saját vevőkörével, akiknek eddig nem vlt pénzük 64bites rendszerre, de most meg még olyat is vehetnek, ami rendesen a falhozvághatja akár a nagygépeket is.
a specint egig csak az int számításokat méri. én erre nem alapoznék. csak azért nem, mert a mai programokban sokkal hangsúlyosabb szerepe van az elágazásoknak, azelágazásbecslésnek, a cache-használatnak, és a ciklus-kezelésnek. ez utóbbiban mind a 2 proci elég jó, a cache-kezelés meg eléggé titkolt algoritmusok alapján megy, (meg az McKinlynek előreláthatólag 3*annyi cache lesz, mint a SLEDGEHAMMERnek)elágazásbecslésben az intelt csak az nem nyomja le, aki nem akarja(AMD, intel SUN... ezek mind jobbak e téren) az IF egységek, emg egyértelműen az IBM felé billentik a mérleg súlyát, ugyanis nekik 2 van belőle. de ha nem 1 mérőprogrammal, hanem valami értelmes szerverprogrammal hasonlítanád össze a power4et a McKinlyvel, akkor sokkal jelentékenyebb különbséget tapasztalnál.
ja, és nemtom, honnan van neked McKinly teszteredményed? az a proci 1 7pecsétes titok, és még a fejlesztői verziót sem küldték ki a nagyobb cégeknek...bár neked biztos van szabadbejárásod az intel laborjaiba, és ott kedvedre tesztelhetsz mindenféle processzorokat, annyit, és akkor, amikor csak akarod. vagy ha nem, akkor csak talán nem a hasraütéses módszer választottd?

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

mir
#67
ammegmi?

When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

fotel
#66
MIR - jól szóltál, tudtam én hgoy tudnak az oroszok

apropó Elbrus 2000 ?😊
Nem is volt, nem is lesz?
mir
#65
hát ez nagyon egyszerű dolog holmes: az alpha a COMPAQ procija, nem a HPé, és ajkármennyire is szeretnének, az egyesülés még nem történt meg, ennélfogva a HPnek nincsen semmi köze a COMPAQ dolgaihoz. ezért nem a HP, hanem a COMPAQ állította le az alpha fejlesztéseket.
ja, és még nem állította le, mert továbbra is folynak, csak bejelentette, hogy 10 éven belül abbahagyják.

P4:
a P4 órajele sosem lesz 10 Ghz, ezzel a maggal olyan max. 4.5 Ghz-ig lehet elmenni komolyabb változtatások nélkül. idén 2.8 Ghz-ig mennek majd el.(kissé bajban lesznek, ha kijön a 3400+ CLAWHammer) a p4 nagyon hosszú pipeline-al rendelkezik ez az oka annak, hogy ilyen mértékben lehet emelni az órajelét, és ez az oka annak is, hogy az elágazásbecslés minőségére fokozottan érzékeny. és ebben az intel valóban nem a csúcs(sőt...) a P4 másik nagy baja, hogy az a végrehajtóegységei nagyon alacsony szintűek, és 1 művelet elvégzéséhez több órajelre van szüksége, mint 1 HAMMERnek, vagy mint a thunderbirdnek.

az itanium nem szar, csak nem is jó. az architektúra igenis meglehetősen jó, az EPIC utasításkészlet sem szar. csak eddig nem sikerült a megfelelő processzort megtervezni mindehez. bár megvannak ennek is az igen súlyos fogyatékosságai, ami csak úgy, mint a pentiumokat, ezeket is elég rendesen megszivatja majd a többprocesszoros rendszereknél. ilyen pl. az osztott rendszerbusz, ami abban a kategóriában, ahová igyekszik egyszerűen példa nélküli. nagyon elmaradott, ez van, sajnálom. a másik az, hogy eem osztani, sem gyököt vonni nem tud, ami a webkiszolgálást ugyan nem nagyon érinti, sőt, a szerver funkciók nagyrészét sem, de pl. a tudományos munkát, és a kódolást jelentékeny mértékben lelassítja. bár ez van, ezt kell szeretni. na mind1

holmes: az itanium télleg tuti, remélem a McKinly végre valami használható mag lesz, mert a merceed kritikán aluli volt, ebben remélem egyetértünk. ha nem, akkor meg talán a következő majd talán... de ez még a jövő zenéje. na mind1. de ez az intelnek nem ad majd okot a egkönnyebbülésre. hiszen gondolkozzunk csak. az itanium 1 marhadrága proci lesz, alkalmazások és optimalizáció nélkül(1 rendes optimalizációhoz min. 3-4 év kell) és mi az előnye? 64bites operanduszok. meg a puszta erő. 1 procival. de ha összerakunk 8 procit, akkor sztem jobban jövünk ki, ha azt 4 alaplapra pakoljuk kettesével, és fürtözzük az egészet(osztott rendszerbusz...😄😄😄) és ez valljuk be, eléggé siralmas megodás. itt viszont az 1 kategóriával alcsonyabb szintű hammer elég rendesen oda tud lépni az intel nyakára: 8 SLEDGEHAMMER 1 alaplapon minden bizonnyal le fogja söpörni a pályáról a 8 itaniumot(még a McKinlyt is) és innentől kezdve már eldőlt a verseny. a mai 32bites szerverek nagy gátját, a 32bites memóriacímzést megoldotta(jólvan, tudom, hogy lehet 36bites memriacímzés is, de ha ezt használjuk, akkor mind a 64bitnyi adatbuszt az a 36bites cím foglalja el, és ez meglehetősen rossz megoldás...) tehát a hammer ezesetbenmegszabadul a memóriakroláttól, és akkor az intel nemcsakhogy sokkal drágább(met ugye nem 1 kategóriáról van szó, és ez az árakban is meglátszik...) hanem teljesítményben is jobbat tud nyújtani. elvileg. persze ahhoz, hogy érdemben lehessen erről beszélni, jó volna, ha mind a 2 rendszer kint lenne már, és lennének összehasonlítások is. a jelen pillanatban hozzáférhető doksik szerint a fenti helyzet a legvalószínűbb, de ez persze még változhat. time will tell...



When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?

fotel
#60
az Alpha fejlesztését a HP nemigen állíthatta le 😉


Supergamer:

A pipleline novelesevel mintahogy a P4-gyel is tettek valoban elerheto a 10GHZ.De mivel az ugraselorejelzes fejletlenebb mint az intelnel


????
#59
A P4..

Egy processor sebessegenek/sebessegkorlatanak novelesere eleg sok fele mod letezik.
Csak roviden egy ketto, pl P4 eseten)

1 lehet noveli a pipeline-t
2 fejleszteni az ugraselorejelzest
3 csokkenteni a csikszelesseget

P4 elsosorban az 1.szamu valtoztatas jellemzo ra.Az ugraselorejelzes nem eppen az erossege, (ebben az AMD vezet, eleg nagy elonnyel).A pipleline novelesevel mintahogy a P4-gyel is tettek valoban elerheto a 10GHZ.De mivel az ugraselorejelzes fejletlenebb mint az intelnel, konnyen megallapithato egy esetleges hibas elorejelzes eseten a teljesitmeny csokkenesi merteke igen csak nagy.

Az ugraseorejelzes mint mondtam talan vilagszinten is az AMD a legjobb, nagyon jol megoldottak, igy ha tovabb novelik a pieline-t (Hammer csalad) nekik kevesebb teljesitmenyveszteseget fog okozni.Masfelol viszont talan az egyik legkoltsegesebb elem a procifejlesztesnel az ugraselorejelzo logika fejlesztese.

Csikszelesseg:ezt ugy nem nagyon kell magyarazni, mert teljesen nyilvanvalo, gyartasi technologia, nm-ben mert tavolsag.
#57
Hi, dearbear!

Ad1.: A p4 architektúra azért, hogy elérhesse a 10GHz-t, nagyon sok mindent feladott. És még így is éppen hogy csak eléri a megkívánt teljesítményszintet, mert a gyártástechnológia az adott csíkszélességen egyenlõre nem engedi meg a túl nagy órajelet. Emiatt tudja egy kisebb órajelen, de jobb párhuzamos végrehajtással rendelkezõ proci felvenni vele a versenyt. Az Intel által hirdetett 10GHz annyit jelent, hogy a gyártástechnológia fejlõdése során a procimagot nem kell újra meg újra áttervezni: elegendõ a jelenlegi core-t kisebb méretben legyártani. Ez a stratégia azonban veszélyes lehet, mert ha így viszonyulnak a dologhoz, akkor nem jut hely a fejlesztésnek, és a folyamatosan öregedõ p4-nek a frissen tervezett vetélytársakkal kell állnia a versenyt.

Ad2.: A szoftverek optimalizálása nem csak annyiból áll, hogy átengedem egy 64bites C fordítón. Át kell írni az ASM betéteket, amik mindig az adott processszorra vonatkoznak: ezek bizony processzor-specifikusak. Ujra kell optimalizálni az adatszerkezeteket, leellenõrizni az adattípusokat.
A Linux-kernelben rengeteg olyan rész van, ami egy-egy adott architektúrához illeszkedik csak. Ezeket meg kell hagyni, és a kód szerkezetének is olyannak kell maradnia, hogy ezeket továbbra is használni lehessen.

Ui.: azért a Linux-kernellel példálózok, mert forrás-szinten csak azt ismerem, ugyebár 😞
#56
Ugyan mar, egy logikusnak tuno gondolatmenetert ki akarna megkovezni, megha Intel fan is vagy? 😊
Mondja ezt neked egy AMD fan 😊...
Oldal 1 / 3Következő →