Apple lanserar Iphone 5S och 5C

Våran är också lite silvrig. Började nötas efter ca 1 år typ

Jag har en kinalur för 1300 med 2600 mah. Sjukt prisvärd telefon f.ö. Men fan vad apple snålar kan man tycka.... Dom tar ju ändå så förbannat mycket för grejerna

Skickades från m.sweclockers.com

"Retina" är inte den maximala upplösningen utan kort och gott en gräns där du vid ett visst avstånd inte tycker det är pixligt längre. Du kan fortfarande se en pixel som är mindre. Det betyder inte att du inte uppfattar högre upplösning eller att en 1280x720 skärm och 1920x1080 skärm uppfattas likadant eller att de två olika skärmarna presterar lika. Dessutom uppfattar du upplösningsskillnaderna i 5-6.3" telefonerna. Du behöver däremot inte öka PPI bara för sakens skull.

Det kan ju finnas många orsaker, frånsett kostnad, till varför batteriet inte är större. Tex. Batterivolym, vikt och tid att ladda.

Tid att ladda? Laddar du med t.ex 1Ah så gör du väl. Eller går det inte att koppla från innan 100%??
Ett större bätteri går att ge mer effekt än ett litet. Så om batteriets kapacitet vore den begränsande faktorn för att ta emot laddning så laddar ett stort snabbare. Om vi ser till lagrad effekt.

Kameran är ju en av få saker som uppgraderats. Vad har du förresten läst att den har 1 Gig ram? Vad jag vet är detta inte bekräftat.

Jag menar att det tar längre tid att ladda ett större batteri fullt med samma laddningsström. Sedan bestäms ofta laddningsströmmen som en faktor av batteriets totala kapacitet. Givet nog ström så laddar man alla batterier oavsett kapacitet på en timma (laddning med 1C), men det går att ladda batterier med upp till 15C (fyra minuters laddning). Dock är det bättre för batteriet att ladda långsammare.

Man laddar inte ett batteri med "Ah" - amperetimme (Ah) är ett mått på elektrisk laddning inte elektrisk ström.

Det jag menade är att det för kunden upplevs som att laddningen tar längre tid om man har ett större batteri och fortfarande är bundet av begränsningarna i USB standarden (och icke standarden som märkesspecifika laddare använder) etc. Som ett exempel se skillnaden mellan iPad 2 och iPad 3, där sistnämnda har ett batteri som har 1,7 ggr högre kapacitet och tar mellan 6 och 7 timmar att ladda mot 4-5 timmar i iPad 2.

Men det är sant att man med ett mycket större batteri och kraftigare laddare skulle få ut mer standby-tid pr. "ladd-tid".

Mitt poäng var att det finns andra aspekter än kapacitet och kostnad. Annars kan du ju lika gärna koppla ett bilbatteri till mobilen och bära med dig det.

Samt lägger till en 15% större sensor, dock med samma upplösning som tidigare. Den större bländaröppningen kommer sig av den större sensorn.

Då förstår vi varandra. Att jag skrev som exempel laddar med 1Ah var för att det är en fast mängd ström under en fast tid. 1A i en timme.
Båda batterierna har samma effekt lagrad, o telefonen klarar sig lika länge oavsett vad det står för %.

Nu är 1 GB LPDDR3 minne är bekräftat av Anandtech, i både 5s och 5c.

Enligt Anandtech som testat med samma kod kompilerad som 32-bit och 64-bit på A7 SoC'en så är det över lag en hastighetsökning av heltalberäkningar på i genomsnitt 27% med en spridning på 67%. Jag bortser här från HW accelerad AES som i sig ger ca 800+% förbättring.

Samma test för flyttalsberäkningar är: En genomsnittlig hastighetsökning på 45%, med en spridning på 60%.

Detta vid att endast kompilera om koden, inga speciella optimeringar utan endast den ökning av antal register samt A64 instruktionerna som A7 SoCen ger. Ni som snackar om att enda fördelen är att kunna adressera 4+ GB minne, ni yrar i nattmössan!

