Hirdetés

2021. március 1., hétfő

Gyorskeresés

Hozzászólások

(#1) CPT.Pirk


CPT.Pirk
Jómunkásember
LOGOUT blog (1)

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

(#2) martonx


martonx
addikt

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!

(#3) Agyturbina válasza CPT.Pirk (#1) üzenetére


Agyturbina
senior tag
LOGOUT blog

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

Lehet ismételten nem fog sikerülni?

,........A szükségletek lettek a célok, és a célok szükségletek lettek........, ,........A paradoxonban az a szép, hogy paradox módon nem szép.............,

(#4) E.Kaufmann válasza CPT.Pirk (#1) üzenetére


E.Kaufmann
őstag

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" !!!

(#5) Alchemist válasza E.Kaufmann (#4) üzenetére


Alchemist
addikt

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.

(#6) CPT.Pirk válasza E.Kaufmann (#4) üzenetére


CPT.Pirk
Jómunkásember
LOGOUT blog (1)

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)

(#7) flashpointer


flashpointer
senior tag

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

(#8) Duracellm...


Duracellm...
veterán

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 ]

(#9) kisfurko válasza E.Kaufmann (#4) üzenetére


kisfurko
aktív tag

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

(#10) Tigerclaw


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.

(#11) Meteorhead válasza Alchemist (#5) üzenetére


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.

(#12) E.Kaufmann válasza CPT.Pirk (#6) üzenetére


E.Kaufmann
őstag

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" !!!

(#13) dokanin


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 ]

(#14) E.Kaufmann válasza dokanin (#13) üzenetére


E.Kaufmann
őstag

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" !!!

(#15) martonx válasza E.Kaufmann (#14) üzenetére


martonx
addikt

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!

(#16) JoeYi válasza dokanin (#13) üzenetére


JoeYi
őstag
LOGOUT blog

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.

(#17) Pingüino válasza martonx (#2) üzenetére


Pingüino
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. :)

A józan ész nem ajándék, hanem büntetés, mert nap mint nap meg kell küzdened azokkal, akiknek nincs.

(#18) Pingüino válasza CPT.Pirk (#6) üzenetére


Pingüino
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.

A józan ész nem ajándék, hanem büntetés, mert nap mint nap meg kell küzdened azokkal, akiknek nincs.

(#19) E.Kaufmann válasza Pingüino (#17) üzenetére


E.Kaufmann
őstag

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" !!!

(#20) Pingüino válasza Tigerclaw (#10) üzenetére


Pingüino
tag

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. :)

A józan ész nem ajándék, hanem büntetés, mert nap mint nap meg kell küzdened azokkal, akiknek nincs.

(#21) E.Kaufmann válasza Pingüino (#20) üzenetére


E.Kaufmann
őstag

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" !!!

(#22) Execᵀʰᵀˢ válasza JoeYi (#16) üzenetére


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.

(#23) dokanin


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.

(#24) Duracellm... válasza Tigerclaw (#10) üzenetére


Duracellm...
veterán

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 ]

(#25) Tigerclaw válasza dokanin (#13) üzenetére


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.

(#26) Tigerclaw válasza Pingüino (#20) üzenetére


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.

(#27) velizare válasza JoeYi (#16) üzenetére


velizare
veterán

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.

(#28) Pingüino válasza Tigerclaw (#25) üzenetére


Pingüino
tag

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. :)

A józan ész nem ajándék, hanem büntetés, mert nap mint nap meg kell küzdened azokkal, akiknek nincs.

(#29) Pingüino válasza Tigerclaw (#26) üzenetére


Pingüino
tag

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.

A józan ész nem ajándék, hanem büntetés, mert nap mint nap meg kell küzdened azokkal, akiknek nincs.

(#30) exedoc


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.

Kicsit írjatok hangosabban, mert ebben a maszkban semmit nem látok! // Unreal Engine Archviz render -> https://youtu.be/ighSeS7TQss //

(#31) Pingüino válasza exedoc (#30) üzenetére


Pingüino
tag

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.

A józan ész nem ajándék, hanem büntetés, mert nap mint nap meg kell küzdened azokkal, akiknek nincs.

(#32) dokanin válasza exedoc (#30) üzenetére


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.

(#33) martonx válasza JoeYi (#16) üzenetére


martonx
addikt

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!

(#34) E.Kaufmann válasza dokanin (#32) üzenetére


E.Kaufmann
őstag

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" !!!

(#35) Meteorhead válasza E.Kaufmann (#34) üzenetére


Meteorhead
aktív tag

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

(#36) sh4d0w válasza Tigerclaw (#10) üzenetére


sh4d0w
nagyúr
LOGOUT blog

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://coreinfinity.tech

(#37) Robitrix válasza flashpointer (#7) üzenetére


Robitrix
aktív tag

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.

(#38) Taranti válasza dokanin (#13) üzenetére


Taranti
senior tag

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

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

(#39) Robitrix válasza dokanin (#13) üzenetére


Robitrix
aktív 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.

(#40) Robitrix válasza Taranti (#38) üzenetére


Robitrix
aktív 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)

(#41) Robitrix


Robitrix
aktív 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.

(#42) hokuszpk


hokuszpk
addikt

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

(#43) Tigerclaw válasza Meteorhead (#35) üzenetére


Tigerclaw
nagyúr

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.

(#44) Tigerclaw


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.

(#45) morgyi


morgyi
nagyúr

Mondjuk én se értem, hogy az AMD féle órajelkapuzás és power management mellett mi értelme lenne.
Sokszor látok olyan scenariot hogy a 6 magból 4 alszik, kettő meg 600Mhz körül ketyeg.

A Linux rendkívül felhasználóbarát, csak megválogatja a barátait

(#46) hokuszpk válasza morgyi (#45) üzenetére


hokuszpk
addikt

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

(#47) arn


arn
nagyúr

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

(#48) dokanin


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 ]

(#49) S_x96x_S


S_x96x_S
senior tag

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

(#50) sel válasza hokuszpk (#42) üzenetére


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 ]

Copyright © 2000-2021 PROHARDVER Informatikai Kft.