vidim, da imajo najnovejše serije tablic vgrajene že štirijedrne procesorje, napovedujejo se že osemjedrni. zanima me, koliko ima pri tablicah smiselno imeti več kot dvojedrni procesor. ali znajo aplikacije, ki tečejo na teh tablicah, dejansko uporabljati paralelno procesiranje ali v čem je smisel imeti toliko jeder?
tablice in število jeder v procesorjih
- Ustvarjalec teme sass
- Začetni datum
Smisel je v marketingu. Zaenkrat. Velika večina aplikacij je single threaded in nimajo nobene koristi od dodatnih jeder. Pisanje multi threaded aplikacij je zelo zahtevno. Veliko "problemov" se tudi ne da razbiti v več neodvisnih delov, ki bi se lahko izvajali vzporedno.
Trenutno več kot dva jedra nima veliko smisla. To je lepo dokazal Apple z A7 SoC, ki z dve,a jedroma brez problema poseka najnovejše quad core procesorje.
Trenutno več kot dva jedra nima veliko smisla. To je lepo dokazal Apple z A7 SoC, ki z dve,a jedroma brez problema poseka najnovejše quad core procesorje.
Ni vse samo marketing. Je pa res da več kot 2-4 jeder nima ravno smisla imeti.
Čeprav se sliši čudno, ima več jeder manjšo porabo. Več jeder z nižjo voltažo lahko "obdela" enako stvari kot eno jedro, ki pa mora imeti ustrezno višjo voltažo in frekvenco. Odvisnost med močjo in voltažo pa je kvadratna funkcija, zato je končna poraba večja.
To da je večina aplikacij enonitnih, to drži. To pa še ne pomeni da na sistemu laufa le ena nit. Razne asinhrone operacije, servisi v backgroundu... to vse teče v novih in ločenih nitih. Če imaš več takšnih zadev prižganih, je bolj optimalno imeti več jeder z nižjo frekvenco in voltažo.
Da pa je A7 dvojedrn in bolj zmogljiv, pa ni nič čudnega, saj je posamezno jedro precej bolj zmogljivo kot pa eno izmed jeder v štirijedrniku. Podobno kot so nekateri i5 precej boljši od i7 v enonitnih scenarijih.
Čeprav se sliši čudno, ima več jeder manjšo porabo. Več jeder z nižjo voltažo lahko "obdela" enako stvari kot eno jedro, ki pa mora imeti ustrezno višjo voltažo in frekvenco. Odvisnost med močjo in voltažo pa je kvadratna funkcija, zato je končna poraba večja.
To da je večina aplikacij enonitnih, to drži. To pa še ne pomeni da na sistemu laufa le ena nit. Razne asinhrone operacije, servisi v backgroundu... to vse teče v novih in ločenih nitih. Če imaš več takšnih zadev prižganih, je bolj optimalno imeti več jeder z nižjo frekvenco in voltažo.
Da pa je A7 dvojedrn in bolj zmogljiv, pa ni nič čudnega, saj je posamezno jedro precej bolj zmogljivo kot pa eno izmed jeder v štirijedrniku. Podobno kot so nekateri i5 precej boljši od i7 v enonitnih scenarijih.
Jedra pridejo prekleto prav, če poganjaš veliko zadev naenkrat. Če jih ne poganjaš je pač bolje imet samo enega ali dva hitrejša cora, kar se pri applu pozna. Pri applu se tudi pozna, da ima UI thread absolutno prioriteto in se posledično zaradi izrisovanja vse ustavi, kar ustvarja boljši vtis hitrosti, čeprav v resnici ne počne nič. Tukaj je tudi razlog zakaj se andoid še z 18 cori zatika in je počasen, apfel pa frči. V resnici je ravno obratno, android naredi v istem času veliko več, ampak ljudje smo čudna bitja pri dojemanju.
Vse animacije in kar je s tem povezano se izvajajo na GPUju. To da se na iOSu ne zatika je razlog le v tem, da so vse "kritične" zadeve za GPU napisane v zbirnem jeziku.
Čeprav bodo nekateri to težko sprejeli, je objective-C je dejansko performančno slabši od statično kompajlane Jave (če pa ga primerjaš z JIT kompajlano pa je še slabše). Še malo branja na to temo: http://www.codenameone.com/3/post/2013/07/why-mobile-web-is-slow.html
(beri poglavje "Why Java Is Fast & Objective-C Is Slow")
Čeprav bodo nekateri to težko sprejeli, je objective-C je dejansko performančno slabši od statično kompajlane Jave (če pa ga primerjaš z JIT kompajlano pa je še slabše). Še malo branja na to temo: http://www.codenameone.com/3/post/2013/07/why-mobile-web-is-slow.html
(beri poglavje "Why Java Is Fast & Objective-C Is Slow")
Seveda je isto, ampak na Androidu je pač "po potrebi", pri iOS pa praktično povsod. Potem pa če še vzameš v zakup da vsak proizvajalec dela neke lastne "dodatke" k sistemu, ki navadno še dodatno upočasnijo delovanje. Zato pa je med seboj edino smiselno primerjati Nexuse in iOS naprave. Pri raznih Samsungih, HTCjih... že več ni to to.
Jaz sem ciljal predvsem na to, da recimo med skrolanjem v web browserju na iosu vse preneha delat in preneha nalagat stran v ozadju, da vse deluje vrhunsko gladko, medtem ko na androidu res ni nujno vrhunsko gladko, stran se pa tudi med skrolanjem naprej nalaga.
No mogoče je kakšen novejši iOS že dobil ščepec multitaskinga in to ni več nujno res. Ne spremljam scene.
Pa ni res, da se na androidu pospeševanje na GPU-ju dela po potrebi. Pospešeno je vedno in to ni vzrok zatikanja.
No mogoče je kakšen novejši iOS že dobil ščepec multitaskinga in to ni več nujno res. Ne spremljam scene.
Pa ni res, da se na androidu pospeševanje na GPU-ju dela po potrebi. Pospešeno je vedno in to ni vzrok zatikanja.
Kodiranje za GPU je po definiciji v asemblerju, ker za pixel in vertex shaderje ne obstajajo višjenivojski jeziki.
Kar se hitrosti ObjC-ja tiče se čisto strinjam. Performančno kritične zadeve se vedno naredijo v C-ju.
@brgo: UI thread mora imeti absolutno prioriteto, tako je edino pravilno. Ko se rabijo cpu cikli za user interface, morajo bg zadeve čakati. V nasprotnem primeru dobiš slabo uporabniško izkušnjo. Jaz imam raje, da je scrollanje smooth, kot da se da prioriteto dekodiranju slik, ki se med scrollanjem nalagajo.
Drugi trik, ki ga apple uporablja že od prvega iphona so pa animacije. Med alociranjem novih view-ov se grafika offlouda na GPU, CPU pa se lahko posveti novi vsebini. Uporabnik pa dobi občutek tekočega delovanja, ker se UI ne blokira za delček sekunde med nalaganjem. Ta princip se na veliko uporablja tudi v windows phone os.
Samega multitaskinga uporabnik ne rabi. Uporabnik rabi, da se aplikacije posodabljajo ko niso aktivne, da se glasba predvaja v ozadju, da dobivaš IM sporočila, ko app ni aktiven,...
18 jederni android pa se zatika, ker v 90% primerov 17 jeder počiva, preostalo pa deluje s polovično frekvenco, da špara baterijo. Zato vsa ta dodatna jedra ne koristijo popolnoma nič za tekoče delovanje OS.
Kar se hitrosti ObjC-ja tiče se čisto strinjam. Performančno kritične zadeve se vedno naredijo v C-ju.
@brgo: UI thread mora imeti absolutno prioriteto, tako je edino pravilno. Ko se rabijo cpu cikli za user interface, morajo bg zadeve čakati. V nasprotnem primeru dobiš slabo uporabniško izkušnjo. Jaz imam raje, da je scrollanje smooth, kot da se da prioriteto dekodiranju slik, ki se med scrollanjem nalagajo.
Drugi trik, ki ga apple uporablja že od prvega iphona so pa animacije. Med alociranjem novih view-ov se grafika offlouda na GPU, CPU pa se lahko posveti novi vsebini. Uporabnik pa dobi občutek tekočega delovanja, ker se UI ne blokira za delček sekunde med nalaganjem. Ta princip se na veliko uporablja tudi v windows phone os.
Samega multitaskinga uporabnik ne rabi. Uporabnik rabi, da se aplikacije posodabljajo ko niso aktivne, da se glasba predvaja v ozadju, da dobivaš IM sporočila, ko app ni aktiven,...
18 jederni android pa se zatika, ker v 90% primerov 17 jeder počiva, preostalo pa deluje s polovično frekvenco, da špara baterijo. Zato vsa ta dodatna jedra ne koristijo popolnoma nič za tekoče delovanje OS.
Pač razmišljaš dosti ozko in hb obstajajo primerne naprave in OS-i. Meni osebno je najbolj važno, da naprava požre in prenese ama čisto vse, takrat ko mi tisto pade na pamet. Sam imam telefon ali tablico skorajda za nadomestek laptopa z windowsi.
Ko ti bo prišlo na pamet, da boš v iOS napravo zadegal usb dvb-t ključek, ki se ti valja v predalu in bo čudežno delal, ali pa samo poskusil malo diagnostike avtomobila s tistim poceni bluetooth donglom me boš razumel, zakaj ni vse v gladko delujoči demo sceni
Ko ti bo prišlo na pamet, da boš v iOS napravo zadegal usb dvb-t ključek, ki se ti valja v predalu in bo čudežno delal, ali pa samo poskusil malo diagnostike avtomobila s tistim poceni bluetooth donglom me boš razumel, zakaj ni vse v gladko delujoči demo sceni
Tipično razmišljanje programerja. To je tudi en večjih razlogov, zakaj je toliko zanič aplikacij Play store-u. Gledano s stališča uporabniške izkušnje . Ker jih dizajnirajo programerji.
Popolnoma nobenega razloga ni, zakaj bi usb dongle moral prekiniti UI thread. Avto diagnostika pa naj logira podatke, obdelajo se pa naj, ko jih uporabnik rabi. Ne pa da se aktivna aplikacija zatika.
Popolnoma nobenega razloga ni, zakaj bi usb dongle moral prekiniti UI thread. Avto diagnostika pa naj logira podatke, obdelajo se pa naj, ko jih uporabnik rabi. Ne pa da se aktivna aplikacija zatika.
)