OWNER EDIT: Content Removed. The Difference Between 32 Bit And 64 Bit in Windows 8
OWNER EDIT: Content Removed.
Digitally signed drivers is a windows 8 feature NOT a 64 bit limitation.
For some reason you have 64 bit driver incompatibility listed as a good thing? Besides, that is also false. Some 32 bit drivers are indeed incompatible with 64 bit windows, but many do still work. From what I understand its something to do with kernel mode vs user mode drivers. In order for a driver to be receive a signature from microsoft it now requires either a dedicated 64 bit driver or at least 64 bit compatibility.
The difference between 64 bit and 32 bit systems goes much deeper than RAM, in fact the RAM difference is almost a side effect of the main difference. A 32 bit computer only has a 32 bit ALU and registers of max size 32 bits etc, it deals with everything as being 32 bits long, 64 bit is of course 64 bit. In binary you can represent a larger number in 64 bits than you can in 32 bits. In 32 bits you can represent a max value (unsigned) or 4294967295, include 0 as an option and there are 4294967296 values available, also how many memory addresses in RAM you can use, with each memory location being 1 byte you end up with 4294967296 bytes, or 4gb.
In 64 bits you can represent 18446744073709551616, which using the above RAM logic comes to ALOT, seriously, its more than a terabyte by the time I got bored of using my calculator. Windows doesnt support a terabyte no, but in theory it could, most motherboards are 64gb limited, or sometimes 32 (laptops often less).
64 bits however does not increase a computers memory efficiency in any way, only lets you use more of it. More RAM does not make your computer any faster if you were not running out before. Lets say you have 3 1 litre bottles and you need to store 2 litres of water, well having those 3 bottles wont be any better than having the 2 bottles you need to store the water present, the same happens in a computer, just with RAM instead of bottles and data instead of water.
That said there is a performance difference between 64 bit and 32 bit computers when doing maths on LARGE values. a 32 bit computer can only do maths on 32 bit numbers, if you need to do greater than 32 bit maths on a 32 bit machine you have to introduce alot of software steps first (most compilers or interpreters actually do this for you, its only if you insist on hand written assembly that you will have to manually add 2 64 bit numbers without the aid of the hardware so much), this is very very slow. A 64 bit computer can add 64 bit numbers natively. Generally when programming a 32 bit number is an int and a 64 bit number is a long, if you set your compiler to 32 bit and compile a program using longs then it will add the code for software addition for you, does mean that running a program compiled for 32 bit computers on 64 bit machines wont have access to the performance gains of said 64 bit machine. To use a long natively you would have to compile the program for 64 bit machines, in which case it will not work on 32 bit machines.
64 bit windows cannot handle more apps than 32 bit necessarily. You can actually hit the windows thread limit within a 32 bit system assuming each thread uses very little RAM. The thread limit is the same on both 32 bit and 64 bit windows. Now if you have a few proper programs and we arent talking a hypothetical situation of running thousands of programs using a few kb of RAM each then yes more RAM would help and if the amount of RAM required is greater than 4gb then of course 64 bit would be king - as would having a multicore computer.
Dedicated graphics cards DO count towards the 4gb RAM limit.
In a nutshell
32 bit program: no faster regardless of 32 bit or 64 bit.
64 bit program: faster than a 32 bit program running on a 64 bit machine (if it uses maths on very big numbers, or decimal points, they need alot of bits too). Will not run on a 32 bit machine.
32 bit drivers: will run on 32 bit machines. Will sometimes run (but not always) on 64 bit machines (same also applies to 64 bit software actually, 32 bit java often runs into issues on 64 bit windows, yet still if you hit the download button on the java website it downloads 32 bit by default, common cause of the OutOfMemory exception in minecraft is 32 bit java on 64 bit windows).
64 bit drivers: will only run on 64 bit machines.
drivers for both systems must be digitally signed for windows to install them, however there is actually a way to install unsigned drivers in windows 8. In order for a driver to receive a signature from microsoft then it must either a) work on both 32 bit and 64 bit machines or b) have 32 bit and 64 bit versions available seperately (older hardware may not have a 64 bit version available)
But yeah, you can't upgrade from 32 bit windows to 64 bit windows using the microsoft update tools. You need to totally uninstall windows, format your hard disk and install 64 bit windows from scratch as if you were installing windows on a new computer you had built yourself.
Someone gave me their old PC once, had 12gb of RAM fitted and 32 bit windows XP..... They didnt realise that they had purchased 12gb (they replaced the sticks that originally came in the PC) for a system that couldnt take 12gb....
The Info was very useful.. and windows 8 has an option to install the unsigned drivers which is in the advanced startup in pc settings.. and simply 64 has a speed double than that of 32 bit. Most of the 32 bit softwares works with 64 bit. But none of the 64 bit software works with 32 bit system.. in a 64 bit system you will have a separate installation for 32 bit softwares (x86) . By default all the 32 bit softwares go in to that folder. The details of the processor can be found in the system information in properties.. surely I'll go for 64 bit system as the processing speed doubles.
Sent from my Celkon A97i
praderj said:
and simply 64 has a speed double than that of 32 bit
Click to expand...
Click to collapse
???
It does not.
Windows 8 supports more than 4 GB on 32 bit mode. It is a system requirement for the processor.
x64 processors are actually faster than 32 bits processors when running native x64 code.
Running 32 bit code on x64 processors does come with a little overhead, as instructions for x64 processors are coded using 64 bits, whereas x32 compiled programs use 32 bits instructions, which, obviously wont be recognized by the x64 CPU. There is fixed by visualizing the whole thing and completing the instruction set with 32 bits depending on the instructions.
It is, technically, ill-advised to run x32 operating systems if you processor is x64 native. The only exception to this rule is when you have less than 4 GB of RAM< because x64 systems consume more RAM than x32 systems.
x32 is pretty much a relic of the past. All CPU's on the planet are x64 CPUs since like 2006.
mcosmin222 said:
Windows 8 supports more than 4 GB on 32 bit mode. It is a system requirement for the processor.
x64 processors are actually faster than 32 bits processors when running native x64 code.
Running 32 bit code on x64 processors does come with a little overhead, as instructions for x64 processors are coded using 64 bits, whereas x32 compiled programs use 32 bits instructions, which, obviously wont be recognized by the x64 CPU. There is fixed by visualizing the whole thing and completing the instruction set with 32 bits depending on the instructions.
It is, technically, ill-advised to run x32 operating systems if you processor is x64 native. The only exception to this rule is when you have less than 4 GB of RAM< because x64 systems consume more RAM than x32 systems.
x32 is pretty much a relic of the past. All CPU's on the planet are x64 CPUs since like 2006.
Click to expand...
Click to collapse
x64 processors are not faster *unless* operating on large numbers. A 32 bit processor can only operate on 32 bit numbers so has additional software overhead for 64 bit numbers. 64 bit processors can do 64 bit maths at the same speed a 32 bit processor does 32 bit. Otherwise everything is the *same* speed bar what you have pointed out about x86_32 on x86_64 operating systems having a slight overhead.
x86_64 processors *can* run x86_32 at near native speeds, they actually have full support in hardware for decoding and executing x86_32 and infact boot the BIOS in this mode before changing the value of a register and calling a hardware interrupt to switch modes, it is actually this which causes the 32 bit on 64 bit OS slowdown as the OS is having to switch into and out of 32 bit and 64 bit modes, but the hardware does support it natively.
more than 4gb of ram on 32 bit is possible yes. Physical Address Extension, invented by intel, extended by AMD to allow 52bit addresses. Windows NT itself does support it. However it is *not* a windows 8 requirement, it is required for x86_64 systems but not x86_32. Enabling it on a 32 bit windows install *does not* allow usage of more than 4gb of RAM. Windows always has hard coded maximum memory limits, for all 32 bit versions of windows except the server releases the limit is hardcoded to 4gb, so even with PAE windows 32 bit will only address 4gb. Windows 7 home basic 64 bit was 8gb, premium 16gb, business enterprise and ultimate all 128gb, hard coded limits, they did the same with 32 bit OSes to 4gb. Windows server enterprise and datacentre versions did support PAE on 32 bit systems fully. Heres an odd one, XP starter edition was hardcoded to 512mb. Windows 8 32 bit is also hardcoded to 4gb in both standard and pro variations.
Recent OSX versions boot directly into 64bit mode exclusively. 32 bit OSX supports PAE with a 64gb memory limit. PowerPC OSX versions of course we no longer care about. Linux also supports 64gb PAE on 32bit.
PAE is not a requirement for 32 bit windows. VIA's line of processors do not support PAE yet do run windows (including 8). For 32 bit PAE is entirely optional and with the exception of server entirely useless.
"All CPU's on the planet are x64 CPUs since like 2006."
This one really made me lol, mostly due to poor wording than actual mis-statement of fact. All CPU's? Really, what about the ARM CPU in my phone, the AVR AtMega328 sitting beside me, the MIPS within my PSP behind me. I know that you know about other architectures existing, but did make me chuckle to read that.
But let us assume you meant all x86 CPU's. Intel atom CPU's and models of the AMD geode line aswell as the entire VIA product line are all x86_32 (VIA if you havent heard of them are a big name in x86 embedded boards for industrial usage), so yeah, every processor since 2006 is totally x86_64. A few atom desktop models (they did exist) supported x64 but that was relatively few, bay trail also has 64 bit models, but for the large part atom is 32 bit.
SixSixSevenSeven said:
x64 processors are not faster *unless* operating on large numbers. A 32 bit processor can only operate on 32 bit numbers so has additional software overhead for 64 bit numbers. 64 bit processors can do 64 bit maths at the same speed a 32 bit processor does 32 bit. Otherwise everything is the *same* speed bar what you have pointed out about x86_32 on x86_64 operating systems having a slight overhead.
x86_64 processors *can* run x86_32 at near native speeds, they actually have full support in hardware for decoding and executing x86_32 and infact boot the BIOS in this mode before changing the value of a register and calling a hardware interrupt to switch modes, it is actually this which causes the 32 bit on 64 bit OS slowdown as the OS is having to switch into and out of 32 bit and 64 bit modes, but the hardware does support it natively.
more than 4gb of ram on 32 bit is possible yes. Physical Address Extension, invented by intel, extended by AMD to allow 52bit addresses. Windows NT itself does support it. However it is *not* a windows 8 requirement, it is required for x86_64 systems but not x86_32. Enabling it on a 32 bit windows install *does not* allow usage of more than 4gb of RAM. Windows always has hard coded maximum memory limits, for all 32 bit versions of windows except the server releases the limit is hardcoded to 4gb, so even with PAE windows 32 bit will only address 4gb. Windows 7 home basic 64 bit was 8gb, premium 16gb, business enterprise and ultimate all 128gb, hard coded limits, they did the same with 32 bit OSes to 4gb. Windows server enterprise and datacentre versions did support PAE on 32 bit systems fully. Heres an odd one, XP starter edition was hardcoded to 512mb. Windows 8 32 bit is also hardcoded to 4gb in both standard and pro variations.
Recent OSX versions boot directly into 64bit mode exclusively. 32 bit OSX supports PAE with a 64gb memory limit. PowerPC OSX versions of course we no longer care about. Linux also supports 64gb PAE on 32bit.
PAE is not a requirement for 32 bit windows. VIA's line of processors do not support PAE yet do run windows (including 8). For 32 bit PAE is entirely optional and with the exception of server entirely useless.
"All CPU's on the planet are x64 CPUs since like 2006."
This one really made me lol, mostly due to poor wording than actual mis-statement of fact. All CPU's? Really, what about the ARM CPU in my phone, the AVR AtMega328 sitting beside me, the MIPS within my PSP behind me. I know that you know about other architectures existing, but did make me chuckle to read that.
But let us assume you meant all x86 CPU's. Intel atom CPU's and models of the AMD geode line aswell as the entire VIA product line are all x86_32 (VIA if you havent heard of them are a big name in x86 embedded boards for industrial usage), so yeah, every processor since 2006 is totally x86_64. A few atom desktop models (they did exist) supported x64 but that was relatively few, bay trail also has 64 bit models, but for the large part atom is 32 bit.
Click to expand...
Click to collapse
The conversation is contained to stand alone processing units, not SoC (arm, intel atom) or something used in industry, because the latter are not really a choice, they come in package.
So yes, all CPU's since around 2006 are x64 native CPUs.
The limit on Windows 8 memory can be modified, though it is not advised, because the processor will be able to map memory areas which are otherwise inaccesable to windows.
mcosmin222 said:
The conversation is contained to stand alone processing units, not SoC (arm, intel atom) or something used in industry, because the latter are not really a choice, they come in package.
So yes, all CPU's since around 2006 are x64 native CPUs.
The limit on Windows 8 memory can be modified, though it is not advised, because the processor will be able to map memory areas which are otherwise inaccesable to windows.
Click to expand...
Click to collapse
Not all CPU's sold in non package form are x86 either, you are seriously mistaken on that front. And still, a SoC is still a CPU.
its always made me chuckle when people declare that a 64bit system is "faster" than a 32bit system
the funny thing is, in the vast majority of cases, and in almost every case for a typical end user, there isn't any differences at all in terms of speed.
Oh well, its probably like the placebo effect. If you think its faster, it probably will seem faster.
as for all the other "actual" differences between the two, SixSixSevernSevern has outlined it very well.
There is an abundance of SoCs and embedded systems running 32bit only and given the world we live in is now very much controlled by SoCs rather than socketed desktop CPUs I think SixSixSevernSeverns point is still valid, 32bit only CPUs are still very much present (although I did spend 10 min looking for a 32 bit off the shelf socketed CPU made post 2006 with no success)
this is about to get a whole lot more muddy with millions of unwashed Apple lovers declaring their 64 bit phones are better than everyone's, but I think from the points made above, we just need to sit there and smile, knowing they are talking out of their arse and got suckered with marketing guff
dazza9075 said:
(although I did spend 10 min looking for a 32 bit off the shelf socketed CPU made post 2006 with no success)
Click to expand...
Click to collapse
Although not socketed VIA's x86 chips (yeah there is a 3rd x86 player, mainly for embedded market) are both 32 bit and not SoC's (I think they have a few models which are SoC's but most use external RAM modules etc etc).
Also why would a CPU within a SoC not qualify as being a non 64 bit CPU made since 2006? Thats like saying that the driver seat within your car does not qualify as being a chair because it is within a car and therefore must be something else entirely, its still a chair, yes its within something else but it is still a chair or in this case a CPU.
If you want to be picky, you can still buy z80 DIPs with external memory and data buses, 8 bit CPU made in 2013 and not a SoC (although you can also buy z80 SoC's too now). z80 is still used by hobbyists and embedded systems, does the job fine, cheap to make, why replace it?
PowerPC chips are used in servers still and available in socketed forms, they are 32 bit. same for SPARC.
dazza9075 said:
its always made me chuckle when people declare that a 64bit system is "faster" than a 32bit system
the funny thing is, in the vast majority of cases, and in almost every case for a typical end user, there isn't any differences at all in terms of speed.
Oh well, its probably like the placebo effect. If you think its faster, it probably will seem faster.
as for all the other "actual" differences between the two, SixSixSevernSevern has outlined it very well.
There is an abundance of SoCs and embedded systems running 32bit only and given the world we live in is now very much controlled by SoCs rather than socketed desktop CPUs I think SixSixSevernSeverns point is still valid, 32bit only CPUs are still very much present (although I did spend 10 min looking for a 32 bit off the shelf socketed CPU made post 2006 with no success)
this is about to get a whole lot more muddy with millions of unwashed Apple lovers declaring their 64 bit phones are better than everyone's, but I think from the points made above, we just need to sit there and smile, knowing they are talking out of their arse and got suckered with marketing guff
Click to expand...
Click to collapse
About Apple, if they do not take advantage of the processor features, they will, in fact, slow down the phone with 64 bit CPU instead of speeding it up.
As i said, the SoC problem is a non-issue, since you can not choose between 32 and 64 bit there because it is not as if you can go and ask the vendor: "you know, ill have this SoC, you can rip the tablet/phone/AIO apart and replace the one inside with this one cause it is 64 bits".
And if you have SoC, you usually don't have a choice about the Windows 8 version either, since it comes pre-loaded with the matching edition.
So this conversation really boils down to PC users. And the point with x32 processors newer than 2006 is pretty much valid.
SixSixSevenSeven said:
Although not socketed VIA's x86 chips (yeah there is a 3rd x86 player, mainly for embedded market) are both 32 bit and not SoC's (I think they have a few models which are SoC's but most use external RAM modules etc etc).
Also why would a CPU within a SoC not qualify as being a non 64 bit CPU made since 2006? Thats like saying that the driver seat within your car does not qualify as being a chair because it is within a car and therefore must be something else entirely, its still a chair, yes its within something else but it is still a chair or in this case a CPU.
If you want to be picky, you can still buy z80 DIPs with external memory and data buses, 8 bit CPU made in 2013 and not a SoC (although you can also buy z80 SoC's too now). z80 is still used by hobbyists and embedded systems, does the job fine, cheap to make, why replace it?
PowerPC chips are used in servers still and available in socketed forms, they are 32 bit. same for SPARC.
Click to expand...
Click to collapse
Im agreeing with you on this one, I was mearly playing devils advocate in saying I couldn't find a off the shelf socketed CPU in 32bit post 2006, but I agree that SoCs and embedded systems contain CPUs and are probably more relevant today then trad desktop CPUs
mcosmin222 said:
About Apple, if they do not take advantage of the processor features, they will, in fact, slow down the phone with 64 bit CPU instead of speeding it up.
As i said, the SoC problem is a non-issue, since you can not choose between 32 and 64 bit there because it is not as if you can go and ask the vendor: "you know, ill have this SoC, you can rip the tablet/phone/AIO apart and replace the one inside with this one cause it is 64 bits".
And if you have SoC, you usually don't have a choice about the Windows 8 version either, since it comes pre-loaded with the matching edition.
So this conversation really boils down to PC users. And the point with x32 processors newer than 2006 is pretty much valid.
Click to expand...
Click to collapse
Im not completely clued up with the Apple SoC /iOS setup, but if its like WOW64 there will be a slight performance hit, but barely measurable let alone noticeable on todays systems.
Im curious as to why you think of SoCs as a non issue given that more devices are probably shifted with them than not, many of these devices directly replacing trad desktop/notebooks
SoC is everything when it comes to future home computing, and the 64 bit question will rear its ugly head again then, but I think we can all agree that having a 64bit system alone does not mean its quicker except in extreme circumstances or when excessive amounts of memory is needed and the 4GB limit is met.
I consider SoCs a non-issue because you do not have a choice. You can not build a PC using a SoC. Hence the issue presented by this thread (choose between x32 and x64) is a non-issue in the SoC world.
the x32 Atom SoCs come on tablets wth x32 windows and you can not replace that SoC with an I5 x64 SoC you find on Surface Pro, hence the discussion on this topic is kinda useless.
I've seen lots of ppl running x32 wndows on systsems with 8-12GB of RAM or x64 on systems with just 1 but this never happened on a SoC based device xD
As for performance, I also believe the x64 CPUs can support more cores than the usuall x32.
But...
x32 CPU running native x32 code will be faster than an x64 CPU running x32 code
x64 CPU running native x64 code is around just as fast as x32 running x32. There are small diffreneces in performance (you can try it out with simple programs with visual studio and compile for different arhitectures), but nothing otherworldly, nowhere near "twice as fast" as apple claims it to be.
dazza9075 said:
Im not completely clued up with the Apple SoC /iOS setup, but if its like WOW64 there will be a slight performance hit, but barely measurable let alone noticeable on todays systems.
Click to expand...
Click to collapse
Even if there is a performance hit, there is almost no downside to using a 64-bit OS for Apple because the CPU is based on ARMv8. Same goes for anyone else that uses the specification. All the better to future proof your platform now so that when mobile devices finally do need to address more than 4GB of RAM, there is only one (64-bit) OS instead of the two that Microsoft has to maintain and developers have to make two versions of software and drivers for.
Sent from my Galaxy S4 using Tapatalk 2.
JihadSquad said:
Even if there is a performance hit, there is almost no downside to using a 64-bit OS for Apple because the CPU is based on ARMv8. Same goes for anyone else that uses the specification. All the better to future proof your platform now so that when mobile devices finally do need to address more than 4GB of RAM, there is only one (64-bit) OS instead of the two that Microsoft has to maintain and developers have to make two versions of software and drivers for.
Sent from my Galaxy S4 using Tapatalk 2.
Click to expand...
Click to collapse
Sorry, but your post makes no sense.
JihadSquad said:
Even if there is a performance hit, there is almost no downside to using a 64-bit OS for Apple because the CPU is based on ARMv8. Same goes for anyone else that uses the specification. All the better to future proof your platform now so that when mobile devices finally do need to address more than 4GB of RAM, there is only one (64-bit) OS instead of the two that Microsoft has to maintain and developers have to make two versions of software and drivers for.
Sent from my Galaxy S4 using Tapatalk 2.
Click to expand...
Click to collapse
I'm with mcosmin222, your post makes no sense. Being ARMv8 means that there is no downside to being 64 bit? The hell are you smoking, decreased 32 bit performance and double RAM usage for 64 bit software on a device still using the same 1gb of RAM as its 32 bit predecessor, MAJOR downside.
Also for most developers there is no extra maintenance for 64 bit and 32 bit OSes. Seriously, most of the time its as simply as changing one setting when building, sometimes more effort is required but usually less than is required to simultaneously support iPad and iPhone in an iOS app (they dont scale well automatically all the time which is why on windows systems and my brief android foray I design with variable screen sizes in mind). Drivers are an issue yes, but most developers are not driver developers, even then 32 bit windows user mode drivers work fine in 64 bit windows, its only kernel mode drivers which require native 32 vs 64 changes.
mcosmin222 said:
I consider SoCs a non-issue -snipped at somewhat random points for size-orldly, nowhere near "twice as fast" as apple claims it to be.
Click to expand...
Click to collapse
mcosmin222 said:
Sorry, but your post makes no sense.
Click to expand...
Click to collapse
Slight hypocrisy there.
It is debated by some whether the atom is a SoC at all, intel do not claim it to be with the exception of a few models which do indeed have more peripherals built into the chip itself than their counterparts, my view is that they are increasingly moving towards a SoC design with the only major external components now being the RAM and storage (of which the typical SoC usually has RAM and sometimes storage internally). There is not a single intel core series processor which is a SoC.
32 bit windows with more than 4gb of RAM I find hilarious, I bought a second hand PC running windows XP 32 bit on 12gb of RAM.... Loaded my copy of windows 7 64 bit onto it immediately. Quite a few people dont seem to realise that the 4gb ram limit also counts video ram too.
I dont know about core count difference for x86_32 vs x86_64. I saw intel demo'ed a prototype 80 core - single CPU (x86 systems can distinguish between having 2 dual core CPU's on one motherboard and 1 quad core CPU) using intel atom 32 bit cores. In the consumer electronics market, 80 cores would be unheard of. Even the server market probably doesn't go beyond 80 very often. Super computers dont always use x86 but may well hit the core limit if there is one
The one place where your suggestion of using visual studio to show 64 bit vs 32 bit differences would really show the advantage of 64 bit is when your software uses a long rather than an int. Int is a 32 bit number. Long is 64 bit. 32 bit processor can't handle longs natively so has to have additional software overhead for longs. Compile for a 64 bit processor and you can use a long instead. Float vs Double I have heard people saying makes a difference but I believe most compilers simply use the x87 math processor embedded within all x86 chips which I think handles doubles natively on both 32 bit and 64 bit x86 processors.
I dislike apple, but I have found one place which justifies the double performance claims. They claimed double performance for the entire SoC as a whole not just the CPU. ARM NEON has had a performance bump in ARMv8. The A7 chip also has an upgraded GPU over the A6X (PowerVR quad core still though so hardly cutting edge). There is also the matter of which benchmarks they use and whether the benchmark does use any 64 bit math. Benchmarks are of course not always indicative of real world performance and for the most part you will *not* see a difference on the iPhone 5S.
SixSixSevenSeven said:
I'm with mcosmin222, your post makes no sense. Being ARMv8 means that there is no downside to being 64 bit? The hell are you smoking, decreased 32 bit performance and double RAM usage for 64 bit software on a device still using the same 1gb of RAM as its 32 bit predecessor, MAJOR downside.
Also for most developers there is no extra maintenance for 64 bit and 32 bit OSes. Seriously, most of the time its as simply as changing one setting when building, sometimes more effort is required but usually less than is required to simultaneously support iPad and iPhone in an iOS app (they dont scale well automatically all the time which is why on windows systems and my brief android foray I design with variable screen sizes in mind). Drivers are an issue yes, but most developers are not driver developers, even then 32 bit windows user mode drivers work fine in 64 bit windows, its only kernel mode drivers which require native 32 vs 64 changes.
Slight hypocrisy there.
It is debated by some whether the atom is a SoC at all, intel do not claim it to be with the exception of a few models which do indeed have more peripherals built into the chip itself than their counterparts, my view is that they are increasingly moving towards a SoC design with the only major external components now being the RAM and storage (of which the typical SoC usually has RAM and sometimes storage internally). There is not a single intel core series processor which is a SoC.
32 bit windows with more than 4gb of RAM I find hilarious, I bought a second hand PC running windows XP 32 bit on 12gb of RAM.... Loaded my copy of windows 7 64 bit onto it immediately. Quite a few people dont seem to realise that the 4gb ram limit also counts video ram too.
I dont know about core count difference for x86_32 vs x86_64. I saw intel demo'ed a prototype 80 core - single CPU (x86 systems can distinguish between having 2 dual core CPU's on one motherboard and 1 quad core CPU) using intel atom 32 bit cores. In the consumer electronics market, 80 cores would be unheard of. Even the server market probably doesn't go beyond 80 very often. Super computers dont always use x86 but may well hit the core limit if there is one
The one place where your suggestion of using visual studio to show 64 bit vs 32 bit differences would really show the advantage of 64 bit is when your software uses a long rather than an int. Int is a 32 bit number. Long is 64 bit. 32 bit processor can't handle longs natively so has to have additional software overhead for longs. Compile for a 64 bit processor and you can use a long instead. Float vs Double I have heard people saying makes a difference but I believe most compilers simply use the x87 math processor embedded within all x86 chips which I think handles doubles natively on both 32 bit and 64 bit x86 processors.
I dislike apple, but I have found one place which justifies the double performance claims. They claimed double performance for the entire SoC as a whole not just the CPU. ARM NEON has had a performance bump in ARMv8. The A7 chip also has an upgraded GPU over the A6X (PowerVR quad core still though so hardly cutting edge). There is also the matter of which benchmarks they use and whether the benchmark does use any 64 bit math. Benchmarks are of course not always indicative of real world performance and for the most part you will *not* see a difference on the iPhone 5S.
Click to expand...
Click to collapse
I think you need to defrag your HDD or something, your browser doesn't display info properly anymore.
Intel Atom is a SoC actually.
You still don't seem to get the idea behind the SoC propblem: it is a non-issue because you can not choose between x32 and x64 windows, as it comes preloaded (I supposed you could change it but for 99% of people that is impossible), hence why i do not consider them in the same category as socketed CPUs.
Do you understand it now?
mcosmin222 said:
I think you need to defrag your HDD or something, your browser doesn't display info properly anymore.
Intel Atom is a SoC actually.
You still don't seem to get the idea behind the SoC propblem: it is a non-issue because you can not choose between x32 and x64 windows, as it comes preloaded (I supposed you could change it but for 99% of people that is impossible), hence why i do not consider them in the same category as socketed CPUs.
Do you understand it now?
Click to expand...
Click to collapse
http://en.wikipedia.org/wiki/Intel_Atom
http://en.wikipedia.org/wiki/Atom_(system_on_chip)
Intel atom system on chip is a subset of the atom lineup.
And I do get the idea behind the SoC chip. It is you that cannot get it through your skull that a SoC still has a CPU within it and is therefore still a 32 bit CPU. It doesnt matter whether the user can choose 32 vs 64 bit software on it, its still a 32 bit CPU manufactured post 2006 as you claim does not exist and frankly your original statement cannot be more wrong.
Also, hardly difficult to obtain and these are still manufactured to this day: http://uk.mouser.com/ProductDetail/...=sGAEpiMZZMsk5yEqv3Bk8TNKQ0wAJ52zqlsFfvN/xPc=
Why hasn't 64 bit completely absorbed 32 bit and just become the norm?
Sent from my GT-I9505 using XDA Premium 4 mobile app
Jay794 said:
Why hasn't 64 bit completely absorbed 32 bit and just become the norm?
Sent from my GT-I9505 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
64 bit = more transistors = more cost, power consumption and larger size in theory. In practise, douchebaggery and the prevalence of 32 bit machines in embedded usage.
Bay trail is moving towards 64 bit for intel atom. Core whatever series CPU's are all 64 bit. I think most of the AMD processors aimed at consumer usage are 64 bit (they manufacture 32 bit SoC's for industrial automation and a few other embedded tasks much to mcosmin's amusement no doubt).
VIA I thought only did 32 bit but apparently their more recent core design is 64 bit capable. They still pitch their older cores at embedded markets though, they have next to zero consumer presence. VIA's chips tend to be tucked within machines in factories or vehicle computers or perhaps the cable box for your TV if you have one (but usually MIPS or ARM appear here, x86 has been used) etc rather than thrown into an off the shelf laptop (although HP released what we would now consider a netbook with a VIA C7). Embedded machines dont always benefit from 32 bit processing (depends on the machine, a CNC mill might be fine with 32 bit maths, the flight computers about something akin to a predator drone might absolutely need 64 bit math), in the event they dont need 64 bit math then using 64 bit software would double the RAM requirement which would then mean needing double the RAM (many machines running a fixed task have only the amount of RAM they require) which then increases cost of the machine.
The atom is probably the biggest use of 32 bit only chips for consumers, with bay trail coming out I think we are reaching the end of 32 bit x86 operating systems for consumers. The embedded market is either going to have to rely on 32 bit chips still being available for them (they are for the forseeable future), or simply run a 32 bit OS on a 64 bit chip or double the RAM they install or something.
Hello,
1- is it possible to compile moto x play kernel to arm x64 and use it?
2- Will it give any advantages over 32 bit kernel, eg. apps should run faster?
3- Why we have 32bit system when cpu supports ARM x64?
Thanks
Pararocker said:
Hello,
1- is it possible to compile moto x play kernel to arm x64 and use it?
2- Will it give any advantages over 32 bit kernel, eg. apps should run faster?
3- Why we have 32bit system when cpu supports ARM x64?
Thanks
Click to expand...
Click to collapse
This has already been told that the hardware isn't powerful enough to get the performance improvements with 64 bit software or kernel.
If the ram get ahead of 4gb, only then the real performance improvement of 64 bit can be seen.
Sent from my XT1562 using Tapatalk
K.khiladi said:
If the ram get ahead of 4gb, only then the real performance improvement of 64 bit can be seen.
Click to expand...
Click to collapse
benchmarks don't support this. At least on desktop pcs with less than 4GB of RAM 64bit systems mostly were faster:
https://www.phoronix.com/scan.php?page=article&item=ubuntu_x86_1304&num=1
Don't know about Android phones though
According to ARM the speed advantage is about 15-20% (see here). Of course the memory footprint is bigger. The Moto X Play has only 2GB RAM, so 64 bit may lose speed against 32 Bit if memory gets exhausted.
This is the same dimension like DroidFish would probably gain according to a mail from the author, which I asked some time ago:
Code:
[quote=tag]in a German Android forum someone insists that chess programs would be
much faster on 64 Bit Android. Do you agree? Would DroidFish for
instance make use of bigger data types, or do they exist already in 32
Bit Android?
[/quote]
The only functional difference in DroidFish when using 64 bit android is
that 6-men syzygy tablebases are supported. The DroidFish user interface
probably only get slightly faster by using 64-bit instructions. Chess
engines can gain quite a bit of speed by using 64-bit instructions though,
but how much they gain depends on the chess engine.
For the stockfish engine that is built into DroidFish I measured 16% speed
increase on my Nexus 6P when using 64-bit compared to 32-bit.
For my own chess engine texel the difference is much larger. The speed
increases about 68% when using 64-bit compared to 32-bit.
The difference can probably mostly be explained by the fact that stockfish
is heavily optimized both for 64-bit and 32-bit architectures, but texel
is only optimized for 64-bit architectures.
Pararocker said:
Hello,
1- is it possible to compile moto x play kernel to arm x64 and use it?
2- Will it give any advantages over 32 bit kernel, eg. apps should run faster?
3- Why we have 32bit system when cpu supports ARM x64?
Thanks
Click to expand...
Click to collapse
1. Maybe, if we can maintain binary compatible with 32-bit userspace blobs. It may be doable with CONFIG_COMPAT and some hackery, but I've never tried such a thing before. I've been contemplating building a 64-bit ROM for lux (using a blend of lux blobs and blobs from 64-bit MSM8939 devices) for quite a while, but I've been too busy to even try, and I have higher priority tasks to take care of when I do get time (such as Audio HAL issues on CM13).
2. Yes, expect a 15-20% speedup. 64-bit sucks with 1 GB RAM, but 2 GB is fine.
3. Motorola wanted to make surnia, osprey, merlin, and lux as similar as possible, so they chose the lowest common denominator.
@squid2 Did you manage to make a 64 bit kernel, buddy?
Asking for this because there is not a single thing like armv8a written in build.prop , So i guess we r using 32 bit android, also this is in build.prop
ro.product.cpu.abi=armeabi-v7a (not armv8)
ro.product.cpu.abi2=armeabi
ro.product.cpu.abilist64= (just empty)
ro.product.cpu.abilist32=armeabi-v7a,armeabi
JJSingh said:
Asking for this because there is not a single thing like armv8a written in build.prop , So i guess we r using 32 bit android, also this is in build.prop
ro.product.cpu.abi=armeabi-v7a (not armv8)
ro.product.cpu.abi2=armeabi
ro.product.cpu.abilist64= (just empty)
ro.product.cpu.abilist32=armeabi-v7a,armeabi
Click to expand...
Click to collapse
Yes bro its OS is 32 bit. Since its processor are based on armv7. And it won't be a trouble as the chip inside is not that powerful.
Ankit_29 said:
No bro. Common its 2017 almost every device is 64 bit.
Click to expand...
Click to collapse
al the latest moto G phones have 64 bit processor and 32 bit system... and the g5 plus is not an exception.
Then the software of both devices is 32 bit? That's a little disappointing
dhk.- said:
al the latest moto G phones have 64 bit processor and 32 bit system... and the g5 plus is not an exception.
Click to expand...
Click to collapse
Sorry I read it wrong. I thought he was talking about processor. Edited my post hope so this time I am correct.:silly:
dhk.- said:
al the latest moto G phones have 64 bit processor and 32 bit system... and the g5 plus is not an exception.
Click to expand...
Click to collapse
lol that is freking weird. but that matters? i mean upto how much extent. what if we had 64 bit os?
Thanks guys, i also did confirmed this myself ,os is 32 bit only although we have 64 bit compatible processor and even 4 gb ram . I donno whats wrong with motorola....
Ankit_29 said:
Yes bro its OS is 32 bit. Since its processor are based on armv7. And it won't be a trouble as the chip inside is not that powerful.
Click to expand...
Click to collapse
Bro snapdragon 625 is not a low end chip, it's powerful enough to run ur phone smooth, and it's based on armv8a and that makes it backward compatible to armv7....so this phone is supposed to run 64 bit os , but u knw moto
JJSingh said:
Thanks guys, i also did confirmed this myself ,os is 32 bit only although we have 64 bit compatible processor and even 4 gb ram . I donno whats wrong with motorola....
Click to expand...
Click to collapse
bcz i think to unify the system for all variants. g5 plus also has 2 and 3 gb ram varints. it must be something which moto has taken into account while pushing 32 bit. so i guess we are good here.lol
rayzen6 said:
bcz i think to unify the system for all variants. g5 plus also has 2 and 3 gb ram varints. it must be something which moto has taken into account while pushing 32 bit. so i guess we are good here.lol
Click to expand...
Click to collapse
Well i think u r right, 64 bit os would b heavy for 2 gb model... i hope we will get 64 bit lineage os sonn...
JJSingh said:
Bro snapdragon 625 is not a low end chip, it's powerful enough to run ur phone smooth, and it's based on armv8a and that makes it backward compatible to armv7....so this phone is supposed to run 64 bit os , but u knw moto
Click to expand...
Click to collapse
Please let me know where I have said SD625 a "low-end chipset". As far I know and own the device and went through several test it shows armv7 (SS attached).
Ankit_29 said:
Please let me know where I have said SD625 a "low-end chipset". As far I know and own the device and went through several test it shows armv7 (SS attached).
Click to expand...
Click to collapse
broo your imei.
@rayzen6
Thank you bro. I didn't noticed it.
I have changed it. Hope no one has downloaded the pic.
Ankit_29 said:
@rayzen6
Thank you bro. I didn't noticed it.
I have changed it. Hope no one has downloaded the pic.
Click to expand...
Click to collapse
:good:
JJSingh said:
Well i think u r right, 64 bit os would b heavy for 2 gb model... i hope we will get 64 bit lineage os sonn...
Click to expand...
Click to collapse
It is not software related. If the hardware is v7, you will not get 64 bit lineage
PunchUp said:
It is not software related. If the hardware is v7, you will not get 64 bit lineage
Click to expand...
Click to collapse
SD625 is 64-bit capable.
KapilFaujdar said:
SD625 is 64-bit capable.
Click to expand...
Click to collapse
You don't get the point. Even if it is a 64 bit SOC, rest of the hardware follows v7 architecture (as SD625 is backward compatible). So it impossible to run 64 bit OS on this device.
What about ram usability
Since we are running a 32 bit Android version 4 GB ram variant is good can Android OS utilise all the 4gb of ram?
ags34 said:
Since we are running a 32 bit Android version 4 GB ram variant is good can Android OS utilise all the 4gb of ram?
Click to expand...
Click to collapse
4 GB is the maximum a 32 bit architecture can support. So yes, it's fully utilised
PunchUp said:
4 GB is the maximum a 32 bit architecture can support. So yes, it's fully utilised
Click to expand...
Click to collapse
The physically addressable memory has not much to do with the "bitness" of the architecture. Most armv7a implementations support lpae (large physical address extension) and can thus address more than 4GB. Actually, I bet this extension is used on the 4GB variant as you also have I/O mapped into the physical address space and would be unable to utilize all of the RAM.
The 32 Bit architecture only confines the virtual address space *per process* to 4GB. Since some of that address space is used to map in shared objects (libraries), stack, kernel interfaces etc. you can usually only use 2-3 GB of RAM per process. This is hardly an issue for a phone (unless you run the Facebook app ). For servers (especially databases etc.) this limitation is an issue and the reason why 64 bit architectures are used there.
AArch64 has some other benefits, such as twice the amount of general purpose registers, 64 bit wide registers (obviously) which allow for 64 bit math, mandatory extensions (no need to check, compiler can just use NEON e.g.) etc. So it's sad that Motorola is not using the SoC's potential.
As for custom ROMs: You'd need a 64 bit kernel which supports the Moto's hardware, 64 bits gfx drivers. Not easy. And then you still need to hope that you can somehow convince the bootloader to boot your kernel in AArch64 state -- which may not be possible. Thus it is extremely unlikely that you get 64 bit support from the community.
Turns out Lenovo thought it would be a great idea to use 32bit for any reason.
realy? yet still this question?
LionLorena said:
Turns out Lenovo thought it would be a great idea to use 32bit for any reason.
Click to expand...
Click to collapse
Wrong area to post this. 64 bit? Get a nexus.
Sent from my Moto G4 using Tapatalk
Why is this so absurd to consider? The device have a 64 bit CPU.
Why not use 64bit Android.
LionLorena said:
Why is this so absurd to consider? The device have a 64 bit CPU.
Why not use 64bit Android.
Click to expand...
Click to collapse
If you had searched for a little bit, you would have found that the answer was already made many times and answered in detail.
LionLorena said:
Why is this so absurd to consider? The device have a 64 bit CPU.
Why not use 64bit Android.
Click to expand...
Click to collapse
Because there's effectively no point. The SD617 has a 32-bit width data bus- a 64-bit ROM would actually yield less performance.
Why do you want a 64-bit ROM anyway? There's absolutely nothing 32-bit Android has to offer over 64-bit Android absurdly high RAM amounts (which you'll never find in a budget phone).
Some software I wanna use is 64bit only.
And what would be "absurdly high"?
Because from what I know the advised ram for 64bit is 4gb.
LionLorena said:
Some software I wanna use is 64bit only.
And what would be "absurdly high"?
Because from what I know the advised ram for 64bit is 4gb.
Click to expand...
Click to collapse
No use of 64 bit unless RAM > 4 GB. Beyond 4GB is the point where 64 bit arch starts.
Moreover does moto even release 64 bit source? I heard something similar in the potter forum.
tywinlannister7 said:
No use of 64 bit unless RAM > 4 GB. Beyond 4GB is the point where 64 bit arch starts.
Moreover does moto even release 64 bit source? I heard something similar in the potter forum.
Click to expand...
Click to collapse
Actually 3.7gb (give it or take) is the limit of 32bit.
So any value over that is valid for 64bit
And to be fair the minimum ram for 64bit would be 2gb.
They say 4gb because is where it matters most.
Since 32 can only deal with 4gb.
1 for kernel and 3 for application.
RAM consumption is huge on 64 bits system, take a look to the Nexus 5X... For an Android device running a 64 bits system you need at least 3 GB of RAM, and also, why do you want a 64 bits system if a 32 bits system offers better performance? The 64 bits system just has new type of instructions that are only for more complex calculations that not even the average user will use
LionLorena said:
And to be fair the minimum ram for 64bit would be 2gb.
They say 4gb because is where it matters most.
Since 32 can only deal with 4gb.
1 for kernel and 3 for application.
Click to expand...
Click to collapse
What software do you need to run on Android that requires 64-bit?
joeeboogz said:
Wrong place to post
Click to expand...
Click to collapse
Oh, I'm deeply sorry, it sounded appropriate to post under its own device category.
Johann0109 said:
RAM consumption is huge on 64 bits system, take a look to the Nexus 5X... For an Android device running a 64 bits system you need at least 3 GB of RAM, and also, why do you want a 64 bits system if a 32 bits system offers better performance? The 64 bits system just has new type of instructions that are only for more complex calculations that not even the average user will use
Click to expand...
Click to collapse
I need it to run 64bit only software.
negusp said:
What software do you need to run on Android that requires 64-bit?
Click to expand...
Click to collapse
Dolphin
Nintendo GameCube / Wii Emulator
Thread cleaned of rather sad tripe.
Keep it civil please...
LenAsh said:
Thread cleaned of rather sad tripe.
Keep it civil please...
Click to expand...
Click to collapse
Thanks !
LionLorena said:
Dolphin
Nintendo GameCube / Wii Emulator
Click to expand...
Click to collapse
In all seriousness, even if a 64-bit ROM were ported to the G4 the SD617 inside would struggle heavily.
You need at least an SD801 to run Dolphin anywhere near smoothly.
negusp said:
In all seriousness, even if a 64-bit ROM were ported to the G4 the SD617 inside would struggle heavily.
You need at least an SD801 to run Dolphin anywhere near smoothly.
Click to expand...
Click to collapse
Hm I see.
Well, I've figured since it was to run some 2D title I would do fine.
Since I don't have a very powerful computer either (dual core i3 3217u) and it run said title at 60fps where other 3D games won't pass 10fps.
But that's expected I guess, I think it's time to move on.
I wonder if the Moto Z is 64bit since it is SD820
Didn't yu yureka have a 64 bit is?
Will 6gb vs. 8gb model impact installing custom roms?
Would upgrading the RAM in your laptop from 4GB to 8GB affect installing Windows 10?
A: No.
Elnrik said:
Would upgrading the RAM in your laptop from 4GB to 8GB affect installing Windows 10?
A: No.
Click to expand...
Click to collapse
Well yes there's a difference - choosing between x86 and 64bit.
sl___ said:
Well yes there's a difference - choosing between x86 and 64bit.
Click to expand...
Click to collapse
Not like there are a lot of choices in custom ROMs where you have to decide between 32 and 64 bit versions...
But ok. Enjoy your 32 bit Windows.
Elnrik said:
Not like there are a lot of choices in custom ROMs where you have to decide between 32 and 64 bit versions...
But ok. Enjoy your 32 bit Windows.
Click to expand...
Click to collapse
I'm not sure how I aggravated a snarky response, but I'll apologize for it.
Re: your analogy question with Windows 10, I answered yes there is a difference. Because after upgrading from 4gb to 8gb, you wouldn't want to sell yourself short by installing an x86 windows and be limited.
I'm not familiar with Android architecture, hence why I was posing this question about if if a 6gb/8gb version would impact compatibility with ROMs. Judging by your response, I'm guessing that's a no.
sl___ said:
I'm not sure how I aggravated a snarky response, but I'll apologize for it.
Re: your analogy question with Windows 10, I answered yes there is a difference. Because after upgrading from 4gb to 8gb, you wouldn't want to sell yourself short by installing an x86 windows and be limited.
I'm not familiar with Android architecture, hence why I was posing this question about if if a 6gb/8gb version would impact compatibility with ROMs. Judging by your response, I'm guessing that's a no.
Click to expand...
Click to collapse
Sorry. It's been a Monday. Didn't mean to snark. (Lord I hate Mondays...)
IMO, there is little need to go above 6, let alone 8. But, if they're going to offer it, take advantage of it. The more you have, the greater number of apps can stay in flight, which also means less the OS has to constantly load from storage, etc.
A lot depends on how the OS handles RAM too - like how the Sammy GS7 had very aggressive RAM management when it came out, and it would close down background apps WAY too soon. Users noticed switching back and forth between apps took longer than it should because each time they switched apps it had to load it from storage back to RAM, which is very slow in comparison.
Then there is the strange concept some people have that you want to keep your RAM and background apps clear for better performance. A self-inflicted GS7 problem as a performance increase... *boggle*. If you examine how RAM works in a typical computer, it pretty much debunks that thought. Once data is in RAM, it's pretty CPU and power neutral (unless being called on). The argument can easily be made that it is more resource intensive to constantly load from storage into RAM, then clearing it asap, than it will ever be to simply accessing data already in RAM. My thought is the only bad RAM is unused RAM, so just let the OS do it's thing.
But regarding your question - no, the ROM probably doesn't care a lick how much RAM the device has, as long as it is enough to load itself, services, and the apps you want to run.