Helyes.
A 32 bites programok futtatása nem teljesen tiszta. Akkor menni fognak, úgy ahogy eddig is egy 64 bites rendszeren és nem kell hozzá emulátor?
A FreeDOS-nak ezzel vége, kár érte, kiváló ügynök volt

Le az elipszilonos jével, éljen a "j" !!!

Jól hangzik, az x86-ra nagyon régóta ráfért már egy ráncfelvarrás.

Én kérek elnézést!

Az Intelnek néhányszor már bejött, hogy az utasítás-architektúra babrálásával keresztbetegyenek a riválisoknak: úgy fest, régi szokások nehezen halnak ki

Azok a 'legacy' módok jelen tranyósűrűség mellett ~ nulla helyet és bonyolultságot igényelnek. Ha beraknának 8086-tól P1-ig minden prociból egyet extrában, még az se lenne számottevő.

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Ok, de ettől versenyképes lesz az Intel az ARM-mal szemben a fejlődés ütemét tekintve? Attól, hogy ez a tervezésnél meg tesztelésnél hoz pár millió dollár megtakarítást évente?

Ki állította meg az órát? Néha az az érzésem, hogy Magyarországot is Kínában gyártották.

Igen. Alapvetően a 16 bites módot nyírják ki teljesen. A 32 biten a ring0 az oprendszer szintje, ami eltávolításra kerülne.

Nekem azért elég cuki, ahogy az Intel a közleményében nemes egyszerűséggel "Intel(R) 64"-ként aposztrofálja az x86-64 (a.k.a. x64, AMD64) világot.

A tej élet, erő, egészség.

intel totális tévúton, nyolcáz wattos zsákutcában -> van egy ötletünk! új utasításkészlet!!!44

"ugyanitt hazájából elüldözött nigériai herceg aranybányájának tulajdonjogát megtestesítő NFT jegyezhető."

Szerintem megtehetik a keresztlicencek alapján.
Régen sem AMD64-nek nevezték, hanem valami EM64-nek, valamint az AMD úgy tudom a "könnyebb" utat választotta, sok utasítás egy az egyben a 32-bites utasítások 64 bites megfelelője volt és a regisztereket is úgy egészítették ki, ahogy az intel a 16-32bites fejlesztésnél a regisztereket (na jó, + új regiszterek, új üzemmódok, nagyobb címezhető memória). Erősen alapoztak az intelre, más kérdés, hogy az AMD lépte meg és be is jött, mert nem kellett nagyon beáldozni a sebességet a régi programoknál, ami azért akkor nagy előny volt, pláne az Itanium-hoz képest, ami még a natív programokkal se tudta hozni az előnyt, visszafelé meg ha volt is egyes processzorokban kompatibilitásért felelős réteg (amit talán elhagytak később) nagyon vacak volt a sebessége.

arty:
Pentium Pro óta már olyan mindegy mi az utasításkészlet. Ha sebesség kell, akkor meg az ARM is zabál. Az Apple sem az ARM nyers ereje miatt Jani, hanem a nagy memóriasávszélesség és a fixfunkciós egységek miatt (ha már egy kézben van az OS meg a HW, könnyű úgy mazsolázni.)

[ Szerkesztve ]

Le az elipszilonos jével, éljen a "j" !!!

"Az Apple sem az ARM nyers ereje miatt Jani, hanem a nagy memóriasávszélesség és a fixfunkciós egységek miatt (ha már egy kézben van az OS meg a HW, könnyű úgy mazsolázni.)"

Leginkább a fixfunkciós egységek, illetve az egy kézben lévő OS és HW optimalizációk miatt.

Én kérek elnézést!

Én itt inkább arra tippelnék, hogy ezzel megspórolnak pár (száz) millió tranzisztort, így a fogyasztásra is jótékony hatással lesz, valamint egyszerűsödik az architektúra. És mivel van keresztlicense szerződés ezt az AMD is tudja majd használni.

Vagy tudnak plusz energiahatékony magokat benyomni ugyanoda, esetleg több hely a gyorsítótárnak.

Le az elipszilonos jével, éljen a "j" !!!

jah, spórolnak vagy 0.5%-nyi tranzisztort
jah, az AMD is ki tud jönni vele.... egy évvel később

"ugyanitt hazájából elüldözött nigériai herceg aranybányájának tulajdonjogát megtestesítő NFT jegyezhető."

"És mivel van keresztlicense szerződés ezt az AMD is tudja majd használni."
Különösen hogy az x86 architektúra 64-bites része az alapjaiban AMD fejlesztés, amit a keresztlicence keretében az Intel licencel az AMD-től...

Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.

maximum par tizmilliot, egy pentium proban mindennel egyutt nemvolt 10 millio.

Első AMD-m - a 65-ös - a seregben volt...

Ha jól értettem akkor a 32-bites részt is kiszednék. Egy Intel Core már kb 150 millió tranzisztorból állt. Plusz azért ezeknek az egységeknek (16,32,64) együtt is kell működniük, ami szintén ad valamilyen szintű komplexitást. Nem vagyok chip tervező szóval csak tippelek.

De szerintem az egyszerűsítés mindig jó.

Az ARM is dobta a 16-bites támogatást amikor architektúrát váltott (AArch32 => AArch64), sőt az Apple az M1-nél dobta a 32-bites támogatást is.

azert irtam a pentium pro -t, az épp annak esett áldozatul, hogy 32 bites kodra optimalizaltak aztan a 16 bites cuccokat ratyi sebesseggel tudta csak futtatni.
az Intel core emlekeim szerint már 64 bites cucc volt.

Első AMD-m - a 65-ös - a seregben volt...

már a Prescott is tudta a 64 bitet, de a Cedar Mill -nel engedelyeztek is, az még messze nem Core.

Első AMD-m - a 65-ös - a seregben volt...

Húú, lehet, régen volt, én a HT-ra emlékszem, hogy a Nortwood-nál kezdték bekapcsolni.

Le az elipszilonos jével, éljen a "j" !!!

Kevésbé komplex rendszer jobban órajelezhető, gyorsabban lehet ki/be kapcsolni. Vágtatunk tovább a 10GHz felé..

Csíramentes, mosott-szárított belsőség eladó.

Ami mondjuk nem is ártana, mert már elég régóta ígérik és nem lehet mindent párhuzamosítani.

Le az elipszilonos jével, éljen a "j" !!!

Kicsit egyszerűsödik az architektúra, ami egyszerűsíti a tervezést és tesztelést. Az Intel-nél az előző generáció és a versenytárs (AMD) teljesítményéhez képest tűzik ki a fejlesztési célt, amit nyílvánvalóan nem szabad túlteljesíteni sem, viszont papíron akkor is meg kell valósítani, ha valójában az adott keretek (idő, pénz, ár, fogyasztás) között nem lehetséges, aminek a gyönyörű eredménye lett a speculative execution sebezhetőség, persze végülis a teljesítmény utólagos visszavételéből is ők profitáltak, legalábbis nem tudok róla, hogy kollektív perben nagyobb összeget kellett volna fizetniük ezért.
Ebből következően a fogyasztásra nem lesz hatása, mert az is előzetesen kitűzött fejlesztési cél, amit így kevesebb érdemi újítással is el lehet érni.

[ Szerkesztve ]

Ki állította meg az órát? Néha az az érzésem, hogy Magyarországot is Kínában gyártották.

Emulációval elvileg bármit lehet a továbbiakban futtatni. Legfeljebb egy kicsit lassú lesz...

Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.

Tudtommal az AMD64 Windows 10+ amúgy sem hajlandó valamiért már 16 bites programot futtatni.

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Ugy tudom az Itaniumon kivul ezt megleptek a xeon phi-ben is, de lehet hogy tevedek. Ott sok utasitast kivagtak.

