Nyilván, HA minden összejönne, akkor ez akár egy értelmes irány is lehetNE. A chiplet dizájnból ilyet is ki lehet hozni, aztán majd kiderül, hogy volt-e értelme ennek a próbálkozásnak (valószínűleg nem lesz).

Én kérek elnézést!

Aha . Hát persze

Egyértelműen megfigyelhető, hogy minél több magot és szálat használ egy CPU, annál inkább csökken a használható órajel nagysága. Oka, hogy minnél több magot zsúfolnak össze fajlagosan egyre kisebb területre egyre megoldhatatlanabb a hatékony hűtése. Nem mindegy, hogy egy egy gyufásdoboznyi felületen 8 magot hűtenek vagy 24-32 magot. Muszáj visszafogni az órajelet egyre inkább a hőtermelés miatt. Jó példa, hogy pár évvel ezelőtti világ leggyorsabb számítógépe kínai volt, amihez egy egyedi tervezésű 262 magos procit használtak. egy olyan proci már csak 1,4 ghz-en tudott működni. A második helyen levő amcsi gépben hagyományos szerver procikat használtak a grafikus gyorsítók mellett úgy 500 ezer magot. Persze azok képesk volta 3 Ghz-3,2 Ghz környékén is menni. (talán 16 magos cpu-k voltak benne valami AMD szerver proci) A kínai gép mégis gyorsabb volt összteljesítményben mivel kapott 10,16 millió magot. Vagyis a 16 magos proci tudott azért 3 ghz környékén futni. (lehetett hüteni még) a 262 magos proci már csak maximum 1,4 Ghzen futott.

valami hasonlót csinálnak az ARM-os android eszközök. Amig kicsi az igény a 4 kisbb órajelű és teljesítményű magot használjál, ahogy sokat kell számolni belépnek a magasabb órajelű gyorsabb magok is. De ennek oka nem a teljesítmény, hanem a fogyasztás optimalizálása. Spórolni kell az aksival, ha nem akarja az ember 6 óránként tölteni a telefont.

Két eset lehetséges: vagy ez tényleg a jövő, és az Intelnek van valami varázsgömbje - és működni fog (egyszer) - de ehhez is hosszú szenvedéseken keresztül vezet majd az út. Biztos vagyok benne, hogy messze lesz a maximális hatékonyságától az elején - 1-2 évig.

Második eset, ami szerintem valósabb, hogy kényszer szülte megoldás, Intel sem hisz benne igazán, és ahogy átlépnek 7nm-re ők is dobják ezt a koncepciót. De addig kell valami, bármi, akármi.

Mindkét esetben 1-2 éven keresztül még tuti nem lesz hatékony a dolog, és bőven AMD / Apple megoldások mögött lesz. Aztán meg vagy kidobják, vagy végül is beválik ez meg majd kiderül.

-=Витя=-

Igen ! Ez "zajlik" pár éve pc fronton is. A netto számítási kapacitás növekszik és ez nem is fog megállni. Emiatt menni kell felfele a magok számával, ami viszont az ilyen felhasználás során, amikor tényleg megdolgoztatjuk a procinkat, az órajel csökkenésével együtt kivitelezhető csak. Sajnos ilyen makacs a fizika, de ha még tudnánk is hűteni, a hatásfok (fogyasztás) önmagában is ugyan ilyen irányba sarkallna. Ezzel szemben viszont egy csomó más esetben (legtöbbünknél ez az esetek többsége szvsz) nincs szükség ilyen mennyiségű számítási kapacitásra viszont ilyenkor meg jobb az erősebb mag. (single perf.). Akár az egérkurzor mozgásának "frissessége" is függ ettől ! Aztán meg a játékokban az fps is, stb., stb. Nem hiszem, hogy őszinte lenne a mosolyunk egy 128 magos, 1 ghz-es mini-magos procival. Hiába tudnánk kiszámíttatni 2 nap alatt az élet értelmét.
Emiatt aztán olyan procik kellenek, amik sok magosak, de az elődeikhez képest sokkal, sokkal flexibilesebbek ! Emiatt jó a teljesen független mag órajel, emiatt gyorsítják a boost órajel elérését és ugyan úgy aztán csökken alvó állapotra kapcsolát, stb. Nyílván annyi ztvevő van az egyenletben, főleg pc fronton, hogy itt egyedül, egy processzor gyártóként nem lehet csatát nyerni. Kell még nagyon sok más is, hogy jól / jobban tudjon működni a rendszer.
Ebben a dologban, ebben a változásban az Amd sokkal előrébb jár, ez azt hiszem nem kérdés. Ők ezt jól megérezték, jó volt az elképzelés és jól is valósítják meg ami a tervekben szerepel. Az Intel kicsit "bealudt". Persze, tippre Lisa Su és Chuck Norris -on kívül senki nem számított erre az Amd-re pár évvel ezelőtt, nem csoda, hogy az Intel nem érezte életbevágónak, hogy mélységében változtasson azon, ami egyébként évek óta (évtized) pazarúl ment.Így visszatekintve teljesen másképp látom a Ryzen-eket. Anno nem láttam ezt a "zseinialitást". Jó volt, hogy végre volt egy jobb procijuk, olcsó vot és persze voltak gyengébb pontjai. Aztán jött a Zen2, ami engem részben elsőre megvett. Úgy működött, olyan dolgokat csinált, tudott, amit simán csak élveztem kitesztelgetni. Most az aktuális teljesítményét nem is nézem, de ott is óriásit léptek előre ! Sokkal kevesebb dolog maradt a "De" után, mint hátrány a nagy riválissal szemben és ami lényeges, volt ahol már előnybe is kerültek !! Anno kb. ennyit láttam. Most már látom, hogy itt lett az inf. fabric fegyver ! Itt lett először annyi cache egy prociba (magonként), amit akkor a "nem is rossz" -nak láttam, pedig ekkora cache-ekkel majdhogynem biztosan középszarnak kellene lenni. Ez is egy hihetetlen eredmény volt Tőlük ! Nem is értettem anno, miért beszélt olyan sokat Lisa a cache-ekről és a rengeteg munkáról, amit abba fektettek. A Zen2 mag viszonylag kis módosításokkal aztán odavert Epyc-néven, aztán Threadripper-ként is addig sosem látott szintet tudott és végül a mobil cpuk világába is sikert ért el, talán a legnagyobbat. (nem eladásokra gondolok. Simán csak a cpu tudására, teljesítményére). Ez a nagy baj inkább, azt hiszem Intelnek. Nem tudom, mik vannak ott a tervezőasztalon, de Amd itt, a Zen2-vel rendelkezett egy olyan produktummal, ami bár nem volt az aktuális "gamer-king", a jövőbe mutatott. A kis CCX-enként gyártott, aztán az inf. fabric mentén tetszőleges számban összefűzhető, bármire alkalmas és formálható zen2 magokkal. Sajnos, ahogy Rocket Lake eddig tűnik, ez még mindig nem arra utal, hogy ez már az Intel új, tervezett útja lenne.. Ami nekem és nekünk azt hiszem, usereknek, vásárlóknak nem jó hír. Nekem spec. tök 8, hogy milyen névvel gyártják azt a procit, amire nincs pénzem... És bár érdekel maga a technologia, de mindegy, milyen jó vagy gyors, ha nincs... RKL sajna pont úgy néz ki, mint amire felheftültek' egy kis plusz cache-t (mert nyílvánvalóan óriási jelene van már manapság. Amd "lubickol" az óriási cache-ből kifolyólag. ), de annak ellenére, hogy az L3 nem is változott, már ez is látható negatívumokat hozott. A pozitívumok mellett persze, bár ezek még nagyon korai infok, de kb. alátámyasztja sajnos a "cache duplázás" forgatókönyvét, úgyhogy nagyon is hihető.
Hú ,ez hosszú lett vazze' ! Közben melóztam és mindig írtam pár sort, most meg visszanézem és aztaq' !

arn : " intel 10 magot tud, az amd meg 16ot " mert csak ennyit akarnak, de akár lehetne 64 is vagy nem tudom, mennyi. Láttam pár Zen3 Tr tesztet... pff... De Zen2 alapú Tr-t is nézhetjük, az is nagyon beteg. Igazábol, ha lenne alkalmas szoftver környezet és persze igény meg sok-sok pénz, akár lehetne otthoni felhasználásra is. Kövi gen-be állítólag már lesz 16+ is desktop-ban. Nem tudom, így lesz-e, de pletykák vannak.

[ Szerkesztve ]

https://www.youtube.com/channel/UCbJjHfBdTsUw3UJAFr-5Gsg

Az AMD fogta a macskás magokat(Jaguar, Puma) valamint az FX-et, ötvözte az előnyeiket, ebből született meg a Zen.

Az Intel fogja a netbook és asztali magokat, majd szó szerint egy lapkára pakolja őket, komolyabb áttervezés nélkül.
A miért?-re egyszerű a válasz: mert nem tudnak egy mindenre jó CPU magot gyártani, és látják a piaci rést abban a szegmensben, amire a Zen az Infinity Fabric fogyasztása miatt már nem képes.

Bevállalják hogy a chip fele semmit sem fog csinálni, mert a 14nm-es lapkaterület szinte ingyen van, "pazarolhatnak" vele a jobb fogyasztási karakterisztikáért.

[ Szerkesztve ]

640 KB mindenre elég. - Steve Jobs

Mii? Az Alderben is lesz 14 nm? Ez komoly?

Jo vicc. Inkabb azert van ez, mert az Intel a laptop prociknal nem tudja utolernia az AMD hatasfokat igy kell valami fogyasztascsokkento kenyszermegoldas.

Ugyanarról beszélünk.

640 KB mindenre elég. - Steve Jobs

Igen, csak eppen az az allitas, hogy ott latnak piacot amire a zen mar nem kepes, nem igaz. Arrol van szo, hogy az intel nem kepes arra amire a zen es igy probaljak meg utolerni a zent. Nemhogy meghaladni.

Szvsz sokan nem látják a fától az erdőt.
A felhozott példáid jók. Én még kiegészíteném két dologgal: érdemes megnézni sokmagos tesztre a Threadrippereket, Computerbase-en van egy ahol pl 280W-ról 180W-ra fogják vissza őket. Alig esik a teljesítmény. Süt belőle, hogy sokkal jobb a hatékonyság alacsonyabb órajeleken, tehát kvázi gyengébb magokkal.

A másik a már említett kisfogyasztású/mobil vonal. De kicsit konkrétabban.
Előttem van egy H-s gen 6. Intel proci és egy gen 10 i5. Kevés maggal, 4/4 ill. 4/8-asok. 4 év különbség és ugyanazt tudják kevés maggal. Allcore kb. 3.2GHz 32-35W-ból. (A régebbiben még nincs tiltva az UV, így kevesebb fesszel az 28W-ból is hozza a 3.1-et, az új még ezt sem tudja. ) De a lényeg... CB20 a HT-t leszámítva koppra ugyanaz az eredmény is.
1200 ill. 1500 pont. 35W. 4 mag.

Magamnak Ryzenes notit néznék, most szedtem össze melyik mit tud. (Valamiért a HT nélküli volt a divat Renoirból ami mobilban furcsa, mert minimális többletfogyasztásból jóval több kraftot ad de azért van 1-2 HT-s modell is...)
A lényeg, 15W-ból
4500U (HT nélkül): 2100 pont
4700U (HT nélkül): 2600
4600U: 2600
4800U: 3200

25-28W:
4500U (HT nélkül): 2500 pont
4700U (HT nélkül): 3000
4600U: 3000
4800U: 3800

35-45W felett már kevesebb modell van és elkezd romlani a hatékonyság, de az már a 4000+ kategória.

Tehát ha 25 vs 35W-on nézzük AMD vs Intel akkor egy laza kétszeres szorzót látunk az előző generációk között.
De ha hendikeppel nézzük, 15W és HT nélkül, akkor is impresszív. Nyilván ebben más is benne van (jobb magok, 7nm...) de a lényeg, hogy a nagyobb magszám, alacsonyabb órajel felé haladva egyre mélyül a szakadék. A kevés/erős(magas frekis) mag egyszerűen nem működik. Ez már Zen1-nél is erősen látszott desktopon is, csak a még 95W helyett 140W-os, 4/8-as, üveghangon menő Intelek mellett nem volt annyira látványos, mint most 6-8-10 magnál és 280W-nál.
Notiknál pedig annyival egyértelműbb, hogy itt esély sincs fogyasztásból kompenzálni. És itt az üzemidőn is látszódni fog.

Szerintem sok mindent fordítva látsz ami a mostani nézőpontból érthető de épp ezek változnak. Lásd M1 és úgy általában a mobil/ultramobil világ előretörése.

1. Írod, hogy csak extra teljesítményre optimalizálnak, de fordítsuk meg a dolgot: magkapod a kis/gyenge magokat. Az Intel specekből nem látjuk de az érezhető, hogy jelentős erőt fognak lekötni a kisebb magok is. Nyilván nem maradhat az Intel 4-6 erős magon. Az édeskevés a mostani 8-12 erős AMD mag ellen. Szóval ez előre menekülés ilyen szempontból is.
Ha pedig otthagysz 6-8 kis magot kihasználatlanul mert csak a 4 nagyon fut a progid akkor máris a plusz (30-50%?) teljesítményért kezdhetsz el optimalizálni.

2. Ami szerintem szintén téves, hogy csak teljesítményorientált programok vannak. 10-ből 8 esetben egy rakás app/service fut a háttérben csak, hogy "legyen". Rohadtul nem teljesítményorientáltak, főleg nincsenek rákényszerítve, hogy minden clusteren egyszerre fussanak. Ezeket csak ide-oda pakolni, esetleg fixálni kell és máris nyertek vele, pl. üzemidőt/fogyasztást. Ezeket akár user is állítgathatja... de nem fogja, viszont automatikusan is elég jól be lehet lőni.

3. Hogy ez mennyire számít üzemidőben/fogyasztásban. Ebben igazad van, hogy relatív és inkább hasznosságfüggő. Hiába fogyaszt/tart vmi a matek szerint sokkal jobban ha nincs rá szükség. Lásd: kibírja 1 napot a noti, csak telefonnál érdekes, stb...
Ha megüti azt a szintet ami elvárt akkor nyilván ebbe senki nem fog extra költséget beletolni.
De szvsz nem itt tartunk. Épp most léptünk notiknál is át ebbe a szegmensbe, hogy desktopot váltanak ki, az ultramobil is folyamatosan erősödik de nyilván mindkettőben lehet szintet lépni, ahogy most is történt. Ha 3-5 naponta kéne tölteni, még erősebb lenne (mert energiahatékonyabb), esetleg 2 év múlva arról beszélünk, hogy nem a notik érték el a desktop szintet hanem a telefonok... ehhez szükség van ilyen szempontból is előrelépésre.

A Zen szokott példa lenni, hogy megmaradt a magas egyszálas teljesítmény, mellé ott a sok mag és az üresjárati (vagy inkább light load és ez szerintem fontos) fogyasztás is oké.
De ez sem magától jött. A chipletes, IF-es dizájn pl minden csak nem energiahatékony idle közelben. Mindennek mennie kell, nem véletlen, hogy a mobil procik monolit felépítésűek és ebben is folyamatosan lépkedünk előre. Pl. a Renoir nem tud feszskálázást sem magonként.
Pl. nálam Zen+-tól (2700) "idle" 70W-tól most 42-ig ment le Reonirral. Dvga nélkül már 28W.
HDD-t, ventiket kirakva, újabb chipsettel már valahol 15W körül lenne. De ez hw oldali főleg, ami érdekes benne, hogy mi az "idle":

4. És ez lenne a lényeg amiért szvsz sw oldali optimalizálásra biztosan szükség van.
A 70W elég soknak tűnt, sikerült kisakkozni, hogy 2db tálcán futó "semmittevő" progi a bűnös. Nélkül 50W alá megy a fogyasztás. Taskmgr-ben azt látod, hogy a proci 0.5-1% között ugrál, mégis ha kilövöd őket akkor -20-25W.
Közben persze másik 10-15 tálcás progi (meg pár 100 háttérfolyamat) ugyanúgy fut.
- Ez hw-ből megoldhatatlan.
- Sw oldalon igazán az adott sw-ben kéne erre gyúrni, hiszen gyakorlatilag ezek "szarul" voltak megírva. Ez szerintem már véleményes, hogy hány usernek tűnik fel és fog-e a fejlesztő "optimalizálni" 0 teljesítményelőnyre is. Szvsz fog, ez olyan szint ami áltagusernél is feltűnik az üzemidőben. Plusz magad írtad, hogy telefonoknál ez működik... de miért? Azért mert ott ez is - erős - része volt a hasznossági faktornak. Ha itt is előjön és kritikus akkor foglalkozni fognak vele.
- És megoldás lehet még a külső ütemező ami a kettő között van. Nyilván csodát nem tud tenni de ilyenkor egy kisebb prioritás, kisebb magra való átrakás azért bőven segíthet.
Ezt viszont elég körültekintően kell megoldani ill. minél inkább az adott sw felé elvinni a megoldást, mert hátránya is lehet. Épp ez az ami miatt a hw közeli megoldások nem jó hatékonyságúak.
Írtad, hogy ennek desktopon nincs jelentősége. Szvsz ilyen szinten ott is van, ill. ha ezek nem működnek megfelelő hatékonysággal akkor annak ilyen kézzelfogható eredményei vannak.
Sokáig ment a Ryzen energiasémák körüli vita is. A fenti problémára pl. egy konzervatívabb séma (fél)megoldást ad. Cserébe viszont brutálisan lelassítja a rendszert reszponzivitásra. Erre születtek anno a kimaxolt sémák: cpu min freki az egekben, core parking letiltva, IF/memória nem vesz vissza, PCIe L1.1-1.2 letiltva, stb...
Ezek off-ra rakva valóban 0 (ami nincs) terhelésnél lehet, hogy nem sokat zavarnak, de valósan, minimál terhelések esetén rendesen rátesznek a fogyasztásra.
Alapból nem csoda, hogy engedélyezve vannak, úgy viszont közel sincs meg az a teljesítmény amit megszoktunk és szerinted is musthave. Power saver sémában egy sz*ros TotalCMD 2mp-ig nyílik meg NVMe-ről 6/12-es gépen. A böngészőindítás hasonló, szintetikus 4k IOPS-okat sem érdemes méregetni, stb...

Ebből elég jól látható, hogy ezt sw oldali támogatás nélkül nem lehet megoldani.
És akkor még nem tartunk ott, hogy hiába desktop. A tömegigény az, hogy ez (minden) mobilon és ultramobilon fusson.

Szóval összegezhető az egész úgy, hogy most is látszik, hogy
1. Nem elég a meglévő mindentudó hw (erős, takarékos és gyorsan frekit/feszt/állapotot váltó) cpu. Ott sem ahol nem lenne jelentősége, mert ott sem tud mindent ami papíron menne neki (max erő vs energiahatékonyság, ill. van a kettő között is élet: sőt, 99%-a ott van, nem a max perf esetekben).
2. Ahol jelentősége van (mobil) ott pedig el is vérzik még sok esetben.
3. Az sw támogatást emiatt úgysem ússzuk meg, most sem váltja ki a hw oldali.
4. Ezt pedig hw oldalról olyan extrával megtámogatni, mint hibrid felépítés akkor már adja magát. (ahogy az eddigiek is hasonlóan adták: több mag, alacsonyabb freki: ez ugyanaz pepitában bár nyilván sokkal egyszerűbb sw oldalról...)

Nem arról van szó, hogy otthagyok 6-8 gyenge magot kihasználatlanul, hanem aki jelenleg párhuzamosított szoftvereket ír, nem tesz különbséget kicsi és nagy magok között, mivel jelenleg ez desktopon nincs. Ahogy a .net sem tesz, így ha akarnék se tudnék, mivel .net fejlesztő vagyok.
És lehet, hogy teljesen az lesz az irány, amit írsz, de ettől függetlenül se érzem azt, hogy egy fejlesztő minek is tenne bármiféle energiát abba, hogy külön használja a gyenge és erős magokat. Egyszerűen nem érzek semmiféle nyomást ebbe az irányba. Hogy az intelnek jó legyen? Hát gondolhatjuk, hogy ez senki sem érdekel az intelen kívül.
Azt simán el tudom képzelni ha én fejleszteném az Androidot, akkor mindenképpen használnám a kis magokat a rendszer üzemeltetéséhez, amikor a telefon zárolva van és a user nem csinál vele semmit, de egy csomó dolognak menni kell úgy is, hiszen ez jelentősen növelném a rendszerem használhatóságát és értékét.
De pc-n? Egyetlen olyan helyzet sem jut most eszembe aminél ennek értelme lenne.

szvsz ezt meg lehet oldani, csak akkor a 8+4 magos mag tenylegesen tobbnyire negy magoskent viselkedik, kiveve, amikor az osszes magot eleresztik.

facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld

A szoftver írója arról sem rendelkezik, hogy melyik magon, stb. fusson az aktuális rendszeren. (mármint a konkrét címzésről) Nem Ő dönti el, hogy a szabad magok / szálak melyikén fut, mert nem is tudná, hiszen ehhez tudnia kéne az aktuális felhasználásnál a mellette futó, egyéb programokat is. Ezért van az ütemező többek közt, ami viszont megmondja, hogy Te fiam ide ménsz, Te meg oda.

[ Szerkesztve ]

https://www.youtube.com/channel/UCbJjHfBdTsUw3UJAFr-5Gsg

Valószínűtlen, hogy alkalmazás fejlesztőktöl bármit várnának, talán eltekintve nagyon széles körben használtakétól (mint böngésző). 8 big + 8 little az 16 mag és kész. A többi az OS ütemező dolga.

Annyit tudok elképzelni, hogy ha akarod (és amit használsz támogatja), akkor megjelölhetsz egy szálat, hint jelleggel, hogy nem kell vele sietni. (Szál prioritás mondjuk mindíg is volt Win32-ben és Java-ban is, de talán erre valai új flaget kéne használni inkább.)

Ill. azért van az a gond, hogy néhol azt csináljuk (vagy hát a framework azt csinálja), hogy annyi egyenlő részre vágjuk a feladatot, ahány mag van. De mivel a fele little magra esik, nem ideális, hogy egyformákra lettek vágva. Bár ami azt illeti, eleve erős tipp csak, hogy egyszerre lesznek kész, és ezért inkább több kisebbre vágunk, és akkor amelyik szál már unatkozik, az kapja a következő darabot...

"A 70W elég soknak tűnt, sikerült kisakkozni, hogy 2db tálcán futó "semmittevő" progi a bűnös. Nélkül 50W alá megy a fogyasztás. Taskmgr-ben azt látod, hogy a proci 0.5-1% között ugrál, mégis ha kilövöd őket akkor -20-25W."

Ez elég érdekes. Mik voltak ezek konkrétan?

Elég off, de mégis van kapcsolata a témához ! Nem tudom, hányan ismerik az Amd Cppc/Cppc2 rendszerét és az ehhez kapcsolódó új windows ütemező működését ? [Anno készítettem erről egy video-t] és bár ma már teljesen másképp tesztelném és más dolgokat is emelnék ki, mentésgemre szóljon, hogy akkoriban (1 éve volt) vajmi kevés info volt erről. Nem mintha manapság hemzsegne tőle a net... A lényeg, hogy Zen2-nél erre amiatt volt szükség, hogy csökkentsék a Ccx-ek közti "fölösleges" adatküldéseket oda-vissza, mivel az nagyon rossz hatással van a teljesítményre. A korábbi, egyenletes magok közti elosztásos módszer helyett egy preferált magos rendszert csináltak, ahol a kissebb számozású magokról indulva, súlyozottan "tölti fel" a többit munkával. Cinebenchet használtam, mert ennek modellezésére nem igazán tudok jobbat, bár tény, hogy ez sem tökéletes, mivel fix számú szálat terhel, de a lényeg így is látszik. Ha esetleg valakinek van jó ötlete, mivel tudnék szabályzott cpu terhelést előállítani (pl. 20, 30, 50%) úgy, hogy nem kötöm szálakhoz azt megköszönném !
4 szálnál az egyik CCX teljesen üresjáratban van, 8-nál 2 mag, magonként 1-1 szálon terhelődik, miközben a jobbik CCX-ben a 2 legjobb mag folyamatos 2 száals terhelést kap, stb. Természetesen ez a megoldás sem jobb minden esetben, igenis vannak olyan alkalmazások, amik a Zen2 felépítés dacára jobbak lennének a hagyományos módszerrel, egy csomó másik esetben viszont ez adja a jobb teljesítményt. Itt olyan megoldás, ami mindig, minden esetben javít nem hiszem, hogy van és nem is lesz. Annyira egyszerű módszernek kell lennie, amennyire csak lehet, hiszen az ütemezésnek villámgyorsnak kell maradnia. Nem lehetnek benne mélyreható vizsgálatok, bonyolult algoritmusok, stb. Egyszerű, terhelés alapú kiosztás kell legyen. Amit lehet súlyozni. Ez egyébként régebb is része volt. A HT képes magok, mikortól kapjanak 2 szálas terhelést. Alacsony terhelésnél még nem "erőltette" a HT-t, ha nem volt muszáj az ütemező.

https://www.youtube.com/channel/UCbJjHfBdTsUw3UJAFr-5Gsg

Ez a mostani azért trükkösebb szituáció, mert nehéz objektíven értékelni, hogy mennyira jó a végeredmény. CCX meg HT gondoknál a cél egyértelműen csak az, hogy minél hamarabb kész legyen a feladat. Itt viszont, választandod kell, hogy magasabb sebességet akarsz, vagy takarékosabb működést, és nehéz eldönteni, hogy adott esetben a felhasználó észreveszi-e, ha az utóbbit választottad.

"Itt viszont, választandod kell, hogy magasabb sebességet akarsz, vagy takarékosabb működést, és nehéz eldönteni, hogy adott esetben a felhasználó észreveszi-e, ha az utóbbit választottad."
És biztos lehetsz benne, hogy ha az utóbbit választod, előbb-utóbb jönnek a user hack-ek, amivel a választásod felülbírálják... és természetesen vice versa...

[ Szerkesztve ]

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.

Igen, ez nem lesz ennyire egyszerű (Cppc-re is várni kellett elég sokat ) szerintem sem. Az is kérdéses még, hogy ez a 2 rész mennyire tud majd egyszerre ill. összedolgozni. Közel sem biztos, hogy pl. ide-oda lehet majd adogatni task-eket illetve, hogy ha lehet, nem lesz botrányosan lassú emiatt. Ott gondolom 2 különálló cache struktúra, stb. lesz, szóval nagyon nem tűnik "simának". Amit leginkább mutatni akartam, az az, hogy egy esetleges task manager-beni működésnek nem lehetnek olyan hűde bonyolúlt kritériumai és nem végezhet mélyreható vizsgálatokat, mielőtt "kiutalná" az adott műveletet valamelyik szálra, mert akkor megette a fene. Gyorsnak, emiatt nagyon egyszerű szabályok által vezéreltnek kell maradnia. Kíváncsi vagyok rá mindenképp, minden oldalról !

CCX-nél inkább a nagyon rossz "cross-ccx" címzések minimalizálása volt a cél. Természetesen egy jobb magra rakni preferáltan a műveleteket jár némi teljesítmény és/ vagy hatásfok növekedéssel is, de ehhez nem kellett volna ennyire erősen súlyozni egy pontra.

Kansas : "És biztos lehetsz benne, hogy ha az utóbbit választod, előbb-utóbb jönnek a user hack-ek, amivel a választásod felülbírálják... és természetesen vice versa..."
1000X !!

[ Szerkesztve ]

https://www.youtube.com/channel/UCbJjHfBdTsUw3UJAFr-5Gsg

Akinek erre van valós vagy akár csak pszichés igénye, ám tegye. Ha nem rontják el feltünően, akkor a legtöbb user hagyja alapértelmezetten, elvégre azt se tudja, hogy ez az egész hibrid dolog az létezik.

