Apple: Beginning February 2015, App Store submissions need to be 64-bit

[DigitalHermit]

Without it you can only ever have 4 GB of RAM and I believe 80GB of Hard Drive, and that's with Intel's proprietary memory extensions in 32-bit mode.

My 32-bit system with 320GB of storage would like to have a word with you...

 

WRONG! http://www.zdnet.com/blog/hardware/clearing-up-the-3264-bit-memory-limit-confusion/3124

 

Consult any computer science professor you trust. Memory limits are instruction-length dependent.

True that you will be limited to around 4GB in RAM but storage is a different story...

 

storage isn't dependant on 32/64bit size

^THIS^

[Snickerzz]

WRONG! http://www.zdnet.com/blog/hardware/clearing-up-the-3264-bit-memory-limit-confusion/3124

 

Consult any computer science professor you trust. Memory limits are instruction-length dependent.

i said storage (hdd space) not ram

you said 32bit limits the hdd to 80gb, which it doesnt

[patrickjp93]

My 32-bit system with 320GB of storage would like to have a word with you...

 

True that you will be limited to around 4GB in RAM but storage is a different story...

 

^THIS^

How much of it is usable? There's a virtual memory address range limit on 32-bit which we surpassed a long time ago. What it is exactly I don't remember, but there is a limit.

 

Edit: it has partly to do with architecture, OS, and motherboard chipset, as well as the chosen format. Windows XP 32-bit is limited to about 2TB. 64-bit can recognize I believe it's 980,000,000 yotabytes.

[DigitalHermit]

How much of it is usable? There's a virtual memory address range limit on 32-bit which we surpassed a long time ago. What it is exactly I don't remember, but there is a limit.

 

Edit: it has partly to do with architecture, OS, and motherboard chipset, as well as the chosen format. Windows XP 32-bit is limited to about 2TB. 64-bit can recognize I believe it's 980,000,000 yotabytes.

 

All of it is usable (not counting the count difference between software and storage manufacturer)...

[TroubleKlef]

Happy to see this. 

 

Even if phones don't take full advantage of the 64bit architecture now, having the bedrock set in place by Apple and other manufacturers will only increase the adoption and integration of it.

[ItsComrade]

Will someone explain why we need 64 bit apps?

[zanduh]

Will someone explain why we need 64 bit apps?

 

Uniformity is highly under appreciated 

[ItsComrade]

Uniformity is highly under appreciated 

 

Yeah, but why  do we need this? It will just make developing for it harder.

[Toddwjp]

Yeah, but why  do we need this? It will just make developing for it harder.

 

devolving for 64 bit would be just as easy as 32 i mean they already do it for pc

[ItsComrade]

devolving for 64 bit would be just as easy as 32 i mean they already do it for pc

 

But why impose these restrictions if it won't yield many benefits? It should be optional, certainly.

[Toddwjp]

But why impose these restrictions if it won't yield many benefits? It should be optional, certainly.

 

because 32 bit is useful but really needs to go away

[Techhog]

The point is that by the time apps DO need 64-Bit, the userbase is ready for it rather than announce 64 bit SoC's at the same time as 64 bit apps.

Right, but then a ton of people will be stuck with phones that can't use new apps. You can't make a requirement like this before it goes mainstream, which is why even Apple held off a generation. You can count the number of flagship 64-bit Android devices released this year with your fingers.

[LAwLz]

Anyone know if the K1 on the Nexus 9 is 64-bit?  Not too knowledgeable about Tegras

The model that is in the Nexus 9 is 64-bit compatible, but the one in the Shield tablet is not. Only the dual core version of the K1 is 64-bit.

 

I still think that going 64bit on mobile is pointless...

Higher performance (even today, and a significant improvement) and future proofing.

 

Without it you can only ever have 4 GB of RAM and I believe 80GB of Hard Drive, and that's with Intel's proprietary memory extensions in 32-bit mode.