[ Szerkesztve ]

Talán ha kidobják a régi dolgokat, akkor hatékonyabban működhet az elágazás becslő, és lehet hosszabbítani a futószalagot. Volt amikor 36 lépcsős volt a futószalag, és amikor jól kiadta akkor gyors volt a Netburst, amikor nem, akkor beesett a sebesség rendesen. Akkoriban nem volt akkora cache, meg DDR5, amivel el lehetett volna fedni a megcsuklást. Reklámozták milyen jó is az MMX, meg az SSE, csak azt nem közölték, hogy külön procedúra, meg várakozási ciklus, mire üzemmódot vált a proci, hogy SIMD utasítást hajtson végre.

Hát amennyiben csak a 16 bites programokat "veszítenénk" el, és cserébe emelhető lenne pl az órajel, akkor szvsz nem nagy áldozat pláne, hogy elvileg virtualizáció útján tovább futtathatóak lennének a programok.
Mert tegyük a szívünkre a kezünket : Hányan használunk még ma is rendszeresen 16 bites programokat a mai modern gépeinken? Már 1999-ben is mikor az első gépem meglett, szinte minden 32 bites volt, a 16 bitre úgy gopndoltunk mint egy régi elavult valami, ami kifutott. A 2000-es évek derekán megkezdtük a 64 bitre áttérést, úgyhpogy így lassan 18-20 év távlatából már talán elengedhetjük a kettővel ezelőtti dolgokat.
(valamint ha jól veszem a 32bites oprendszerek sem tudnának bootolni, de azzal úgyis 3,5GB RAM körül volt a plafon (minden memóriafajtával összesen 4GB) amit meglehetett címezni, szóval ha van minimum 4GB RAMja az embernek akkor már nem is érdemes 32 bitezni; és ahogy észreveszem ma már 16-32GB az elterjedt; a mai RAM árak mellett 16GB alatt nem is építenék gépet, de a 32GB-t, vagy a 48GB-t sem gondolom ördögtől valónak)

Inkább azt kérdezzék miért nincs szobrom, mint azt, hogy miért van...

Semmivel nem fog ettől az órajel emelkedni, vagy semi ami nekünk mérhető (OK, picivel kevesebb tranzisztor). Gondolom a lényeg, hogy a CPU tervezőknek/tesztelőknek egyszerűsödik az élet.

Emlékszem, hogy még 2001-2002 körül olvastam, hogy majd jön a TEJAS mag ami 5GHZ-es lesz, és 2005-re a Nehalemmel meg 10GHZ-en fognak vágtatni a procik.
Akkoriban volt az elektrotechnika tanárnak az egyik órán egy elszólása : "a mai átlag otthoni processzorok 10GHZ körüli órajelen járnak", elnevettem magam, és kijavítottam, hogy majd 3-4 év múlva, de akkor igen.
Ehhez képest eltelt 20+ év, és ugyanaz a 3-4GHZ-es alapórajelek vannak (ok, magasabb IPC-vel) mint amik 2003-2004 tájékán. Sőt, amennyire tudom az 5GHZ ma is csak tuningal van meg, azt meg 2005-ben a Pentium D-jeim is tudták.
Sőt, manapság inkább az van, hogy a baseclockok még csökkennek is, elég összehasonlítani mondjuk egy 10400F-et meg egy 12400F-et.

Mivel nem lehet mindent jól párhuzamosítani ezért igény lenne a magas(abb) magórajelekre is. Szó se róla, örülök neki, hogy 10 év "négymag" (sőt, inkább négy szál) holtpontjáról elindultunk a dinnyésebb irányba (ezt a kommentet is 12 szálról írom), de tudnék neki örülni, ha aztán egy nap mégiscsak birtokolhatnék egy 10GHZ-es processzort (még a tuning eredményeim is messze vannak tőle eleddig)

Inkább azt kérdezzék miért nincs szobrom, mint azt, hogy miért van...

