- Otthoni hálózat és internet megosztás
- Microsoft Excel topic
- YouTube
- Letartóztatták a bitcoin-Jézust
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- Mobilinternet
- Crypto Trade
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Synology NAS
Új hozzászólás Aktív témák
-
atti_2010
nagyúr
válasz rviktor25 #100 üzenetére
Erős a gyanúm, h ha télleg átalakul közel 100%-osan ilyenre az iparág, akkor az Intel befektett annyit, h megint első legyen rövid időn belül
Ez nem csak befektetés kérdése, szakember kell hozzá és azok meg nem lézengenek az utcán.
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
Löncsi
őstag
válasz atti_2010 #101 üzenetére
Ez nem csak befektetés kérdése, szakember kell hozzá és azok meg nem lézengenek az utcán.
Nem most volt hír arról, hogy Huddy átment az Intelhez? Azért csak van miből gazdálkodnia a kék-csapatnak..
Elvették a radírját, azt az egész élete egy nagy kompenzálás, hogy ő igenis kan és igenis 2 méteres a fallosza - by stranger28
-
atti_2010
nagyúr
-
-
Abu85
HÁZIGAZDA
válasz atti_2010 #103 üzenetére
Ez nem így működik. Valóban nem lehet gyorsan átpártolni, de Huddy fél évig nem dolgozott sehol. Ez volt gondolom az AMD követelménye. Fél évvel a kilépése után csatlakozott az Intelhez. Teljesen korrekt átigazolás.
Löncsi (#102): Huddy egy devrel szakember, a hardverhez túl sok köze nincs. Ő direktívákat fogalmaz meg, és a fejlesztőkkel tartja a kapcsolatot. Gyakorlatilag ugyanaz a feladata mint volt az AMD-nél. Nyilván nem kérdés, hogy az Intel a Game-Ont akarja erősíteni, és Huddy jól jön, mert a semmiből vezető fejlesztői partnerprogramot csinált az AMD-nél a Gaming Evolvedből. Egy ilyen ember minden pénzt megér. Most ugyanez a feladata az Intelnél.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
FireKeeper
nagyúr
egy ilyen összetett architektúrát megtervezni nem úgy megy ám, hogy mevesznek egy szakembert, és a következő negyedévben már kész a die-terv.
steam, GOG, uPlay: @petermadach || HotS: PeterMadach#2675 || Xperia 10 V || Ultrawide & SFF masterrace || Unofficial and unpaid VXE R1 shill
-
Abu85
HÁZIGAZDA
válasz MPowerPH #104 üzenetére
A felvásárlás lehetősége 2006-2007 környékén elúszott. Senkinek nincs ma olyan eladó GPU-architektúrája, ami képes az x86/AMD64-es címtartományos belül címfordításra és támogatja az x86 virtuális memóriát. Az AMD a GCN-t nyilván úgy sem fogja odaadni. Marad az eredeti koncepció, vagyis a Larrabee integrálása.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
MPowerPH
félisten
válasz atti_2010 #106 üzenetére
Persze. Én ezzel arra akartam utalni, hogy van idejük a nulláról kezdeni. De az az érzésem, ekkora hátrányt lehetetlen lesz ledolgozni. Részben más felé is kacsingatnak, elég a felhőre gondolni.
Abu85: Értem, akkor még rosszabb a helyzet, mint azt eddig gondoltam.
[ Szerkesztve ]
Don't Tread On Me
-
Abu85
HÁZIGAZDA
A Tegra grafikus teljesítményének nézz utána. Eléggé a konkurensek mögött van. Nem is várhatod el, hogy az IMR architektúra ultramobil szinten felvegye a versenyt a TBR/TBDR-rel, amíg a memória limitáló tényező. Ha az alapok nem a G70-re épülnének, akkor talán közelebb lenne, de a G80 és a Fermi túlságosan tranzisztorigényes. Ezek nem skálázhatók le ilyen szintre.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz MPowerPH #109 üzenetére
Nem rossz a helyzet. Sőt egyszerű. Működésre kell bírni a Larrabeet. Ez a kulcs az egészhez. Akkor lesz rossz a helyzet, ha kiderül, hogy sehogy sem lehet a rendszert skálázni. Az a Larrabee, amit nem adtak ki, egy eléggé optimista elképzelés volt az Intel részéről. Túlontúl úgy álltak neki, hogy mi az amire a programozó konkrétan igényt tart, és nem úgy, hogy mi az ami ténylegesen megvalósítható. Ezen az elven kell változtatni, és a rendszer is működésre bírható. A tranzakcionális memóriakezelés egy jó út ebbe az irányba, sőt még a programozóknak is kedvező. Innentől kezdve lényegében már "csak" annyi maradt, hogy a memóriaalrendszer túlterhelését megakadályozzák. Ez majd ilyen trükközős dolog lesz.
Maga a Larrabee mag az működik. Nem azzal volt a probléma, hanem ami mögötte volt. Raktál a rendszerbe két magot, akkor szuper, négyet, az is nagyon jó. Még a nyolccal is ment, de 32-ig nem skálázódott. Tipikusan a memóriaalrendszer adta meg magát. Egy bizonyos mennyiségű mag fölött túlterhelődött. Ugye itt az NVIDIA és az AMD a GPU-architektúráknál nem véletlenül alkalmaz egy eltérő megközelítést. Inkább az elsőszintű gyorsítótárakra helyezik a hangsúlyt (nagyon sok regiszterrel a feldolgozók mellett), és komplex szervezéssel. Az Intel ezt pont fordítva csinálja. Az utolsó gyorsítótár a fő szempont, ráadásul gyűrűs busszal és eléggé egyszerű szervezéssel. Ezek nyilván onnan erednek, hogy az Intelnél a mérnökök inkább procis tapasztalattal bírnak. Csak ugye itt még nem igazán találkoztak skálázási nehézségekkel, ami tipikusan a GPU-architektúrák nyűgje. A Larrabee-vel már igen. Okulni kell belőle és készíteni az új verziót az előd hibáit figyelembe véve.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #19617792 #112 üzenetére
Ezek nem PowerVR hardverek. Itt nem kell a szerencsétlen ImgTec-től függni. Persze az Intelnek is kellene egy kicsit több koncentráció pl.: OpenGL-re, de összességében sokkal jobb a helyzet, mint az új Atomnál.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Angel1981
veterán
-
ddekany
veterán
Abu, mi ez a tranzakcionális memória kezelés támogatás egy CPU kapcsán? Ez tisztán szoftveres kérdés volt eddig, hogy tranzakcionális (STM) vagy zárolásos (szemafor, monitor, stb.) módon oldjuk meg a közös memóriaterületek írását. Szóval hogy jön itt képbe a hardver? Lesz STM megvalósításához valamiféle hardveres gyorsítás? (Miféle?)
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
A programozó oldaláról az lesz, hogy nem kell a zárolásokkal törődni. Egyelőre a részletek nem tiszták, de valószínű, hogy nem tisztán hardveres a megvalósítás. Ez nem is lenne szerintem ideális. Valszeg az AVX2-höz kötött, ahol új utasítások lesznek erre. Gyakorlatilag az lesz az eredménye, hogy nem kell kézzel optimalizálnod a párhuzamos végrehajtást. Az AVX2 elvégzi helyetted.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
P.H.
senior tag
Itt a 8.1 The Problerm With Atomic Operations és a 8.2 Transactional Memory fejezetekben van példákkal illusztrálva az elméleti háttér és a valószínűsíthető gyakorlati megvalósítása, egy L1D melletti cache-sel.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
KAMELOT
titán
Jelent írtam ,hogy most ez elég. Későbbiekben mások lesznek a trendek. Én mindig a legjobb ár / minőség / teljesítményt veszem alapul.
szavatosság és az időtállóság szempont de amint látod egy GTX260-al is simán elmennek a gamek Full-ban.(#62) Youri: Ezt jó tudni. Kár pedig!
V1200 - 18CORE - SUPRIMX
-
Mexildos
aktív tag
Szóval azt mondjátok, hogyha szerver cuccot venne az ember gépnek akkor az 5 évig is elmegy úgy hogy cserélni kéne? Vagy ha melóra van hergelve akkor azért kell előbb cserélni? Az S2011 kb. meddig lesz ütőképes? A két utas proci alaplapok mikor jönnek? Az S2011 foglalatot mikor váltja le az Intel?
-
-
ddekany
veterán
AVX2-vel kapcsolatban lövésem nincs, szóval nem tudom mire gondolsz... Amit P.H. hivatkozott, azt tudom hova tenni, és az az utasításkészlettől függetlenül vonatkozik a memória írásokra és olvasásokra. Ott tudtában van a programozó annak, hogy konkurens programot ír. mert zárolással ugyan nem kell törődni, de a tranzakció állapotát figyelni kell, gond esetén meg újra kell próbálkozni. Az mondjuk elég komoly korlát benne, hogy nem az összes elérhető memória korlátozza a tranzakciók össz méretet, hanem a CPU egy fix paramétere... tehát gondolom ez már csak ezért sem válthatná ki a mostani magas szintű STM megvalósításokat.
[ Szerkesztve ]
-
P.H.
senior tag
Nekem annyira nem tűnik komoly korlátnak, mivel elsősorban pl. a Windows-os EnterCriticalSection() - LeaveCriticalSection() API-hívásokat váltja ki hardveresen (másoknak: egy sorszálú programnak mindig csak legfeljebb 1 szála tartózkodhat az így körülvett kódrészben; ha van már "ott" valaki, akkor a következő belépőnek meg kell várnia, amíg amaz befejezi a tevékenységét, addig megáll ezen szál futása); az ilyen szakaszokban eddig is a lehető legkevesebb memóriaművelet volt, mivel igen "drága" ez a program szempontjából . És amellett, hogy kiváltja, eléggé hatékonyan teszi, mivel egyrészt a replay-t és a várakozást (while (1) { ...; delay; }) hardveresen oldja meg (esetleg a delay-t egy PAUSE-szerű megvalósítással), másrészt:
"If transactions are performed on the same memory location over and over again, the speed improvements can be astronomical since, in the one case, we have one or two main memory accesses in each round while, for transactional memory, all accesses hit the transactional cache, which is as fast as L1d."
Persze ilyen, L1D-szintű dedikált cache-es megvalósítás esetén szó sem lehet az OS általi szálvándoroltatásról.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
ddekany
veterán
"az ilyen szakaszokban eddig is a lehető legkevesebb memóriaművelet volt"
Amíg a kritikus szakaszban nagyon jól tudod hogy mi fut le... De ha meghívsz onnan 1-2 függvényt egy alkalmazásban mondjuk, akkor hamar gáz lehet. Meg persze itt mindennek amit meghívsz figyelembe kell vennie, hogy tranzakcióban van (LTX, VALIDATE stb utasítások hívogatása, stb). Nyilván ettől még ez jó kernel funkciók és hasonlók heggesztéséhez, csak alkalmazás-programozás szinten nem látom hogy használható lenne.
"Persze ilyen, L1D-szintű dedikált cache-es megvalósítás esetén szó sem lehet az OS általi szálvándoroltatásról."
Lehet, hogy ez megoldható annyival, hogy akkor a folyamatban lévő tranzakció sikertelen volt és kész. Tehát mintha valaki konkurensen belerondított volna, ami szokványos szituáció. Amúgy hasonló szituáció léphet fel akkor is, ha időosztásos többszálúság van, mert a kontextus váltás után ha az új szál is elkezd tranzakcionális utasításokat kiadni, akkor hozzácsapná a CPU az előzőt szál folyamatban lévő tranzakciójához amit csinál...
[ Szerkesztve ]
-
Balala2007
tag
Az AVX RefGuide 12. kiadasaban a 8. fejezetben benne van a konkret Inteles magvalositas. Tegnapelott lett publikus.
AIDA64.com
-
P.H.
senior tag
válasz Balala2007 #129 üzenetére
Köszönöm.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Nem dedikált cache-t alkalmaz, hanem egy read-set és egy write-set cím- és értéktáblát és két külön módot kínál:
- a HLE (Hardware Lock Elision) kompatibilis az összes eddigi processzorral: XACQUIRE ill. XRELEASE utasításprefix-szel mint tippekkel dolgozik, pl. mutex-változó be- és visszaállítására. A kettő közötti programrész tranzakcióként fut le (más szálak a módosított változók eredeti értékeit olvashatják), ha közben másik szál nem akarja beállítani ugyanazt a mutex-et; ha mégis, akkor az eddigi változásokat eldobja, lefut újból az egész, de már nem tranzakcionálisan: hibás a program, más (pl. OS-) zárolást kell alkalmazni. Ha más is írni akar ugyanazokba a változókba, akkor is.
"The processor automatically detects any data conflicts that occur during the transactional execution and will perform a transactional abort if necessary."
"With HLE, if multiple threads execute critical sections protected by the same lock but they do not perform any conflicting operations on each other’s data, then the threads can execute concurrently and without serialization. Even though the software uses lock acquisition operations on a common lock, the hardware recognizes this, elides the lock, and executes the critical sections on the two threads without requiring any communication through the lock — if such communication was dynamically unnecessary."
"Improper use of hints will not cause functional bugs though it may expose latent bugs already in the code."- az RTM (Restricted Transactional Memory) új utasításkészlet 3 utasítással: XBEGIN, XEND, XABORT. Ez felel meg a linken leírtaknak: XBEGIN utasítás jelzi a kritikus rész kezdetét, XEND a végét (megszakítható XABORT-tal). A kettő között a read-set táblába feljegyzi az összes olvasott, a write-set táblába az összes írt változó címét és értékét (64 byte-ra igazítva). Ha sikeres a lefutás az XEND utasításig, akkor az összes változtatás egyszerre lesz látható; ha nem (pl. valaki módosított közben a változókon, vagy XABORT utasításra futott), akkor az XBEGIN-nek paraméretként megadott programcímen folytatja a végrehajtást, regiszterben megadva, hogy mi történt ("abort caused by XABORT", "the transaction may succeed on a retry", "another logical processor conflicted with a memory address that was part of the transaction", "an internal buffer overflowed", stb.)
Mivel a tranzakciók egymásba ágyazhatók, nem kell figyelembe vennie a meghívott függvényeknek, hogy tranzakcióban van a hívó (persze szerencsés a lehető legkevesebb műveletet végezni itt). Mivel a táblák az olvasott vagy módosított 64 byte-os cache-vonalak címeit rögzítik, elég lehet az általuk lefedett memóriaterület (1 KB = 16 bejegyzés).
"Lehet, hogy ez megoldható annyival, hogy akkor a folyamatban lévő tranzakció sikertelen volt és kész."
Így valóban nincs nagyobb jelentősége, mint egy vándorlás miatti cache-refillnek. A megszakítások (timer a context switch-hez vagy így az OS API-hívások jó része is) abortálják a tranzakciót. Mondjuk az érdekes, hogy az x87- és az MMX-utasítások is.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
Chiller
őstag
válasz FireKeeper #20 üzenetére
az ES-t biztos, hogy lehet tuningolni, azok mindig szorzózármentesek.
Nem lehet, tele van a net fórumhozzászólásokkal. Sajnos Xeonnak ismeri fel a lap, és azokat pedig élből nem engedi.
Legalábbis ez volt még a legutoljára a helyzet.
Az itteni s2011 topikban is feltettem a kérdést, de hiába. Pedig legalább 1 ilyen ES proci már hetek óta van hazánkban, de valahogy túl nagy a csend körülötte....
-
ddekany
veterán
"A kettő közötti programrész tranzakcióként fut le (más szálak a módosított változók eredeti értékeit olvashatják), ha közben másik szál nem akarja beállítani ugyanazt a mutex-et; ha mégis, akkor az eddigi változásokat eldobja, lefut újból az egész, de már nem tranzakcionálisan: hibás a program, más (pl. OS-) zárolást kell alkalmazni."
Ugyan azon mutex beállítása biztos nem dobja a tranzakciót, annak nem sok értelme lenne. Pont azzal dicsekedett az Intel, hogy coarse-granularity lockingot lehet használni a programozó- és memória/cache-rendszer-szopatós fine-gradient helyett, de hasonló áteresztőképességgel. Ez meg azért lenne, mert ha van egy összetett adatstruktúrám (pl. valami map), aminek van egyetlen zára (tehát coarse-granularity locking van), akkor beléphet több szál is oda egy időben, és csak ha ténylegesen egymás lábára léptek, akkor az XRELEASE visszatekeri az állapotot az XACQUIRE utasítás kiadásakorira, és akkor tényleges zárolással (azaz HLE nélkül) újra végrehajtja a kritikus régiót.
"A megszakítások (timer a context switch-hez vagy így az OS API-hívások jó része is) abortálják a tranzakciót. Mondjuk az érdekes, hogy az x87- és az MMX-utasítások is."
Szóval, mint sejteni lehetett, ez nem érinti a mostani olyan STM megvalósításokat, amik alkalmazás-kódot futtatnak tranzakciókban. Alap építő elemek megvalósításához, mint ilyen-olyan konkurens asszociatív tömb, fa, stb. lesz ez jó. (Ott is csak ha nem használsz lebegőpontos számításokat... érdekes kikötés.)
-
dezz
nagyúr
"Érdekes azonban észrevenni, hogy a Haswell kialakítása milyen elnyújtott. Ez állítólag szándékos, ugyanis úgy tudjuk, hogy lesz a terméknek egy Halo kódnevű verziója, melynél a tokozásra kerül egy DRAM lapka"
Na, hát nem megmondtam! Remélem, az AMD is időben tud lépni (pl. amikor Intelnél már nem lesz ez "brutal extra", mármint árban).
(#65) Löncsi: Azért hülyeség, mert a Llanót eleve leváltja a Trinity. Ja, hogy arról még nem is hallottál!? (Van egy sejtésem, melyik site-on szívtad magadba a "tudást".)Roadmap ügyben nézd és láss: [link], [link] (Az infó jó része régóta tudható.)
(#72): "Az APU-ban is egy dGPU-s chip van"
Az elég érdekes lenne, mivel az APU az 1db chip... Persze értem, mire akartál utalni, csak éppen a fogalmakkal nem vagy tisztában.
Egyébként a Trinity IGP-je 50%-kal erősebb, mint a Llanóé, és az AMD szerint minden generációváltásnál ez lesz.
-
atti_2010
nagyúr
Szóval most azon szenvednek hogy megközelítsék a Llanot, de már a nyakukon a Trinity ami vagy 40% lesz erősebb a Llanonál aztán meg jön a Kaveri, sosem fogják APU-ban utolérni az AMD-t a szimpla CPU-nak meg vége.
[ Szerkesztve ]
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
tombar
senior tag
válasz atti_2010 #141 üzenetére
nagyon valószínű, h ez csak IGP terén fog megvalósulni, legalábbis előfordulni. a 40%ot meg nem érdemes életbiztosításnak venni. ws, hpc és szerver téren még mindig ott vannak plusz az sincs kizárva, h teljesen rossz oldalról közelítik meg a dolgot. egyetlen hibájuk szerintem az, h a larrabeet rossz oldalról erőltették. mondjuk ahogy a konkurens cégekkel bánnak, megérdemelne egy kiadós sallert. szegény nV
Everybody knows, you dance like you fuck. So let me see you dance!
-
atti_2010
nagyúr
Persze szerverekben ők a királyok jelenleg, én most nem azt mondom hogy tönkre megy az Intel de át fog kelleni gondolják az edigi stratégiát.
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
tombar
senior tag
válasz atti_2010 #143 üzenetére
az tény h későn kaptak észbe, csak lapos frontot ugye hamarabb indították a sandyt, ami a gyengécske hd mellet is jól fogy(ott). nagyon átlagban még szerintem elmondható, h valamelyest ki tudja használni a nevét, de komolyabb előrelépések kellenének. meg pl nV optimusát sem kellett volna lelőnie.
Everybody knows, you dance like you fuck. So let me see you dance!
Új hozzászólás Aktív témák
- Kerékpárosok, bringások ide!
- Újabb Samsungok telepíthetik a Galaxy AI-t
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Mindent megtudtunk az új Nokia 3210-ről
- Milyen billentyűzetet vegyek?
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- nVidia tulajok OFF topikja
- Vezetékes FÜLhallgatók
- Léghűtés topik
- Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
- További aktív témák...
- i3 8100/ ingyen automata
- AMD Ryzen 5 1600X
- Beszámítás! Intel Core i3 10105 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen