...ennek megfelelően kellene megírni a szoftvereket... - vagyis értelme csak az újonnan írt programoknál lenne és ott sem felhőtlen az ég, a mobilos példa láttán.

Ebben a történetben az AMD-nek van igaza szerintem.

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

Sajnos ez tipikusan az a történet, ahol mindenkinek igaza van, viszont a kétféle igazság annyira kibékíthetetlenül távol esik egymástól, hogy évek, évtizedek kellenek majd az álláspontok közeledéséhez, aminek mi felhasználók isszuk meg a levét.

Én kérek elnézést!

Megint a gombhoz akarják a kabátot varrni, mint az Itanum esetében.

Lehet ismételten nem fog sikerülni?

Szerintem nincs. Pénzügyileg lehet nem éri meg, egyébként meg sok olyan szolgáltatás fut pl Windows alatt, amit rá lehet lőcsölni a kisebb magokra, már ha az NT kernel is úgy akarja. De az se feltétlen rossz irány, hogy a Ryzen magokat tudja rugalmasabban kezelni energia/teljesítmény szempontjából egy Intelénél

Le az elipszilonos jével, éljen a "j" !!!

Akár az is mértékeadó lehetne, hogy a fejlesztő pl. a thread priority-nak megfelelően core affinity-t is megad. De sok esetben így sem egyértelmű..

Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.

A ZEN magok annyira gyorsan tudnak órajel meg feszültségváltásokat csinálni, hogy gyenge magok beépítésének kevés értelmét látom. Akkor már inkább a Windowsban kellene gyomlálni mindenféle background processzt... Itt a céges gépen az Xbox game bar meg hasonló hasztalan dolgoknál is van feljegyzett processzor idő...

Agyturbina: jah. Akkor már inkább FPGA-t tokozzanak a procin belülre

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

" nyolc kis és nyolc nagy magot keverne "
legyen benne 16 nagy mag es problem solved

Ez lett volna egy intel által kihirdetett "ki tud a program fejlesztőknek több pénzt adni" c. verseny, amiben ha részt venne AMD, akkor is csak a biztos második helyért indulhatna. Ehelyett gőzerővel megy tovább a technológiai versenyben.
OEM-ek örültek volna, ha együtt álmodja velük a jövőt és együtt 100%-on pörögtethettek volna ennek a marketing gépezetét.. amiből Intel húzta volna a legtöbb hasznot..

[ Szerkesztve ]

Megint segget csináltak a szájukból. Amikor még próbáltak belépni a mobil piacra, akkor azzal hárították a sokat fogyasztó magjaikat ért kritikákat, hogy ez jobb, mert hamar befejezi a munkát, és mehet aludni. Most meg ez nem jó, kell a "kicsi" mag. Ja, mert nem férnének be a fogyasztási keretbe 16 "igazi" maggal, és az hogy nézne már ki marketingeséknél, hogy AMD-nél már 24 magos is van, nekik meg 12 sincs...

Remelhetoleg hazon belul azert teljes erovel dolgoznak ezen az AMD-nel is. Ugy latom, hogy nem tetszik az AMD-nek, hogy jelenleg pont nem az az igeny, amit ok terveztek, vagyis hogy mindenbe meg tobb egyforma mag keruljon. Mar korabban is latszott hogy tultoltak az egeszet es feleslegesen sok magot raktak processzoraikba. Szervereknel, munkaallomasoknal az nagyon jo irany, foleg ha virtualizalas is van, de az atlaguser, legyen az home/office/gaming felhasznalas, nem kell 8 mag, tobb meg plane nem, amerre tovabb akartak menni. Itt is a szoftveres oldal van lemaradasban es ha a programozokon mulik, lemaradasban is lesz, mert toluk mukodokepes termeket kovetelnek, es az optimalizacio sokadlagos kerdes, egy-egy szegmenst kiveve. Egyik sem fogja azt mondani a fonokenek, hogy en csak 1 feature-el lettem kesz, mig a tobbiek 16-al, de ez multiprocesszorra optimalizalt implementacio. Who cares? You are fired!

Ha az ARM eseten ez fogyasztascsokkenest jelentett, akkor erdemes megcsinalni X86-ra is. Nem az a lenyeg, hogy azonnal tokeletes is legyen, hanem hogy kezdjek el. Mar az is hasznos lenne, ha manualisan vagy valami preset alapjan ugyanazon a valasztott magok/magokon futnanak az alkalmazasok. Az OS processzei, egyszerubb appok processzei futhatnanak a kis magokon vegig, sot lehet hogy bizonyos kod reszek kaphatnanak valamilyen meg takarekosabb, dedikalt reszt is a chipbol, ahogy pl. az Apple chipjeinel ez mar jo ideje igy van.

Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.

Onnantól kezdve, hogy azt mondod "a fejlesztő..." már lehetetlen az egész. Látom lelki szememim előtt az új Outlook app (Project Monarch) fejlesztőit, akik azt nézik hogyan lehet JavaScriptből szálakat a kis és nagy teljesítményű magokhoz rendelni az ilyen-olyan műveletekhez. Na persze, a mai kliens oldali programozás pont a teljesítmény ideális használatáról szól, amikor mindent web technológiákra húznak, a játékok AI-ját garbage kollektoros script nyelvekben rakják össze (Lua)...

Az APU vonalról is azért szállt le AMD desktopon, mert ahol van dGPU, ott állatira fölösleges cifrázni a végrehajtó egységeket, mert olyan time-to-market nyomás van a szoftverfejlesztőkön, hogy nincs idő olyan dőreségekkel szöszölni, mint a teljesítmény. Tessék megnézni, lepkehálóval kell fogni a GPGPU programozókat. Ugyan a BIG.Little az IGP-nél könnyebben programozható, mégsincsenek illúzióim, hogy hányan fognak foglalkozni vele azon túl, amit ingyen megkapnak az OS-től.

Na ezt már többször felvetettem, hogy a gyakran használt kódrészeket nem csak gyorsítótárazni kéne, hanem pl egy FPGA-ba automatikusan felprogramozni, de tudom megcsinálni nehezebb, mint mondani

Le az elipszilonos jével, éljen a "j" !!!

Egyébként elképesztő, hogy Intelnél milyen vakon vannak. Nem tűnik fel nekik, hogy mobilon azért működik a heterogén design, mert működési jellegéből adódóan egy mobil eszköz 80%-ban készenléti módban van, amikor várja a hívásokat meg az értesítéseket és ilyenkor gyönyörűen ki tudja használni az oprendszer a kisebb magokat.
De ilyen mód nincs pc-n. Ha egy laptopot nem használsz lecsukod és alvó módba kerül amikor nem csinál semmit.
Mobilon se az appoknak kell a kicsi mag. Én mobil fejlesztő vagyok, de még sohasem futottam bele abba a kérdésbe, hogy egy funkciót meg kéne csinálni a kis magokra, mert úgy jobb lesz.

Ez az egész kb olyan, mint amikor a microsoft hirtelen kitaláta a win 8-al, hogy akkor most legyen minden érintőképernyős, mert az mobilon olyan jól működik. Pedig az első pillanattól világos volt, hogy az esélytelen. Egyszerűen baromi kényelmetlen a laptop előtt tartani az embernek a kezét folyamatosan, hogy nyomkodhassa a képernyőt. Azt a képernyőt, amit az ember gondosan tisztogat állandóan.

[ Szerkesztve ]

Szerintem nem vak, csak máshogy nem megy a skálázás a jelenlegi magjaikkal, inkább kunyiznak a Microsoftnál, hogy kicsit püfölgesse a kernelt, hogy jobb legyen az alapjárati fogyasztás.

Le az elipszilonos jével, éljen a "j" !!!

Tegyük hozzá, hogy ha az MS-nek sikerülne ilyen téren továbbfejlesztenie a kernelt, akkor azzal azért mindenki nyerhetne, nem csak Intel.

Én kérek elnézést!

az az értelme, hogy a kismagok elegendőek az alap oprendszer funkciók és a böngésző, videólejátszó, zenelejátszó kezelésére és ettől sokszorosára nővet az üzemidő. A nagymagok pedig pedig csak akkor durrannak be ha videót vágsz, játszol, stb.

És az AMD azért téved, mert a Windows gyorsan rászabható erre a designre és a fő 3-4 böngésző is pillanatok alatt átállítható erre a koncepcióra. Minden más pedig futhat az oldscool nagymagokon, amíg képesek nem lesznek futni hibrid módon.

Ezt az egészet az Apple megvalósította az M1-el, az Intelnet pedig tartania kell a lépést, nincs más választása.

Csak ebben az a vicces, hogy a heterogén processzor design hardveresen tipikusan egy olyan terület, amit nem kell nagyon túlvariálni. Így, hogy a szabadalom be van adva, tehát ellehetetleníteni már nem tudják őket, amint az Intel kitaposta az utat, és az oprendszer és a programok is megfelelően kezelik a problémát, az AMD egyszerűen összelegóz magának egy heterogén procit a különböző chipletekből, és kész is van. Szóval teljesen érthető, hogy nem sietnek vele, mert nincs szükség nagy tapasztalat szerzési időszakra, simán felzárkóznak a megfelelő időben.

Egy másik cikk alatt már leírtam félig offban, de ide meg kapcsolódik, hogy ennek a heterogén processzordesign-nak szerintem nem is az energiahatékonyság miatt lenne értelme, mert olyan kicsi a különbség, hogy nem éri meg a szenvedést.

Inkább ott lenne értelme, ahol futtatnak olyan programokat is, amik nehezen, vagy egyáltalán nem párhuzamosíthatók, viszont rendkívül erőforrásigényesek. Azokat a programokat dedikáltan rá lehetne tolni 1 vagy max. 2 darab hatalmas, magas frekvenciájú magra, minden más meg akár figyelmen kívül is hagyhatná a nagy magot, és futhatna a relatív kicsi, de önmagukban nézve megfelelően nagy méretű magokon párhuzamosítva.

Ha már a NUMA meg a HT valamennyire le van kezelve a Windows-ban és a rossz emlékű AMD-s osztott bulldózer vagy milyen magokkal is tudott trükközni, akkor heterogén magok támogatása sem kéne, hogy nagy gond legyen.

Le az elipszilonos jével, éljen a "j" !!!

Olyan szempontból mindenképpen üdvözlendő a sok mag beépítése, hogy ha eleve nincs sok magos hardver, akkor aztán végképp nem is fogják magukat törni a fejlesztők, hogy párhuzamosítsák az alkalmazásukat, mert minek? Így legalább amiben könnyen megoldható, ott meg is oldják, és már ez is előrelépés. Plusz ugye jellemzően nem egy programot futtat egy ember egyszerre. Az is tök jó, ha mondjuk az oprendszer háttérfolyamatai nem ugyanazokon a magokon futnak, mint a teljesítményigényes programé, mert van elég mag, hogy különbözőre legyenek pakolva. Jó dolog ez, csak szoftveresen utána kell menni.

Azért szerencsére a programnyelvek is tolják a programozókat, .net-es Foreach, Java-s Stream API, újabb nyelvek már kapásból erre optimalizáltak, az aszinkron programozásnál is van töbszállúság, stb.

[ Szerkesztve ]

Le az elipszilonos jével, éljen a "j" !!!

>az az értelme, hogy a kismagok elegendőek az alap oprendszer funkciók és a böngésző, videólejátszó, zenelejátszó kezelésére és ettől sokszorosára nővet az üzemidő.

Amíg a csodás electron webappok (slack, discord, teams?) és egyéb gigabájtokat (túlzás) letöltő híroldalak reklámokkal együtt megeszik a gép felét addig ilyenekben ne gondolkozzunk.

