Her er nye iPhone X

[Gjest Slettet+5132]

Basert på AndroidAuthority sine oppdagelser, og etter jeg har tenkt meg litt om, kan det være at jeg må trekke tilbake mine uttalelser om at nyere CPU-er gjør at programvareutviklere slipper å optimalisere programvaren sin. Det virker derimot som om de nyeste CPU-ene krever vel så mye optimalisering i koden for å få full guffe som de tidligere modellen, og det virker ikke som om kompilatoren gjør dette for deg. 

 

Så for store programmer med en utømmelig mengde utviklere til å finoptmalisere mot gitte CPU-er, vil man kunne merke forskjell, men det gjør neppe at Ruter-appen klarer å selge deg billett dobbelt så raskt som på en S8

Endret 20. september 2017 av Slettet+5132

[Lunaris]

Det er ikke gitt at optimalisering sparer batteritid (flertråding mot entråding trenger ikke å gjøre det for eksempel, og vil heller ta mer batteritid). 

 

Og det er tilfeller hvor en oppgave oppleves som for treg, selv om man kun gjør den en gang om dagen si (ting som å legge på filtere til bilder er ikke noe jeg gjør ofte, men hvis det ikke gjøres momentant blir jeg fort irritert) -- optimalisering har da lite å si for batteritid, men mye eller alt å si for brukeropplevelse.

Samtidig så bruker faktisk alle brikkeprodusenter multicore for å spare strøm?

 

Jeg forstår ikke hvorfor du stadig kommer med slike uttalelser og teorier som direkte står i strid med det brikkeprodusentene selv gjør?

 

 

 

Angående kamera har ikke Apple hatt noen oppadgående trend. De har vært blant de beste, i åresvis. Ingenting spesielt. Ja de designer egen ISP og SW, men som jeg sa så lager Samsung ISP, kamera og SW. Ingen grunn til at Apple skal ha fordel mot det fordi de lager HW og SW.

 

 

Det har selvfølgelig mye å si om Geekbench rapporterer mye høyere resultater for iPhone relativt sett enn alle andre. Ingen betviler at A11 er best, det er å forvente. Det å være over 50% bedre enn konkurrenten er utrolig. Det å være 27% er veldig bra, men ikke i utrolig klassen.

[Gjest Slettet+5132]

 

Det er ikke gitt at optimalisering sparer batteritid (flertråding mot entråding trenger ikke å gjøre det for eksempel, og vil heller ta mer batteritid). 

 

Og det er tilfeller hvor en oppgave oppleves som for treg, selv om man kun gjør den en gang om dagen si (ting som å legge på filtere til bilder er ikke noe jeg gjør ofte, men hvis det ikke gjøres momentant blir jeg fort irritert) -- optimalisering har da lite å si for batteritid, men mye eller alt å si for brukeropplevelse.

Samtidig så bruker faktisk alle brikkeprodusenter multicore for å spare strøm?

 

Jeg forstår ikke hvorfor du stadig kommer med slike uttalelser og teorier som direkte står i strid med det brikkeprodusentene selv gjør?

 

 

 

Du misforstår hvorfor de kommer med multicore. Jeg antar du ikke har drevet med HPC? Eller studert algortimekompleksitet? Flerkjerne kan spare strøm, iallfall når du har et heterogent design. Det det IKKE kan, er å spare strøm for en gitt algoritme du vil kjøre. Igjen, hvordan vil du få en sorteringsalgoritme til å gå raskere på flerkjerne mot enkeltkjerne? Det er mulig, men du får ikke gevinste du tror du får, og det vil kreve mer strøm.

 

Du misforstår også poenget mitt. Jeg sier ikke at multicore aldri gir strømsparing. Jeg sier at for å fullføre den samme oppgaven i flertråding på en prossor X som er halvparten så treg som prosessor Y i enkeltkjerne, må prosessor X utføre MER arbeid for samme oppgave, nettopp fordi parallelsering av algortimer kan koste. For noen ting er det gratis, og det finnes andre fordeler med multicore enn ren hastighet, men for ren hastighet for alle algortimer, taper man faktisk en del på å kjøre multitrådet.

 

EDIT: Hvis du vil lese mer om begrensinger til parallelisering, kan du sjekke ut disse slidesene for eksempel (har ikke lest igjennom dem selv, du finner mye annen informasjon på nettet). Jeg har drevet med dette i ganske lang tid nå, og vet hva du taper med parallel kode. Du må ha parallel kode for å oppnå topp hastighet, men i mange problemer ender du opp med å løse MER kompliserte problem i parallel enn enkle problem i seriell, og det gjør at 2 kjerner ikke alltid er dobbelt så raskt som 1.

Endret 20. september 2017 av Slettet+5132

[Lunaris]

Problemet er at du alltid snakker om en prosess. Det er ingen som bruker de strømsparende kjernene på tunge oppgaver. Og hvem sier du må parallellisere all koden? Ingen har sagt det. Målet er at alle prosesser i systemet fordeles utover flere kjerner. 

 

Og så har du det faktum at mange av prosessene er fra OS. Altså google. Som har hat utrolig mange år på seg. De har faktisk kunnskapen og tiden til å lage skikkelige parallelliserte prosesser, selv om det er vanskeligere.

 

Og kan du ikke løse det med flere, ja så tar du det på en stor kjerne og setter opp frekvensen på den da. Problem løst. 

 

Se du kommer bare med masse teori og slikt, men det virker ikke til at du ser på hvordan det er i praksis. Og i praksis så utnyttes 4+ kjerner utrolig bra i Android.

 

 

Noe av det tyngste vi har til vanlig er jo gjerne spill. Du kan si utifra teorien din at hvis du tar koden i parallell for spillmotoren så går det utover ytelse, og det vil det jo i praksis og. Og så har du 4x ytelse som følge av flere kjerner for å kompensere.

 

 

Jeg vet heller ikke om du har sett på grafer med frekvens og strømforbruk? Alle chiper er bygget for å være effektive rundt et frekvensområdet. Hele poenget med low-power er at de er laget effektive rundt lavere frekvens, og at det er mer effektivt enn å sette de store brikkene til lav frekvens. Som og betyr at når du pusher en enkelt kjerne så får du 1% mer ytelse for 20% mer strøm liksom. 

 

Så det er enda et punkt du ignorer helt med teorien din. Du tar ikke med fysikken til brikkene i det hele tatt. Du ser det 100% fra et SW synspunkt som du har erfaring fra, og hva som er bra for DEG. Men ofringene på HW siden blir da så latterlige at det aldri i livet er verdt det. Så det er ikke ideelt for SW ytelse og strømforbruk slik det lages nå. Ei heller fra HW perspektiv. Men det er et veldig bra kompromiss. Nok kjerner at HW folkene får det ganske bra til, ikke for mange slik at SW folka klarer å få rimelig god kode til tross.

 

 

Det kan alltid være bedre. SW folka kan skrive apps i assembly istedenfor f.eks. Men hele greiene er basert på kompromiss, og du virker ikke å se det. Du diskuterer bare alt utifra SW teori. Og ignorerer både praksis og andre synspunkt i samme slengen.

[Gjest Slettet+5132]

Du viser at du misforstår helt. Her er det snakk om å få et segment av et program til å gå raskere. Sideprosessor vil da være ganske irrelevant, og kan løses med å ha en "langsom" sidekjerne. Selvfølgelig kan man sette opp kjernehastigheten, men det går kun til et visst punkt på grunn av varmebegrensinger. Det jeg sier er at for å få dette segmenetet til å gå raskere, må en da ty til flerkjerne/parallelitet. Når du gjør det, løser du et tyngre problem enn du ellers ville ha gjort, og du bruker dermed mer strøm. Forstår du det?

[ATWindsor]

Han misforstår jo ikke, han poengterer, som rett er, at selv om en oppgave har større kompleksitet om den gjennomføres med flere tråder, så gjelder allikevel:

 

- De fleste program har mer enn en oppgave å gjøre

- Ytelse har ikke en lineær effektkostnad på hardware-siden.

 

AtW

[Gjest Slettet+5132]

Han misforstår jo ikke, han poengterer, som rett er, at selv om en oppgave har større kompleksitet om den gjennomføres med flere tråder, så gjelder allikevel:

 

- De fleste program har mer enn en oppgave å gjøre

- Ytelse har ikke en lineær effektkostnad på hardware-siden.

 

AtW

 

Nå så jeg kun på problemer hvor man ønsket å optimalisere ett segment av et program for en gitt CPU/telefon. Da hjelper det lite at programmet har andre deler og andre oppgaver, en må fortsatt optimalisere dette segmentet (eg. legge på et bildefilter). Ytelse mot strømforbruk trenger ikke skalere lineært, nei, og jeg påsto aldri at alle paralleliseringer ville bli mer strømhungrige, men noen kan bli det. 

 

Det er derimot ikke det samme som å si at flere kjerner ikke gir noe på generell ytelse eller strømforbruk, og det har jeg heller ikke påstått. Alt jeg sier er at det finnes eksempler hvor en har en flaskehals i programmet, og denne flaskehalsen kan du kun optmalisere bort ved å bruke mer strøm via dyrere parallele algoritmer.

Endret 20. september 2017 av Slettet+5132

[newnick]

Jeg tror de har en helt unik fordel ved å kontrollere hele stacken, og at denne bare vil øke. Altså at vi bare såvidt har sett starten så langt.

 

Men vi får se. Det kommer jo også an på om AR slår an og om Apple klarer å innovere raskere enn resten.

Slik AR er blitt hypet i det siste i nye ios, trodde jeg dette var noe helt nytt, helt til jeg kom på at dette lekte vi med for flere år siden i androidverden. Så vi snakker om eldgammel teknologi pakket inn i sølvpapir. Og eplespiserne biter på. ?

[Gjest Slettet+5132]

 

Jeg tror de har en helt unik fordel ved å kontrollere hele stacken, og at denne bare vil øke. Altså at vi bare såvidt har sett starten så langt.

 

Men vi får se. Det kommer jo også an på om AR slår an og om Apple klarer å innovere raskere enn resten.

Slik AR er blitt hypet i det siste i nye ios, trodde jeg dette var noe helt nytt, helt til jeg kom på at dette lekte vi med for flere år siden i androidverden. Så vi snakker om eldgammel teknologi pakket inn i sølvpapir. Og eplespiserne biter på.

 

 

Nå har også iOS støttet AR tidligere, via for eksempel Snapchat sine filtere Det nye med iOS 11 er at de har et API inkludert i operativsystemet, det har ikke android såvidt jeg vet(?). Det finnes AR-APIer til Android, men de kommer ikke innebygget i boksen. Dessuten kan det vel være at de har mangler iOS-APIet ikke har, og sikkert fordeler også.

[MrL]

 

Jeg tror de har en helt unik fordel ved å kontrollere hele stacken, og at denne bare vil øke. Altså at vi bare såvidt har sett starten så langt.

 

Men vi får se. Det kommer jo også an på om AR slår an og om Apple klarer å innovere raskere enn resten.

Slik AR er blitt hypet i det siste i nye ios, trodde jeg dette var noe helt nytt, helt til jeg kom på at dette lekte vi med for flere år siden i androidverden. Så vi snakker om eldgammel teknologi pakket inn i sølvpapir. Og eplespiserne biter på.

 

 

Du har tydligvis misforstått hele konseptet, integrasjonen og teknologien.

 

For det første, så er dette utviklet for å fungere med de nye dybdesensorene til iPhone. Du får her software som er optimalisert mot hardware, og omvendt - det finnes ikke på android eller telefoner til android - og vil gi veldig nøyaktige AR simulasjoner.

 

For det andre er dette nå et ferdig kit som betyr at hvem som helst kan benytte teknologien uten å ha kjennskap til hvordan den fungerer. Dette åpner opp for helt nye muligheter. 

[_dundun_]

Det finnes på Android også, i form av Project Tango. Finnes hundrevis av folk som bruker det hver dag og sikkert over to apper!

 

Google har lansert en kopi av Arkit også, så om noen år kommer det til noen prosent av Androidmodellene i butikken.

Endret 20. september 2017 av Audun_K

[Gjest Slettet+5132]

The Tango SDK only supports the Asus ZenFone AR and Lenovo Phab 2 Pro phones. Google is continuing AR development with ARCore, a new platform designed for building augmented reality apps for a broad range of devices without requiring specialized hardware.

 

Det er jo to kjempepopulære telefoner! Skal dog sies at ARCore ser mer lovende ut, men det er fortsatt under utvikling.

[_dundun_]

Selve teknologien er jo gammel, point clouds har man hatt lenge og jeg lekte med Layars på iOs for seks år siden. Det nye nå er gode APIer på telefonene "alle" har, samt at man i iPhone X har en Kinect i mobiltelefonen.

[UrgeLoL]

Det er jo kanskje den største svakheten til android. Uansett hva google kommer med av nyvinninger til android så tar det lang lang tid før utviklerene kan benytte seg av disse, om de ønsker å treffe en stor del av androidbrukerene.

[newnick]

Det er jo kanskje den største svakheten til android. Uansett hva google kommer med av nyvinninger til android så tar det lang lang tid før utviklerene kan benytte seg av disse, om de ønsker å treffe en stor del av androidbrukerene.

Det hadde vært ønskedrømmen din, ikke sant? Sannheten er at de fleste nye funksjonene i android er plukket fra tidligere modeller fra alle produsentene, slik at det blir bakt inn i android oset, i stedet for at hver enkelt produsent må implementere dette. Split screen for eksempel. Det eksisterte lenge hos samsung, og sikkert andre produsenter, før det ble implementert som en standard funksjon i android.

[newnick]

 

 

Jeg tror de har en helt unik fordel ved å kontrollere hele stacken, og at denne bare vil øke. Altså at vi bare såvidt har sett starten så langt.

 

Men vi får se. Det kommer jo også an på om AR slår an og om Apple klarer å innovere raskere enn resten.

Slik AR er blitt hypet i det siste i nye ios, trodde jeg dette var noe helt nytt, helt til jeg kom på at dette lekte vi med for flere år siden i androidverden. Så vi snakker om eldgammel teknologi pakket inn i sølvpapir. Og eplespiserne biter på.

Du har tydligvis misforstått hele konseptet, integrasjonen og teknologien.

 

For det første, så er dette utviklet for å fungere med de nye dybdesensorene til iPhone. Du får her software som er optimalisert mot hardware, og omvendt - det finnes ikke på android eller telefoner til android - og vil gi veldig nøyaktige AR simulasjoner.

 

For det andre er dette nå et ferdig kit som betyr at hvem som helst kan benytte teknologien uten å ha kjennskap til hvordan den fungerer. Dette åpner opp for helt nye muligheter.

Og poenget ditt? Er uansett en hype som iallefall jeg aldri bruker. Dybdesensor, eller avstandssensor har jeg også i min Nexus 6p.

[MrL]

 

 

 

Jeg tror de har en helt unik fordel ved å kontrollere hele stacken, og at denne bare vil øke. Altså at vi bare såvidt har sett starten så langt.

 

Men vi får se. Det kommer jo også an på om AR slår an og om Apple klarer å innovere raskere enn resten.

Slik AR er blitt hypet i det siste i nye ios, trodde jeg dette var noe helt nytt, helt til jeg kom på at dette lekte vi med for flere år siden i androidverden. Så vi snakker om eldgammel teknologi pakket inn i sølvpapir. Og eplespiserne biter på.

Du har tydligvis misforstått hele konseptet, integrasjonen og teknologien.

 

For det første, så er dette utviklet for å fungere med de nye dybdesensorene til iPhone. Du får her software som er optimalisert mot hardware, og omvendt - det finnes ikke på android eller telefoner til android - og vil gi veldig nøyaktige AR simulasjoner.

 

For det andre er dette nå et ferdig kit som betyr at hvem som helst kan benytte teknologien uten å ha kjennskap til hvordan den fungerer. Dette åpner opp for helt nye muligheter.

Og poenget ditt? Er uansett en hype som iallefall jeg aldri bruker. Dybdesensor, eller avstandssensor har jeg også i min Nexus 6p.

 

 

 

Poenget er å forstå hvilken kraft Apple har til å gjøre eksisterende teknologi levende og bedre. Ja du har de sensorene i din Nexus - og jeg hadde MP3 spiller før iPod, touchmobil før iPhone og nettbrett før iPad.

 

AR teknologien har aldri vært utbredt på android, og over natten kom den til titalls (muligens flere hundre) millioner av iPhone eiere - det kommer til å få en helt annen effekt. 

Endret 20. september 2017 av MrL

[Lunaris]

Ehm, har ikke folk fått med seg AR/VR? Alle andre satser på VR, og så kom Apple der og sa: "VR suger, AR er tingen!!!"

 

Så at nesten ingen har det på Android er fordi ingen produsenter bryr ser om AR, de fokuserer på VR. Bare fordi Apple har noe betyr det ikke at det er bra, og at alle andre må/burde ha det. Ærlig, jeg var ikke den eneste som så spill-demoen med AR vel? 

 

Så langt så er det jeg har fått ut av Apples AR at du kan få bedre ansikt på snapchat, men det er jo egentlig en endring i frontkameraet. Forbedring av eksisterende funksjon. 

[Gjest Slettet+5132]

Ulempen med VR er at du må ha ekstra utstyr i form av Samsung Gear VR eller Google Cardboard, det er ikke noe en har med seg overalt, og iallfall ikke like ofte som en har med seg telefonen.

 

Til utvida virkelighet trenger du kun telefonen din, og det gjør det mye mer tilgjengelig for Folk Flest®

 

Dessuten vil jeg nå påstå at foreløpig gjør VR seg bedre tilkoblet en PC med full ytelse.

[Lunaris]

 

Nå så jeg kun på problemer hvor man ønsket å optimalisere ett segment av et program for en gitt CPU/telefon. Da hjelper det lite at programmet har andre deler og andre oppgaver, en må fortsatt optimalisere dette segmentet (eg. legge på et bildefilter). Ytelse mot strømforbruk trenger ikke skalere lineært, nei, og jeg påsto aldri at alle paralleliseringer ville bli mer strømhungrige, men noen kan bli det. 

 

Det er derimot ikke det samme som å si at flere kjerner ikke gir noe på generell ytelse eller strømforbruk, og det har jeg heller ikke påstått. Alt jeg sier er at det finnes eksempler hvor en har en flaskehals i programmet, og denne flaskehalsen kan du kun optmalisere bort ved å bruke mer strøm via dyrere parallele algoritmer.

 

Du har aldri kun et program på telefonen din. Du har rimelig mange. 

 

Du antar og i dette at du har en ekstrem single-core last som gjør at ting går saktere pga lav single-core ytelse. Men som jeg sier så går nettlesing på OnePlus raskere enn Apple selv om Apple har bedre singel core ytelse, bedre resultat fra browser benchmarks, og SW optimalisert for deres CPU. 

 

Teorien din er svært avgrenset, og kan ikke overføres til noe virkelige scenarioer. Så hva vil du egentlig frem til? Jeg er helt enig i at teorien din stemmer, men det har løsninger. Vanligvis trenger du ikke. For selv om du har noe som trenger tid på en kjerne, så får du gjort det, og i tide.

 

Som jeg tidligere har sagt, skal du virkelig ha ytelse, så må du parallellisere. Jeg bryr meg ikke hva du sier om vanskelig bla bla, du har bare ikke noe valg. Holder du ikke selv på med blant annet Nvidia GPUer? Jeg mener se på HPC, det hjelper ikke å snakke om 1 kjerneytelse der. Singel core er ofret for multicore på Intels high-end CPUer. For multicore er eneste veien. 

 

Så du vil ikke lage drøye oppgaver single-core, så da får du ikke de tyngste som er bare singel core, og da går det fint, fordi den er uansett kraftig nok. Det jeg nevnte med 1 stor + 3 små f.eks. Det løser problemet, så enkelt. 

 

Hvis du har en veldig tung oppgave og du må ha den på kun 1 kjerne, så gjør du noe galt. Da får du aldri god ytelse på noe.