- Realme 9 Pro+ - szükséges plusz?
- Google Pixel 6/7/8 topik
- Milyen hagyományos (nem okos-) telefont vegyek?
- Samsung Galaxy S23 Ultra - non plus ultra
- Motorola Edge 40 - jó bőr
- Okosóra és okoskiegészítő topik
- Xiaomi 11 Lite 5G NE (lisa)
- Telekom mobilszolgáltatások
- Eredeti dizájnnal tér vissza idén a Nokia 225 4G
- Apple iPhone 13 Pro Max - őnagysága
Hirdetés
-
Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
ph A szokatlan külsejű CineBeam Q képes a 4K felbontás megjelenítésére.
-
Friss előzetesen a Destiny 2: The Final Shape
gp Érkezik az utolsó nagy kiegészítő, azonban a fejlesztők szerint ettől még nem lesz vége a franchise-nak.
-
Közel 1 billió dollárt vesztettek a big tech óriásai
it Nagyot kaszáltak a shortolók, az úgynevezett Magnificent 7 közel 1 billió dollárt veszített a piaci értékéből a múlt héten.
Új hozzászólás Aktív témák
-
CPT.Pirk
Jómunkásember
...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)
-
martonx
veterán
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!
-
E.Kaufmann
addikt
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" !!!
-
Alchemist
addikt
válasz E.Kaufmann #4 üzenetére
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.
-
CPT.Pirk
Jómunkásember
válasz E.Kaufmann #4 üzenetére
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)
-
flashpointer
őstag
" nyolc kis és nyolc nagy magot keverne "
legyen benne 16 nagy mag es problem solved -
#16939776
törölt tag
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 ]
-
kisfurko
senior tag
válasz E.Kaufmann #4 üzenetére
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...
-
Tigerclaw
nagyúr
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.
-
Meteorhead
aktív tag
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.
-
dokanin
aktív tag
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 ]
-
martonx
veterán
válasz E.Kaufmann #14 üzenetére
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!
-
JoeYi
őstag
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.
-
Pingüino
senior tag
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.
-
Pingüino
senior tag
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.
-
E.Kaufmann
addikt
-
Pingüino
senior tag
válasz Tigerclaw #10 üzenetére
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.
-
E.Kaufmann
addikt
-
Execᵀʰᵀˢ
tag
>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.
-
dokanin
aktív tag
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. -
#16939776
törölt tag
válasz Tigerclaw #10 üzenetére
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 ]
-
Tigerclaw
nagyúr
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.
-
Tigerclaw
nagyúr
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.
-
nagyúr
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.
-
exedoc
senior tag
É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.
-
-
dokanin
aktív tag
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. -
E.Kaufmann
addikt
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" !!!
-
Meteorhead
aktív tag
válasz E.Kaufmann #34 üzenetére
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). -
válasz Tigerclaw #10 üzenetére
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
-
Robitrix
senior tag
válasz flashpointer #7 üzenetére
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.
-
Robitrix
senior tag
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.
-
Robitrix
senior tag
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)
-
Robitrix
senior tag
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.
-
hokuszpk
nagyúr
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...
-
Tigerclaw
nagyúr
válasz Meteorhead #35 üzenetére
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.
-
Tigerclaw
nagyúr
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.
-
hokuszpk
nagyúr
válasz #32839680 #45 üzenetére
"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...
-
arn
félisten
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
-
dokanin
aktív tag
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 ]
-
S_x96x_S
őstag
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ó!"
-
sel
csendes tag
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 ]