Azt se felejtsük el, hogy egy desktop programozó, ha optimalizál akkor általában a sebesség miatt teszi, nem pedig az energiagazdálkodás miatt. Ez a koncepció pedig pont ellentétes ezzel. Egyedül akkor látnám értelmét nekiállni a magok és feladatok szétválasztásának, ha lenne mondjuk pár extra képességű mag, nem pedig gyengébb magok.
Szerintem ennek csak akkor van bármi értelme ha ezt az oprendszer tudja hasznosítani a saját működésében és ott kimutatható bármi előny. Egyéb fejlesztőkre hagyatkozni szerintem reménytelen.
Mondjuk kíváncsi lennék, hogy mennyit lehetne ezzel nyerni, mert egy frissen telepített windows üresjáratban most is 0 és 1% processzorkihasználtság között mozog.

Ha ez a 8+8 felállás szoftveresen beérik és a tovább lepésnél nem akarnak +8 kicsi mag helyett újra +8 nagyot betenni, akkor mehetnek tovább a 8+16/4+24-es felállásra. Tehát ugyan ott lesznek, hogy ki kell fizetni azokat a programozókat, akik a több szálra optimalizálást végzik.
De ha ráunnak erre és 16 nagy magot adnak, akkor is skálázódnia kell annak a programnak 8-nál több szálra, ha el akarják adni.
.. e közben AMD már a 32-64 magos Desktop processzorokat fogja árulni, és azok a szoftver cégek amik ezt ki tudják használni sokkal jobb piaci pozícióban lesznek, mint azok akik nem hajlandóik erre.

Szóval kellene egy egyel jobb indok, hogy miért maradnak a max. 8 mag támogatásánál?

[ Szerkesztve ]

A M1 eleg nagy sokkot okozott nekik. Nem csak egy kover piacot veszitettek, veszitenek el, de az utod nagyon komolyan bealazta oket. Az M1 megmutatta, hogy az ARM olyan szegmensekben is tobb mint versenykepes, ahova ok nem vartak es hamarosan jonnek az utodjai, amik meg komolyabban betehetnek nekik, elhappolva a lezsirosabb falatokat a piacon. A masik oldalrol az AMD okoz gondot, es bar ok kezelhetobb problemat jelentenek, az se jon jol. Valamit lepniuk kell.

Az M1 es varhato utodai sikeret mondjuk nagyon nehez lesz leutanozni, mert az Apple szo szerint ugy tud fejleszteni, hogy mindent hazon belul keszitenek. Erre keptelen az Intel es az AMD is, de idevehetjuk a Microsoftot is. Nekik harmojuknak uj alapokra kell helyezniuk az egyuttmukodest, mert ugy nez ki hogy az Apple csak azert nem fogja kihuzni aloluk a szonyeget, mert meg nincs szandekaban mainstream gyartova valni.

Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.

A fejlesztok azert sem torik magukat a parhuzamositas miatt, mert nem azt kaptak meg feladatnak. Az elerheto hardver sokkal erosebb mint kellene, es az OS arra kepes mar, hogy szetdobalja a fuggetlen processeket a magok kozott. Nincs miert penzt es idot beleolni ebbe a teruletbe, hacsak nem valami olyan alkalmazasrol van szo, ahol a hatekonysag es az elerheto teljesitmeny kiemelten fontos. de ezek az appok talan a fejlesztok 1%-at sem erintik. Emellett sokkal komolyabban kellene megfizetni az a programozot, aki ert is ehhez a terulethez es jol is csinalja.

Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.

ahhoz olyan os is kell, és alkalmazások. erre pedig se kínálat, se kereslet. ha valami kiderült a sok kikönnyített windows variáns bukásából, az ez.
persze ettől még simán lehet, hogy ez lesz a következő trend, ha az apple végigcsinálja, ők képesek ekkorát rántani a piacon.

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

Azért amíg az Apple olyan pénzekért adja a termékeit, amennyiért, addig a többieknek nincs nagyon mitől félnie.

Azért az, hogy a windows ütemezője bizonyos feladatokat szét tud bontani, és külön szálra tenni, nagyon nem egy ideális dolog. Egyrészt ez nem is működik mindennel, másrészt azért az ő bontása távol áll az ideálistól.

Én ennek nem igazán látom értelmét. Vagyis értelme lenne, hiszen eszetlen módon lehetne pakolni a magokat a processzorokba. Szoftveres oldalról már más tészta. Mire erre a programok jórésze átáll az nem egyik napról a másikra lesz, ha egyáltalán veszik majd a fejlesztők a fáradságot ebbe időt, pénzt, és energiát ölni. Kicsit amolyan önző módon új irányt váltana az Intel, és ezzel megint letolnának mindenki torkán olyat, ami igazából csak nekik jó. Ugye a sok éves fejlesztést megkerülve kiszarnának pár processzort aminek a koncepciója igazából már adott, nekik idézőjelbe csak a magok számával kéne foglalkozni. Így rövidebb idő alatt érhetnék utol az AMD-t legalábbis a magok számában, meg a fogyasztásban.

Hát, ez az, hogy csak magok számában, meg fogyasztásban érnék be őket. Csak azok a magok nagyon nem ugyanolyanok, úh. használhatóságban ugyanúgy le lennének maradva. Ez így ebben a formában, ahogy csinálják, csak marketingnek jó, semmi másnak.

Azért nem fog átállni egy fejlesztő sem erre a koncepcióra mert egyáltalán nincs miért.
Ennek csakis a fogyasztás szempontjából lenne előnye, de ez meg a fejlesztőket a legkevésbé sem érdekli. És, hogy miért? Mert a szoftvereik felhasználóinak a fejében sosem kapcsolódik össze, hogy a laptop azért merül le hamarabb, mert ez és ez a szoftver nem a legotimálisabban van megírva.

Az Apple? Talán egy évtizede így van az Androidnál és az ahhoz szánt mobil Soc-oknál.

Én kérek elnézést!

