Qualcomm Employee: Apple's 64-Bit A7 Chip 'Hit Us In The Gut'


Recommended Posts

Source: http://www.macrumors.com/2013/12/16/qualcomm-employee-64-bit-a7-chip-hit-us-in-the-gut/

 


"The 64-bit Apple chip hit us in the gut," says the Qualcomm employee. "Not just us, but everyone, really. We were slack-jawed, and stunned, and unprepared. It?s not that big a performance difference right now, since most current software won?t benefit. But in Spinal Tap terms it?s like, 32 more, and now everyone wants it."

[...]

"The roadmap for 64-bit was nowhere close to Apple?s, since no one thought it was that essential," the Qualcomm insider says. "The evolution was going to be steady. Sure, it?s neat, it?s the future, but it?s not really essential for conditions now."

But once Apple introduced a 64-bit processor, all the other phone-makers wanted one too. "Apple kicked everybody in the balls with this. It?s being downplayed, but it set off panic in the industry."

Basic psychology of want, not because I need, but because I want. Eg. I want what he has, just cause I don't have it.

 

Its like most analyst said: 64-bit makes little-to-no-difference but you can bet money that all the flag ship Android phones next year are going to be sporting it in response to Apple.

Its like most analyst said: 64-bit makes little-to-no-difference but you can bet money that all the flag ship Android phones next year are going to be sporting it in response to Apple.

 

This. If anyone argues so much about who does it first who does it right on here when it comes to Apple vs Android, it's me. Just like every release of an iDevice, how many Android devices have you seen try to follow a feature right after? HTC Fingerprint for example. Apple may not have done the fingerprint first, but they did it right which made others attempt to follow.

  • Like 1

Its like most analyst said: 64-bit makes little-to-no-difference but you can bet money that all the flag ship Android phones next year are going to be sporting it in response to Apple.

Pretty much.

 

Sad that when everyone else points out how useless at the moment 64 bit makes in smartphone OSes, they get bashed.

I can see that. Apple touted 64-bit goodness as a major selling point, and relevant or not, if other smartphones don't have 64-bit processors, they'll all be have-nots.

  • Like 2

It is the same old thing again. This situation is like, when you have two balls which look exactly the same and you will need the heavier in the future. Your friend drops the balls from a skyscraper and you are waiting for them on the ground. At this moment, as technology goes, the balls are still falling and there is no difference between them, but when they hit the ground and the software will begin to harness the benefits of 64 bit technology, you will need the heavy stuff.

 

Apple, yet again, tried to flash its E-penis and painted the ball red. Now everyone wants a falling red ball even if it does not matter. How easily distractable customers are. 64 bit is twice as much as 32, it must be soooooooooooo much better!

  • Like 1

It's hard to quantify just how much this will matter in a year or two. When AMD introduced 64-bit desktop CPUs it wasn't "needed" either but it jump started the industry and competition and soon after it was a necessity. 

  • Like 1

Basic psychology of want, not because I need, but because I want. Eg. I want what he has, just cause I don't have it.

Some of that is at play yes, but technology is also a chicken or egg industry...

 

What should come first? Software that needs 64bit or chips that support 64bit? See the conundrum?

 

Usually software waits for the hardware to exist before they start exploiting it. So the sooner we get 64bit hardware the sooner we'll get applications that take advantage of it. We can't accurately say if the advances will be useful or not yet because we don't yet have them...

Its like most analyst said: 64-bit makes little-to-no-difference but you can bet money that all the flag ship Android phones next year are going to be sporting it in response to Apple.

 

Samsung already announced 64bit.  But this is normal no matter what industry you work in.  Someone produces something, others find value and add it to their products.

Its like most analyst said: 64-bit makes little-to-no-difference but you can bet money that all the flag ship Android phones next year are going to be sporting it in response to Apple.

and then Windows Phone will be reviewed poorly for using "only" 32bit processors. :laugh:

This. If anyone argues so much about who does it first who does it right on here when it comes to Apple vs Android, it's me. Just like every release of an iDevice, how many Android devices have you seen try to follow a feature right after? HTC Fingerprint for example. Apple may not have done the fingerprint first, but they did it right which made others attempt to follow.

My Motorola Atrix finger print worked fine.  2 years before the iPhone 5.

  • Like 3