A konzolok korlátozott butított PC-k. Viszont hatalmas előnyük a fix hardver, ami miatt az adott címet csupán egyetlen hardverkonfigra kell optimalizálni, mindenhol ugyanazokkal a driverekkel lehet számolni, így a végeredmény jobban optimalizálható, és hamarabb is elkészül.

Inkább azt kérdezzék miért nincs szobrom, mint azt, hogy miért van...

Egy modern konzol azért eléggé eltér egy PC-től hardverben is. Brutális memória sávszélesség, és közös memória CPU és GPU közt (utóbbi kb. mint modern IGP-k esetén). De nyilván, az hogy a hardver tudása fix, sokat segít a játékot készítőknek, mert pontosan tudod mivel meddig nyújtózkodhatsz. Régeben fontos volt még az, hogy a driver réteg vékonyabb, de ez az overhead gond modern DirectX meg Vulcan estén talán már ritkábban lényeges.

[ Szerkesztve ]

Hm, eggyel utánad írtam az órajel emelésről, honnan tudtad, hogy majd arra (is) akarok kilyukadni? Milyen elágazásbecslőd van?

Inkább azt kérdezzék miért nincs szobrom, mint azt, hogy miért van...

Igen, a fix hardver és a kevés szoftveres réteg az egyik nyitja szerintem a jó teljesítménynek.
A közös memóriánál is, igen GDDR6(?) RAM van a rendes RAMnak is, meg a VGA RAMnak is, ami gyorsabb egy PChez képest, bár az osztott memória nem tudom mennyire jó dolog, emlékszem még a régebbi integrált VGAknál elég komoly kapufa volt. Igaz azok még SSD meg DDR RAMok estén voltak, és a lassabb rendszer memóriá használta végülis a VGA is.
Viszont a 10GB RAM pl aggasztó, nem tűnik soknak, pláne annak fényében, hogy egy mai átlag PC-ben 16-32GB RAM van, és a RAM árak így alakulnak, hamarosan a 48-64GB sem lehet luxus.

Bár mondjuk itt jegyzem meg, nem tudom konzolon hogy alakul pl a Far cry 6 betöltési ideje, de nekem 32GB RAMmal (10400F + RTX3060 12GB), és M2 SSDvel attól kezdve, hogy rákattintok a játék ikonjára, addig, hogy felépítve körülöttem a pályát bent állok a játékban, nagyjából 3 perc telik el, ezt rémisztőnek érzem. (pláne, hogy ekkor van a RAMból 10GB se használva, a VGA Ramból meg 5-6GB). Persze eben benne vannak a kötelezően X ideig a képernyőn maradó feliratok is, de akkor is ne már ... (Az AC : Syndicate is elrabol az életemből 2 percet mire a pályán vagyok, pedig az 2015 novemberi, amikor még aligha szaladgáltak 6 mag 12 szálas procik, meg 32GB RAM, meg M2 SSD az átlag useer gépében, VGAból is a 2-4GB volt a menő)

Inkább azt kérdezzék miért nincs szobrom, mint azt, hogy miért van...

Az ARM a kezdetektől 32-bites volt Amire te gondolsz, az a Thumb üzemmód, amikor 16 bites szavakba voltak kódolva az utasítások (hogy kisebb helyet foglaljon), de az az eredeti ARM-ban benne sem volt, az csak egy külön kiegészítésként jött később. Ráadásul csak annyit tett, hogy máshogy dekódolt, nem másmilyen üzemmód volt (mint mindenféle szegmenses mágia inteléknél).
Szerintem nagy változást nem kell várni, amiket megszüntettek, azok igen nagy valószínűséggel már eddig is mikrokóddal mentek. Valószínűleg csak a tesztelésen akarnak spórolni, ahogy már mások is írták.

Talán ha kidobják a régi dolgokat, akkor hatékonyabban működhet az elágazás becslő, és lehet hosszabbítani a futószalagot.