Jajj, azok a "csúf gonosz" fejlesztők.
Van értelme amúgy sok apró magnak, már a Win2000-ben is rahedli szolgáltatás futott, most olyan mindegy, hogy többszálú vagy sem, mert magukat a programokat szét lehet szórni.
A programozók/fejlesztők meg egyre magasabb absztrakciós szinteken dolgoznak (már aki nem valami rendszerprogramozó vagy esetleg pont egy fejlesztőeszközt fejleszt) és azért ezen szintek alatt a "motortérben" már gondolnak arra, hogy a mai hardverekben nem egy-két végrehajtó egység van, hanem már a 4+ az átlag, szervereken meg sokkal több.
Beszéltem egy ismerősömmel, mutattam egy programom, majd kiröhögött, minek pöcsölök olyan alacsony szintű dolgokkal, mint szálkezelés, ott van egy fejlettebb keretrendszer, az majd megoldja. És nem a sufni kft-nél dolgozik az illető, hanem egy multiban egy programozó csapatot vezet. Ja és hiába magas az absztrakciós szint, és van elrejtve sokminden előlük, azért van munka dögivel, úgyhogy egyrészt nem is akarnak kicseszni a júzerrel, de magukkal sem, mert az egyre összetettebb üzleti folyamatokat csak egyre magasabb szinteken képesek lekövetni időre.

Le az elipszilonos jével, éljen a "j" !!!

Pusztán a vita kedvéért (elvégre ez egy fórum)...

"És nem a sufni kft-nél dolgozik az illető, hanem egy multiban egy programozó csapatot vezet."

Ez még így önmagában nem jelent semmit. Csapatot vezetni multinál sok esetben annyit jelent: képes követni az ipari trendeket és azokat valós feladatokra alkalmazni, lefordítani. Nem jelenti azt, hogy valaki a létező technológia határait feszegeti.

"Jajj, azok a <<csúf gonosz>> fejlesztők."

Ebben igazad van, a fejlesztők nem gonoszak. A fejlesztő hiánycikk, ergo az egekben van a fizetése, amit viszont nehéz kigazdálkodni sok esetben. Ezért óriási a nyomás, hogy időre kész legyen valami és kell a fícsör és eszedbe ne jusson optimalizálni ha nem feltétlen muszáj.

Emlékszel 15 évvel ezelőtt az ICQ-ra? (Most is megy, csak nem itthon) 15 évvel ezelőtt lehetett vele csetelni, smiley-t küldeni, képet, videót, hangot... pont azt tudta 15 éve, amit mondjuk ma egy Facebook Messenger. Csak 12 MB volt, nem 304,87 MB és mai szemmel nézve okosóra szintű hardveren futott. Nem is készült el kevesebb több idő alatt vagy több munkával. Akkor most miért hízott ekkorára?

Mert az élet egyre több területére szivárog be a technológia, többet kellene programozni (hiánycikk), és ezért készülnek keretrendszerek, hogy olcsóbban lehessen többet markolni. Ez az ótvar Messenger ami a FB saját keretrendszerére épít (MetaOS) amivel webet-telefont-PC-t lehet célozni egyetlen kóddal egy monstrum. Nem is kellő gonddal készült, a teljesítmény rohadtul nem lehetett szempont. Nekem ne mondja senki, hogy szöveget, képeket, videót csak ennyiből és ugyanennyi RAM-ból lehet kihozni. (És én is ebből élek, GPGPU programozok, jó elképzelésem van róla milyen erőforrás igénye van egy ilyen alkalmazásnak.)

Ebben a szép új világban amit a tech cégek csináltak maguknak keretrendszert keretrendszerre okádunk, sokszor gondolkodás nélkül (csak azért mert most ez a divatos). Sok esetben valóban gyorsabban is lehet haladni a fejlesztéssel, és a végeredmény egyformán ótvar minden platformon.

Elnézést kérek, ha a véleményem sarkos, de nem vagyok jó véleménnyel az aktuális ipari gyakorlatról; a minőségre többet kéne adni, több fejlesztési idővel, akár kevesebb fizetésért (mondom ezt úgy, hogy magam is fejlesztő vagyok). Kevesebb technical debt lenne, kisebb lenne a nyomás, kevesebb a crunch, kevesebben égnének ki... alapvetően élvezetesebb lenne a munka. Környezetkímélőbb is lenne (ha hardver helyett szoftvert hajkurásznánk és kihasználnánk a meglévő erőforrásokat, a hardver cégek is versenyezhetnének szoftverben (lásd Samsung LinuxOnDex és társai) hogy kitűnjenek a tömegből).

Egyelőre elég, ha egy gyártó elmegy ebbe az irányba, mert nem a hardveren múlik elsősorban a siker, hanem a fejlesztőkön. Ha ők nem haszálják ki a lehetőségeket, vért izzadhatnak a gyártók lásd Itanium, vagy akár a Microsoft ARM-os Windows-a.

https://www.coreinfinity.tech

A dolog nem ennyire fekete fehér. 16 nagy mag sokat fogyaszt nagyon melegszik. Azt a CPU-t le is kell hüteni annyira hogy tudjon magas órajelen dolgozni. Az egyik megoldás, hogy raknak a prociba magas órajelen nagy teljesítménnyel futó magokat és kisebbeket . Ha van egy 8+8 magos proci és szükség van mondjuk 4 mag futására. Akkor futni fog 4 gyors magon. ha van egy programom, ami 14 magot használ egyszerre na akkor gond van. elég "okosnak" kell lenni a rendszer feladatütemezőjének vagy magának a programnak, hogy jelezni legyen képes, hogy melyik programág igényel nagy teljesítményt melyiknek elég kisebb telejsítmény ís. A hétköznapi életben a legtöbb feladat esetén nem lehet egyenletesen szétterhelni sok magra a futást. Lesz olyan mag, ami agyon gyötri a használt magot lesz, ami csak lépecol és alibiből futat le pár kisebb program ágat. Abban igaza van az AMD-nek, hogy elöbb a programoknak és a rendszerek erőforrás ütemezőjének kell megfelelő szintre fejlödni. Az intel már kisérletezett egy 4+1 magos procival. 4 általános mag és 1 darab nagy teljesítményű mag. Az eredmény nos nem volt kielégítő. a rendszer erőforrás ütemezőjénél korántsem volt igaz. hogy mindig a legoptimálisabban hozta össze a nagy teljesítményű magot és a program leginkább számítás igényes ágát egymással. Vagyis korántsem alakult optimálisan a program futás. Az optimalizáláshoz olyan program fejlesztő nyelvek kellenének ráadásul, ahol a program fejlesztő valamilyen módon minősíteni tudja a program ágakat, hogy melyik igényel nagy teljesítményt és melyik csak átlagos. Aztán ezen információk alapján az erőforrás ütemező tudna lépni, hogy mit rak nagy teljesítményű magra mit hagy csak úgy lébecolni a háttérben. Amig ezek nincsenek biztosítva szoftver szinten nos a dolognak túl sok értelme tényleg nincsen.

Én már azzal megelégednék, ha a mobilomon zenehallgatás közben tudnék szókeresővel játszani.

Úgy vélem, a játékokkal kapcsolatba hozott agresszivitás nem azok jellege miatt van, hanem (általában) csapnivaló minőségük okán.

na igen ebben van igazság. egy ARM proci esetén sokkal primitivebb az erőforrás ütemezés. ha nézünk egy 4+4 magos procit. Ahol van mondjuk 4 mag 1,6 Ghz és van 4 gyors mag 2,4 Ghz.
Ott azt csinálja, hogy ha kicsi a terhelés akkor a 4 gyengébb magot használja valamilyen terhelési szint felett meg a gyorsa nagy fogyasztású 4 magot. Megjegyzem az idő nagy részében szinte be se kapcsolnak a gyors magok legfeljebb pár játékban vagy esetleg CPU teszt programban. Viszont annyira primitiv a vezérlés. hogy ha én futtatok a telefonon mondjuk egy 2 magot használó applikációt, és elég neki a kisebb mag teljesítménye. Akkor auz látjuk, hogy a 4 gyengébb mag teljesítménye együtt változik. tehát egyszerre hajtja mindig 4 magonkánt az órajelet. Akkor is ha a 4 magnak éppen csak kétmagon van dolga. ettől még a nem terhelt két mag órajele is simán felmegy a 2 terheltel együtt. Tehát ez egy meglehetősen primitív vezérlés.
X86-os procik esetében viszont különféle terheléseket látunk magonként. Simán látunk adot pillanatban 80%,50% 45% 25% 12% 5% és mind ezt egyszerre eltérő órajelen. Tehát egy X86-os proci a konkrét magon szükséges terhelés mértékében vezérli a szükséges magokat. Persze bonyolítja a helyzetet, hogy a magok alapból eltérő teljesítményre képesek. Olyankor össze kell valahogy hozni a nagy számításigényű programágat a nagy teljesítményre képes magokkal. Amig ez nincsen megoldva hogy kezelje a kérdést mind a program, mind az rendszer erőforrás ütemezője, addig csak a véletlen múlik, hogy mi hol fut adott pillanatban. Sőt kifejezetten béna is lehet a dolog. Ha a nagy számítást igénylő progrmágat akarja a lassú magra tenni, és a kis számitást igénylő programágat ütemezi a nagy teljesítményű magra.

Na itt a másik gond az armos procival, nem igazán arra készült, hogy komoly multitask fusson rajta egyidőben. vagyis hogy 6 alkalmazás fusson rajta összesen 24 programágat futatva és egymás elöl tépkedve ki a mondjuk 8 fizikai magot. Komoly multitaskos környezetben az ARM-ok erősen alul teljesítenek ahogy ki kell szolgálni egyszerre 50-60 futó task 350 szálát rögtön gondok lesznek. egy windows rendszer és egy x86-os procit 20 éve erre edzenek és fejlesztenek. Persze azért nem éri el egy asztali windows egy szerver windows rendszer stabilitását és képességeit, de azért komolyan tudnak az asztali rendszerek(linux is)

ha most ránézek a win 10-es gépemre akkor azt látom, hogy 88 folyamat fut 1120 szálat lefoglalva. (természetesen adott pilanatban nem fut ténylegesen egyszerre 88 folymat és 1120 szál de ennyi van jelenleg a feladatütemezőre rábízva. hogy alkalom adtán adjon nekik lehetőséget mikor szükséges. Egy arm proci erőforrás ütemezője már megzakkanna ennyi feladattól.

The Future is Fusion !

Az AMD már párszor befürdött vele, hogy a fejlesztőkre akarta bízni, hogy használják ki a hw tudását. Egyszersemjöttbe.
Nemcsodálom, hogy nemakarnak még1x ugyanabba a folyóba lépni.
Főleg ha igaz, hogy bizonyos utasitáskészletek ( pl : avx2 , avx 128-256-512 ) csak a nagyobb magokon lesznek elérhetőek, mert akkor sacc/kb. ugyanaz a szitu, mint a 4 x86 core + 8 radeon core és hasonló felállású apuk voltak.

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

Ameddig szinte versenyszeruen jonnek az uj keretrendszerek, fuggvenykonytarak, sot neha egy-egy uj nyelv is, es ezek kozott szo szerint gyakran az aktualis trend, divat dont, nem is lesz jobb a helyzet. A programozoknak folyamatosan tanulniuk kell, de megsem jutnak semennyit sem elore, mert csak azt tanuljak hogyan kell almat hamozni 82 fele modon. Aztan vannak a renegatok, akik csak azert sem hasznalnak trendi keretrendszert, de helyette irnak sajatot, amivel nem a kutba, csak a kavajara.... Vagy azok akik leragadtak egy 5 evvel ezelotti verzional.

Mindenhol folyik el a penz es az ido olyan kepzesre, olyan dolgok megtanulasara, amiknek letezniuk se kellene. Az optimalizalasra semmi ido nem jut, sot gyakran latni, hogy a tesztelesre sem.

Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.

Kezdesnek az is eleg lenne, mint amilyen az Nvidia fele Optimus logikaja volt, vagyis alapbol minden app a gyengebb vagy erosebb magokat hasznalna egy beallitas szerint, aztan a user felulbiralhatna egy mozdulattal. Nem lenne semmilyen dinamikus menet kozbeni allitas. Mar ezzel is elorebb lennenek. Lehetne gyartani az uj x86-os heterogen CPU-kat.

Kesobb meg az M1-tol es elodeitol sokat lehetne tanulni. Egy teto ala hoztak a bedrotozott, specialis vegrehatjo egysegeket, a kis es nagy magokat, sot meg beraktak egy ML blokkot is, majd kore tettek egy gyors eleresu memoria rendszert. Ezert is kellene a MS-nek es a CPU gyartoknak kozosen dolgozni a jovo x86-os megoldasan. Nem epithetnek olyan CPU-t, ami nincs tamogatva az operacios rendszerek altal. Mondjuk az AMD es az Intel most nincs olyan viszonyban, hogy ilyen melysegben kozosen dolgozzon, igy valoszinuleg az lesz kozottuk a nyero, aki hamarabb jon ki egy jo architekturaval.

Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.

"Mondjuk én se értem, hogy az AMD féle órajelkapuzás és power management mellett mi értelme lenne."

az, hogy az Intelnek is evekbe tellhet hasonlo rendszert fejleszteni, ezt meg osszelegozzak a meglevo ip -bol, a tobbit oldja meg a szoftvervilag.

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

Az intel a gyartastechnologiai hatranyat akarja elsosorban mankozni. De az os nem tudja ugy leosztani, hogy eloszor a nagyteljesitmenyu magokat priorizalja?

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

Arra is kíváncsi lennék, hogy hogyan gondolja az intel azt, hogy a fejlesztők nekiállnak optimalizálni egy procira, aminek a részesedése a piacon nagyon sokáig kimutathatatlan lesz. Amíg a működő procik legalább 20%-a nem ilyen, szerintem egy cég sem fog nekiállni az ilyen fejlesztéseknek. Viszont nem fognak elterjedni ha meg semmi sem használja ki őket. Ördögi kör. Windows Phone tipikus esete.
Még ha bizonyos programok számára ez valami előnyt jelentene esetleg akkor tudnám elképzelni. De ez a programok szempontjából pont semmit sem jelent. Hogy tovább bírja a laptop, mint amin fut szerintem totál hidegen hagy minden fejlesztőt.

[ Szerkesztve ]

Azért van még fejlesztési tartalék - a jelenlegi architektúra finomításában is.
mig a 4000-es Ryzenekben fix ... a Mobil Ryzen 5000 -ben már dinamikusan lehet szabályozni a cpu magok feszültségét - és eléggé vissza lehet venni ..

https://videocardz.com/newz/amd-ryzen-5000-mobile-zen3-architecture-detailed

Mottó: "A verseny jó!"

Robitrix , az M1-es MacBook Air- emen most épp 354 folyamat 2034 szála fut az ARM processzoron :-) . az előző i5- ös MacBook -jaimhoz képest nem is a kb dupla sebesség,
ventilátor nélküli teljesen néma működés, és a dupla akkora akku idő a legfeltűnőbb, hanem a teljesen akadás mentes működés. Mint az Android és az IOS közti különbség , nincsenek mikro laggok, megtorpanások , teljesen fluid a működés, nem érzed hogy "van" egyáltalán maga az OS vagy épp a gép.

[ Szerkesztve ]

Hát az ilyesminek csak úgy látom értelmét, ha automatikusan működik, ha a programozóknak kell megírni, akkor nem lesz megírva. Ha nem képes automatikusan működni, monitorozni magát a proci, és aszerint váltani magot, akkor inkább kuka. Mint most az SLI DX12 alatt, nem is támogatja már semmi.

Meg eleve volt is chiptervező részleg a mobilok miatt, volt honnan kiindulni.

Le az elipszilonos jével, éljen a "j" !!!

Milyen mikrolagok? Parhuzamosan hasznalok androidot es iost, annyira egykutya... Mindegyiknek megvannak a sajat hulyesegei.

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

azért az inteles Mac is sokkal stabilabb és kevésbé micro laggolós volt mint a Windows ... :-)
pláne hogy az Mac OSX az első perc óta ( 12 éve ) VGA-val számolta az ablakkezelést, ( OpenGL) szemben a windowsal , így nem ugrott meg a CPU terhelés minden egyes ablak mozgatásra :-)

Mondjuk ha csak egyetlen hardverre kell megírni egy oprendszert, nyilván valamivel stabilabb lesz. Viszont ezt a "microlag" mániát nem értem tőled. Még telefonon oké, ott létezik a jelenség, de asztali oprendszeren mit értesz microlag alatt? Értelmezhetetlen, illetve nem létezik a fogalom. Feltéve persze, hogy valaki nem egy 20 éves gépen akar windows10-et futtatni, de ott meg nem micro lagok lesznek, hanem elég méretesek. Ha egyáltalán elindul a rendszer.

[ Szerkesztve ]

Erről az egészről nekem is az jutott eszembe hogy az új zen3 magokat már a cpu ha nem aktív alapból lekapcsolja ami nem masodpercekben mérhető hanem nanosecundumokban. Olyankor pedig nem fogyaszt semmit plusz annyira alacsony feszültségek mellett is képesek üzemelni ahol már nincs értelme mérni az áramfelvétel.

Ebből a szempontból csak annyi értelme van big.little koncepciót követni PC-n hogy több magot írhatnak a dobozra amit ugyan annyi tranzisztor felhasználásával valósítanak meg de az 1szálas teljesítmény ugyan úgy meg lesz(1-2 magon) a több szálas meg nem lesz kiemelve a marketing anyagokban(intel).

