Apple lanserar Iphone 5S och 5C

Bortser du från hårdvaruaccelererad AES borde du väl rimligtvis även avstå från hårdvaruaccelererad SHA1? Gör man det får man ett betydligt lägre genomsnitt på ungefär 7%. Slutsatsen blir väl snarare att 64-bit är en mindre uppgradering och inte alls den rejäla uppgradering på 27% som du hävdar. För heltal alltså, flyttalsberäkningarna drar ju nytta av utökade register samt DP SIMD (vet inte vad det innebär och orkar inte kolla upp det) så där är ju uppgraderingen större. De största skillnaderna verkar ju inte ha något med 32 vs 64 bit att göra utan snarare att AArch64 har en del uppdaterade instruktioner som gör det bättre än AArch32.

Det som oroar mig mest är Dijkstra, som har ett resultat på -25%. Anandtech säger att de tror att detta beror på att den är pekartung och om man vet vad Dijkstras algoritm är håller man nog med om att det verkar som ett rimligt antagande. Problemet här är ju bara att pekare även är rätt vanligt förekommande i alla vettiga program. Förmodligen är de flesta program inte riktigt lika pekartunga som ett program som kör Dijkstras algoritm, men kanske ändå tillräckligt för att drabbas av denna prestandaförlust. Svårt att säga utan tester på riktiga program.

Håller med helt! Fingeravtrycksläsaren kändes ju onekligen som att det var en enorm gimmick-varning på men Apple verkar ha lyckats. Jag har svårt att säga något definitivt innan jag hört fler utlåtanden från folk jag litar på, men det verkar onekligen lovande. Bra jobbat Apple (samt de som utvecklade själva sensorn förstås)!

Det är självklart att jag skulle plockat bort SHA 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%. Om det är förbättringar med AArch64-arkitekturen och A64 instruktionsuppsättningen så anser jag att dessa kan tillskrivas övergången till just 64-bitars arkitektur jämfört med 32-bitars arkitekturen. Ja, förbättringen för 64-bit int var sämre än jag först trodde, men den samt förbättringarna för flyttal måste fortfarande kunna tillskrivas övergången till 64-bit då denna innebär de nya instruktionerna och nya arkitekturen.

Det är klart att pekare har en högre kostnad när de är dubbelt så stora, det påtalade även Petterk för några poster sedan. Dock tycker jag det är mycket intressant att Dijkstras algoritm exponerar denna svaghet, och det skulle vara spännande att se en jämförelse mellan 32bit A6 och 32 bit A7. A7 kompenserar till viss del med ökad L1 cache (dock med 1/3 högre latens) och en L2 med 1/2 latens mot A6. Vid 32 bitar får man alla de extra resurser som A7 har till rådighet för att motverka de försluter som 64-bitars kod innebär.

Beror lite på vad man jämför med, jämför du x86 och x86-64 ser du inte samma typ av skillnader som om du jämför AArch64 med AArch32 trots att du jämför 64-bit vs 32-bit. Menmen, klart är väl i alla fall att för ARM-processorer, vilket i princip alla telefoner är så är 64 bit en prestandamässig förbättring, om man bortser från det där med pekare då...

Även jag har tidigare påtalat att det är en nackdel att pekarna är större men tänkte då mest på att de tar mer minne och inte att prestandan minskar (även om även det är rätt självklart). Om den här prestandaförlusten lyser genom på vanliga applikationer (som som sagt var använder sig av pekare i rätt hög grad) blir det helt plötsligt inte längre en fördel med 64-bit. Jag tror dock rent spontant att det inte kommer ge någon enorm förlust, men det har jag inte något direkt belägg för så kan inte argumentera för det (eller motsatsen). I värsta fall kanske A7 presterar lika bra på 64-bit som på 32-bit i en genomsnittlig applikation, vilket ju ändå gör att det får anses vara värt det, åtminstone för framtiden när minnena blir större och fördelarna med 64-bit mer uppenbara.

En jämförelse mellan 32-bit A6 och 32-bit A7 i Dijkstras algoritm skulle med stor sannolikhet falla väl ut till förmån för A7. I så fall är ju jämförelsen 32-bit A6 vs 64-bit A7 mer intressant eftersom det är då A7 presterar som sämst. Jag tror dock A7 skulle vinna även den duellen, men nu är det återigen bara jag som spekulerar och har inget som kan stödja mitt påstående.

Ja, jag utgick från att det var ARM 32 eller ARM 64 de hade att välja mellan, men det är sant i denna prestandaklassen så blir plötsligt x86-64 ett alternativ genom Bay Trail.

Fast att de tar mer minne slår ju först och främst på L1 och delvis L2 cacharna eftersom det inte ger någon mening att fylla internminnet på 1 GB med pekare, det är först och främst där som prestandaförlusten inträder.

Ja antagligen skulle A7-64 vinna över A6-32 i en sådan test, men man kan ju fortfarande kompilera för 32 bitar om det är intressant.

Endera du eller jag har nog missuppfattat hur en cache funkar. Som jag förstått det innehåller en cache kopior av saker som finns i minnet. Anledningen till att det även lagras i cachen är att det är något som processorn tror att programmet ofta vill komma åt och att det går snabbare att läsa från en cache än att läsa från minnet. Detta stöds även av Wikipedia-artikeln som säger:

"The cache is a smaller, faster memory which stores copies of the data from frequently used main memory locations."