If you by "Intel's proprietary memory extension" mean PAE (made by Intel but it's not proprietary) then no, you can address far more than 4GB with that. Pretty sure certain versions of Windows, OS X and Linux can address up to 64GB of RAM with PAE enabled on an 32bit OS.

[patrickjp93]

The model that is in the Nexus 9 is 64-bit compatible, but the one in the Shield tablet is not. Only the dual core version of the K1 is 64-bit.

 

Higher performance (even today, and a significant improvement) and future proofing.

 

If you by "Intel's proprietary memory extension" mean PAE (made by Intel but it's not proprietary) then no, you can address far more than 4GB with that. Pretty sure certain versions of Windows, OS X and Linux can address up to 64GB of RAM with PAE enabled on an 32bit OS.

They can at a massive performance hit. Think of it as block bits/flags in a special register. You have 16 4GB blocks (64GB), and each block switch requires 15 clock cycles (at least on Westmere). In a wide application which requires bank switching and spans more than 1 block, you're going to feel like a slug.

[LAwLz]

They can at a massive performance hit. Think of it as block bits/flags in a special register. You have 16 4GB blocks (64GB), and each block switch requires 15 clock cycles (at least on Westmere). In a wide application which requires bank switching and spans more than 1 block, you're going to feel like a slug.

I'll just cite RedHat and their tests of PAE (page 10).

 

The performance impact is highly workload dependent, but on a fairly typical kernel compile, the PAE penalty works out to be around a 1% performance hit on RedHat’s test boxes. Testing with various other workload mixes has given performance hits ranging from 0% to 10%.

 

Yeah, that 1% performance decrease and potential massive performance increase (from more RAM) sounds really scary...

And if you want more benchmarks than those from RedHat, Phoronix got you covered. It's pretty much within margin of error.

 

 

I can't remember which ones, but a few of the newer 32bit Snapdragon chips also supports PAE. I doubt Qualcomm would even bother implementing it if there was a big performance penalty.

[Samfisher]

Right, but then a ton of people will be stuck with phones that can't use new apps. You can't make a requirement like this before it goes mainstream, which is why even Apple held off a generation. You can count the number of flagship 64-bit Android devices released this year with your fingers.

 

Exactly why I posted that Google should have done something like this as well, push for 64-Bit a generation ago, giving 64-bit compatible devices time to spread to developers and consumers alike.

[patrickjp93]

I'll just cite RedHat and their tests of PAE (page 10).

Yeah, that 1% performance decrease and potential massive performance increase (from more RAM) sounds really scary...

And if you want more benchmarks than those from RedHat, Phoronix got you covered. It's pretty much within margin of error.

I can't remember which ones, but a few of the newer 32bit Snapdragon chips also supports PAE. I doubt Qualcomm would even bother implementing it if there was a big performance penalty.

Those tests are far from comprehensive. Look at a memory intensive workload instead of the lightweight stuff red hat did.

[Techhog]

Exactly why I posted that Google should have done something like this as well, push for 64-Bit a generation ago, giving 64-bit compatible devices time to spread to developers and consumers alike.

And how, exactly, were they supposed to do that?

[Samfisher]

And how, exactly, were they supposed to do that?

 

By doing what Apple did, release 64-bit compatible SoC's?  Google is big enough to pressure ARM/Qualcomm/Nvidia to push for 64-bit SoC's and release them on the NExus 5/Nexus 7 (2013), just like how Apple released their A7 a generation ago.

[dalekphalm]

Uhm.... What? What are you posting about? You realize that in the context if this thread, it has literally nothing to do with what you posted? That's the strength of the encryption cipher used by IE.

 

This thread is about 64-bit ARM CPU's, and apps that are (or will be) compiled as 64-bit applications. It might be 50 years before we see a 256-bit consumer CPU, let alone OS's and Apps compiled for it.

 

Without it you can only ever have 4 GB of RAM and I believe 80GB of Hard Drive, and that's with Intel's proprietary memory extensions in 32-bit mode.

You're partially correct here. 32-bit is limited to 4GB of RAM (Of course, that's total System Usage, including a bunch of stuff the user won't see, so it's closer to 3.5GB usable). However, 32-bit is NOT limited to 80GB.

 

We still have a bunch of legacy Windows XP machines (which, by virtue, are all 32-bit), and not one has a drive as small as 80GB. Most are using 160GB or 320GB drives... sooo yeah. No idea where you got the idea that 80GB was the max size... Spoiler alert: It's not.

 

storage isn't dependant on 32/64bit size

Exactly. There are limitations in each OS for storage size, but it's much higher than 80GB.

 

WRONG! http://www.zdnet.com/blog/hardware/clearing-up-the-3264-bit-memory-limit-confusion/3124

 

Consult any computer science professor you trust. Memory limits are instruction-length dependent.

Did you even read that link you posted? It doesn't mention storage (As in, HDD's, etc) once at all... It only talks about memory limitations, and the 4GB limit (As well as explaining the in-depth technical reasons why the usable RAM is less than 4GB - but that wasn't in dispute)

 

My 32-bit system with 320GB of storage would like to have a word with you...

 

True that you will be limited to around 4GB in RAM but storage is a different story...

 

^THIS^

Indeed. We still have about... 50 to 55 Windows XP machines at work... all with 160GB or 320GB HDD's

 

The model that is in the Nexus 9 is 64-bit compatible, but the one in the Shield tablet is not. Only the dual core version of the K1 is 64-bit.

 

Higher performance (even today, and a significant improvement) and future proofing.

 

If you by "Intel's proprietary memory extension" mean PAE (made by Intel but it's not proprietary) then no, you can address far more than 4GB with that. Pretty sure certain versions of Windows, OS X and Linux can address up to 64GB of RAM with PAE enabled on an 32bit OS.

Indeed! Windows Server 2003 supported 64GB of RAM on both Data Center and Enterprise 32-bit Editions due to PAE (which stands for Physical Address Extension conveniently)

http://en.wikipedia.org/wiki/Windows_Server_2003#Editions

 

The 64-bit versions of those editions supported up to 1TB or 2TB of RAM (depending on AMD64/EMT64 vs Itanium).

 

PAE has been around for years, and was used in Server editions of Windows OS for a long time. While there may be a performance hit by using PAE, it obviously wasn't a big enough hit, since Microsoft used it in two of their biggest and most popular server OS's of all time (Server 2003 Enterprise edition was massively popular, and I imagine still in use by a decent number of companies even today).

[dalekphalm]

By doing what Apple did, release 64-bit compatible SoC's?  Google is big enough to pressure ARM/Qualcomm/Nvidia to push for 64-bit SoC's and release them on the NExus 5/Nexus 7 (2013), just like how Apple released their A7 a generation ago.

The problem is that Nexus devices make up a very very small percentage of Android OS's. ARM already has 64-bit SoC's, and flagship devices will start to ship with them. I imagine that most flagship Android devices released in 2015 will have a 64-bit SoC.

 

However, Flagship devices are a pretty small section of the market. So to make it a requirement that all new apps are compiled for 64-bit, means that either:

1. You'll need to provide 32-bit backwards compatibility or emulation (Much like Windows does - I assume that 64-bit Android does this? I cannot confirm though) OR

2. You'll have 90% of your customer base unable to use new Apps.

 

Hopefully, # 1 is already true though.

 

I do think that pushing 64-bit is the way to go, but the problem with Android is because the device market is so fragmented, there's very little incentive for app devs to do this.

[Samfisher]

The problem is that Nexus devices make up a very very small percentage of Android OS's. ARM already has 64-bit SoC's, and flagship devices will start to ship with them. I imagine that most flagship Android devices released in 2015 will have a 64-bit SoC.

 

However, Flagship devices are a pretty small section of the market. So to make it a requirement that all new apps are compiled for 64-bit, means that either:

1. You'll need to provide 32-bit backwards compatibility or emulation (Much like Windows does - I assume that 64-bit Android does this? I cannot confirm though) OR

2. You'll have 90% of your customer base unable to use new Apps.

 

Hopefully, # 1 is already true though.

 

I do think that pushing 64-bit is the way to go, but the problem with Android is because the device market is so fragmented, there's very little incentive for app devs to do this.

 

Like many Nexus devices, the SoC's in Nexus devices tend to be what is used for the whole of the next gen.

[ItsComrade]

because 32 bit is useful but really needs to go away

 

Then shouldn't they let the developers freely incorporate that if the platform warrants it? not restrict them?

[Toddwjp]

Then shouldn't they let the developers freely incorporate that if the platform warrants it? not restrict them?

 

the issue is that phones will stay 32 bit as long as apps are made 32 bit and vice versa, you need a company to release new standards to push the market forward, eg like vesa saying this is now display port 1.3 etc.

 

everything in 64 bit would have the advantage of you just being able to take code from one device (this is an over simplification)  and run it on another. eg pc to phone, tablet to pc etc which is what we want as having everything work on all your devices is nice

[ItsComrade]

the issue is that phones will stay 32 bit as long as apps are made 32 bit and vice versa, you need a company to release new standards to push the market forward, eg like vesa saying this is now display port 1.3 etc.

 

everything in 64 bit would have the advantage of you just being able to take code from one device (this is an over simplification)  and run it on another. eg pc to phone, tablet to pc etc which is what we want as having everything work on all your devices is nice

 

I guess. I wish there was some kind of way to push it a little slower, incentivise it more.