- Megjelent a Poco F7, eurós ára is van már
- Feljutott a G96 a Moto széria csúcsára
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- Samsung Galaxy Fit 3 - keveset, de jól
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Honor Magic V3 - mágikus realizmus
- Yettel topik
- Motorola Edge 40 - jó bőr
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- iPhone topik
Új hozzászólás Aktív témák
-
Livius
őstag
Nyugalom mindenkinek, a garfénnek hála úgy néz ki simán lesz itt még 10nm is, sőt amilyen brutálisan fejlődik az anyagtudomány (fizika), lesznek itt még nem várt nagy eredmények bőven, az új anyagok révén. Igaz Magyarországnak sok haszna nem lesz ebből, mint eddig se volt sajna az ipari, kutatási és oktatási gyér támogatottság miatt.
Si-vel 11nm lesz a fizikai határ, de a grafén segítségével ez lefog menni 10nm alá. [link]
-
#90
Abu85
HÁZIGAZDA
KőkorSzaki
#89
Abu85
HÁZIGAZDA
válasz
KőkorSzaki
#89
üzenetére
Inkább csak elemzik a problémát. Igazából régóta vannak róla tanulmányok, hogy egyre magasabbak az átállás költségei. Csak idő kérdése volt, hogy elérünk egy olyan szinten, amikor a node váltása nem hoz költségcsökkenést.
A HSA alapítvány alapvetően egy régebbi problémára reflektálva született. Nevezetesen a Dennard Scaling hanyatlása vezetett ahhoz, hogy a tranzisztorok bekapcsolásához szükséges energia a node váltásával egyre kevesebbet csökken.
A válasz egyértelmű a cím kérdésére. A probléma létezik jó megoldás pedig nem igazán van. Mivel ez a HSA anyaga, így azt vázoltam fel, hogy ők mit gondolnak megoldásnak. Ha a többiek is felvázolnak valamit, akkor azt egy külön cikkben részletezem, de előbb meg kell szólalniuk. -
#89
KőkorSzaki
tag
KőkorSzaki
tag
Ha jól látom, akkor az eredeti problémafelvetés is a HSA-tól jön, tehát egyfajta magyarázat saját tevékenységük értelmére, és nem egy független szakértők által felvetett és reálisnak tartott forgatókönyv. Jelen cikkből ez nem derül ki megfelelően, hiszen a bevezetőben (ahol a problémát leírjátok) nem hivatkozik a HSA-ra, független problémaként prezentálja. (Ráadásul a folytatásból az jön le, hogy még szerencse, hogy itt a HSA, a fizika kikerülése, stb.) Lehet persze mondani, hogy kit érdekel mindez, de az itteni olvasóközönség nagyon is kíváncsi a hardverfejlesztésekkel kapcsolatos hírekre és tendenciákra, tehát pl. arra is, hogy a cikknek adott címben megfogalmazott kérdésre mi a válasz (nem véletlenül választottátok ti sem ezt a címet, ugye?), és erre a cikk - a fentiek miatt - SZERINTEM egyáltalán nem ad választ, nem erről szól.
-
buherton
őstag
Hard real time: elektromos kormány szervó, légzsák, fék, stb...
Minden ami mikrokontroller azt gyakorlatilag C-ben írták. Lásd mikró, távkapcsoló, szinte az összes firmware, riasztók, kávéfőző és még sorolhatnám nap estig.
Nem mellesleg csak, hogy teljes legyen a kép. A C++-nak vannak tovább gondolt változatai, mint pl. a Qt C++-a, amiben a standard könyvtárnál hatékonyabb tárolók/típusok/szál kezelés stb...
Jah hogy te PLC-zel.
(#76) bambano: De tovább kell olvasni.
While it's not specified how the data was measured (for example if the original Quake 2 executable compiled in 1997 was used, which may be considered bad as current C compilers may achieve better optimizations for Quake), it notes how the same Java source code can have a huge speed boost just by updating the VM, something impossible to achieve with a 100% static approach. For other programs the C++ counterpart runs significantly faster than the Java equivalent
Bár én PERL-ezek, úgy hogy csendben maradok a gyorsaság terén
.(#85) mzso: A pistával bejövő új kernelt átírhatták volna, ha nagyon akarták volna vagy ha probléma lett volna az előzővel.
(#79) BatchMan: Kb. 150.000 sor C kód lefordítva 2,6 MB Motorola hex formátumban.
-
#65675776
törölt tag
Nézd meg mennyi helyet foglal a winsxs. Az felel a visszamenőleges kompatibilitásért, és ez teszi ki a a Windows mappa >50%-át. Szóval ha faragni akarsz a Win-ből, akkor első körben el kell dobni ezt. A beépített driverek visznek el további ~25%-ot (System32 és SysWOW64). Szóval tulajdonképpen a Windows mappa 75%-a kidobható lenne. Csak akkor ugye lehetne keccsolni már a rendszer telepítésekor is minden hw-hez a driver megadásával (XP-nél floppy-val élmény lett volna). Vagy lenne egy feltelepített OS-ed, ami mindent csak a létező legalapabb funkcióival képes kezelni. Pontosabban nem mindent, mert lenne pár generic driver mondjuk lemezvezérlőhöz, VGA-hoz és pár nélkülözhetetlen eszközhöz.
Plusz ha nekiugranál egy sw-t telepíteni, akkor megint belefutnál abba, hogy egyes modulok nem a neki megfelelő verziójúak. Három eset lehetséges:
1. Nem működik a sw, esetleg a verzióprobléma miatt már a telepítést is visszautasítja (2. legvalószínűbb lehetőség.)
2. Kérdés nélkül felülírja a meglevő verziót a sajátjára, nem foglalkozva azzal, hogy esetleg ez más sw-eket használhatatlanná tesz. (Legvalószínűbb lehetőség.)
3. Gyűjtöd a különféle verziókat, és minden a saját magának megfelelőt használja. (Ez meg pont az a megoldás, ami ma van a Windows-okban.)Win2k a visszamenőleges kompatibilitást sok szempontból teljesen elvetette, nem kellett kompatibilitási rétegekkel és verziókövetéssel foglalkozni benne. Az XP mivel asztali, általános OS-nek készült már tartalmazza mindezt, meg is hízott 1,2GiB-ra.
-
-
Cefet
aktív tag
Sajnos nem tudok neked erre vonatkozó linket küldeni, mert nem tudom, hogy hol olvastam, vagy láttam esetleg videón.
Ha érdekel a téma, akkor ajánlom figyelmedbe ezt.
A HP mérnöke beszél a memrisztor történetéről, néhány nagyon érdekes rajz és táblázat kíséretében.
Talán itt is láttam olyan paraméter grafikont, ahol az 1 és 2 nm közötti memrisztorok mérési eredményei voltak feltüntetve. Persze ez labor, de bőven elég lenne az is, ha csak a mostani mainstream technológián tolnák ezerrel. Ahogy a Toshiba... -
-
buherton
őstag
Minden program nyelvnek meg van a saját hülyesége. Vélhetően szakmaibeli vagy, vagyis nagyon jól tudod, hogy tökéletes program nyelv nem létezik. Valamiben minding sántítani fog.
C-t tisztán talán már senki sem használ.
Ez így nem teljesen helytálló. Hard real time rendszerekben 100% C-t használnak, és csak a nagyon alja van asm-ben írva. A kernel dettó. Majd a kernelre épülő programok vannak batch, bash, C++, C#, phyton stb.-ben írva.
De szerinted értelmes, hogy a Win8 30G (optimalizált kód?), mint oprendszer?
Ezt nem értem.
-
bambano
titán
"Java mennyire lesz már így lassú, mert most sem a sebességéről hírös?" akkor neked egy kis hír: [link] "In some real-life programs, Java out-performs C. One example is the benchmark of Jake2 (a clone of Quake 2 written in Java by translating the original GPL C code). The Java 5.0 version performs better in some hardware configurations than its C counterpart."
-
BatchMan
senior tag
Csak példának írtam, mert látványos. Egyébként szerintem sok kód lefut, majd kerül az eredménye a kukába menet közben. Csak nem tűnik fel.
Természetesen lehet C++ -ban is hatékony kódot fejleszteni, csak az időben nem lesz hatékony. A végén meg ott találod magad az inline assembly-ben, és akkor már csúcs hatékony kódod lesz, de az már nem C++. -
-
Cefet
aktív tag
Részben igazad van, részben nincs...
A memrisztoros tárolók (pendrive, memcard, SSD) 1-2 éven belül megjelennek. A HP és partner cége a Hynix még próbálják jegelni az egyébként már megjelenésre kész terméket, hogy ne döntsék be a Flash piacot. De ha csak nem kartelleznek, akkor nem fog menni, mert a Sandisk és a Toshiba is elkészült egy 24nm-es csíkszélességű, 32GB kapacitású chippel. Bár hangsúlyozzák, hogy ez csak egy teszt chip, de a gyártási eljárás, és a kapacitás is bizonyítja, hogy az új technológia kész a versenyre a hagyományos Flash-el szemben. Már most látszik, hogy le tudnak menni bőven 10nm alá a gyártástechnológiában, a maximális tárolókapacitás pedig a mérnökök szerint " UNLIMITED "! Ez egy "kicsit" hihetetlen, ahogy a magyarázat is: a rendkívül egyszerű áramköri felépítés és a minimális energia igény miatt, egy nagyobb csíkszélességen készült (a vezérlő áramköröket tartalmazó) alapra akár 1000 adattároló réteg is fölépíthető. A kutatók petabit/cm2-es adatsűrűségről beszélnek.
Ami a processzorként való alkalmazást illeti, arról valóban sokkal kevesebb az infó. Menni fog a dolog, mert működő kapu-áramkörök már vannak. A kérdés az lehet, hogy a hagyományos elvet kövessék-e, vagy valami egészen újat alkossanak. Képzelj el egy olyan számítógépet, ahol a feladat, a program önmaga döntheti el, hogy a leghatékonyabb végrehajtáshoz számára milyen hardver kell, és ennek megfelelően szervezi át a végrehajtó egység belső felépítését. Ez lehetséges lesz, talán még futás közben is. -
BatchMan
senior tag
A C++ hátránya, hogy az egymásba épülő osztálydefiníciók miatt egy csomó felesleges kód keletkezik és hajtódik végre. Logikus és szép, hatékony fejlesztő eszköz, de nem hatékony a végrehajtandó kód. (Pl. Winben számtalanszor látom, hogy kirajzol valamit, majd felülírja. Vagy leteszel egy kurzort és újra generálja az egész oldalt.
Ettől hatékonyabbat szeretnék. Ha tudnám pontosan mit, már milliomos lehetnék.C-t tisztán talán már senki sem használ.
A C++ alkotói előre látták ezt a problémát, és előre is bocsánatot kértek a világtól, hogy rászabadították, de momentán nem volt jobb ötletük. De azóta eltelt 25 év.
Igen tudom mi az alapja Linuxnak, és sejtem a Windows-ét is. De szerinted értelmes, hogy a Win8 30G (optimalizált kód?), mint oprendszer?
-
buherton
őstag
C++ helyett mit szeretnél?
Csak azt akartam mondoni, hogy a mai hardverek sokkal jobbak, mint amennyire kihasználjuk őket, további fejlesztésüknek jelenleg az értelmét nem látom.
Ki fejtenéd egy kicsit bővebben?
Azt azért remélem tudod, hogy a 40 éves C alapja a Winfosnak és a Linuxnak is, és minden olyan programnak aminek hard real time-ban kell működnie. Nem véletlenül...
-
BatchMan
senior tag
Szép, szép a hardver fejlesztése, de sokat dobhatna a 25 éves C++ helyett valami hatékonyabb megoldás. A szoftveresek lazán gazdálkodnak az erőforrással, időre optimalizálnak. (Lásd Google project butter)
A mindenen futó kód viszont már többször elhalt.Csak azt akartam mondoni, hogy a mai hardverek sokkal jobbak, mint amennyire kihasználjuk őket, további fejlesztésüknek jelenleg az értelmét nem látom.
-
buherton
őstag
magas szintű programozási nyelvekkel, mint a C, a C++, a Java, a Python, vagy éppen a JavaScript és a HTML5. A rendszer nem függ majd a hardver utasításkészletétől, így lényegében a programot csak egyszer kell megírni, és a kód bármin futhat
Ez most a lefordított binárisra értve vagy a kódra? Ha kódra, akkor ez miért olyan nagy felfedezés? Ha binárisra, akkor sebességben mennyire lesz gyors? Java mennyire lesz már így lassú, mert most sem a sebességéről hírös?
Mivel minden hardver eltérő fizikai utasításarchitektúrát használ, így szükség van egy virtuális utasításarchitektúrára, ami viszont közös lesz.
Erről szól a Java, nem? Akkor miért keverik bele a többit?
-
bambano
titán
"Ezt alapvetően a gyártástechnológia fejlődése teszi lehetővé azzal, hogy az említett időintervallumot figyelembe véve jelentősen csökken az egy tranzisztorra levetített normalizált költségek száma."
na akkor ugyanezt magyarul is.mert az egy tranzisztorra levetített normalizált költségek száma mindig pontosan egy. ugyanis csak a közvetlen költséget vetítik le egy tranzisztorra, a közvetettet nem szokás.
-
P.H.
senior tag
Érzésem szerint elbeszélünk egymás mellett (én nem konkrétan a Larrabee-ra céloztam), viszont elgondolkodtató, amit mondasz, mert a Netburst kulcsa és egyben kritikus pontja is az L2 mérete volt: sem PII-nél, sem PIII-nál nem sikerült annyira megvágni a Celeron-teljesítményt az L2 méretével, mint a P4-nél, amelynek teljesítménye (a hatalmas trace cache miatt kényszerűen kis méretű) L1 helyett az L2-re van utalva.
Aztán "komolyabb" IGP-jükkel, főleg a Sandy Brigde mellett megint előjött a cache-probléma. Talán nem véletlen, hogy alternatív felépítésnél is megint a megosztott Last Level Cache jön elő az Intel-nél: tapasztalat és szemléletmód kérdése lehet ez.
-
Abu85
HÁZIGAZDA
Azon én is elgondolkodtam, és arra jutottam, hogy a Larrabee skálázásnak a kulcsa az L2 cache és a belső buszrendszer. Mivel nincs annyi szál a processzormagokban, hogy elfedje az adatbetöltés késleltetését, így a legfontosabb, hogy a szükséges adat ott legyen a megosztott L2 cache-ben. Valószínűsítem, hogy a grafikus feldolgozás során egy Larrabee mindenképp mozaikos leképzést használna. Ha a mozaikokat sikerülne úgy kialakítani, hogy a magok L2 gyorsítótárához igazodjanak, akkor úgy gondolom, hogy ideálisan működhetne a hardver.
Ami ennek a hátulütője az azonnali leképzést előnyben részesítő API-kkal való küzdelem mellett, hogy a skálázódáshoz mindenképp nagy L2 cache és igen komoly belső busz kell. Ehhez pedig nagyon szükség van a tranzisztorokra.Ha pedig nem működne még így sem, akkor ott a ZiiLabs, mint B-terv. Ezzel a koncepcióval sok pici belső hálózatba fűzött magot lényegében ki kell egészíteni egy lightos GPU-val, ami a fixen működő funkciókat végezné, mint a textúrázás. Azt amúgy sem éri meg emulálni.
-
#58
Neovenator
senior tag
Dluinet
#55
Neovenator
senior tag
Persze, egyértelmű. Ugyanakkor nem is ugyanabból a büdzséből gazdálkodik a két cég, és a gyártástechnológiát biztosító háttér sem azonos, finoman szólva sem. Intelnél mentalitásban vannak gondok, nem is aprók, de ha teszem azt ezen túljutnak egyszer, a technikai oldal felzárkóztatása nekik biztos, hogy jóval könnyebben megoldható, mint az AMD-nek, aki jelenleg sajnos nem teheti meg, hogy milliárdokat csengessen be évente R&D-re, a többi tényezőről nem is beszélve.
-
#55
Dluinet
nagyúr
Neovenator
#53
válasz
Neovenator
#53
üzenetére
nem teljesen egyforma a gyártástechnológiája az APU, a GPU-nak és a CPU-nak
össze kell egyeztetni a gyártástechnológiát az architekturával
-
#53
Neovenator
senior tag
atti_2010
#52
-
#52
atti_2010
nagyúr
Neovenator
#51
atti_2010
nagyúr
válasz
Neovenator
#51
üzenetére
A gyártástechnológiáját a füle mögé tűzheti ha nincs APU-ja amit gyártson rajta, azt könnyebb megcsinálni a TSMC -fél év alatt megoldja.
-
derive
senior tag
Vedd bele, hogy ma a legtöbb játék konzolport. Ha a konzolokban az AMD megoldásai terjednek el, hamar elolvadhat ez az előny, elég ha mondjuk az Intel procinak CPUn kell számolnia amit a Kaveri lepasszolhat a GPUnak.
Ennek egyébként a lényege, hogy egy általános hardver felől elmennek a célhardverek felé, aminek az adott feladat jobban fekszik. -
P.H.
senior tag
Anélkül, hogy túlzottan ragoznám a gondolatmenetemet, azon is érdemes elgondolkodni, hogy az Intel tick-tock (azaz két évente új gyártástechnológia, ezáltal felgyorsított közelítés a határhoz) stratégiáját mi motiválja vajon? Egyrészt a piac biztosan nem, mivel vezetők eléggé széles, laptop/asztali/szerver szegmens-skálán, konstans teljesítményt hoznak ott évről évre; másrészt a teljesítményigény sem, fogyasztók láthatóan elégedettek sokkal lassabb (telefon/tablet) megoldásokkal is.
Az viszont látható, hogy az Intel gyártástechnológiai fejlődésével senki nem tud lépést tartani, még a bérgyártó(k) sem. Ennek hozománya elméletileg, hogy az Intel-nek nem kell a chip-ek "okosságán" annyit fejleszteni, radikális váltásokra kevésbé képes/kényszerített, mert ehhez hozzáadódik a kifejlesztett csíkszélesség-előnye is, így behozhtatlan marad, sőt betörhet más, neki idegen (telefon pl.) térrészre is.
Ez sokkal inkább filozófia, mint műszaki megközelítés, de melyik nyereségesebb (és ad K+F alapot) és milyen távon?
-
P.H.
senior tag
Minden igaz, amit írtál, csak most a Moore-stopról szóló cikk topikjában vagyunk: növelhető még "nyugodtan" a teljesítmény adott tranzisztorszám mellett is, ha az adott feladatra fordított tranzisztorok száma csökken, másra fordítottak száma pedig nő (jó példa erre a Netburst trace cache-e, aminek 80-100 KB-ját félórajelen kellett járatni, vs Core2). Ezzel szvsz csak jól járunk mi vásárlók, amíg nem jön más gyártási technológia: eggyel kevesebb szám (tranzisztorszám), amivel indokolni lehet a felárat. Illetve megéri azonos gyártástechnológián is újra- és újraoptimalizálni a mickroarch-okat, nem csak várni az újabb, kisebb csíkszélességet ("Designers can count on another 30% die area to work with every 2 years, so every 2 years they increase the size of these structures without worrying about ballooning the die.")
Ismerem a GCN erejét, 55W-os 7750-em van negyed éve arra, amire CUDA-t használtam addig
-
P.H.
senior tag
Szerintem nem volt álmodozás számítási részről, csak a bevezetése legalább olyan "fájdalmas" lesz, mint pl. az OLED-é. Hányszor olvastuk már, hogy egy-egy technológia olcsóbb vagy a meglevő gépsorokkal gyártva is okosabb, mint az őt megelőző. Igen, a gyártónak olcsóbb. A bolti árcédulán ez biztosan nem fog jelentkezni, még a tárolók terén sem, ne legyenek illúzióid: egy termék bevezetési időpontja és árdiagramja teljesen független a fejlesztési, majd gyártási költségtől.
-
Abu85
HÁZIGAZDA
Az emelt órajellel nyilván nincs gond. Viszont nem csak Moore-stop van, hanem Dennard Scaling stop is. A Moore-stop csak egy újabb kellemetlen dolog, ami a mérnökök dolgát nehezíti, a legjobban viszont biztosan a Dennard Scaling falba futásától fáj a fejük, ennek pedig nem a magas órajel a megoldása.
Az Intel szerintem előbb-utóbb értékeli a helyzetet. Vettek olcsón egy ZiiLabs-ot, mert szerintem ott már nem mindenki hisz abban, hogy a Larrabee valaha is jól fog működni. A mostani GPU-kkal az Intel ott áll ahol a part szakad. A Gen7.x-et nem tudják normálisan felfelé skálázni, míg a Larrabee-t lefelé nem lehet. Eközben ránéznek egy GCN-re és azt látják, hogy az 4 wattos tablet SoC-októl skálázódik a 200+ wattos GPU-kig. És ráadásul a teljesítmény a skálázást eléggé lineárisan követi.
-
-
P.H.
senior tag
válasz
#65675776
#29
üzenetére
Az onimózus kijelentés a Pentium 4 Optimization Guide-ban jelent meg, nem (csak) a nyilvánosságnak szóló sajtónyilatkozatokban, ezért szvsz érdemes eljátszani a gondolattal:
- az elég kérdéses lenne, ha ezzel együtt 2002-ben 20 GHz-en járó chip-részekkel számoltak volna a jövőre nézve
- mivel láthatóan megvalósítható, a Moore-stopnál ez a megközelítés is felhasználható; hiszen láthatóan működőképes ez a koncepció is - miszerint a chip egy része emelt órajelen megy - CPU-knál 3 korábbi csíkszélességen és az nVidia is több generációban alkalmazta ezt gond nélkül. -
P.H.
senior tag
válasz
#65675776
#17
üzenetére
Azt azért nem hagynám figyelmen kívül, hogy a Netburst chip-ek háromféle órajelet alkalmaztak: a lapka kb. 40-50%-a a hivatalos magórajelen járt, 30-40%-a ennek a felén, és kb. 10-15%-a a hivatalos magórajel kétszeresén (azaz 1.3 GHz-es Willamette esetén 0.7 - 1.3 - 2.6 GHz volt a felállás, egy 3.6 GHz-es Prescott esetén 1.8 - 3.6 - 7.2 GHz). Ezt megcsinálták 130, 90 és 65 nm-en is, a területszázalékos arányok változtatása nélkül - hozzátéve, hogy a Presler órajelnövelését nagy valószínűséggel a Core2-irányú jövő kaszálta el.
Jó kérdés, mi lett volna a Netburst-alapú Nehalem, ami egyetlen magjával majdnem akkora lett volna, mint egy kétmagos Netburst; nyilván változtak volna a területi arányok az eltérő órajeleket illetően.(Hozzáteszem, egyetlen mikroarch. van, amire kifejezetten utálok programot írni, tehát nem védem a Netburst-öt egy pillanatig sem, de ilyen többórajeles felépítésben nem volt technikailag messze a 10 GHz. És újra elővehető)
#26 S-eye: Az Intel semmilyen formában nem vesz részt a HSA-ban, teljesen x64-alapú jövőben gondolkodik, de hasonló felállásban (több erős mag mellett sok alacsonyabb tudású).
-
MZperX75
addikt
Emléxem kb 10-12éve magyarázta nekem valaki
kb 45nm-es lesz a hátár ,ott ki kell találni valamit mert ezt nem lehet trtani azt hiszem akkor épp 130nm tartottunk....Hát ki is találtak 45nm-en majd 32nm-re majd 22-re is Intelék is és az AMD is
Lesz 20alatt is élet,figyeljétek meg...valami lesz az tuti!
Quantum gépet a nagyérdeműnek 100-ad annyi fogyasztással 10X gyorsabb APU-kat.
-
Remus389
veterán
ha ez az irány zsákutca lesz, lesz más irány
pl hallottam qvantum szamitogepekrol, vagy grafen (?) alapú chipekrol, amik 100 GHz vagy attól gyorsabban tudnak működni
esetleg hatékonyabbá teszik a processorok működését
szóval nem kell félni, meg amúgyis egy q6600 mindenre elég.
-
-
Ruuwa
tag
Talán még 14 (10) nm ahol meg tudják oldani a gyártást, de tovább már nem sokáig lehet menni. Már csak azért sem, mert pl a Szilícium atomsugara ~0,1 nm. Csak hogy nagyságrendileg érzékelni lehessen, hol járunk mostanában mint gyártástechnológiai mérettartomány.
És persze más kérdés a meg lehet csinálni, és a megéri megcsinálni.
-
oO7
őstag
azon túl, hogy fejlettebb módszerrel integrálják majd a GPU-t a CPU-ba és "hozzáférhetőbb" lesz a programozók számára, miben fogja a HSAIL megoldani a csíkszélességgel kapcsolatos problémát? és ha ez a része megvalósul a dolognak, utána merre tovább? vagy ha ez megvan, akkor hátradőlnek a processzorfejlesztők és szúrós szemmel néznek a compiler fejlesztőkre, hogy akkor mostmár legyenek szivesek ők is dolgozni?
-
Fecniii
tag
A fejlődés sosem állhat meg...
Most akkor ha jól értelmezem akkor a jövőben úgy fog kinézni egy PC hogy lesz benne egy heterogén APU meg csomó közös memória, és minden amit erre megírnak az el fog futni tableten mobilon és minden egyében amibe HSA hardver lesz?
Sonyfa: mert? a nm-nél nincs kissebb érték?
.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- GAINWARD RTX 4070 Ti SUPER Phoenix 16GB GDDR6X - 3 év garancia
- ASUS TUF Gaming GeForce RTX 3090 24GB GDDR6X
- BESZÁMÍTÁS! Gigabyte AORUS MASTER RX 6800 XT 16GB GDDR6 videokártya garanciával hibátlan működéssel
- Csere-Beszámítás! Sapphire Nitro+ RX 6700XT 12GB Videokártya!
- MSI RTX 3080 Ti SUPRIM X 12GB GDDR6X Videokártya! BeszámítOK
- Kingmax 1x2GB DDR3-1333 RAM
- 15,6" Dell Latitude laptopok: E6540, E5550, E5570, 5580, 5590, 5500, 5501, 5510/ SZÁMLA + GARANCIA
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Huawei Nova Y90 128GB, Kártyafüggetlen, 1 Év Garanciával
- 120 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest