Az Intel részéről az egész egy igen jelentős kockáztatásnak fogható fel, hiszen lényegében az Alder Lake sikerét teljes mértékben a szoftverfejlesztőktől teszik függővé.

Erre építeni eléggé merész vállakozás, tennék egy nagyobb összeget arra, hogy ez nem fog beválni a kékeknek.

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak

Valószínűleg hasonlóan sikeres lesz, mint a Buldozer elképzelés az AMD-nél. Technológiailag érdekes, de a gyakorlatban zsákutca.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

Szerintem 10 év kb. és lehúzzák a rolót, vagy IBM sorsára jutnak. Egy ryzen 3 pro 4450U lapost kaptam certifikációra, ami veri a 10.generációs corei5 U-s cpu-kat és még a i7-eseket is megszorítja. És a gép fele annyiba kerül,mint az inteles Enterprise variánsai. Ez a mag terhelés függő dolog meg nem fog menni szerintem, mert a programozói éra az már nem arrló szól ezer éve, mint régen. sehol sem szempont már az optimalizáció. (Persze tisztelet a minimális kivételeknek)

És mondá az Úr: És legyen immáron a kocka, tetraéder!

"Az Intel részéről az egész egy igen jelentős kockáztatásnak fogható fel, hiszen lényegében az Alder Lake sikerét teljes mértékben a szoftverfejlesztőktől teszik függővé."

Akkor az Intel történetnek itt a vége No persze gondolom a háttérben azért dolgoznak máson is, csak most hirtelen nem tudnak jobbat, mint ezt a koncepciót elővenni.

Én kérek elnézést!

én is szkeptikus lennék, ha out of the box nem működik valami, hanem szoftveres támogatás kell. a többszálúsítás is hosszú évekbe telt mire jutott valahova.
amúgy androidon miért működik? legalábbis feltételezem működik mert ott elég divat a különböző magok keverése.

An open mind is like a fortress with its gates unbarred and unguarded.

Nem feltétlen, de a Ringbus felépítés 10-12 mag fölött a növekvő késleltetés miatt elveszti előnyét az Infinity Fabric-kal szemben. Viszont lesznek atom mag nélküli variánsok minden kategóriában, ahol nem lesz meglepetés.

Én innen nem látom ezt annyira kockázatos lépésnek, mert: worst-case: senki nem csinál semmit a szoftver támogatás érdekében, a problémába futott és magára maradt user még mindig:
a; vehet magasabb TDP kategóriás processzorral szerelt gépet,
b; megpróbálhat maga profilt gyártani a gyengén futó alkalmazáshoz.

Kérdés az, hogy a vásárló bázis mekkora része fog-e ebből az egészből bármi negatívat észre venni, illetve ezek az emberek közül, mennyien határolódnak majd el az a, vagy b, megoldástól, mert ezeket a vásárlókat vesztheti el.

[ Szerkesztve ]

Óriás bukta lesz. Kb akkora mint a win 8.
Teljesen vakon vannak. Egy fejlesztő sosem optimalizálna lefele. Csak felfelé szoktunk. Azaz azért optimalizálok, hogy gyorsabban fusson egy program. Azért nem fogok dolgozni, hogy kevesebbet fogyasszon egy laptop, mivel ezt nem a programom számlájára fogják írni.
Androidon meg azért lehet ez sikeres, mert az oprendszer marha jól ki tudja használni ezt, amikor a teló a zsebben van és csak alapfunkciókra van szükség, ahol a lassúság sem gond.

Mert Androidon nem 30+ éves alapokra építkeztek.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

win8 nem bukott meg, csak a win7fanok hisztériáztak!

"amikor valaki baromságokat beszél, megszületik egy unikornis"

a Buldozer is a programozókon bukott meg, pedig ott is volt értelme a 2*128bit-es fpu-nak, amit össze lehetett fogni 256bit-es utasítások feldolgozására is, csakhát nah... programozók nem mentek utána, és itt is ez lesz...

Igen, pontosan erre gondoltam én is.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

ha valakinek van eleg penze es befolyasa a piac felett akkor az az intel, akar meg sikerulthet is nekik, jo pozicioban vannak hozza.
marpedig igyekezniuk kell mert az apple m1-bol akarmi is lehet 3-5 ev mulva es AMD sem ugy tunik hogy levette volna a labat a gazpedalrol....kezdjuk elerni az "energiahatekonysag korat" amikor mar nem a nyers ero szamit, mert az emberek 90%at a telefonjaban levo szamitasi kapacitas siman kielegiti.

amikor a 4750u 23w-bol hozza a vizhutott 3700x+PBO(no power limit) teljesitmenyenek 70-80%at...

copass: win8 rossz tegelybe nyultal a reggeli fustolnivaloert, szerintem teafuvet szivtal...

[ Szerkesztve ]

It's gotta feel so good to moo as a cow. Probably feels really good to moo

Majd egyszer ha az AM4 foglalat CPU-i már nem lesznek elég gyorsak, és új PC kell, akkor elgondolkodom, hogy Intel vagy AMD. (vagy esetleg egy ARM, vagy egy még újabb szereplő?)
Most ez így annyira sem érint, mint hogy mennyi WC papír maradt az Auchanban.

Csak azt nem értem mire gyúr ezzel az intel? A leghosszabb üzemidőre? Mert nyilván a teljesítmény esélytelen ebben a felállásban. Viszont már ma is simán elérhetőek olyan laptopok, amik egész nap bírják. Ennél hosszabb üzemidőre már csak nagyon speciális esetekben lehet szükség.

Androidon is főleg addig működik, hogy az alkalmazás kiválasztja az egyik klasztert. Olyan program alig van, ami mindegyik magon fut, általában vagy a nagy vagy a kisebb magokat célozzák, de az összeset egyszerre szinte semelyik, mert túl nagy munka foglalkozni az eltérő késleltetésekkel.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Hát épp ez az, hogy Androidon se igazán működik jól a dolog. Vagy az egyik clustert használják a progik, vagy a másikat. Legalábbis többnyire, és nagyon kevés az olyan eset, amikor ténylegesen hibridként mindkét cluster meg lenne hajtva.

Oh, és most látom Abu is pont ezt írta

[ Szerkesztve ]

Én kérek elnézést!

köszönöm a válaszokat, hasznos infó volt. eddig azt hittem jobban kihasználják ezt, főleg hogy pl a snapi 888 már háromféle maggal jön. hát akkor PC-n sok szerencsét hozzá intelnek

An open mind is like a fortress with its gates unbarred and unguarded.

AMD-nél nagyon örülnek az Alder Lake-nek az tuti.

Nem, az Intel számára a worst case az, hogy a konkurenciától vesznek procit az Intel helyett, aki lehet hogy nem ad pl. 2 nagy + 8 kicsi magot a 9W-os TDP-szinten, hanem ad 4 nagy magot(esetleg HT-vel), ami külön-külön elveri teljesítményben a 2 nagy magot is meg a 8 kicsit is, cserébe nem kell foglalkozni a különböző magokra való optimalizálással.
De mintha ezt írta volna Abu is az utolsó bekezdésbe...