Att något lagras i en cache betyder alltså inte att det inte tar upp plats i minnet. Jag kan ha misstolkat något, processorer är rätt avancerade, men med tanke på att det är denna bild jag fått av de kurser jag läst på området och det även stöds av Wikipedia-artikeln känner jag mig rätt säker på att jag har rätt.

Det är helt korrekt, jag menade aldrig att något blir borta från RAM utan det hämtas från cache istället, vilket sparar mycket tid. Russinet i kakan är att eftersom RAM är så ofantligt stort att man aldrig skulle fylla det med endast pekare så är det först och främst antal pekare som cacharna kan hålla som påverkas. Sagt på ett annat sätt: 1 GB RAM är så ofantligt stort att med tanke på storleken av en 64bit pekare på 8 byte (100 MiB = 1.311×10^7 pekare) är det inte det totala antalet pekare man får plats med i RAM som begränsar oss, utan antalet pekare som får plats i L1 på 64 KiB = 8192 stk (samma som för 32 KiB L1 på A6).

Därmed spelar det lite roll att man inte dubblerat RAM utan "bara" L1. Iofs. så har nog den ökade latensen en del inverkan, men det är så det är. You can't win them all.

Jag hävdade aldrig att enbart pekare skulle fylla minnet, jag bara påpekade att det tar mer minne. Då tänkte jag dock inte på att det skulle kunna leda till att cachen fylls vilket även gör programmet långsammare, vilket får anses vara ännu värre än att programmen skulle kräva mer minne. Övergången till 64-bit innebär dock att alla appar (oavsett om de är kompilerade för 32 eller 64 bitar) får mindre minne att göra saker med, eftersom operativsystemet körs i 64 bitar och därmed tar mer minne. Det finns ju liksom en anledning till att systemkraven på minne för Win8 64-bit är högre än för Win8 32-bit (att det råkar vara just dubbla mängden beror nog mest på att det är vanligare med 2 GB RAM än typ 1,5 eller vad som nu egentligen kan krävas).

Vore intressant att se en jämförelse mellan iOS7 på iPhone 5/5C (som ju kör 32-bit) och iPhone 5S (som kör 64-bit) för att se hur stor skillnaden i minnesanvändning faktiskt är. Att iOS7 64-bit tar mer minne är ju tämligen uppenbart, men hur mycket vore intressant att se.

För övrigt är det inte bara pekare som blir dubbelt så stora i och med övergången till 64 bitar, precis som i C/C++ blir även en int (heltal) dubbelt så stor om man kompilerar för 64 bitar, till skillnad mot till exempel Java och C# där en int alltid är 32 bitar, oavsett vilken arkitektur man kompilerar för (förmodligen delvis för att båda dessa språk körs i en virtuell maskin).

EDIT: Om man var nära att slå i taket på minnesanvändning med 32 bitar är det alltså högst sannolikt att man faktiskt gör det med 64 bitar. Att dubblera minnet är förmodligen inte nödvändigt dock.

Ett vanligt sätt att utvärdera ett problem är att ta hänsyn till ytterligheterna. Detta resonemang ledde mig in på spåret om att det är först och främst vid mellanlagringen som man får problem med den ökade pekarstorleken. Det var inte min mening att lägga ord i din mun, utan det var ett sätt att belysa en ytterlighet.

En annan fråga som vi inte har diskuterat är att man genom att stödja både 32 och 64-bitars appar på samma enhet måste ha dubbelt så många stödbibliotek, där olika bibliotek behöver att laddas för appar kompilerade för 32 och 64 bitar. Detta var en av orsakerna till att Win64 sattes att använda mer minne än Win32, då många olika standardbibliotek behövde vara laddade för båda arkitekturerena (vi minns WoW64 och WOWEXEC som det var en del snack om på den tiden respektive övergång begav sig). Hur detta artar sig på iOS 7 64 blir spännande att se.

Ja, att de extra biblioteken som måste laddas för bakåtkompatibilitet kommer att ta mer RAM i anspråk än vad de nya större pekarna tar är i alla fall säkert.

Vad jag vet så använder Apple sig av LP64 minnes-modellen och den definierar explicit en int som 32 bitar, men man kan säkert köra IL64 med, där int, long, longlong och pointer alla är 64 bitar.

Nej, men eftersom man på iOS inte har så stora möjligheter att ta upp minne när ens app ligger i bakgrunden och iOS lämnar relativt mycket minne till applikationen så tror jag inte att det kommer att märkas nämnvärt. Vad som kan bli sämre är bytet mellan appar, när det börjar bli lite minne så skickar iOS ut kommandon till appar som ligger i bakgrunden om att de ska spara ned viktiga filer och släppa minne annars så stängs de ned. Detta artar sig för användare som att det blir lite segare att byta mellan appar, då de måste skapa sina datastrukturer i minnet på nytt. Inga appar får swappa allt minne till flash, som går på ett skrivbords-OS. Så man försöker eliminera ett problem men skapar ett annat.

Oklart vad som gäller i iOS, men eftersom de använder LP64 i Mac OS är det väl rimligt att anta att det gäller även för iOS. Det hade jag ingen aning om och kom därför med felaktig information. Däremot är ju long och size_t större (64 bit vs 32 bit), men dels var det inte det jag sa och framför allt har det mindre betydelse eftersom long inte används lika flitigt som int. size_t (känns rätt mycket som en C/C++-grej och inte Objective-C men jag vet inte) är väl något mer använt menmen...

Jag hade i alla fall (förmodligen) fel, du har (förmodligen) rätt.