Visst en del av ökningen står för ökningen av antal register och är inte ett direkt resultat av övergången till 64-bitars intruktionssettet, men man kan lungt säga att 64-bitars A7 är en rejäl uppgradering.

OBS! Spetsen_n11 påpekar korrekt at SHA1 också ska bortses från eftersom den är hårdvaruaccelererad, nya resultaten för heltalsberökningarna är således en ökning på 7% i snitt och en spridning på 16%.

Nu har ju många inklusive VVoid länge påpekat att AArch64 är i princip helt annorlunda mot tidigare 32-bitars ARM-arkitekturen, helt kanske är fel sätt att beskriva det men det är lite mer än en förlängning och fler register med 64-bit dword dessutom har du nya eller annorlunda instruktioner för SIMD/FPU. Som kommer med ARMv8, alltså förändringar hos Neon och instruktionerna med ARMv8 som inte finns i 32-bitsdelen som kör samma instruktioner som förr. Det blir därför ganska olika kod (och instruktioner till processorn) från kompilatorn. Medan på PPC och x86-64 inte spelar så stor roll om det är 64-bit eller 32-bit när det gäller prestanda, alla SIMD-instruktioner finns tillgängligt vilket som. Att bara öka ordstorleken kan i många fall göra det slöare, men det beror också på halvledardesignen. Därför man inte bara breddar och breddar, för du kan köra jättebrett och jätteslött Det tar ju längre tid att köra bredare vägar i vissa fall.

När det gäller minne har A15 redan stöd för LPAE och mer än 4GB minne med hjälp av 40-bit adressering, eftersom det inte är Windows kan också varje process använda upp till 4GB ram. Det är främst andra förbättringar 64-bit ger, och kan möblera om annat. Även om du på sikt säkert vill att program ska kunna adressera mer än 4GB minne. När det handlar om att öka antalet register och prestandan därifrån säger Anand själv "The doubling of the register space with x86-64 was responsible for up to a 10% increase in performance.". Men där så rörde inte AMD/Intel SSE-instruktionerna. Du får några möjligheter du inte har när du kör AAarch32 på samma chip hos ARMv8-kompatibla processorer, och de har möblerat om så det är inte samma instruktioner i båda lägena, en del instruktioner har ersatts av andra eller tagits bort och koden kommer helt enkelt inte se likadan ut när det är handkodat eller från instruktionerna kompilatorn ger automatiskt. Så ja en hel del skillnader. Och förändringarna från AArch32 används ju dessutom inte hos kompilatorn eftersom verktygen säger till den att den ska vara helt kompatibel med tidigare ARMv7-chip. Sen ser du själv att det finns saker som är slöare (eller lika snabb) i AArch64 än AArch32. De stora förändringarna beror på hur VFP/NEON-instruktionerna har förändrats bland annat om vi bortser från AES-stödet. Annars är det inte så mycket mer än ±10% där sakerna är som lika. Gör man på olika sett och stödjer olika funktioner så skiljer det såklart mer. Det är inte som att Webkit är 27-45% snabbare (eller någon programsvit får de resultaten) och därför kör över allt annat. Krait 400 och Silvermont (32-bit x86) står sig väl i sånt som browsertesterna. Du får ju tänka på att det är nästa generations chip som kommer driva Apple i ett och ett halvt - två år framåt. Det är långt ifrån chip som kan driva stationära Macs.

Ja jag håller fullständig med dig Petterk, detta är inte endast en övergång till A64 utan en mängd med ändringar. Men Anands tester visar att det finns fördelar hos A7 i förhållande till A6 som kan tillskrivas 64-bitars arkitekturen. Dock är det, som du mycket riktigt också påpekar, syntetiska benchmarks. Men även syntetiska tester kanske hjälper Martinot att "se nyttan med 64-bitars processor på telefoner i dagsläget".

Det som är imponerande är ju att hela iOS7 med hela userland, och alla medföljande program är 64-bit. Apple har lärt sig bra från skrivbordet där. Det är bara bra som övergång, om ett par år är alla plattformar 64-bit, och chippen kommer användas i andra tillämpningar där de har ännu mer nytta av det hela.

Och ja, alla Appar kommer i princip vara omkompilerade för iOS då de infört så mycket ändringar i 7an och till stor del därav också för 64-bit. Lite som att om du kör Android NDK:t kompilerar för Intel samtidigt som du bygger din ARM-app som du testar på ARM-emulator och telefoner. Android kanske inte är så illa ute för x86-64 då det redan stödjer att man bygger och packar in stöd för flera arkitekturer i samma program / apk. iOS har fördelen att de kan köra universial binaries, men även Android som stödjer flera arkitekturer (kommer som olika filer packat i samma program) har fördel av vanlig server/desktop-distribution av GNU/Linux. Vi får se när de tar steget, vi får se Linux-servrar för AAarch64 innan mobiler iaf. Dalvik behöver ju förbättras och anpassas för att rulla fint på 64-bit antagligen. Dalvik-delarna av programmen drar ju fördel av en 64-bit dalvik även om dess native-bibliotek (om den även har sådana) är 32-bit. Där beror allt på hur mycket jobb man lägger ner som vanligt.

Stödet finns i Xcode / Ios-SDK numera, och apierna är ju samma för iOS7 oavsett om det är 32 eller 64-bit. Enklast är att strunta i 64-bitar som jag sett det, men steget är inte så stort (mycket av det rullar på 64-bit på t ex Mac eller Linux redan och är portabel kod, ser att många projekt klarar att byggas "experimentellt" för A64/IOS7) och emulatorn verkar köra x86_64, inte för att jag testat något själv. Det finns inget krav, och det kommer det nog inte finnas fören de lägger ner 32-bit-produkterna. När det gäller virtuellt minne stödjer inte Darwin, Linux eller Windows 64-bit med dessa chip, x86-64 har 48-bit adressrymd det har denna också. Fördelen är att de kan möblera om som sagt.

Ja, jag är övertygad om att Apple kommer att kräva att man sätter build taget till ARMv8 precis som de gjorde med ARMv7 för iOS 5 och att man skeppar feta binärer. I och med Xcode 4.5 försvann ARMv6 stödet helt (innan dess var det en del strul med att Apple inte testade det och vissa bibliotek länkade inte etc.). Detta kommer att ge binärer som är kompilerade för 64 bitar i AppStore på bara några veckor, Apple är duktiga på att flytta menigheten framåt.

Jag tror att en orsak till att 64bitar stödet kommer nu är för att minska antalet build tagets, den enda stora förändring på iOS har varit övergången från ARMv6 till ARMv7, i och med att ARMv8 kommer nu så tror jag att det blev enklare att inkludera A64 samtidigt som ARMv8. Om det har att göra med att Apple inte önskar en 32 bitars armv8 eller för att minska antalet binärer kan jag bara spekulera i.

Grunden för att lyckas med feta binärer är att hålla antalet variabler lågt och göra det möjligt för utvecklare att testa för att upptäcka eventuella fel redan i utveckling. Man förlorar lätt utvecklare om felen endast fångas upp vid en AppStore Review. Armv7 + Armv8_A64 är två tagets, två variabler. Utvecklare behöver en iPhone 5S och en annan iPhone, iPod eller iPad.

Det är först och främst flyttalsberäkningar som drar nytta av de nya 64-bitars instruktionerna, men också TouchID använder sig av den nya enklare processisolering och "privilegie-modellen" som kommer med den nya ISAn.

Ibland måste man bygga om från grunden, och eftersom det är en komparativ fördel för Apple att köra native kod så måste de försöka att bygga bort en del av de nackdelarna genom att inte tvinga sina utvecklare att hela tiden ta hänsyn till nya plattformar. Det kommer att komma tillräckligt med nyheter i form av ny hårdvara, upplösningar och tillägg som sticker käppar i hjulen för utvecklare.

Precis som Petterk säger så kör simulatorn på x86-64 (det är dock inte en emulator, utan binärer byggs för hostsystemet med iOS libs kompilerade för x86-64, som om det var ett iOS för Intel CPUer).

Det är nog väldigt individuellt beroende på vilken typ av appar du har. Skaffar man program från utvecklare som är intresserade av det de gör så tror jag absolut att man har stöd inom några veckor. Appar som uppdateras ofta brukar få stöd för nya funktioner snabbt. Sedan är det ju inte precis "Hitta närmaste brevlåda"-apparna som drar nytta av de nya möjligheterna, men spel och mer krävande program kommer utan tvivel att få stöd fort.

Helt gå miste nej, att alla program skulle anpassas nej det är inte troligt, all "infrastruktur" finns däremot på plats till skillnad för hur det gick till när OS X bytte gradvis till att stödja 64-bitar program. Du får däremot fördelarna av den nya SoCn, dess arkitektur och nya grafikdel samt OpenGL ES 3.0 (för de som vill dra nytta av det) vilket som. Så jag ser inte hysterin. Det blir säkert krav på att de byggs som universial binary så småning om. Om ett par år är det även 64-bit i deras lägsta produkter. Tycker inte man ska vänta sig någon stagnation från utvecklarna vilket som.

När utvecklare går över är helt individuellt, det finns ingen som kan svara på det alls. Däremot finns alla förutsättningar så när det passar så händer det. Men varför du är orolig vet jag inte riktigt, det kommer i de flesta fall inte gå att se någon skillnad ens med prestandamätningar. Gråter du över att Microsoft Office (med fördel) kör i 32-bitar?

@beh ja det är simulator. Är lite van med andra system. Poängen är att mycket som driver dessa program också rullar på andra plattformar och rullar kompilerade för x86-64 på dessa också. De kör inte bara kod som skrivits för telefoner och ren C/C++/ObjC som bygger fint för x86-64 utan asm med samma verktyg lär rulla fint på AArch64, det är samma bibliotek som 32-bitarsvarianten så de behöver inte skriva mot helt andra APIer utan arbetet byggs på ju på båda vilket uppmuntrar att tiden läggs ner. På andra plattformar blev det nytt 64-bit ställt mot gammalt 32-bit bibliotek som blir "legacy" väldigt ofta. Det som är nytt i iOS 7 som inte är bundet till hårdvara finns i både 32 och 64-bitars versioner och utvecklarna kommer idag från många olika miljöer så en sån här övergång går nog mycket smidigare än tidigare och de har oftast redan gjort en liknande övergång på server eller skrivbordet, och ser ingen nackdel att haka på det nyaste och renaste även om de måste skriva om eller lägga till en del kod. Deras byggmål är ju iOS 7 oavsett ISA. Fördelen är att hela plattformen flyttar framåt inte vilken arkitektur det handlar om.

Det finns t ex ingen anledning att vara hysterisk över att Android rullar på både ARM och Intel idag. Så länge energi läggs på de viktigaste komponenterna och verktygen stödjer det bra så fungerar det i allmänhet mycket bra. Både Android och iOS har förut dragits med olika ARM-isa också. Tycker det görs lite stor sak av det hela. Det får in förnyelse, sen kanske inte allt får genomslag i 32-bitarsprogrammen eller hos ISAn för 32-bit, men de programmen som inte är redo kanske inte heller behöver det. Det kommer ändå in andra förbättringar genom ny hårdvara, arkitektur. Alternativet hade ju lite varit att trimma den gamla, vilket till stor del hade handlat om strömförbrukning och klockfrekvenser. Tittar vi på Qualcomm så har deras (kunders) telefoner och plattor helt andra termiska gränser, helt andra förutsättningar när det gäller batteri osv. Var glad att du inte får iOS 6.2 och överhettad telefon. Det går inte att tala om någon nackdel här.