Új hozzászólás Aktív témák

• #17 #54625216 törölt tag #06658560 #14

  Új Válasz 2018-04-03 12:54:07 #17

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  #54625216

  törölt tag

  válasz #06658560 #14 üzenetére

  Az Apple ökoszisztéma fenntartásához szükség van tartalomgyártásra is, ahhoz meg nem jó a felhő + gyenge hardver. A tartalomgyártást pedig nem engedheti ki az Apple a kezei közül, mert azzal megint csak más platformoktól függene.

  Igazából nem látom esélyét, hogy az Apple a közeljövőben a desktop vonalon is ARM-ra váltson. Eddig minden architektúra váltást az indokolta, hogy az aktuálisan alkalmazott technológia lemaradt a teljesítmény versenyben.
  Jelenleg viszont még mindig az x86 vezeti toronymagasan a desktop CPU mezőnyt, így nincs technológiai oka a váltásnak.
  Max. olyasmit tudok elképzelni, hogy mondjuk 4-8-12-16 ARM procit pakolnak egy Mac-be, ami összteljesítményben már le tudna nyomni egy x86-os megoldást.
  Az Apple elméletileg megteheti, hogy az egész ökoszisztémát brutál mód multithread-re erőlteti, de még ha az OS-t titokban fel is készítik erre, 2020-ra akkor sem tudnának előrukkolni egy ennyire radikális megoldással, mert ahhoz legalább néhány meghatározó szoftver fejlesztőnek (Adobe, Autodesk, stb.) is ugrásra készen kellene állnia.

• #30 opr veterán #06658560 #14

  Új Válasz 2018-04-03 13:34:11 #30

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  opr

  veterán

  válasz #06658560 #14 üzenetére

  Van, ahol ez mukodik, viszont van olyan tipikusan magas cpu-igenyu alkalmazas, ahol a felho a nagy kesleltetes miatt kiesik. (vegyuk figyelembe, hogy fel is kell tolteni az adatot meg le, nem csak a ping van)
  Ilyen pl a zeneszerkesztes, filmvagas, kepszerkesztes, stb. Persze a vegleges termeket mar ertelmes cegek cloudban vagy valami serveren renderelik ki, de odaig el is kell jutni.

  Programozasnal sok esetben nagyon jol mukodik a lepkefing ereju kliens, eros buildserver elgondolas, de szerintem ez inkabb azt jelenti, hogy a programozas a specialisabb jellegu feladat.

  De pl egy ertelmesebb IDE egy nagy volumenu projekttel biztos, hogy egy a11-et kifektet a picsaba forditas nelkul is ma is, es akkor meg nem profilozunk vagy ilyesmi. Alattam a Ryzen 7 1700 (otthon) meg a mittomen milyen xeon nem kicsit erolkodik/haldoklik/szenved sokszor, pedig distributed build van.

  Pl. Egy combosabb webkit fork rebuild 4-5 ora ugy, hogy befogok magam melle meg 15 gepet xeonostul ramostul mindenestul.
  De ha a buildtol eltekintunk, amikor valami nagyobb dolgot irok at/valtoztatok, aztan tesztelek/profilozok, neha konkretan az eger is akadozik, annyira terheli a gepet a cucc.

  Dolpa #15:
  "Nem kell a nulláról tervezni, már meg van az alapja az A11 személyében."
  Igen, kb mint ahogy a ferrarinak se kell nullarol tervezni, mert mar megvan az alap a kispolak szemelyeben.

  "Én már alig várom, hogy ez a szutyok x86 eltűnjön végre a süllyesztőbe, már az x86-64-et sem kellett volna erőltetni."
  Ezt azert leervelhetned jol, ha mar igy kinyilatkoztattad.

  "Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin

Új hozzászólás Aktív témák