R5 2600@4Ghz 80W , B450M Pro4, DDR4 16GB 3200MHz cl14 B-die, Hellhound 6700XT 12GB

Egy esetben lehet értelme a nagy magnak, olyan alkalmazáshoz dedikálva, ami nagyon rosszul, vagy egyáltalán nem párhuzamosítható, de nagyon teljesítményigényes. Bár ilyenből alapból sem sok, meg egyre kevesebb is van.

Mondjuk azért a boost nem teljesen ugyanaz, mintha folyamatosan nagy frekin tud járni egy mag. De igen, valamilyen szinten működik.

Nem tudom, de miért érte meg akkor ugyan ez (külön erős és gyenge magok) az M1 esetén? Az sem mobilba megy, szóval ugyan az a felhasználási terület. Illetve ott azt is láthatnánk (de hirtelen nem találtam semmit), hogy a fejlesztői részről ott mit kell ezzel tenni. (Bár én arra számítok, hogy szinte semmit. Talán, ha akarom, egy szálat késleltetés kritikusnak jelölök, vagy háttérszálnak. A többit majd az OS eldönti hova teszi.)

[ Szerkesztve ]

Nem nagyon volt más választásuk... ai Intellel szakítan akartak, és ahelyett, hogy az AMD-hez mentek volna(naná, tudtak ők is az ellátási nehézségekről), inkább saját kezükbe vették a fejlesztést. Viszont így ha nem akartak éveket rászánni az alapokra, gyakorlatilag az ARM és a RISC-V közül választhattak.
Tudtommal az ARM-nak nincs olyan feljett energia-menedzsmentje, mint az X86-nak, pontosabban van, de annak szerves része a big.little design. Szóval ezért szerintem.

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.

Az ARM és RISC-V csak egy ISA, ami az energiamenedzsment mikéntjét nem határozza meg. Ráadásul az Apple saját mikroarchitektúrát használ. Szóval nem önmagában az ARM az oka. Eleve a vertikális integráció miatt választották (nem függnek mástól, mert ellenben az x86-attal, ARM ISA-t van jogod megvalósítani), na meg mert mobil vonalon már rég ARM-et használnak.

Lehet, bár azért az Apple sem most kezdte, és ráadásul mobil vonalon hegyezték eddig az ARM-os megoldásukat, ahol sokkal nagyobb prioritás a fogyasztás, mint desktopon.

[ Szerkesztve ]

> ... Intellel szakítan akartak,
> és ahelyett, hogy az AMD-hez mentek volna(naná, tudtak ők is az ellátási nehézségekről)

Lis Su azt nyilatkozta pár héttel ezelőtt, hogy az AMD továbbra is marad az Apple partnere a diszkrét GPU vonalon.

Az, hogy az Apple CPU fronton nem az AMD -hez ment, (kb 4-6 éve, amikor az Apple meghozhatta ezt a döntés ... ) , annak az lehetett az oka,
hogy akkor még
- nem volt az AMD-nek versenyképes mobilprocesszora ..
- és lehetett valami szokásos X86 kizárólagossági klauzula az Apple-Inteles szerződésben, ami kizárhatta az AMD-t CPU fronton

amikor az apple a döntést meghozta ( sok -sok évvel ezelőtt ) ,
akkor nem voltak még ellátási gondok ..

Mottó: "A verseny jó!"

Ebben is van valami, de szerintem egyszerűen in-source-olni akarták a CPU-t. Diszkrét GPU az Apple portfóliónak a jó részébe nem kell...

És még az is benne van a pakliban, hogy mikor(és amennyiben) az NVidia bekebelezi az ARM-ot, koppannak a döntésükkel, bármennyire is esküdözik most Huang úr, hogy a licenszelésen nem akarnak változtatni...

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

Hát, ha ez nekik megér potom 40 milliárd dolcsit, aligha fognak csak a szerver meg AI részlegekkel foglalkozni... és a consumer-piaci customerek jó része versenytársa az NV-nek...

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.

Lehet, hogy mégse lesz alkalmuk kifizetni...

Nem azt kérdőjeleztem meg egyébként, hogy megéri-e, hanem arra próbáltam rámutatni, hogy ha már az eghész ARM-ot megveszik, nem látom garantáltnak, hogy az ARM-ügyfél versenytársaikkal(pl. Qualcomm, Intel, AMD, MediaTek, Samsung) nem fognak kicsit se kibaszcsizni... ahogy a linkelt cikkben is idézik: "consider whether, following the takeover, Arm has an incentive to withdraw, raise prices or reduce the quality of its IP licensing services to NVIDIA's rivals."
És ez aligha tetszene az Apple-nek, akik nincsenek különösebben jóban a zöldekkel...

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

Szvsz az idei év választ fog adni mindhárom kérdésedre.

Én kérek elnézést!

Nem hinném, hogy 5-6 évig fenntartaná Apple ezt a jelenlegi tranziens helyzetet. De majd meglátjuk.

Én kérek elnézést!

> Azért az Apple M1 elég sok problémát felvet:
> 1. Hogy lesz így teljesítménybeli difi a gépek között?
> 2. Hogy lesz ehhez dGPU passzintva ha kevés a kraft?
> 3. Hogy lesz ebből MacPro?

Ez az Apple gondja ... majd megoldja ( ha tudja )
Eőssen eltökéltek és Valószínüleg végiggondoltak mindent, 1-2 éven belül nem lesz X86-os Apple gép.

A pletykák szerint idén ( márciusban ) - jön az M1X 12 magos ( 8 erős + 4 energiahatékony )
és év végére/jövőre meg akár a 32 magos verzió.
És ha az Apple Laptopokban pár év múlva a 16 power + 4 efficient mag lesz az általános,
akkor igen csak felkötheti a gatyáját a X86-os ( + Windows ) konkurencia.

És még az AMD-nek se lesz könnyű ... a következő 100 napban megjelenő M1X -még a legjobb ZEN3-as mobilchipet is ledarálja teljesítményben.