My Motorola Atrix finger print worked fine.  2 years before the iPhone 5.

 

I don't think his point was that Apple came out with a fingerprint reader on their phone first.  His point was that your Motorola Atrix introducing the feature didn't mean squat to other Android manufacturers.  Once Apple released the iPhone 5S with a fingerprint reader there was a sharp 'me too' response almost immediately from the Android OEMs.

  • Like 2

Even quad cores are overkill.  64 bit is getting ready for when phones need more then 4 gigabytes in memory. 

You do realize that 64-bit has more advantages than just memory capacity, right?...

  • Like 1

I'm not an Apple fan at all. I hate their "Walled Garden" and one size fits all designs but I have to hand it to them. I'd love an A7 SoC in a phone I actually liked.

As for those saying 64bit doesn't make a difference it's true there isn't much, if any improvement (in some cases things may even slow down) simply by going 32bit to 64bit. The ARMv8 architecture isn't just an ARMv7 with 64bit tacked on though and it DOES have substantial speed improvements even when running just 32bit software. ARM really took this opportunity to clean up and fine tune their design and it paid off.

Apple really is ahead of the game in SoC design and 64bit OS support (their entire OS and all it's built-in apps have 64bit versions already) so that's a big win for them. They need it though because iOS apps are native code and everything needs to be recompiled to support 64bit. That's going to be a HUGE and long transition for them. In contrast since Android and Windows Phone compile to byte-code unless developers wrote parts in native code (NDK on Android, not sure if Windows Phone has an equivalent) they have to do nothing. The 64bit JIT engine provided by the OS will automatically compile their byte-code application 64bit. This means the migration to 64bit will take much less time on Android/Windows Phone so it's good Apple has a head start to stay competitive (competition is good for us consumers)

I'm not an Apple fan at all. I hate their "Walled Garden" and one size fits all designs but I have to hand it to them. I'd love an A7 SoC in a phone I actually liked.

As for those saying 64bit doesn't make a difference it's true there isn't much, if any improvement (in some cases things may even slow down) simply by going 32bit to 64bit. The ARMv8 architecture isn't just an ARMv7 with 64bit tacked on though and it DOES have substantial speed improvements even when running just 32bit software. ARM really took this opportunity to clean up and fine tune their design and it paid off.

Apple really is ahead of the game in SoC design and 64bit OS support (their entire OS and all it's built-in apps have 64bit versions already) so that's a big win for them. They need it though because iOS apps are native code and everything needs to be recompiled to support 64bit. That's going to be a HUGE and long transition for them. In contrast since Android and Windows Phone compile to byte-code unless developers wrote parts in native code (NDK on Android, not sure if Windows Phone has an equivalent) they have to do nothing. The 64bit JIT engine provided by the OS will automatically compile their byte-code application 64bit. This means the migration to 64bit will take much less time on Android/Windows Phone so it's good Apple has a head start to stay competitive (competition is good for us consumers)

 

I used to think Android apps were less native due to the fragmentations and whatnot. It may be quicker, but it'll still be hard to get it to roll out on all the devices out there like Apple can.

I used to think Android apps were less native due to the fragmentations and whatnot. It may be quicker, but it'll still be hard to get it to roll out on all the devices out there like Apple can.

Android apps are "less native" so the same app can run on multiple different architectures. This is why you can have an app that runs on an ARM based phone as well as an Intel based one (completely different architecture). More new ones are even on the way with Imagination Technologies (people who make the PowerVR GPUs used by Apple and others) having bought MIPS expect to see devices running MIPS/PowerVR SoCs in a 2014/2015. Google does it this way because they don't make their own hardware and they want to be able to use whatever is best at any given moment and not be stuck to one architecture. It works in their favor for the 32 to 64 bit transition as well. The hard work is done in the JIT compiler provided by the OS instead of every app having to be recompiled. That work is typically done by the hardware manufacturers, for example Intel has been checking in a lot of code to the Android codebase to get 64bit working on their processors. Once that is complete any OEM making an android phone with an Intel SoC will use the Intel provided JIT compiler and app developers will have to do nothing. The exception being if the app uses the NDK (native development kit) in which case it has architecture specific native code and the app developer will need to recompile the NDK parts for every architecture they wish to support (just as Apple app devs will have to).

On a side note Android is also making a AOT (Ahead of Time) compiler called ART (Android Run-Time) to replace the Dalvik JIT engine so that apps compile from byte code to native code on install instead of on run. If you are familiar with .Net this is similar to the NGEN tool that .Net has which apps like Paint.Net use on install.

So you are saying that 64-bit is more useful with 512MB memory as a whole, than 32-bit with 2GB memory?

Uh...where are you drawing that conclusion from?  The point is that the amount of memory doesn't matter.

Yes, you can use more than 3.5GB of memory with 64-bit, but that's only one of many advantages.

A major benefit is security.  

 

Educate yourself on why a 64-bit instruction set is very beneficial.  There's a lot of information out there.

Apple leads the way....once again.

I wouldn't say leading, as it would if ATM it were a meaningful advantage, like pointed above, 64 IS the future, but in 2-3 years. Heck we've barely transitioned into 64 bit on desktops.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • A different thing with Russia. When you say is it better, depends on things. It is better that we don't have the E.U making rules and laws that have nothing to do with them. Is the trading part better? No, that is really mucked up, but then we knew that was going to happen and we would have make agreements, like we do with other parts of the world. Freedom of movement is certainly better, but could be improved, we still need more control over our borders. do you live in the U.K?
    • So what am I quoting from them? I never listened to what Farage or his cronies said. I wanted the U.K to leave the E.u years before the referendum and it had nothing to do with Farage and his cronies. So what country do you live in? Did we work much better together? We were always at logger heads with the E.U because we disagreed with them so much. Maggie was always on at them. I would have thought the E.U was glad to get rid of us as we stopped the integration or made it a two tier. Now without us they can integrate more. I would not have voted out if it was just a trading block and we can still work together on somethings.
    • MPC-BE 1.9.0 by Razvan Serea Media Player Classic - BE is a free and open source audio and video player for Windows. Media Player Classic - BE is based on the original "Media Player Classic" project (Gabest) and "Media Player Classic Home Cinema" project (Casimir666), contains additional features and bug fixes. The BE mod (Black Edition Mod) is a skinned version of Media Player Classic Home Cinema, much better looking than the plain old MPC. MPC-BE 1.9.0 changelog: Splitters Fixed crashes in some situations. AudioSplitter Added support for the RF64 format. Fixed reading of channel layout for some WavPack files. Added support for ID3 tags for Wave64 files. Unknown Wave64 chunks are now ignored. AviSplitter Added support for 'y408' video. Improved support for 'HEVC' video. FLVSplitter Added support for VVC video. MP4Splitter Improved handling of corrupted files. MatroskaSplitter Expanded support for V_UNCOMPRESSED video codecs. Fixed support for frame rotation (ProjectionPoseRoll). Improved support for "V_MS/VFW/FOURCC / HEVC". MpcDvdVideoDecoder Fixed conversion to YUY2. Fixed display of menus for some DVD-Videos. RoQVideoDecoder Output in NV12 and YV12 formats is allowed. Full range is used. MPC Video Decoder RGB32 format will be output as a top-down bitmap by default. Added support for the "IID_MediaSideDataDOVIMetadataV2" interface. Removed support for the deprecated "IID_MediaSideDataDOVIMetadata" interface. Fixed retrieving the name of the video adapter when using NVDEC. Fixed crashes in some situations. MPC Video Converter Added support for AYUV video format. MpcAudioRenderer Improved input format validation. Optimized retrieval of supported formats for exclusive mode. Added the "Keep audio device active when paused" setting. Fixed crashes and freezes in various situations. Subtitles Added the ability to open the properties of an external subtitle renderer in the "Subtitles" settings panel. Fixed external subtitle connections for VSFilter. Fixed a crash when rendering PGS/SUP subtitles when using AVX2. YouTube Improved support for yt-dlp. The built-in YouTube parser is no longer used. Player The HTTP read strategy has been changed. If the playlist contains one entry, more key combinations can be used to control the player (jump through chapters, adjust volume). Improved support for reading ASX playlists. The translation of the MediaInfo report for Chinese, Korean and Japanese has been removed. Added blocking of 32-bit filter "PICVideo Lossless JPEG Decompressor" (pvljpg20.dll), because it crashes. Added blocking of the system filter "AVI Decompressor", which will eliminate the crash of VFW codecs. Fixed a rare crash when using the "/slave" key. Fixed a crash when getting a list of fonts for OSD. Added the ability to load an external audio file using hotkeys. Fixed opening a network path starting with \?\UNC. The "Determine duration when adding" playlist setting now works for YouTube video URLs. The "Online media services" settings panel has been redesigned. Added a "Merge files using FFmpeg" option to the file saving dialog. This option is activated when playing multiple streams obtained using yt-dlp. Added loading of local .dpl playlists ("DAUMPLAYLIST"). Fixed a hang when the user closes the player during the URL opening process. Various interface fixes. Installer Updated MPC Video Renderer 0.10.5. Updated MPC Script Source 0.2.17. Added MPC Image Source 0.3.6. Translations Updated Japanese translation (by tsubasanouta). Updated Chinese (Traditional) and Dutch translation (by beter). Updated Romanian translation (by Andrei Miloiu). Updated Hungarian translation (by mickey). Updated Turkish translation (by cmhrky). Updated German translation (by Klaus1189). Updated Chinese (Simplified) translation (by wushantao). Updated Italian translation (by mapi68). Updated Korean translation (by Hackjjang). Updated Chinese (Traditional) (by udfbe). Updated libraries dav1d 1.5.3-6-g04b69f9; ffmpeg n8.2-dev-1857-g4653e68aab; libpng git-v1.6.55-9-g7d52a8087; Little-CMS git-lcms2.18-26-gf739cda; MediaInfo git-v26.05-38-g702c9b7fd; ZenLib git-v0.4.41-91-g073f297; zlib 1.3.2. Download: MPC-BE 64-bit | Portable MPC-BE 64-bit | ~20.0 MB (Open Source) Download: MPC-BE 32-bit | Portable MPC-BE 32-bit Link: Media Player Classic - BE Home Page Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • Apple reportedly looks to blacklisted Chinese memory chips as RAM prices climb by Karthik Mudaliar Image via Apple Apple is reportedly trying to get a clearance from the Trump administration to buy memory from ChangXin Memory Technologies (CXMT) to get some relief from soaring DRAM prices. As per a report by the Financial Times, Apple approached the Commerce Department more than a month ago and also spoke to other officials and allies in Washington. For starters, CXMT is a company that's already been placed on the Pentagon's list of Chinese military companies. The Chinese company is the country's top DRAM maker. For Apple, the timing is certainly awkward but not surprising. Tim Cook had recently warned that Apple would have to raise prices because AI companies are buying up large amounts of memory for data centers, and just like that, Apple raised MacBook and iPad prices. Micron also recently revealed that customers have committed billions of dollars to secure memory supply years in advance, which shows us how aggressive securing infrastructure has become. This gives suppliers such as Samsung, SK Hynix, and Micron more leverage, while pushing hardware makers to look for alternatives. CXMT is one of those alternatives, but not the simplest one. Apple has spent many years trying to diversify parts of its supply chain away from China, especially for final assembly, while still depending heavily on Chinese manufacturing and suppliers. Even domestic brands from China are moving towards CXMT and YMTC instead of relying on Samsung, Micron, and SK Hynix. For Apple, though, it would invite more scrutiny than local Chinese companies. For now, this is more like a lobbying effort rather than a confirmed supply deal. There's no official statement from either of the parties. What is clearer, though, is the pressure behind such a request. AI demand has certainly made hardware a bottleneck, and companies are trying everything they can to bring things back to normal, even if that means making politically sensitive choices. Source: Financial Times
    • I did test it a month or so back, but ... the results I expect to be on the first page are not there.
  • Recent Achievements

    • Week One Done
      flexorcist earned a badge
      Week One Done
    • One Month Later
      Woland13 earned a badge
      One Month Later
    • Week One Done
      Woland13 earned a badge
      Week One Done
    • One Year In
      bernmeister earned a badge
      One Year In
    • Week One Done
      Scoobystu earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      486
    2. 2
      +Edouard
      220
    3. 3
      PsYcHoKiLLa
      147
    4. 4
      Steven P.
      74
    5. 5
      FloatingFatMan
      70
  • Tell a friend

    Love Neowin? Tell a friend!