- Huawei P30 Pro - teletalálat
- Milyen okostelefont vegyek?
- Honor X7 - tavaly minden jobb volt
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Mobil flották
- Samsung Galaxy A55 - új év, régi stratégia
- Redmi Note 12 Pro - nem tolták túl
- Yettel topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Megjelentek az első HMD okostelefonok, ezek a magyar áraik
Hirdetés
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Már nem az Apple a kínai mobilpiac kedvence
it Az IDC szerint az Apple 6,6 százalékkal kevesebb mobilt tudott leszállítani Kínában az első negyedév során – a Counterpoint 19 százalékos visszaesést említ.
-
LG 34GS95QE-B: OLED paneles, ívelt gamer monitor
ph Félmillió forintba kerül az LG új, 240 Hz-es gamer monitora. Megnéztük, mit tud!
Új hozzászólás Aktív témák
-
Ezekiell
veterán
válasz #30786816 #450 üzenetére
Az sztem menni fog. De innen is látszik mennyi eltero igény van, és mekkora szeletet fed le a termekkinalatuk most. Ezt az egészet megoldani ARMmel... Az húzós.
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
Auratech
őstag
válasz Ezekiell #449 üzenetére
Talán közben ezerrel készültek a váltásra és úgy gondolták, az iPadra nem az a PS kell, ami hamarosan amúgy is át lesz portolva. Szerintem, amikor az armos notik megjelennek, hardverkiépítettségtől függően akár menni is fog a PS mondjuk az Pro-n, meg amin mehet, jelezve, hogy a teljes funkcionalitást egérrel, billentyűvel érhetünk el iPadon.
Ha gyengébb a vas, memória, gpu.. ugyanúgy nem települ hardverkompatibilitás miatt, mint az Air2-re az AR-t használó progik.Auratech Field Recording
-
VirsLee
őstag
válasz Auratech #457 üzenetére
Szerintem itt a probléma főleg azzal van, hogy a legtöbb eladott iPad-nek 2 vagy 3 GB memóriája van. Az én 2 GB-os iPad-em is gyors, de párhuzamos futtatásoknál, hamar elkezd újratölteni böngészőlapokat, vagy eljut oda hogy-hogy egy-egy alkalmazás már újraindítás nélkül el se indul.
-
Auratech
őstag
Hát igen. Az én Air2-m is elég fürge a maga három magjával, de például a covidos JHU oldalt nem hajlandó rendesen betölteni. Egyébként még elég frissnek hat.. Persze a tablet 6 éves. Annyira nem mai.. Olvasókönyvnek, hangmodulnak, médiajátszónak.... jó lesz.
[ Szerkesztve ]
Auratech Field Recording
-
#54625216
törölt tag
válasz Ezekiell #444 üzenetére
Szerintem az egész átállás legizgalmasabb kérdése, hogy az apple magára madar-e a "célhardver" koncepciójával, vagy új trendet indít el.
Az minden esetre jól látszik, hogy a 80-as évek eleje óta a hardver fejlődése tolja előre az iparágat és ez a fejlődés legalábbis az általános célú, egyszálas számítási teljesítményben nagyjából elérte a korlátait.
Ebből a szempontból az Apple váltása csak annyiban merész, hogy ők lépik meg elsőként azt, amit előbb-utóbb mindenkinek muszáj lesz.Ami a hardver optimalizációt illeti, ott van példának a Nintendo Switch. Eleinte volt rá a Zelda meg kb. semmi más, de a Switch eladások így is hamar elérték azt a kritikus tömeget, amit a 3rd party kiadók már nem hagyhattak figyelmen kívül. Így olyan játékokat is portoltak rá, mint a Witcher, ami a konzol megjelenésekor még a kétkedők első számú példája volt, hogy na az biztosan nem lesz rá.
Az Apple ebből a szempontból jó helyzetben van, mert az első pár millió ARM-os Mac-et biztosan el tudják adni csak az "Apple exkluzívokkal", a 3dr party fejlesztők meg kénytelenek lesznek azt a piacot is lefedni, ha nem akarják, hogy a konkurencia eléjük vágjon.Ami az Adobe-t illet, az Adobe eleve szarul optimalizál akármire, mégis a Photoshoppal demózták az ARM-os Mac-et.
Szvsz az Adobe-t első sorban az motíválja, hogy ha nem jelennek meg időben Mac-re, akkor sokan alternatív megoldásokat keresnek és ha kiderül, hogy lehet képet és videót szerkeszteni Adobe nélkül is, azt a PC-s eladásaik is megsínylik.
Az iPad esetében ilyen dilemmájuk nincs, mert bár kereslet lenne rá, de a PS hiánya iPadon nem indít el számukra kedvezőtlen felhasználói trendet. -
Ezekiell
veterán
válasz #54625216 #460 üzenetére
A Switch ugye game console, szóval nem nagyon lehet összehasonlítani egy általános célú számítógéppel.
Az meg hogy az X86/64 elérte az egyszálú korlátait, hát az erős túlzás, bőven van teljesítménynövekedés van year to year. Valamint single core performance max játékoknál elsődleges, bármi produktivitás-centrikus felhasználásnál a multicore performance lesz a lényeg mindig is, sőt évről évre egyre jobban.
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
-
Ezekiell
veterán
válasz #30786816 #464 üzenetére
A másik oldalról nézve meg a developerek a bottleneck, amikor nem készítik fel az alkalmazásukat normálisan 6-8-10-akármennyi magra
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
Ezekiell
veterán
Ahogy az Applenél is előfordult már ilyesmi
Apple Pippin.
The 20th Anniversary Macintosh.
Macintosh Portable.
iMac Hockey Puck Mouse.
Apple III.
Apple Newton.
QuickTake 100.Csak az nem hibázik, aki nem is csinál semmit.
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
Ezekiell
veterán
Persze, mindent nem lehet. De azért elég kevés olyan van a hétköznapokban, ami ne tudna értelmesen kibasználni 4-6-8 magot, ha jól lenne megírva.
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
#54625216
törölt tag
válasz Ezekiell #461 üzenetére
"A Switch ugye game console, szóval nem nagyon lehet összehasonlítani egy általános célú számítógéppel."
Éppen ebben lesz szerintem paradigmaváltás a consumer piacon. A verseny nem az általános célú teljesítmény növelése lesz, hanem azoknak a számítási feladatoknak hardveres gyorsítása, ami a consumer felhasználók számára kritikusak.
"Az meg hogy az X86/64 elérte az egyszálú korlátait, hát az erős túlzás, bőven van teljesítménynövekedés van year to year. "
2000-2010 között a leggyorsabb intel cpu-k (P4 1.5Ghz - i7 980x) között az egyszálas teljesítmény különbség a PassMark szerint kb. 4.4X, míg 2010 és 2020 (i7 980x - i9 10900K) között 2X.
Többszálas teljesítményben viszont az i7 980x és a csúcstartó AMD Theadripper 3990x között már 12X a különbség, de még házon belül is az i9 10980XE alacsonyabb órajelen 5X gyorsabb.
Tehát jól látszik a trend, hogy az egyszálas teljesítmény növekedése lassul, a többszálasé meg gyorsul.
Az Apple is akkor váltott PowerPC-ről Intelre, amikor egyértelművé vált, hogy a nagyobb teljesítményt csak egyre növekvő fogyasztással lehet PowerPC alapon elérni. Hiába volt még növekedési potenciál a PowerPC-ben, jól látszott, hogy az Intellel szemben már középtávon se lett volna esélye."a multicore performance lesz a lényeg mindig is, sőt évről évre egyre jobban"
Egyetértek, és ez az, amiben az ARM technológia nyerhet, mert ugyanabból a tdp keretből és árból nagyobb többszálú teljesítményt tudnak kihozni. (Csak hogy elébe vágjak a vitának: nem feltétlenül egy chipbe paszírozva jöhet össze a teljesítmény, lehet alacsony fogyasztású és olcsó arm chipekből többet rakni egy gépbe úgy, hogy az össz fogyasztás és az ár közel azonos egy intel cpu-hoz viszonyítva.)
-
hunluki
senior tag
A W8 nem volt rossz mint asztali OS (jobb memóriakezelés pl érezhető volt), a csempés koncepciót meg azért tolták hogy a windows phone miatt ismerős legyen a népnek. Csak fordítva sült el és nem megszokták a népek hanem megutálták egy életre. Amúgy nem lett volna rossz, csak a megvalósítás és a userekre erőltetés miatt visszalőtt.
[ Szerkesztve ]
-
dokanin
aktív tag
Technikailag lehet, hogy jobb volt, de pl, hogy jutott eszükbe levenni a bezáró X-et és arra kényszeríteni a felhasználókat, hogy találják ki, hogy mostantól az ablak fejlécének közepét kell elkapni az egérrel, majd végigvonszolni a kép aljáig, ha be akarják csukni.
Ez a művelet még ma is meghaladja sok felhasználó képességeit. (Nyomni a gombot és közben mozgatni az egeret).
És ezt még hosszan lehetne sorolni.
Szóval vannak azért elképesztő nagy baklövések is, amik simán végigmennek a legpénzesebb multi döntéshozói láncán. -
Ezekiell
veterán
Hál Istennek nem használom a cuccaikat, de ebből kiindulva nem is nagyon bízok bennük, hogy ezt az ARM váltást abszolválják
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
Auratech
őstag
Szerintem az gyakori hiba, hogy nem tudatosul, hogy a naprakész, profi produkciós szoftvereknek inkább a naprakész gamer pc-k gépigénye dukál, nem pedig egy jobb irodai gép. A PS-nél nem bírod lejjebb venni a részletességet, meg kilőni az effekteket, hogy kiférjen a vason a "60 fps..." , hát még a videóvágás..
Egy rendben tartott I7-es, minimum 16GB ram, 256 ssd, gtx1060-as vga... pc azért nem dől meg a PS-től, de jó ha van tartalék és sávszél..Egy tanteremnyi i5ös,-4GB, ram, integrált vga, 500-as sata vinyó, sulinetes imageből bloatware telepakolt win10 géptől várták az okos feletteseim, hogy faszán menjen rajta az Adobe CC.. hát nem..
Három gépből kiszedtem a ramot az egybe, így16 lett, bevittem a saját ssd-met, friss gyári bios, újratelepítettem, tettem bele egy 1030-as alacsony profilú vga-t és mellétettem az egyik érintetlen gépnek és jé.. elfogadhatóan reszponzív lett, amelyikben volt egy kis odafigyelés.[ Szerkesztve ]
Auratech Field Recording
-
#54625216
törölt tag
válasz Auratech #476 üzenetére
"Szerintem az gyakori hiba, hogy nem tudatosul, hogy a naprakész, profi produkciós szoftvereknek inkább a naprakész gamer pc-k gépigénye dukál, nem pedig egy jobb irodai gép."
Ez windows ökoszisztémában nagyjából így van, de a Mac referencia hardver, azaz a fejlesztő vagy támogatja vagy nem, de ha bevállalja, akkor kénytelen az adott erőforrásokhoz optimalizálni.
Kb. olyan ez, mintha a PC-re fejlesztett játékot konzolra is ki kellene adni: PC-n belefér, hogy ha szarul van megírva a kód, akkor növelnek a hardverigényen, de konzolon fix erőforrásokkal kell gazdálkodni, azaz a fejlesztő vagy optimalizál, vagy bele se kezd. -
Xero
nagyúr
válasz #54625216 #477 üzenetére
Mac-en pont annyira optimalizalnak 2006 ota mint Windowson. Neha annyira sem. Elotte rosszabb volt.
Emlekszem, hogy a nativ(nem rosettas) elso Photoshop kb 10x indult gyorsabban MacBook Pro-n, mint 1-2 evvel elotte az egyel regebbi PPC only Photoshop PowerBookon. Mas muveletek hasonloan alakultak. Igaz a G4 nagyon oskovulet volt mar, de nem volt penz PowerMac G5-re.Egy code build pl pontosan annyit eszik meg Mac-en mint Windowson vagy Linuxon, nincs szignifikans elteres. Adobe Premier-t ugyan en max koca szinten hasznalok, de amennyire tudom Mac-en ez is lassabb mint Windowson. Bar szerencsere ott a Final Cut.
Bizonyos dolgokon lehet csiszolni es az apikkal nagyjabol lehet iranyitgatni a fejlesztoket, de csodak nincsenek.
-
Alchemist
addikt
válasz #54625216 #471 üzenetére
"hanem azoknak a számítási feladatoknak hardveres gyorsítása, ami a consumer felhasználók számára kritikusak"
Ha a fejlesztők nem kapnak ehhez több magra és gyorsítókra automatikusan és hatékonyan optimalizáló fejlesztőrendszert, akkor vagy nem lesznek a gyorsítás lehetőségei kihasználva vagy a bugokkal fognak küzdeni vagy hagyják a fenébe az almás platformra való fejlesztést (kilógnak az idő-pénz-jó termék háromszögből).Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.
-
-
Alchemist
addikt
válasz Ezekiell #480 üzenetére
Azért ehhez eléggé túl kell mennie pl. a jelenlegi autovectorizing lehetőségein, pl. speciális gyorsítók, koprocesszorok szinkronizált feldolgozását megoldani a fejlesztő számára transzparens módon. Ez egyáltalán nem lehetetlen, viszont most szükséges lesz.
[ Szerkesztve ]
Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.
-
-
Ezekiell
veterán
válasz #30786816 #484 üzenetére
Nem a JVM turkálás a lényeg. Ahogy az általad linkelt cikkben is nagyon jól írják, "ARMv8-based server vendors invest heavily in parallelism and memory bandwidth, while keeping the power consumption low. For example, Qualcomm Centriq 2400 platform is said to have 48 single-threaded cores and 6 channels of DDR4 memory per SoC. Marvell ThunderX2 has up to 64 four-threaded cores in dual-socket configuration"
Ennek a kihasználása a lényeg, és hogy végre normális multithreaded alkalmazásokat írjanak a népek, ne 1 szálon futó szarokat.Na de nagyon elmentünk programozó topic irányba, van annak helye, folytassuk ott
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
Alchemist
addikt
válasz Ezekiell #485 üzenetére
"végre normális multithreaded alkalmazásokat írjanak a népek"
Ne is írjanak, hanem a modern fejlesztőrendszer optimalizáljon többszálasra, illetve a könyvtárak legyenek így optimalizálva. Fejlesztési idő/költség szempontjából nem éri meg a multithreading-be való kézi begyömöszölés.Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.
-
Ezekiell
veterán
Valamennyire nyilván optimalizál a compiler/runtime, de nem annyira, mint a kolléga szeretné. De annyira nem is fog.
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
Tin
veterán
válasz Ezekiell #488 üzenetére
Egy parhuzamos architekturat sose fog felepiteni egy fordito. Eleve mas tervezes, masfele mukodes, es igy tovabb. Persze, vannak rutinok a programkonyvtarakban, amik parhuzamosithatoak, de azok mar amugy is ugy vannak implementalva. Sokan nem is ertik, mirol beszelnek, amikor ezt leirjak. Egy szekvencialis program nem parhuzamosithato "csak ugy", es amugy sem biztos, hogy a rovid muveleteknek lenne barmi ertelme.
A multiprocesszor kornyezetbol leginkabb a szervektermekek tudnak profitalni, ahol sok szekvencialis muvelet futhat parhuzamosan, de ott mar eleve mukodik ez a megkozelites oprendszer szinten. Nem mellesleg azok a programok, ahol ez kihasznalhato (pl. kepfeldolgozas, video, vagy mas szamitasigenyes muveletek), mar eleve ugy vannak megirva, hogy ezt hasznaljak.
Eleve a gondolkodasunk is mas, es szerintem nagyon ertelme sincs megtervezni egy programot parhuzamos architekturara, mert a valoban szamitasigenyes muveletek mar eleve ugy hajtodnak vegre, az osszes tobbin meg az 5% gyorsabb uj processzor nagyobb gyorsulast hoz, mint az aktualis processzoron torteno parhuzamositas. -
Ezekiell
veterán
Teljesen egyetértek. Annyit hozzátennék, hogy itt ugye egy X86->ARM váltásról volt eleve szó, ami teljesen más architektúra/elv, RISC vs CISC, jobban épít a multithreadre és a több magos futtatásra, szóval ha ugyanazt a teljesítményt akarja egy fejlesztő kihozni az appjával, mint X86on, akkor muszáj ezt észben tartania, és így irnia a programját.
Aki mibennünk nem bízik, az önmagában sem bízik. Aki mibennünk nem bízik, az a mi fényes békénkben sem bízik. És aki a mi boldog, fényes békénkben nem bízik, az áruló.
-
Tin
veterán
válasz Ezekiell #490 üzenetére
Persze, de a kerdes eleve a hogyan? Kb milyen programot vagy kepes megirni multithreadingre, ez mennyiben mas gondolkodast kovetel meg, es a vegen mi lesz a haszna?
Eleve, hogyan osztod ki a munkadarabokat akkor, ha mar eleve a parhuzamositas miatt ugy kell dolgoznod, hogy tudnod kell, hogy a rutinoddal mik mukodnek parhuzamosan, azok hogyan kommunikalnak, es mi mit csinal? Ha meg egyedul csinalod az egesz nagyobb blokkot, magadnak optimalizalva, akkor is vajon mennyit nyersz vele?
Minden, ami nehany masodpercnel lassabb, erdemes megvizsgalni parhuzamositas szempontjabol, de ezek a muveletek altalaban adtabazis-kezeles, adatmasolas, adattoltes, konverzio vagy feldolgozas. Az osszes letezo esetben pontosan tudnod kell hogy mit csinalsz az adattal, milyen pontokon szedheto reszekre es ezaltal parhuzamosithato, es eleve van-e ertelme az egesznek, mert mondjuk nyernel vele nehany masodpercet. Az adatbazis-kezelesi resze meg amugy is mar parhuzamositott, ahol parhuzamosithato.
Elmeletileg jol hangzik a dolog, de amig a hardverek teljesitmenye ebben az utemben no, a fejlesztok pedig dragak, a jo fejlesztok pedig mocskosul dragak, megis ki invesztal bele ilyenbe csak azert, hogy nyerjen vele 10% teljesitmenynovekedest? Akinek meg ez megeri, azok meg reg megtettek.
Az apple a chipbe fog pakolni egy rakat specifikus elemi muveletet hardveresen, es ezekkel fognak tudni gyorsulast elerni. Aztan majd jon egy uj Photoshop effekt, amire nincs hardveres rutin, es ugyanugy lassu lesz mint x86-on.
-
#54625216
törölt tag
Szvsz az Adobe termékeket úgy általában nem érdemes benchmarkként használni, mert a legszarabban optimalizált szoftverek a piacon.
A Photoshop külön állatfaj még az Adobe cuccai között is. Emlékszem amikor bejött a CC, előtte azt hiszem 7-es volt az utolsó verzió. A CC-vel áttértek 32 bites motorra úgy, hogy az összes létező képet float-ra konvertálták a memóriában, de 32 bit módban csak néhány hdr formátumon lehetett az eszközök kevesebb, mint 1%-át használni. Viszont így megtriplázódott a program memória igénye és a használhatatlanságig belassult. Konkrétan ha a 7-esben elmentett psd-n akartál CC-ben dolgozni, akkor gyakorlatilag semmilyen új funkciót nem kaptál, viszont vehettél új vasat, hogy rendesen tudjál dolgozni. Szánalom.
Az Adobe a grafikai világ Microsoftja: szar termékeket tolnak le a userek torkán és a piaci erőfölényükből élnek, mert hogy azért használják olyan sokan Adobe-t, mert olyan sokan használják.
(A 3D animációs piacon ugyanez az Autodesk: sorra felvásárolták a 3D animációs szoftvereket és vagy kinyírták őket, vagy használhatatlan bughalmazt kreáltak belőlük, mégis - a piacvezető pozíciójukat kihasználva - piacvezetők tudnak maradni.) -
Auratech
őstag
válasz #54625216 #492 üzenetére
Hát ez így kábé ok.
Az A. Audion esetén az effektekkel kirenderelt wav az alapból 32 bites. Na már most az alsó 8-10 bitet simán lehet csonkolni, mivel nincs olyan hanganyag, ami 32 biten old fel, extrém esetet kivéve, pld a Zoom F6 32 bites (dual ad konverteres) rögzítőjét, ahol pld nincs szükség gain állításra, de ez csak egy eszköz. 32 bites dinamikát kb. Daredevil hasznosíthat.. Az alapzaj már a Brown-féle mozgás hangja. Mixerben ok és kell is, akár 48bit, de felesleges a végeredményben.
Sok progiban beállítható, hogy a temporary file szóhossza mekkora legyen.. Ahogy a játékokban a textúra színmélysége..tömörítése.Auratech Field Recording
-
#54625216
törölt tag
válasz Auratech #493 üzenetére
Normál esetben a 8 bites képeket is van értelme 16 vagy 32 bites színmélységben szerkeszteni. Ha több effektet pakolsz egymásra és mondjuk az egyik 1 fölé tolja a fényességet (kiégeti a képet), a másik pedig azt korrigálja (mondjuk egy maszkkal), akkor a 8 biten a kiégett részek helyén nem jönnek vissza a részletek, hanem szürke paca lesz, mert az 1 fölötti értékek a műveletek során elvesznek. 32 bites színmélységnél viszont a program képes az 1 fölötti értékeket is kezelni, így tetszőlegesen tolhatsz bármit 1 fölé (vagy akár negatív tartományba).
Csakhogy a PS CC-nél csak a kép bitmélységén módosítottak, az eszközökön semmit, azaz a 8 bites képeken ugyanúgy csak a 8 bites effekteket lehetett használni, így a 32 bitre konvertálásnak az égvilágon semmi értelme nem volt: minden 8 bit mellé írtak még 16 nullát, a műveleteket meg csak az első 8 biten végezték, a plusz 16-ot meg ignorálták. Ezzel nőtt az erőforrás igény, a funkcionalitás meg nem változott.
Azaz vagy maradtak volna 8 bites ábrázolásnál vagy írták volna át az összes eszközt rendesen 32 bitre.Persze az Adobe-nál pontosan tudták, hogy mit csinálnak: a fejlesztők megírták a 32 bites PS-t majd jött a marketing team és szétcincálta, hogy ez a feature megy majd a következő verziókba, ez meg az utána következőkbe, az erőforrás optimalizálás meg az utolsó a prioritások között.
Ilyen az, amikor egy cég erőfölényből diktál egy iparágnak. -
Alchemist
addikt
válasz Ezekiell #488 üzenetére
Jogos amit írtok és ez meg is válaszolja a kérdést. Ha a vas egyszálas teljesítménye gyengébb lesz, akkor a teljesítményt igénylő szoftverek jó része is, hacsak valaki nem finanszírozza meg a spec architektúrára való reszelgetést.
Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.
-
Tin
veterán
válasz Alchemist #495 üzenetére
Nem lesz gond. A pár évvel ezelőtti 6700K proci a gépemben egy sima H.265 dekódolásban is megizzad, 100% CPU, szerintem még folyamatosan sem tudja kikódolni. Egy mai mobil proci lazán kódolja befelé 4K-ban 60 fps-el, mert benne van a hardveres támogatás.
Az Apple bele fogja pakolni a gyakran használt rutinokhoz tartozó hardveres gyorsításokat a SOC-ba, és a programok ezeket fogják hívni. Effektek, szűrők, elemi számítások, stb, mind gyorsítva lesznek. Ha a saját programjait (pl. Final Cut) átírja úgy, hogy ezeket használják, agyonvernek teljesítményben egy erős x86-os procit, mindezt alacsony fogyasztással, simán megy a realtime rendering. Az Adobe is csatlakozhat, definiálja hogy milyen hardveresen gyorsított funkciók kellenek, és az Adobe termékek is hasíthatnak. Ez az előnye.
Hátránya: új effektekhez új proci kell, vagy döglassú lesz szoftveresen. Célhardvereket csinál az Apple, amin a saját és az a néhány progi hasít, de a nyers számítási teljesítménye korántsem lesz akkora. Felhasználókat nem érdekli, csak a sebesség és a fogyasztás, a gépek persze elavulnak pár év alatt ahogy fejlődnek a szoftverek, de kit zavar. Jól meglátták az ebben rejlő lehetőséget, és ki is fogják használni. A vásárlóknak ez jó hír, a szoftvergyártóknak sem gond, a trükk persze trükk marad, de kit izgat.... lefogadom, hogy a többi procigyártó is majd követi a példájukat, amivel - sajnos - pont a nyers teljesítmény fejlesztése fog visszaesni a specifikus hardveres gyorsítás kárára.
-
Alchemist
addikt
A nagy fejlesztők, brandek esetében ez járható út, viszont a kisebb fejlesztői erőforrásokkal rendelkező, de teljesítményt igénylő és nem feltétlenül média rendering-et célzó cégeknél vajon mi lesz a megoldás?
Ezért hoztam fel pl. a Matlab-ot vagy akár más, mérnöki számolós szoftvereket.[ Szerkesztve ]
Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.
-
-
#54625216
törölt tag
válasz Alchemist #497 üzenetére
Belinkelem ide is, amit pár (száz) hozzászólással feljebb már írtam:
Apple ökoszisztémában számít: olyan feladatok, amik az apple userek kiszolgálása szempontjából fontosak, azaz pl. a mérnöki-tudományos számítások pont nem ilyenek
Végtelen teljesítmény igény: ezeknél a számítási idő a konstans, mert a teljesítmény növelésével arányosan nehezedik a feladat, amíg a rendszer el nem éri a user számára még elviselhető számítási időt (pl. 3D render: addig bonyolítják a látványt, hogy még le tudja renderelni a gép vállalható idő alatt)
A cpu platform váltás szemponjából tehát az utolsó téglalap az érdekes, abban lehet valódi kockázata az Apple-nek, hogy lesznek olyan - az ökoszisztéma szempontjából lényeges, végtelen teljesítmény igényű, nem párhuzamosítható és célhardverrel nem kiváltható - feladatok, amiben a saját cpu-juk gyengébb lesz az x86 megoldásoknál.