Finally someone got it right regarding 64-bit performance increase:

It seems that the bulk of the A7’s performance gains do not come from any advantages inherent to a 64-bit architecture, but rather from the switch from the outdated ARMv7 instruction set to the newly-designed ARMv8. – iFixit iPhone 5s Teardown

64-bit architecture myths

I should start a video serie “fun with flags 64-bit theories”, but for now I will stick with only this short article. Here is the ironic part:

“There’s no shortage of pundits and self-described experts asserting that Apple’s shift to a 64-bit architecture is either a hoax, a pointless marketing ploy that will deliver no real benefit, or an inevitable shift that everyone will eventually follow anyway at some point, and therefore neither newsworthy nor deserving of any credit.” – for Apple Insider, Daniel Eran Dilger

The journalist then went on citing several Apple statements out of the iOS development guidelines. Considering those statements as true because aimed at developers. I guess that should be viewed as scientific proof ;-) You can read the full article though, it is not all bad, and better than many others I have recently read on the subject. But up to now, the most accurate comments on the new 64-bit ARM CPU for Apple’s iPhone 5s is from Anand. One of those statement is:

“When all apps running on the device are compiled for the 64-bit runtime, iOS never loads the 32-bit versions of those libraries, which means that the system uses less memory and launches apps more quickly,” – Apple

This is slightly marketing terms. A 64-bit apps is likely to use more memory than the same 32-bit counter part, most basic data types have had their size increased. But this is true that the 32-bit stack does not need to be loaded. There is an engineering trade-off to make per app: does the gain in memory consumption when switching to 64-bit exceeds the 32-bit stack footprint? But the author does not get that point and conclude that:

“The company also outlines why it will be beneficial for third party apps to release 64-bit versions of their titles for users, even if those apps don’t in themselves score massive gains from the move to 64-bits: the key result will be lower memory use for the end user.” – for Apple Insider, Daniel Eran Dilger

Lower memory use for the end user when 3rd party apps release 64-bit apps? That would be astonishing. If all 3rd party apps were 64-bit then there is no need for 32-bit stack, but I guess this stack represents a fraction of the overall available/used memory. Apple is also recognising this drawback of 64-bit systems as they state later on:

“Because so many fundamental types have increased in size, the 64-bit version of your app uses more memory than the 32-bit version does. (…) Expect to spend more time optimizing the performance of the 64-bit version of your app.” – Apple

But this is something the journalist blatently ignore.

Note: Moving from 32-bit to 64-bit does not mean you need twice the amount of memory. Not all data types have their size doubled, and apps can be refactor to use less demanding data types.

Then the stunt on the 64-bit memory model (either LP64, LLP64 or ILP64) is also a funny one. Really who cares unless you are a developer which has to use binary data or which needs to optimise an app for memory usage? Unix decided long ago to go the LP64 way (although I do not think all Unix flavour did follow it) after evaluation (performing a trade-off) severa criterias including portability, interoperability or performance. And Windows decided to go the LL64 way, which is not bad either. And regarding performance differences between those models, it only affects the memory pressure and depending on the application this can have no impact or some performance hit. And in this regard, Microsoft choices for Windows would limit the memory pressure when directly recompiling a 32-bit apps for 64-bit.

I am not going on to talk about the journalist speculations on Android move to 64-bit with its engineering and business chalenges. I fully agree that moving to 64-bit has its challenges, and then moving the apps ecosystem is another challenge of its own. But I do not think that moving the core of Android, including Dalvik, to 64-bit is as difficult as the author is implying at least from a pure technical stand. But like him, this is my gut feeling and I have nothing to base this statement on! Hence, I won’t talk about it.

Overall, this journalist, Daniel E. Dilger, is doing a better jobs than many other before him regarding the 64-bit transition which Apple is trying to do for its mobile ecosystem. But this article is clearly biaised towards Apple and in order to be so, the journalist has taken many shortcut and wrongly understood statements made for developers (not journalists!).