Csak azt mondd meg, eleve miért lenne bárkinél tétel régi dolgokra optimalizálni az elágazásbecslőt vagy bármi mást?

A 32 előtti világ mindennel (!) együtt belefér a mai procik igen kis szegletébe, és nem az a kérdés, hogyan fusson gyorsabban, hanem az, hogyan lehet lelassítani...

Reménykedni ugyan lehet, de nem, ez a lépés nem fog nagyobb teljesítményt hozni 64-en, senkinek, sehol, semmilyen formában: legjobb esetben ~ közömbös lesz.

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

(valamint ha jól veszem a 32bites oprendszerek sem tudnának bootolni, de azzal úgyis 3,5GB RAM körül volt a plafon (minden memóriafajtával összesen 4GB) amit meglehetett címezni, szóval ha van minimum 4GB RAMja az embernek akkor már nem is érdemes 32 bitezni;

Kicsit okoskodnék. Volt az Intelnek valami PAE (Physical Adress Extension) teknológiája, amivel a 32 bites processzor már 32GB-t meg tudott címezni. A Pentium Pro óta benne volt a processzorokban. A Windows Server 2003 ezt tudta is, meg a linux kernel is támogatta. Az az MS trehánysága volt, hogy XP alatt max. 3.5GB memóriával kellett küszködni.

Csak emiatt nem kellett volna 64 bitre váltani, de egyetértek a többiekkel. A 32 bitet el kellene felejtenünk.

Én próbálgattam a 32 bites 2003-at (úgy rémlik, már az R2-est és nem warez, hanem egyetemistaként kaptam ideiglenes licencet, pár szerepkört telepítve egy az egyben XP volt). Az volt az érzésem, hogy azért is fogja vissza a PAE-t 32 bites XP alatt (úgy rémlik nem volt lekapcsolva csak korlátozva) a Microsoft (üzleti okok mellett), mert sok driver nem is működik rendesen vele. Nekem több kékhalálom volt ugyanazon a gépen 2003 alatt, mint XP alatt, viszont szerveren teljesen stabil volt. Nekem gyanús hogy pl főleg a grafikus kártyák meghajtóival lehetett valami geb@sz.

Le az elipszilonos jével, éljen a "j" !!!

Szerintem a HW-es legacy kukázása a HW és SW platformok migrálását is megkönnyíti. Pl. x86-os Android, ARM-os Win. De a GPU, NN alrendszerek is könnyebben mozgathatók lesznek a HW platformok között.

Ha együtt van többszáz watt kiszolgálására alkalmas táp és hűtés ki lehet pöckölni az órajel maximumot a technológiából egy-egy magra. Erre gondoltam.
Teljes processzorra valószínűtlen, hogy lesz még ilyen, mert a felület/hőforrás egyre csökken és egyre közelebb kerülnek egymáshoz a hotspot-ok. Tehát nem lehet a hőt kellő sebességgel elvonni. Amíg kellő számú inaktív mag van, addig lehet a hőt(terhelést) egyenletesen szétosztani a fizikai felületen, de ez is csak egy kényszermegoldás a magasabb kihasználtság elérésére, mint az első.

A 45nm-es időszakban volt is egy nagy bumm. Core2duo-ban volt rendesen tartalék, hűvösen és szépen is ment, levegőn. Sajnos a Quad és a Nehalem annyival el lett bonyolítva, hogy alapfeszen ill. erős kínlódás árán ment annyit mint a 45nm-es quad.. 1,4V/3,8-4GHz
Szerintem jó helyre lőtték be a "jósok" azt az 5GHz-et, csak a kapkodással nem számoltak mert ezeket a többmagos dizájnokat már nem csiszolták addig, minta duo-t képesek voltak.

Amúgy próbálkoztam annyit ezekkel a vackokkal, hogy már rég nem hiszek abban, hogy a(z önkényesen) magasabb órajel majd több problémát old meg mint amit okoz.

[ Szerkesztve ]

Csíramentes, mosott-szárított belsőség eladó.