Apple bags top Windows feature: Blue Screen Of Death arrives on iPhone 5S Apple's latest iPhone 5s handsets are suffering "Blue Screen of Death" crashes that force folks to reboot their expensive gear. And we're told application software, when launched by the user, crashes twice as often on the new mobile than freshly run code on the iPhone 5c and 5. That's all according to data provided by app- …
"um no, because on x86 (desktops and servers) we needed to break the 4GB barrier."
When I built my first Athlon 64 system in 2003, it was common for desktop computers to have 512MB of RAM. Now your higher end phones have at least 1GB of RAM and often 2GB.
If anything, the transition to 64 bit on phones/tablets is happening relatively late, not early (as many people are claiming).
But let's be honest, people are only saying it's unnecessary "hype" because Apple is doing it first. If Android devices switched to 64-bit first, then all the Apple haters would be out in force, saying that Apple was behind the times and only focused on selling shiny, overpriced products to people who were technically illiterate.
From Real World Technologies more than a year ago, when ARM64 was first announced and long before people started factoring their feelings about Apple into the assessment:
"Like x86, ARMv7 had a fair bit of cruft, and the architects took care to remove many of the byzantine aspects of the instruction set that were difficult to implement. The peculiar interrupt modes and banked registers are mostly gone. Predication and implicit shift operations have been dramatically curtailed. The load/store multiple instructions have also been eliminated, replaced with load/store pair. Collectively, these changes make AArch64 potentially more efficient than ARMv7 and easier to implement in modern process technology." (http://www.realworldtech.com/arm64/)
Apple's marketing division is hyping it based on 64 being a bigger number than 32 but that side of things almost certainly isn't why moving to ARM64 is a performance win.
In any case it's false to say that if something does not need a 64-bit address space then moving from ARMv7 to ARM64 is of no advantage. The feature Apple are shouting about may or may not be pointless; the improvements they aren't mentioning are real.
This post has been deleted by its author
Android should adapt relatively easily — the vast majority of apps run through the Dalvik virtual machine so all it takes is for someone at the centre to port that and those apps will take advantage of whatever ARM64 mode offers without any per-app reengineering.
The NDK apps will run because a backwards compatibility mode is present in current designs. They won't run as well as if they had been recompiled.
Although most Android devices are ARM based, there are a few that use x86 or MIPS processors. It's the Dalvik VM that mostly enables that.
"However, I don't know how easy it will be for Android to adapt due to the fragmentation of the operating system."
Because most Android apps are jit compiled on the device itself, most existing apps will be able to take advantage of a 64 bit architecture with no modification providing the Dalvik vm is optimised for 64 bit (which it almost certainly will be on a 64 bit device).
64-bit just for hype purposes
At the rate these devices are going I was wondering how long it would take. Apple just happened to get there first, but it could be any other phone as well. That Nokia with its massive image sensor could do with some more poke too, but in general we seem to expect a lot from devices that in 30 years converted from car batteries with antennas to more computing power than was used to send a man to the Moon (or simulate that, take your pick).
However, those novelty problems are exactly the reason why I tend to wait about half a year before buying anything new. An extra bonus is that I then don't have to queue either :)
Increased efficiency, increase speed, smaller etc, etc. it's just Apple using the latest chip technology. It's nothing to do with the age old 8-16-33 bit arguments, this is a fixed width RISC. They've slimmed down the architecture, not made it more complex. It's also backward compatible, which is perfect. I like ARM, always have.
Ummm, do you think that it takes 24 hours to boot up after a crash or something?
Go ahead and tell me Android phones never crash, I'll have to tell my friends that their GS3s occasionally crashing when they take photos or send text messages is all in their heads.
I don't have a 5S, but my 5 did have one weird thing since I installed iOS 7. One time the top bar was missing on the home screen, so no listing of signal strength, battery life, etc. In apps when it was there, and on the lock screen it was there, but when I went to the home screen it would be wiped out for some reason. I simply powered it down, powered it back up again and all was well. No computer is foolproof, not even if it has an Apple logo on it or runs Linux.
Apple software crashes the same as any substantial software does (*). It's just years of Apple adverts that claimed otherwise and years of technically challenged purchasers who believed it.
(*) My personal experience is that IOS based software (especially Safari) crashes noticeably more than Windows and Linux based stuff. 15-20 years ago MS based stuff was pretty poor, but Apple have used the time to overtake them.
Why?
There's a good chance a lot of it will be down to the "use" of undefined and implementation-defined behaviour. All programming languages have these (take a look at the extensive list in ISO 9899:1999, the standard for C), and moving from one compiler / machine to another generally makes them bite.
Crittercism is a third-party SDK that people integrate in order to get real-time crash reports and in-the-field profiling. So the information comes from sampling the applications of those developers that have opted to use their SDK.
Apple supplies crash reports too, but only in a very rustic form.
I would imagine that 'they' (Crittercism) are relying on apps that have their crash-monitoring and reporting software installed by participating developers. The devices phone home quite often and – voila! – crash stats are available.
NB, crash logs are a useful source of information to the creators of iOS jailbreaks as they can be used to identify weaknesses in the OS.
There's a lack of diversity in the Apple iEcosystem by default.
Devs get used to the status quo
The status quo changes
Devs can't cope
There you go - a classic example of snags due to lack of diversity. I would be willing to bet that those devs that manage apps on other platforms as well are able to cope better with arch changes.
As you sow ...
Cheers
Jon
Also (regarding x86 transition as an example), on Linux it *didn't* result in random crashes. You could run 32-bit userland, no crashes since everything would work the same (you had >32-bit address space *total*, each app was still limited to less than 4GB.) And no significant problems mixing 32-bit and 64-bit other than some duplicate libraries. It never was that big a deal.
Pure speculation, I wonder if isync is using something like Linux's TUN/TAP or in-kernel VPN to give isync it's own network interface (which tunnels through to Apple to do it's thing)... if so, then instead of just opening a socket to Apple, there'd be some kind of unusual kernel involvement. I'm quite sure it's just some quick fix either way.
@AC. I have NEVER had my S3 lock up where it required battery pulling out, etc. It's also NEVER rebooted on it's own and had it 15ish months. Some apps have 'crashed' occasionally but never taken the phone with it, and still running the stock Orange ROM that came with it (I keep meaning to install Cyanogen or summit, but never get the time to faff with backups, etc...). I can't remember the last time I have manually rebooted the thing, prolly a handful of times since I got it, and I use it daily for calls, texts, games, internet (FB, Email, Web, etc). I'm not saying iPhones are any worse (I don't know!), but I can say that my experience of Android on an S3 has been stella.
My previous HTC Desire did crash and reboot at times, but my experience with the S3 has been stable and reliable. Also have a HP Touchpad I do flash and play with all the time, and that can have problems, but thats what you get with tinkering and playing, though now my CM10.1 I'm running on it is excellent, well done to those devs!
Is not always a good idea, especially with things that have a lot of new code and hardware in them. As stuff gets more complex, there is more to go wrong with them.
I tend to let the early adopters do the pain for me - I'm quite happy to hear the bleats of woe and the promises of fixes that mess something else up.. Wait 6-12 months and then take the plunge based on reading reviews and general market feedback.
"We're dealing with Apple, after all, and our role as consumers is to simply sit back and wait until Cupertino's iOS engineering team releases an update."
As opposed to what, exactly? Whipping up your own OS in VB?
At least you will get an update, and another, and another... until your old 5S is obsoleted with iOS X on the new iPhone 8S in 3-4 years
"The BSOD problem is not new to the iPhone – it has been reported previously on the iPhone 5, 4S, and 4, as well, but our best guess is that those appearances were due to hardware problems."
I know I risk being burnt at the stake by the Appleati for making such a heretical statement, but the hardware problem is the iPhone itself. No surprises here.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