[ 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.

Vegul is az Intel megtehetei. Elvegre az elmult 2-3 evben is minden osszejott neki.

Addig gyorsítottuk a világot míg mi magunk maradtunk le...

Ez "Atom" bomba lesz, csak nem oda ahova szánták.

Az API és az ütemező sokat segít(het) a dolgon. A fejlesztők kb. nem foglalkoznak vele semmit. Ezért is naív elképzelés, hogy most majd nekiállnak a fejlesztők ... de minek is állnának neki? Egy Office bonyolultságú alkalmazásnál majd totózni fognak, hogy ez a metódus most 1-2-X? Évekig ezzel szórakozhatnának. Ráadásul az esetek többségében ha elől fut akkor kell a kraft, ha háttérben fut akkor is kell. Csak akkor nem kell ha készenlétben is fut.
Egy M1 port is hónapokig (lesz akinek évekig) tart.

Szerintem elég, ha az MS-el megegyeztek.
Ha a win+böngésző+office+víruskereső+videó lejátszó fut a kicsi magokon, megnőhet annyira az átlag üzemidő, hogy a vevők ezt választják.

Nagy raktár kis helyen! Anyagáron eladó ~200m hosszú rakódófelületű gördülő polc rendszer. A helyigénye csak 3.6m*1.4m. Akár egy lakáscserét is megspórolhat vele!

Én ezt azt hiszem inkább kihagyom. Megvárom a másokon kísérletezés milyen eredményt hoz.

Ha volna sonkánk, akkor csinálhatnánk sonkás tojást, ha lenne tojásunk!

Hat nekem a böngésző + office + win ne a kicsi magon fusson
Video + virus mehet, de ha emiatt akadozni kezd mert a viruskereso a lassu cpu-n fut, de nyilvan amig nem vegez addig blokkolja a file hozzaferest, akkor az sem lesz jo.

[ Szerkesztve ]

OK

Nem az a kérdés, fut-e, hanem hogy milyen gyorsan, illetve tud-e egyszerre futni az összesen...
Ha nézed, mi áll a cikkben az utolsó előtti bekezdés utolsó mondatában, az már most meg van/lesz oldva, hogy csak a kis magokon fusson, sőt a kisebb 1C-s és 2C-s procikon az a default a hibrid működést nem támogató alkalmazásokban.

[ 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.

Szakadt intel csak ennyire képes? Komolyan anyagilag sokkal jobban áll mint az AMD... nem igaz nem képes valami értékelhetőt letenni az asztalra. 14 nm++++++++++

Idén jön az asztali Alder Lake-S is 8+8 maggal, de a hír hallatán ez csak marketing jelegel jön. Így mondhatja az intel nekik is van 16 magos procijuk, a kérdés hogyfog élesben teljesítani?

Ha éveken át így fognak tökölni valóban egyszer oda jutunk az AMD behozhatatlan előnyhöz fog jutni.
Ott a 5900/5950X ami ellen az intelnek még nagyon sokáig nem lesz válasza.

Hiába szúr, itt Ryzen a úr!

a dolog sikeressége igazán egy dolgon múlik. Mennyire sikerül optimalizálni hozzá a rendszerek erőforrás ütemezőit, hogy kihasználják rendesen a hibrid magok előnyét. Tehát, hogy optimálisan a nagy teljesítményű program ágakat a gyors magon akarja futtatni. Vagyis fel kéne hozzá okosítani a windows vagy más rendszerek erőforrás ütemező részét. Tavaly nyáron adott ki a az intel korlátozott számban egy 4+1 magos hibrid procit. Ahol 4 normál mag volt és egy gyors mag. Akkor a gyakorlati mérések alapján nem jeleskedett a windows, hogy a gyors magot eredményesen össze hozza a legnagyobb teljesítmény igényelő folyamatokkal. Vagyis korántsem volt optimális a proci kihasználás.

ott sem működik azért kifejezetten optimálisan. például nekem olyan telefonom van ami 4 gyors magból(2,16 ghz) és 4 lassabb(1,6 ghz) magból áll. Elméletben egy magon képes a 2,16 ghz helyett felmenni 2,36 ghz-ig. Ez az elmélet. A gyakorlat az, hogy a futó alkalmazások igen ritkán használják ki a maximálisan elérhető sebességet. Az esetek döntő részében egyszerüen be se kapcsolnak a gyors magok. Ennek gondolom alapvetően energia takarékossági okai vannak. Spórolni kell az aksival. Igaziból csak pár alkalmazás, néhány játék van ami jobban kihajtja a teljesítményt a prociból. Ilyenkor lehet érezni, hogy pár perc után elkezd langyosodni a telefon hátulja. Vagyis azt kell mondanom egy andoidos rendszer is csak nagyon lagymatagon teszi oda a program alá a kakaót. Inkább lébecol csak, ha teheti.

Ha az AMD igy halad, akkor kb 8 ev es annyi beveteluk lesz mint az Intelnek.

A buldozernek azért volt némi hardver hibája is. Elvben nem szálasított proci volt. Vagyis optimális teljesítménnyel kellett volna menni. Viszont valamilyen gyártási okból úgy volt felépitve, hogy a nem szálas proci magok 2 magos csoportokba voltak összefogva. Például egy 8 magos Buldozer proci esetében 4*2 mag volt a felépítés. Aztán ehhez a 2 magos csoportokhoz egy közös gyorsító tárat rendeltek hozzá. Vagyis a 2 magnak osztozkodni kellett a közös cache-n. Amivel gyakorlatilag pont úgy megvalosították a több szálas mag hátrányát a egy mag két szálat. Ott is az okozza a teljesitmény vesztést, hogy a közös gyorsítótárt adott pillanatban nem tudja a két program szál egyszerre használni. Így ha az egyik program szál mondjuk adatot akar olvasni a cache memóriából, akkor a másik programszálnak ki kell várni pár gépi ciklust, mikor felszabadul a számára is a cache memóriához hozzáférés. Ez okozza azt a lassulást, hogy szálasított proci teljesitménye kisebb. Ha egy mag teljesítménye 100% és a 2 mag teljesitménye 200% mondjuk, akkor a 1 mag 2 szál esetében úgy 160-165% körül van a teljesítménye. Na ugyan ezt a teljesítmény vesztést valósitották meg a buldozer proci 2 magonként hozzá rendelt közös gyorsító tárral. Ráadásul voltak teljesítmény gondok a 2 magos csoportok és a fő memória közti adatátvitel sebességével is. Ez okozta, hogy hiába volt elvben egy buldózer proci 8 magos a gyakorlatban úgy viselkedett, mint egy 4/8-as proci és azt a teljesítményt is hozta lemaradva az intelek mögött. A ryzenek estében ezt javították valamilyen szinten, ezért is gyorsabbak a ryzenek összes magon és szálon kihajtva az hasonló intelekkel szemben. Ráadásul valamilyen okból gyengébben muzsikál az Intel többszálasítási megoldása a HT, mint az AMD többszálasítási a SMT... Nem véletlenül nyomatta sok évig az intel a 4/4, a 6/6 és a 8/8 szálasítás nélküli procikat. Remekül felismerte, hogy a többség amúgy is játszik a gépen, amihez tökéletes a 4-6-8 mag. Aztén valamikor a 9-10-ig generációban kénytelen volt visszahozni a többszáluságot, mert más alkalmazásban tarthatalan volt, ahogy egy 16 -24-32 szálas AMD asztali proci hülyére veri teljesítményben az inteleket, ha sok magos és szálas alkalmazást kellett futattni. Ezért kénytelen volt nyitni a több száluság fele, hiszen a világ nem csak játékból áll. De a HT hátrány most i meg van az SMT-vel szemben.

Eleve probléma, hogy amikor az ember használja a gépet, nem akarja, hogy bármi lassú legyen, ergo ilyenkor semmi haszna nincs a kisebb magnak. Telefonon még létezik a készenléti üzemmód, amikor a user nem csinál semmit csak az oprendszer a háttérben és ilyenkor tényleg van értelme kicsi magoknak. De ilyen pc-n nincs.

És arra is kíváncsi lennék mivel lehetne meggyőzni akárcsak egy fejlesztőt is, hogy álljon neki optimalizálni olyan procira, amiből a piacon jelenleg 0 darab van és még a programja sem lesz gyorsabb tőle. Ráadásul ha mégis meg akarná csinálni ezt bárki, vennie kéne minimum egy olyan gépet, amiben ez van, tehát még költenie is kéne rá.
Hát ez tuti bukó. Nem tudom hol élnek ezek!

Ezenkívül a Bulldozerben a végrehajtó egységek egy része is közös volt a 2 közösködő magban , csak akkor adott optimális teljesítményt, ha a fordító,ütemező erre tekintettel lett volna. Nem nagyon tudok olyan programról, ami ezzel tényleg foglalkozott.
Azt az előnyt,hogy 6-8 magot adott az AMD 2011-ben, szintén nem használta szinte senki.

Többszálú feldolgozást jelenleg is sokat használok a programokban jellemzően tömbösített adatok feldolgozásánál. Ilyenkor annyi egyenlő csoportra osztom az adatokat ahány szál van, majd amikor az összes elkészül, összesítem az eredményt és visszatér a program.
Viszont ha egyetlen szál is lesz, ami lényegesen lassabb mint a többi, akkor kb, az egésznek a teljesítménye annyi lesz, mintha minden a leglassabb szálon futna.
És ez egy gyakori módszer. A .net paralell framework is pont így működik.
Szóval ilyen párhuzamosított programok esetén kb csak hátrányt fog jelenteni az Alder.

[ Szerkesztve ]

Pont ezen gondolkodtam, hogy mennyivel nehezebb különböző teljesítményű szálakat összehangolni...
Ez is jó : a 15W kategóriában -ez a legelterjedtebb - az I7 változat 2C+8c kiépítésű, azaz igazából 2magos. Már azt hittem,végleg megszabadultunk a 2magos I7-től ,erre most visszaszivárog.

a fejlesztok nagyresze eddig is kiemelten ugyelt ra, nehogy barmit is optimalizaljon, -- az AMDnek voltak proci es videokartya fronton is ilyen otletei, egyik se lett nepszeru -- most miert lenne maskepp ?

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

azért ha megszaporodnak a hibrid magok, akkor az meg fog jelenni a fordító programokban is. Utána csak annyi a dolga a fejlesztőnek, hogy mikor fordítja az alkalmazást bekapcsolja az optimalizálást a hibrid felépítésre. Bár ennek valami olyasmi előfeltételét látom, hogy magának a programozónak kéne valamilyen módon minősíteni adott program szálat, hogy milyen erőforrás igényű az adott program ág. Például valamilyen bejegyzéssel a programág elején az adatoknál. Például egy direktívával, ami megmondaná, hogy adott programszál az alacsony, közepes vagy magas erőforrás igényes. Ami valahogy belefordulna a gépi kódba, amit aztán a rendszer erőforrás ütemezője tudna kezelni és akkor igyekezne a nagy számítás igényű program szálat a gyors magokra rakni a kisebb prioritásúakat meg a normál magokon használni. Elvégre legoptimálisabban mégis csak a program fejlesztője tudja megbecsülni, hogy a programja melyik része mennyi teljesítményt igényel. persze tehetné azt is, hogy minden programágat magas prioritással lát el, de akkor lehet magával baxna ki, mert lehet, hogy a kis teljesítményt igénylő programágat akarná ráerőltetni a gyors magra a rendszer és a nagy teljesítményűt a gyengébb magra. A másik megoldás meg az volna, hogy a rendszer figyelné a futás elindulása után, hogy melyik programág mennyi időt használ futásra, amiről készitene egy statisztikát, ahol minősíti maga a program ágak erőforrás igényét. majd egy idő után ez alapján probálná meg összehozni a magok teljesítményét a programszálak igényével. A dolog hátránya, hogy kell némi idő mire előáll futásközben egy használható teljesítmény statisztika és nem biztos, hogy minden programszálra egyből sor kerül és annak minden teljesítmény igénylő része neki áll futni. Simán lehet olyan programot irni, ami elindit egy feladatra valami program szálat majd valami feltétel teljesülése esetén máshogyan számol más részét használva a programágnak egy másik feltétel esetén meg megint mást csinál. Mondjuk kétféle adat beérkezése esetén eltérő dolgot kell vele elvégezni. Az egyikhez sokat kell számolni a másikhoz kevesebbet. Így nem biztos, a rendszer által készitett statisztika pontos lesz. Jobb megoldás ha a program készítő maga határozza meg melyik program ág fog sokat számolni és melyik keveset...... Ki a fene tudná nála jobban, mint aki irta a programot?

csinald ugy, hogy a cpun elerheto szalszamot beszorzod 1.5 -el, es annyi reszre osztod a feldolgozast. A nagyobb magok kapnak ket egyseget, a gyengebbek meg egyet. Valamennyi gyorsulas csak lesz

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

hát pont ezt csinálják a program magokat és szálakat legjobban kihasználó mivel ugyan azt a programot futtatják gyakorlatilag minden lehetséges program magon és szálon csak persze eltérő adatokat feldolgozva. ilyenek, a tömöntések, videó feldolgozások. rendérélésék, titkosítások stb. Más felől viszont az átlagos program nem ennyire szétosztható teljesítmény igény alapján. Lesz olyan program ág ami annyit fut, hogy megszakad és lesz olyan ami csak néha ugrik be egy kicsit edzeni a CPU-n. Főleg egy olyan alkalmazásban, mint például egy játék program. Hiszen annak eldöntése, hogy adott pillanatban mi futhat mi mellet és melyik programágnak kell várni egy másik eredményére meglehetősen kaotikus és véletlen szerű mert esemény vezérelt.
Hibá irok egy játékot arra, hogy mikor tűzet nyit a játékos akkor elindul egy külön programszál arra, hogy kiszámolja a leadott lővés eredményét. Hasba lövöm túl éli az ellenség, vagy surolja a lövés vagy miszlikre robban a feje, mert fejbe találom stb. Semmit nem ér a külön kiszámolás program ág, ha nem nyit tűzet az játékos a célra. Nyilván nem állhatok neki kiszámolni egy le se adott lövés következményét, mert foglamam sincsen hová fog pontosan lőnni a játékos. ezért is nem lehet egy játék program tökéletesen optimalizálva a magokra és szálakra. Hiszen nehezen tervezhető a pontos futás és az események előre. Ezért is ingadozik azért erősen a játék közben használt magok és szálak száma illetve a szüksége idő a futáshoz. Egy játék program nehezen optimalizálható és előre jósolható.