Note: I love Apple since many years, I have a MacBook and an iPad (and an iPod lying somewhere). But I am pationate about Linux since almost its inception, and thus I do have an old computer and several VMs running it. I also have an Android phone since recently. The only OS which I do not stand but forced to use (only for work) is Windows. So with this context in mind, I guess my opinions above are rather objective.

Continue reading “64-bit architecture myths”

64-bit chips are too much for a smartphone! Really?

After today’s Apple event, the press is on ebullition to report on it. One journalist at Gigaom has written an article on “Apple’s new 64-bit chip is too much for a smartphone, but great for a MacBook“, he explicitly stated the following:

For chip nerds the idea of 64-bit chip inside a smartphone is overkill. The benefits of a 64-bit chip is that is can take advantage of 4 gigabytes of addressable RAM, but most smartphones are barely hitting 2 or 3 GB of RAM today.

First, let’s correct his statement and then I will tell why I think that a smartphone can benefit from 64-bit chip.

Continue reading “64-bit chips are too much for a smartphone! Really?”

Flash Player “Square” is out on preview for Linux

Adobe Flash Player 64bit

Adobe released yesterday a preview of Flash Player “Square”. It includes native 64bit support and IE9 hardware acceleration enhancement. Yes, you’ve got it! Adobe is again supporting a 64bit release of their plug-in and for all 3 platforms: Linux, Mac OS X and Windows.

I have updated my previous article on surfing the web in 64bit with the new details.

To get more information, jump to Adobe Labs.

Note: there is a free (libre) alternative to Adobe Flash product called Gnash, however it is still far from being stable enough on all web sites to be widely use. But anyway, it is a highly interesting project which have made recent huge improvements towards reliability and speed. You should try Gnash first and if it doesn’t work for you, then go for Adobe.

Update: Flash Player “Square” is now Flash Player 11, and there is a second beta released this August 2011.

Surfing the web in 64 bit

Adobe Flash plug-in 64bit
Adobe Flash plug-in 64bit

The major problem faced by 64-bit Linux users is getting Flash Player to work properly on the platform. With the latest version of Ubuntu, it installs the 32-bit release of Adobe Flash Player along with the necessary 32-bit libraries so it can work.

However, using 32-bit Flash is sometimes buggy (when it is working). What about a 64-bit version of Flash Player?

Gnash, the free (libre) alternative is not enough mature to work on all web sites. But Adobe is currently working on a 64-bit version of its player. It is now available in the labs for download. This is still a beta, so using this plug-in could make your browser unstable (also see warning at the end of this post).

Before installing it, you should remove any previous installation of Adobe Flash Player, you can use Synaptic (System -> Administration) for this purpose.

The downloaded file has the extension .tar.gz, it is a compression format like ZIP. You can double-click on it and extract the file (libflashplayer.so) to your home directory, or use the command line: “$ tar zxf flashplayer11_rc1_install_lin_64_090611.tar.gz“. Now, you need to copy the extracted file to a system directory, close all internet browsers before doing so. It is assumed that the extracted file is in your home directory.

$ sudo cp $HOME/libflashplayer.so /usr/lib/mozilla/plugins/

You can now launch Firefox or Chromium on your 64-bit system and watch Flash media content. My own experience is a more stable system! But do not forget, Flash is not a free software.

Updated 2010-06-08: Adobe issued a security warning for all Flash players (all platforms) covering 10.0.45.2 and earlier release. Which most probably means that it includes the 64bit version as well (this is not confirmed). The only safe version (recommended by Adobe itself) at the time of writing is Flash 10.1 RC which is sadly 32bit-only.

Updated 2010-09-16: Adobe released yesterday a new preview of its 64bit capable Flash Player. Links in this article have subsequently been updated.

Updated 2011-08-13: Adobe released a second beta of Flash Player 11 which as 32bit and 64bit implementation. This release includes also an Adobe Flash system preference. Just uncompress the .tar.gz file in a temporary directory and copy the uncompressed usr folder to your root ‘/’ directory.

Updated 2011-10-01: Updated for the first release candidate of Flash Player 11.