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?