Egy mai CPU szerintem bőven túl gyors tud lenni kb. bármilyen körmönfont ütemezési szabályhoz. Persze itt a gond az információ hiány, avagy hogy ki lehet-e találni elég jó heurisztikát. Pl. látsz egy szálat, ami közel 100%-on teker kis ideje. Na most akkor az sürgős, mert érzi a felhasználó (pl. amiatt 0,5 helyett 1 másodpercig vár egy UI-s visszajelzésre), vagy tökre nem figyel arra, amit az csinál? Ki tudja...

Az intel jelenleg mindennel nagyot kockáztat.

Szerencsére nem. Ha a Big-Little koncepció nem válik be, attól még nem megy csődbe a cég, továbbá már sok éve tesztelnek MCM megoldásokat Intelnél is. Pl. Nvidia részéről is a hopper széria már eleve olyan lesz, mostanság meg pletykálgatnak 2 chipes Intel DG2-es csúcskártyáról 960EU-val.
A következő 1,5-2 évben már minden bevethető újdonság megjelenik Intelnél is, így nem lesz ekkora szakadék sem.

[ Szerkesztve ]

A fejlődés üteme ami számít, ami meg talán leginkább a céges kultúra kérdése (ha amúgy van elég pénz). Szóval ki tudja, hogy 2 év múlva behozza, vagy az AMD még jobban elhúz tőle.

[ Szerkesztve ]

Ha megnézed a készülő Ponte Vecchio-t, akkor láthatod, hogy a cég történetében az eddigi legambíciózusabb termék, és több tekintetben elveri majd a Tesla kártyákat is. Ennek alapján a 2022 és 23-as év sokkal izgalmasabb lesz szerver fronton is(a Sapphire rapids procikba is minden újat beraknak), egyébként már az Alder Lake is nagy ugrás, amire összpontosítanak idén. (2 és 8 mag között lesz Gracemont nélküli változat azoknak, akik nem akarnak fejfájást, aztán a Raptor Lake frissítésnél talán lesz 10 nagy magos változat is.)

És mindeközben az AMD csak malmozni fog, az Arm meg visszafejlődik. Ja, várj...

Én kérek elnézést!

Látom nem jött át a lényeg: AMD szemszögéből ekkora előny 2 év múlva már nem lesz, erre fel is készülnek addigra. Intelnek van elég pénze, hogy a lemaradását jóval gyorsabban lefaragja, mint a Bulldozer bukás után az AMD. Ez nekünk végfelhasználónak pont jókor jön, mivel az AMD idén és jövőre kellően megszedi magát zsozsóval.

Értettem én, csak én meg azon a véleményen vagyok, hogy ha 1 nő 1 gyereket 9 hónap alatt hord ki, akkor hiába raksz oda 9 nőt, akkor se fogják tudni 1 hónap alatt kihordani a gyereket.

Amúgy meg a verseny abszolút jó nekünk, mivel mostanra meg az AMD kezdett elszállni az árakkal. Szóval szurkolok az Intelnek, de a csodákban már nem hiszek.

Én kérek elnézést!

Ez jóó
Egyébként én is azt látom, hogy a pénz és szándék még kevés.

[ Szerkesztve ]

kíváncsi vagyok a memóriavezérlés mennyire lesz milyen... határozottan emlékszem hogy ilyen heterogén ARM rendszeren szórakoztak emberkék azzal hogy natívan futtattak rajta standalone oprendszereket. most nem ugrik be konkrétan mi volt de egy olyanra emlékszem pl hogy a két kicsi magon ment egy OpenBSD a négy nagyon meg Linux, kíváncsi vagyok ilyet meg lehet-e majd csinálni ezeken a heterogén x86 procikon.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Van még rakás közös erőforrás (I/O, intterruptok, stb.), felteszem ARM-os megodásoknál is. Ehhez hypervisor kell. Ilyen szempontból ez olyan, mint egy akármilyen többmagos processzor.

nyilván van más is. ARM SoC-ok között van olyan ahol szinte teljesen külön lehet őket használni hypervisor nélkül. bár ebben az esetben sejthető hogy nem erről lesz szó.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)