'
Apple is working on a new ARM-based processor with as many as 32 high-performance CPU cores that could appear in a Mac in late 2021, according to a new report from Bloomberg. The processor could also appear in a new “half-sized Mac Pro” in 2022. Alongside it, the company is also reportedly developing CPU designs with up to 16 high-performance cores and four power-efficient cores which are destined for new versions of the MacBook Pro and iMac. The new processors could arrive as early as spring 2021. Future Apple Silicon designs could also feature GPUs with up to 128 dedicated cores.
News of the upcoming processors comes as Apple has just released its first Macs powered by its own chips. The new MacBook Air, MacBook Pro, and Mac mini each used the company’s M1 chip, which features a CPU with four high-performance cores and four high-efficiency cores. However, the company’s more powerful machines like the Mac Pro continue to use Intel chips. Apple has said it intends to transition its whole Mac lineup onto its own chips over the course of two years.'

https://www.theverge.com/2020/12/7/22158264/apple-32-core-processor-arm-mac-macbook-pro

[ Szerkesztve ]

Mottó: "A verseny jó!"

Ez csak akkor probléma az AMD-nek, ha a karos almán natívan futni fog a Windows és még licencelve is lesz a proci másoknak. Elsőre kicsi a sansz, másodikra meg semmi.

Le az elipszilonos jével, éljen a "j" !!!

> Ez csak akkor probléma az AMD-nek,

rövid távon csak az X86 -os ökoszisztéma presztízse sérült ..
de ha az Apple sikeres lesz, akkor ez minta lesz mindenki másnak ..
mind mobil - mind szerver szinten.

és ha a jövő szoftveres ökoszisztémáját - multiplatformosra tervezik ( ARM & X86 ) -
akkor elég nagy lesz a verseny! ( ami mindenkinek jó ! )

Mottó: "A verseny jó!"

> Meg kicsit nehezen hiszem el, hogy most körbehugyozza
> az arm a világot az Intellel szemben almáéknál.

mindenkinek emésztenie kell ..

nézd meg a teszteket ...
és tedd hozzá azt, hogy az M1 ezt az eredményt
- 4 gyenge + 4 erős maggal
- kisebb frekvencián ( 3.2GHz & ~20-24W TDP)
adja.

The 2020 Mac Mini Unleashed: Putting Apple Silicon M1 To The Test
https://www.anandtech.com/print/16252/mac-mini-apple-m1-tested

The performance of the new M1 in this “maximum performance” design with a small fan is outstandingly good. The M1 undisputedly outperforms the core performance of everything Intel has to offer, and battles it with AMD’s new Zen3, winning some, losing some. And in the mobile space in particular, there doesn’t seem to be an equivalent in either ST or MT performance – at least within the same power budgets.

What’s really important for the general public and Apple’s success is the fact that the performance of the M1 doesn’t feel any different than if you were using a very high-end Intel or AMD CPU. Apple achieving this in-house with their own design is a paradigm shift, and in the future will allow them to achieve a certain level of software-hardware vertical integration that just hasn’t been seen before and isn’t achieved yet by anybody else.

Mottó: "A verseny jó!"

Ok, de kérdés, hogy a Mac szilikon mennyi olyan funkciót valósít meg hardveresen, amit pl a Cinebench kihasznál, de a Ryzen-nek meg izomból kell nyomnia szoftveresen?

Le az elipszilonos jével, éljen a "j" !!!

"Meg kicsit nehezen hiszem el, hogy most körbehugyozza az arm a világot az Intellel szemben almáéknál."

Ez nem hit kérdése. A tények meg makacs dolgok.

Én kérek elnézést!

> Ok, de kérdés, hogy a Mac szilikon mennyi olyan funkciót valósít meg hardveresen,
> amit pl a Cinebench kihasznál, de a Ryzen-nek meg izomból kell nyomnia szoftveresen?

ezt nem pontosan értem.

A Cinebench R23 - CPU teszt .. nem teszteli se a GPU-t se más gyorsítót .
Ugyanazt a programkódot lefordítják X86 -ra és ARM -re - ahogy tudja a rendszer.

Az Apple M1 ben összesen: 16 billion transistor - van,
míg az új AMD-ben sokkal kevesebb
"AMD's Zen 3 based Ryzen 5000 series mobility processors feature 10.7 billion transistors "

Mottó: "A verseny jó!"

Nyilván több, mint win + x86 esetben, bár tegyük hozzá, hogy amíg intel procikat használtak, is elég volt egyfelé optimalizálniuk.

Szóval szerintem nem a szarrá optimalizálás itt a fő kulcs. Ami nagy előny, hogy egy kézben van a hardver és az OS is, az, hogy ilyen könnyen le tudnak ennyire brutális architekturális váltást vezényelni.

Én kérek elnézést!

Elég sokat számíthat optimalizálás szempointjából, ha pl. a RAM ugyanazon a lapkán van... ha csak a RAM sebességét valamelyest közelítik vagy optimalizálják a cache-hez.

Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.

Azért egy valamire való CPU benchmark alatt a CPU ideje 99%-ban az alkalmazás kódját futtatja (remélem...), szóval valószínűleg nem számít, hogy milyen OS, stb.

Nocsak, nocsak: [link]
Tévedhetetlen Abu újabb (sokadik) állítása dől meg?!?

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Techpowerup igy indit:

Xeon Platinum 8468,Ryzen 7500F,Gigabyte B650M K,Xeon Phi,i9 7960X,i9 7920X,Xeon w2135,Gskill royal 4400,Gskill Trident Z,Pico 4,Red Devil 7900XTX,Asrock W790 WS,Fury Pro RDIMM 6000,Z590,Intel Cryo,Intel 11900F,Ryzen 5600,Radeon 7600,Radeon 6800...

Zen5 ? josokaleszez. elobb a negyes jojjon ki, aztan majd meglatjuk,.

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