Új hozzászólás Aktív témák
-
hapakj
őstag
Hát összesen egy Windows Vista-s WDDM driver van, szóval nincs sok választék
XP-sből van újabb is, s talán Vistára meg Win 7-re fel mennek az XDDM driverek is, de kétlem hogy azokkal menne a DX11 (asszem a DirectX 9Ex DDI-t kell implementálnia a drivernek hogy menjen)
De igazából mindegy is. Manapság a Windows 7 is ugyanolyan sz*r mint a Windows Vista. Win 10-el kéne mennie -
hapakj
őstag
remek
Nekem meg közbe sikerült beszerezni egy PCI-os GeForce FX 5200 és beüzemelni rajta a DirectX 11 runtime-ot és Feature Level 9_1-el működik is
Perpixel Shading DX11-ben GeForce Fx-en:
Sajnos csak Windows Vistával volt stabil valami miatt ez a Geforce FX, de szerencsére Vista SP2-n platform update patchekkel van DX11 is
Szóval már csak le kéne cleanupolnom minden és lassan megy a Vulkan is rajta -
Pikari
veterán
Amikor még a windows fontosabb volt számomra, mint egy darab üres tejfölösdoboz, próbálkoztam azzal, hogy újabb mingwre cseréljem ezt az ősrégi verziót. De valahogy sose akarta az igazságot. Például olyan exéket produkált, amik régebbi windowsokon nem indultak el. Vagy olyan dll-eket keresett a fordított exe, amikről még a google se hallott - vagy misztikus gnu glibc dlleket kellett az exe mellé másolgatni ahelyett, hogy a windowsba épített c runtimeot használta volna. Én pedig az ilyesmi silányságot mélységesen elítélem, és nem akarok kísérleti nyúl sem lenni. Nem szeretem a meglepetéseket sem. Ez a fordítókörnyezet meg már be van lakva mindennel, ami nekem kell. Úgyhogy az elkövetkező mondjuk 15-20 évben pont nem tervezem frissíteni vagy lecserélni. Ha majd az intel akkor is heterogén processzorokat árul, talán megfontolom, hogy írjak valami generikus support kódot ehhez.
-
hapakj
őstag
Ahogy nézem, windows 10 és fölötte [link]
De mindent le lehet kérni tőle, amiket írtál. Még ahogy nézem azt is meglehetne oldani, hogy az AMD féle chipletes design esetén külön adja vissza az egy lapkára tartozó magokat.
Konkrétan volt kollégák már írtak úgy kódot, hogy a HT ne zavarjon be és az ütemező mindig csak egy taskot rakott egy fizikai magra.
-
Pikari
veterán
Kézzel ki kéne gyűjtened, hogy az oprendszerben melyik mag melyik nagy fizikai magot, kis magot, HT szálat takarja, minden egyes biglittle intel processzorhoz, és cpuidet hívkodni mindenhez mindenféle obskúrus alig dokumentált dolgokat figyelve, remélve, hogy nem fagy le sehol, nem rakják át kicsit máshova az infót, vagy formázzák egy kicsit máshogy... aztán egy crossplatform függvényt írni ifdefekkel tele, amivel ki tudod választani, hogy a folyamataid/szálaid hol fussanak attól függően, hogy épp mi az, amit futtatsz a programodon belül, majd ezt a programod minden funkcióhoz kiméregetni, hogy ez mikor mit eredményez. Aztán három hét múlva, a következő kernel verzió megjelenésével kezdheted előről mert máshogy fog ütemezni, és a profiljaid kontraproduktívak lesznek a teljesítmény és a fogyasztás tekintetében.
Te meg épp a tamagocsi programodhoz írod az etetést és a szaratást, és nem fog érdekelni, hogy az intelnél mire gondoltak a költők.
Szóval ez egy elméleti lehetőség, a gyakorlatban nem lehet megoldani.
-
csendes
addikt
Ez a stílus amivel a programozók saját magukat szigetelik el. Ha valaki valamit kérdez, annak az az oka, hogy nem tudja, de érdekli. Erre az a válasz, hogy mi már a kérdésből tudjuk, hogy nem értesz hozzá, nem fogja a csapatmunkát előrevinn, mivel ha tudná, nem kérdezné. Ami külön felháborít, az a "miért erőlteted", ha valaki próbálkozik, hogy valamit megértsen. Mindenki elkezdte valahol.
Pár perc kereséssel vannak megoldások a cpu szálak kiválasztására, például Process Lasso Windows-ra, systemd linux-ra. Az előbbi ilyeneket tud
CPU Affinities
Set permanent CPU affinities so that processes run on the desired set of CPUs every time they launch.
CPU Sets
A ‘softer’ form of CPU Affinities that are more like preferred cores.
Priority Classes
Set permanent CPU, I/O, and memory priorities so that processes run at the desired priorities every time they launch. -
cucka
addikt
Ezen felül - olyat tudsz csinálni, hogy az oprendszer ütemezőjének javaslatot teszel, hogy egy processz melyik magon fusson. A processzeknek van prioritásuk, az ütemező ezt is figyelembe veszi.
De teljes kontrollod nincs efölött, ez az oprendszer dolga.Azt amit elképzelsz, azt úgy lehetne megoldani, ha az oprendszer nyújtana erre szolgáltatást, amit jelenleg nem nyújt.
Ezért van a probléma ezekkel a hibrid intel procikkal. Fut vagy 200 processz a gépen egy időben, és az ütemező nem mindig találja el jól, hogy a játék amit futtatsz az melyikre legyen kiosztva. (Ja és ugye nem csak a processzeket kell kiosztani, egy processzen belül lehet sok thread, azt is. Ráadásul hatékonyan. Szóval ez nem egy egyszerűen megoldható probléma)
-
Értettük elsőre is, hogy nem értesz hozzá, nem kell elismételni
![;]](//cdn.rios.hu/dl/s/v1.gif)
A szálak indítása, leállítása, ütemezése dinamikus dolog, nem fordítási időben dől el, ergó a compilerrel ez ügyben nincs igazán tárgyalnivaló. Nem is értem, hogy miért erőlteted ezt.
Ez pont olyan dolog, amit futásidőben a kód letárgyal az ütemezővel. -
csendes
addikt
Ok, megfogalmazom újra, hogy egy programozó is megértse: amikor a forráskód egyes elemeit fordítod, akkor nem lehet megadni, hogy ez most melyik szálon fusson majd?
Egyébként miért kellene ezeket tudni úgy általában egy felhasználónak? Legfeljebb azt kell megmondani, hogy neki üzleti szempontból mi a fontos.
Éppenséggel kódot is írok, compilert is asználok, de ez most mindegy is. -
hokuszpk
nagyúr
lehet az fáj az Intelnek, hogy már nem ők döntik el, mi a kismag meg a nagymag
de ez eddig is igyvolt ; en pl. amiota szamtechhel foglalkozom, tudom, hogy nincs olyan, hogy "eleg eros hardver". Programozóul : a nagymag is kismag, mert simán tudok olyan kodot irni, ami azon is lassan fut. De ha mégsem, akkor majd beteszunk +1 interpretert a stack tetejere ami az aktualis trendnek megfeleloen irt kodot leforditja a regi interpreter szamara ertelmezheto formara ami majd p kodot general egy még régebbi futtatokornyezetnek.
Ugyhogy kapja ossze magát az össze hw mérnök. -
Pikari
veterán
A kérdés remekül rávilágít arra, hogy kb 10 ezer emberből 10 ezer nem tudja, hogy mi az az ütemező, mi az a compiler, mi az a thread, vagy hogy a futtatható állományok elején mi a fene az a header.
És mindegyik katatón előre és hátralengések közepette NEKED, programozónak nyög, felhasználótól kezdve procitervezőn át, hogy "valahogy oldjad meg" azt a 22-es csapdája szintű problémát, amit megfogalmazni se tudnak, de innentől kezdve a te bajod, és te tartozol érte felelősséggel, mert így döntöttek
. Az intel nem tartja jó megoldásnak, hogy nem te oldod meg a problémájukat. Beleraktak pár atom szintű magot az i9ekbe, a prezentációk és a managerek szerint kurva jó ötlet volt és ez a jövő! És ők úgy döntöttek, hogy ez a te felelősséged és problémád innentől. Ki vagy te, hogy kibújsz alóla?Megmondom, hogy lesz ez megoldva: sehogy. Rendes processzort kell venni.
-
Compiler honnan tudna, melyik szalat akarod hol futtatni? Max olyat lehetne csinalni, hogy default beallitas az, hogy minden mehet barhol, ami felulirhato, ha dedikaltan xy magot akarsz az adott szal eseten preferalni (de ugye az utemezo belepiszkitasa miatt ez se lesz fix soha) - es pontosan ez is tortenik.
-
csendes
addikt
"A hibrid dizájn tekintetében az egyik nagyon hasznos trükk az operációs rendszer egyes API funkcióinak használata, amivel el lehet érni, hogy a késleltetés tekintetében magas tűréssel bíró szálak az E-magokon fussanak,"
Ezt nem a compiler-nek kellene tudnia és a build-nél csak beállítani a flag-eket? Mondjuk el tudom képzelni, hogy a tesztelésnél ez többletmunkát okozna. -
brabbitz
aktív tag
Ez teljesen igaz. Bar hozzateszem hogy a DX12 2015-2016os release ota azert boven volt idejuk ehhez. Egy prociigenyes programrol van szo, oda nagyon jo lett volna ha minnel elobb megoldjak ezt a problemat. A ubisoft fejleszto csapatara (legalabbis ennel a jateknal) hatvanyozottan igaz a leirasod.
hat ami kesik, az nem mulik legalabb.
remelhetoleg lesz performance update mert eleg jatszhatatlan lett. -
Pikari
veterán
Egyik apiról portolni a kódot másikra rohadt hosszadalmas és idegőrlő. Még akkor is, ha csak textúrázott + szines háromszögeket rajzolsz ki, és semmilyen különleges technikát, featuret, effektet nem használsz sehol. Meg nem is nagyon ért hozzá senki. Fingreszelőmanager next+next+finish szintű wasd editorban repkedő, szkriptnyelvben szkriptvarázsolgató kamufejlesztőből sok van, csak ez nem fog tudni renderert írni. Programozóból meg egy sincs, és ha találsz is, olyat kell találnod, aki épp ért a kívánt apihoz, és valahogy meg is kell győznöd valahogy, hogy átírja. DX12-re átírni amúgyis rizikós lett volna, mivel csak mostanra terjedtek el úgy-ahogy a kompatibilis rendszerek. Szóval akik az ilyen több százezer/több millió soros bloatwarek egyik apiról másikra történő átírásában reménykednek, nem nagyon vannak tisztában azzal, hogy mekkora volumenü munkáról van szó, főleg akkor, ha a renderelő nem egy teljesen függetlenül működő, mindenből különválasztott modul vagy függvénygyűjtemény, hanem a 3d engineből a game enginebe összevissza átnyúló összepatkolt spagettikót.
-
brabbitz
aktív tag
Bulldozer/Vishera arch nagyon későn érett be, ez is nagy probléma volt, illetve az Intel monopolium miatt a fejlesztés ezekre is elmaradt.
Erdekes hogy 2016 korul kezdtek el foglalkozni ezzel a Arch-al, csak a problema az volt hogy mar oregecske volt, illetve jott a Ryzen, és kiderült hogy nem fogja kovetni a FX család vonalát. (Hála ég)Eleg puritan, naiv peldam, de most pl a Ubisoft áttérítette az R6-ot DX12-re Vulkanrol.
FX-et nagyon jól kezeli a játék DX12-ben, és és föld a különbség DX11 és 12 között, nagyon szépek a FPS számok, viszont erre várni kellett majdnem 10 évet?
De a snowdrop motor legalább szepen kezeli a procit.Megkésett a dolog. Hát ez van.
Az Intel még nagy játékos, pénz és a fejlesztők hajlandóságától függ hogy összejön v. sem.
-
proci985
MODERÁTOR
nagyon leegyszerustive OS szinten a process control blockba kene belenyulni ami a futo programok adatait tarolja es kene kvazi egy negyedik scheduler ami cserelgetne az instrukciokat.
meg lehetne oldani a CPUn is belul, de egy instruction swap adott esetben olyan szinten lassitana a futtatast, ami vallalhatatlanul lassu lenne. es itt most nem csak valaszido-varianciara erzekeny valos-ideju rendszerekrol (pl, jatekok) beszelunk, hanem ugy barmirol.
JAVA? ... ott az egész környezet erre épül, kb. mindegy a hardver alatta ha van futtató környezet
Java mar az OS szint felett van, de sajat virtualizacios layerje van. viszont, tobb mint 10 eve a Java programok is (reszben) elore forditanak, nem csak JIT compilert hasznal. kitalalhatod, hogy szinten performance okok miatt.Az ütemezője a CPU-nak meg az utasítást figyelve tudja, hogy melyik magra kell küldeni ha olyan kódfajta érkezik.
Ezt meg lehet csinalni, de innentol megint ott vagyunk, hogy PC desktopon az E magok egyedul arra jok, hogy elmondhassa az intel, hogy lam nekik is van 32 magos megoldasuk es legalabb papiron versenykepesek legyenek az AMDvel. Fejlesztokent legegyszerubb innentol rarakni egy flaget, hogy csak a P-core altal tamogatott utasitasokat hasznaljuk. Ami gyorsabb is OS szinten, mert nincs potencialis bottleneck a CPU belso utemezojevel ahogy probalja overrideolni ami nem a sajat feladata lenne. Meg egyszer ez egyebkent latency spikeokat tud csinalni, ami jateknal mikroakadast jelent. -
nem mondtam, hogy egy hétvége alatt össze lehet dobni egy ARM<-->x86 emulációt. De intel és amd itt előnyben lenne mert akár hardveres fordítót is kreálhat hozzá nem csak szoftver szinten tudja létrehozni... persze egy ilyen fordítóval már lehet ugyan ott lenne tranzisztor igényben. Így inkább operációs rendszer szintjén kéne lekezelni, hogy kisebb magokat egyfajta virtualizációs (JAVA? ... ott az egész környezet erre épül, kb. mindegy a hardver alatta ha van futtató környezet) környezetben futtassa.. azt jó van az úgy.
De VIA-nak volt egy érdekes CPU koncepciója, hogy 8 mag "sima" AVX nélkül és egy 9. dik csak AVX képes mag van egy ringbushoz hasonló felépítésben. Az ütemezője a CPU-nak meg az utasítást figyelve tudja, hogy melyik magra kell küldeni ha olyan kódfajta érkezik.
Nem tudom mi történt ezzel a felépítéssel, koncepció szintjén maradt, vagy készült termék is belőle (talán 4-5 éve lehetett róla PH-n olvasni cikket). -
proci985
MODERÁTOR
és akár ARM magokat is lehetne használni E magként x86 emulációval
a gyakorlatban ez annyira egyszeru, hogy a MacBook Proknal volt egy par honapos periodus, amikor a "ok, de hogy fogok virtualizalni" kerdeskorre eleg bonyolult volt a valasz. qemu mukodik, virtualboxra mai napig nem lattam ertelmes megoldast (marmint qemu mellozesevel, de nyitott vagyok).eltero cache szervezes is problema, korabban az Intel az AVX512ot amiatt irtotta ki, mert az E magok nem tudtak. a P es az E magok osszehangolasa nem menne. meg desktopon ertelme sincs (felhasznaloi/uzemeltetoi szemszogbol).
-
Igen, pontosan igy van. Ezert is nem ertem, megis, mi a picsat akar a jatekfejlesztoktol a kedves intel. A fentiben ezt probaltam meg picit szarkasztikusan kifejezni: Azaz hogy jatekok eseten gyakorlatilag nincs olyan fontosabb elem/folyamat/akarmi, amit lehetne szamuzni az E magokra.
Szoval az ertelmes megoldas amugy szerintem az lenne, hogy nem a jatekfejlesztoket basztatjuk, hanem ha jatek, akkor menjen a P magokon, ha van eleg es kesz. A minden mas, ami jatek alatt ugyis csak a hatterben fut, meg mehet az E magokon, ugyse erdekel senkit.
-
GIstvan83
csendes tag
emlékeim szerint a legextrémebb akkori intel roadmapek szerint azért pontosítanék.
Szóval a netburt eleve egy átmeneti architektúra volt, ugyanis a tervek szerint a sikeres ia64et lehozzák a mainstreamba, ahol x86 emulációval is elsöprő fölényt tudnak.. majd természetese az ia64es proci, már valami 10ghz plusszon járt, ekkor már kivezetve az x86ot.
elő kéne keresni azokat a funny roadmapokat. De még tán pc guruban is volt.. ahol az az intelbuzi áltuningos cikkíró élvezkedett. Nem jut eszembe a neve.
-
Mobilokon mondjuk egyszerűbb a bevezetés mert nem kell rendszerszintű kompatibilitást tartani így "felrúgható" a régi verziókkal való támogatás (és meg is teszik X időnként a kernelben).
#15 opr:
Sajnos hiába veszünk valamit sokszor kismagra, ha egyszerüen kritikus dolgot teszünk rá, akkor "be kell várni" őket, így az egész teljesítményt visszafogja... Ráadásul IO overheadje erősen problémás a más sebesség miatt, a számolások nem egyenletes ütemben érkeznek vissza, így még nagyobb késleltetés lehet a végén vagy egy már ember által is érezhető "darabos" megjelenés egy késleltetés kritikus folyamatban (pl. játéknál... amikor furán "darabos" lesz, program lehet ki se tudja mutatni mert azt is befolyásolja az egész architektúrális feltorlódás, de érezni egyszerüen, hogy "nem sima".. ez a jelenség tűnik el ha nincs E mag)... szomorú, de nem egyszerű ezt megoldani.Ez a háttérben a pálya betöltés.. ott is... megoldható, de az is inkább IO igényes folyamat (memória sebesség, csatlakozók pl. PCIE sebessége, háttértár sebessége) számít, persze lehet számolni, de azt lehetne akár pár "extra" erősebb maggal is jelentős teljesítmény vesztés nélkül (az IO terhelés miatt valamennyi teljesítmény vesztés mindig lesz egy háttérfolyamat betöltődésekor is), eléggé "használd ha már ottvan" pótcselekvés ott az E mag.
#28 KROK640:
Netburst és bulldozer alap koncepciója részben azonos "egyszerű mag" ami könnyen megy magas órajelen... a bulldozer veszte is az, hogy ahol végződött órajelben, valójában ott lett volna eredeti tervek szerint az alja a legkisebb modelleknek (4-6Ghz tartományba tervezték még papíron a működést az első modelleknek, de a 4Ghz-el már szendvedett a gyártástechnológia).Az E magokkal nem csak a nagy sebesség különbség a gond, az utasítás készlet különbség is problémás... De szerintem akár teljesen lehetne mellőzni is őket, és akár ARM magokat is lehetne használni E magként x86 emulációval... fogyasztásban lehet még jobb is lenne.. haszna meg kb. azonos végeredményben. A C magok nem annyira csökkentettek képességben... lényegében egy hely optimalizált mag, kevesebb cache-vel, és a "kompaktabb" összeépítés miatt korlátozottabb elérhető órajellel.. De mivel homogénebb a végeredmény, optimalizálni is egyszerűbb rá, kevésbé viselkedik különbözően egy-egy művelet esetén és sebességben is kiszámíthatóbb a reakcióidő.
-
cucka
addikt
A nehéz rész pont az, hogy hogyan írd meg úgy, hogy élvezetes legyen ellene játszani.
A játékok amúgy tele vannak ilyen trükkökkel és csalásokkal, minden szinten. (Pályadizájn, ellenfél viselkedése, health menedzsment, minden de tényleg minden "csalás" bennük
)Ha belegondolsz, írsz egy algoritmust, ami a lövöldözős játékban játszik, akkor az alapesetben 100%-os pontossággal fog célozni, és valószínűleg 1 frame idő lesz a reakcióideje.
-
-
En is ezen agyalok, hogy egy jatek eseten mik azok a folyamatok, amik el tudnak lezengeni az e-magokon.
Eddig ezeket talaltam:
- shader compile menuben vagy elso betolteskor update utan: ezek mehetnek (menjenek) mindenen, szartol repuloig minden csak szamolja ezeket nyugodtan, ennel jobban parhuzamosithato dolog a vilagon nincs- preloading/streaming, ha ugy van megirva, hogy inkabb zabaljon tobb ramot, de legyen tobb ideje mukodni. Itt ugye arrol van szo, amikor streamelunk be uj palyareszeket pl, mert megy a fohos az ajto fele, es nem akarunk toltokepernyot meg liftezest (a'la Mass Effect), hanem a jatekos szempontjabol eszrevehetetlen legyen az atmenet
- telemetria... Mert baromira raer, abszolut nem idokritikus, 0.1ms keses senkit nem erdekel se abban, hogy kinyilt az "acsi csuhajja", se abban, hogy a jatekosok hany %-a pisilte le a piros ajtot.
-
Hát pont ez az, hogy melegedés miatt nem skálázódtak úgy ahogy tervezték. Habár a NetBurst valamikor 2000-ben jött, szóval ekkor még szabadott naivnak lenni. Lásd Anand, ezt a cikket vicces ma olvasni.
Jelenleg a 6 GHz nagy nehezen elérhetővé vált, de milyen áron...
Nálam most a Zen4 magos 7940HS az 5.0-5.2 GHz-re tud turbózni egy magon, ekkor ~20 watt körül van a CPU package. A régi laptopomban az Alder Lake 12850HX 4.8 GHz max turbón ~40 wattot kér. Ez azért sok mindent megmagyaráz, Intel 7 (10 nm) vs TSMC 4 nm. -
#13
Valamivagyok
tag
Valamivagyok
tag
Érdekes hozzá állás, kinek lenne érdeke, hogy ez jól működjön? Jelen pillanatban ez csak nekik, 0%-os ennek a cuccnak a piaci részesedése. Ellenben a játékok 8/16-os processzort használó konzolokra íródnak, amin jól is futnak. És itt nem az AMD-nek lejt a pálya, csupán ők indultak meg másik irányba. Érdekes lesz, hogy bírják majd rá a fejlesztőket, hogy őket "kövessék".
-
hokuszpk
nagyúr
én úgy fordítanám, hogy aki éppen gyártástechnológiai hátrányban van, az innovál valami szerinte forradalmit, és ha nemjön be, akkor a fejlesztőket hibáztatja
@Goose-T :
"Na és játékoknál mi az a feladat, ami késleltetés tekintetében magas tűréssel bír? Főleg játék közben? Hát persze, hogy nincs ilyen feladat, hiszen a játék egy realtime program lényegében, nem kívánatos a késleltetés."némelyik játékban az ellenfelek mondjuk lőhetnének lassabban vagy ilyesmi
-
Goose-T
veterán
késleltetés tekintetében magas tűréssel bíró szálak az E-magokon fussanak, ugyanis így a kevésbé kritikus feladatok eleve a kisebb teljesítményű magokra kerülnek, ahova valók, ami automatikusan felszabadítja a P-magokat, hogy azok a kritikus munkát végezhessék
Na és játékoknál mi az a feladat, ami késleltetés tekintetében magas tűréssel bír? Főleg játék közben? Hát persze, hogy nincs ilyen feladat, hiszen a játék egy realtime program lényegében, nem kívánatos a késleltetés.
Az operációs rendszer maga megoldhatná az egészet úgy, hogy a saját háttérfolyamatait valamint a 3rd party háttérben futó szolgáltatásokat (vírusírtó, updater daemon stb.) ráosztja az E magokra, minden másra pedig ott a
mastercardP-mag.A játékfejlesztőknek pedig marhára nem kéne ilyen szarságokkal foglalkozni, mert a feladatütemezés az oprendszer feladata és kész. Most sem foglalkoztak vele, csak csináltak egy hekket, hogy a fos E-magokra inkább ne menjen rá a játék, mert csak a baj van vele.
-
Hát, van ebben igazság, de a teljes kép valahogy így hangzik:
A Netburst nem lett volna rossz, csak hát nagyon elszállt a fogyasztás a magas órajellel, hiába bármilyen gyártástechnológia, így az Intel hagyta a fenébe.
A Bulldozer elsődleges problémája az volt, hogy játékok alatt iszonyat gyenge volt, mert csak több szálon volt versenyképes a Sandy Bridge-dzsel, egy szálon már semennyire. Másrészt gyártástechnológiában hiába volt mindkettő 32 nm, azért a GlobalFoundries és az Intel gyártósorai nem egy kategóriák sajnos.
Jelenleg meg ott tartunk, hogy épp az Intel van lemaradva gyártástechnológiában, ezért fűtenek a processzorai magas órajelen. Pl tavaly az Intel Raptor Lake (13-14 széria) az Intel 7 nevű gyártástechnológián készült, amit eredetileg 10 nm-nek hívtak. Az AMD Zen4 (7000-es széri)a meg TSMC 5 nm-en (a mobil verzió 4 nm-en). Ez egy nagyon komoly lemaradás, ezért kellettek az E core-ok.
-
Taranti
senior tag
Nincs új a nap alatt programozóéknál:
[link]
"Végeredményben az Intel Netburst és az AMD Bulldozer is bukás lett, ugyanakkor nem feltétlenül azért, mert olyan rossz ötlet elszakadni a P6 dizájn alapjaiban történő másolásától. ..... Persze ez nem jelenti azt, hogy a Netburst vagy a Bulldozer lenne a megoldás a gondokra, csupán azt érdemes látni, hogy az Intel és az AMD is látta, illetve látja a potenciális problémákat, és megpróbálták kezelni azokat. A sikerhez azonban az is kell, hogy az alkalmazásokat az újszerű dizájnokra optimalizálják, amire nem igazán került sor a Netburst és a Bulldozer esetében sem." -
persze intelnek muszaj tolnia az E magokat, mert meginkabb kibukna, hogy mekkora lemaradasban vannak. persze egyszerubb a fejlesztokre kenni.
Sajnos így látom én is. Nemrég váltottam Alder Lake-ről Phoenix Pointra. Részben azért, mert az E magokkal meggyűlt a bajom, pl a VMware elég furcsán bugzott. Habár azért sok baj nincs vele, de sokkal szimpatikusabb az AMD megoldása a C magokkal, amelyek szoftver szempontjából 100% ugyanolyanok mint egy sima Zen mag.
-
proci985
MODERÁTOR
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
magokra. 
Új hozzászólás Aktív témák
- Nyaralás topik
- Kínai és egyéb olcsó órák topikja
- Google Pixel topik
- PlayStation 5
- Elektromos autók - motorok
- Telekom T Phone 3 5G – modern tudakozó
- Nem okoz az adattárolón hibát a Windows 11 augusztusi frissítése
- Háztartási gépek
- CADA, Polymobil, és más építőkockák
- Xbox Series X|S
- További aktív témák...
- MacBook felvásárlás!! MacBook, MacBook Air, MacBook Pro
- GYÖNYÖRŰ iPhone 13 mini 256GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3406, 96% Akkumulátor
- MacBook, Apple M1 / M2 kompatibilis dokkolók, DisplayLink 4K, USB-C, Type-C
- Windows 10 / 11 Pro Retail aktiváló kulcs Azonnal szállítással, számlával, garanciával!
- 0% THM 6 havi részlet, beszámítás! Gamer PC, notebook, konzol, Apple termék, hardver KAMATMENTESEN!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest