Technical Discussion
  >> Linux Issues


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | 3 | 4 | 5 | (show all)   Print Thread
Standard User AEP
(fountain of knowledge) Fri 18-Mar-11 09:14:46
Print Post

32- and 64-Bit


[link to this post]
 
This is likely to be a lengthy post, so stop right now if you are not interested!

Background
In Camie's recent post a few common misconceptions about 64-bit programs have arisen so I thought it might be useful to explain my understanding of the subject. As background, I have been interested in 64-bit assembler for the past 6 or 7 years and have studied the AMD and Intel manuals quite carefully. I have a web site that details some of my research, in particular bootstrapping a processor into 64-bit (more properly "long") mode and then getting it to actually do something. This has been quite favourably received by others trying to understand these things. I am an interested amateur, not a professional.

Memory Addresses
It is a fairly obvious truism that 64-bit addresses are twice the size of 32-bit addresses. But this doesn't mean that a 64-bit program is twice the size of a 32-bit one, or uses twice the RAM. In practice very little of the data in a program consists of absolute addresses. More commonly memory is addressed via addresses stored in registers - in particular local variables to functions are stored on the stack and will be addressed via the BP register. The stack itself would (if other things were equal) be bigger, because it also contains the return address and other details, but other things aren't equal.

Data
No difference here (in general). A 64-bit program can address data in 8-bit increments just as a 32-bit one can. So no more storage space is needed for data. One exception to this is the Interrupt Descriptor, Page, and other Descriptor tables where the entries are always a fixed width. But, each of these tables tends to occupy its own memory page, which is probably not fully used. So it's a bit like the (lack of) difference between a 1 bit file and a 1 Kb file on a disk.

Data Bus
Someone raised the fact that the data bus is 64-bits wide even in 32-bit mode. True, but the processor can only move memory from registers to the data bus (and vice versa) and those registers can only hold 32-bits of data. The upper 32-bits of the data bus are there, but they're empty in most cases. A dual carriageway is fine, but if everyone sticks to the left-hand lane....

Registers
Now we start on the good stuff! In 64-bit mode the processor has 16 64-bit general purpose registers available, as opposed to 8 32-bit registers. Similar considerations apply to floating-point and MMX registers. This means that a lot of data, particular transient variables, can be stored in registers rather than RAM. So, less RAM to store the data, and no pointers needed to access it. The result is more efficient and considerably faster code.

Instruction Set
The 64-bit instruction set offers a richer selection allowing for more efficient programs.

Calling Convention
In 32-bit mode all parameters to a function are passed on the stack. In 64-bit mode the first four parameters are passed in registers (got to make use of all those lovely extra registers). The result is that a 64-bit program uses less RAM for most function calls; and those function calls execute much more quickly.

I/O Ports
No real difference here. The I/O address space is totally different from the memory address space and is plenty big enough for any ports a system might use.

Conclusion
Will a 64-bit program use more RAM? It's difficult to say. All programs are different, so the answer is "possibly" (and possibly it may be less); but the difference will likely be in the order of 5% at the most.

Will a 64-bit program run faster? Undoubtedly; it's got everything in it's favour so, assuming your compiler is making full use of those extra facilities, there's no contest. And modern compilers are very good. As I said in the other thread, to run a 32-bit OS and programs on a 64-bit processor is a bit like buying a Jaguar V-12 and then pulling the spark plugs off 6 of the cylinders. It still works, but....

It is most emphatically not true that, as you often see stated, the only difference between 32- and 64-bit OSs is the amount of RAM they can address.

I should emphasize that all of this is referring to 64-bit programs running on a 64-bit Operating System. This is the Linux forum, so we don't have to worry about compatibility with 32-bit programs. It's trivial to recompile a program to 64-bit and any distro you use will have done so (or for the hard-cases, you'll be doing it yourself in your Gentoo installation).
Standard User camieabz
(legend) Fri 18-Mar-11 10:02:31
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
I can really only comment with regard to how 64-bit Windows utilizes memory over 32-bit Windows (specifically Vista 64 over XP 32). Unfortunately, MS seems to have decided to allow many of the services, processes and apps access to far more RAM than we have previously been used to.

To give an example, my system a month ago used around 1.5GB of RAM to boot (that's leaving the system along for 20 mins after boot; allowing any security software to get going, and have a scan etc.)

Now, since I made the tweaks I did, it's at 1.1GB, which in my mind is still steep for a boot, but is pretty good for Vista. Disabling pretty much everything relating to group policy, shared networking and other excessive services, processes and tweaking other programs, I reduced the load by 27%. Notice from the pic that the Total/Cached/Free is 4093/3070/306 respectively. Vista likes to try to use all the memory it can for pre-fetch and other similar processes, and speed up the user's experience. I think this is a flawed idea. Although people are creatures of habit, they are not all the same. I would have preferred 75% allocated for regular usage and 25% set aside for other things (if such an allocation would actually make any difference).

The system hasn't increased its boot time noticeably, but there's a definite increase in responsiveness from apps, and while we would expect cached programs to be faster on re-load, the responsiveness of these has increased too. Some say that with all that RAM, you should just use it. WHat's the point of having it, if you don't use it? I say that the boot-up RAM is the computer's usage, while the rest is for me. smile

I doubt if my own future PC needs would exceed 4GB of RAM for a while. I experimented with opening 20 tabs, a sizzeable game and numerous other light and heavy apps to see what swapfile usage got involved. I was up to 2.5GB RAM usage and 1.5GB swapfile (Windows does this without my input), so I set my swpafile minimum to 2GB and the max to 3GB (hopefully reducing the likelihood of the swapfile thrashing the disk anytime soon).

With Windows, I feel it's more a case that the software uses what it likes, rather than what it needs. It's fair that some apps have many features and need extra space, but I'm for disabling as many non-regular features, sevices and tools from an automatic perspective, preferring them to be started when I choose to start them.

Does the system feel faster? The RAM is faster, as is the CPU, and the programming of Vista is such that it will try to second guess my regular usage with pre-fetch, and in general the daily stuff runs faster.

Perhaps I can try a test with XP 32-bit sometime down the line, once all my own concerns are sorted. I do remember that on first impressions of Vista, I felt the increase in hardware had been cancelled by the increase in software. Was a little miffed. Over time I've tweaked the system to the point that it's far faster than the XP for daily usage, but can't guess at like for like benchmarks.

Once W2K and XP get dropped (2020ish? wink ), the differences will probably be there, but not noticable, as software will be even more bloated, and hardware will be different. Prolly have 64 cores per CPU, 10PB SSDs and have electrodes attached to the head rather than input devices. grin

~~~~~~~~~~



© Camieabz 2002-2011 - All rights and lefts reserved.

report this link
Standard User AEP
(fountain of knowledge) Fri 18-Mar-11 10:13:56
Print Post

Re: 32- and 64-Bit


[re: camieabz] [link to this post]
 
I'm not sure about Vista, but the way that Windows 7 uses memory confuses many people. It does appear that it uses a lot of RAM, but the truth is that most of that memory is used for caches and is immediately released to applications when it is needed. This gives the impression of a very memory-hungry system when, in reality, it is just a system using memory efficiently.

I'm with those who say, if you've got the RAM you might as well use it. To me it's like spare cash (no pun intended). The great thing about Internet banking is that it lets me immediately move money from my current account into a savings account and back again. So if I'm not using that spare £500 I let the bank use it, and they pay me for the privilege (not as much as I'd like, but...). But as soon as I need it I just transfer it back to the current account and it's immediately available for me to buy that new computer. Windows 7 uses memory a bit like that.


Register (or login) on our website and you will not see this ad.

Anonymous
(Unregistered)Fri 18-Mar-11 10:55:08
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
(carried over from other thread.Long, short summary at end)

"There's a lot of tosh talked about 64-bit processors. "

Absolutely. So many people use 64bit to mean so many different things, and rarely do they make themselves clear. Me included smile You're clear enough for me so far.

But at least when the comparison is between an AMD64 system (or Intel equivalent) in 32bit mode and the same AMD64 in 64bit mode, nothing changes in the physical hardware. No magick happens when you boot a 64bit OS to make the path to memory suddenly twice as wide and therefore up to twice as fast. Obviously if you were comparing a 32bitwide path to memory with a 64bitwide path to memory, there may well be benefits. But that's not happening in an AMD64 box in 64bit mode (as you obviously know, but other readers may not).

"why not use the extra width of the CPU registers,"

The extra width of the CPU registers doesn't matter unless you're working with an operand bigger than 32bits. How much code does that cover? If your operand is bigger than 32 bits it typically has to come from somewhere. If you're lucky, it's another register, otherwise it's cache or main memory.

Addresses (pointers) in a 64bit world are bigger than 32bits smile

"there are twice as many of them" (registers)

As per your base note in this thread, there generally will be something in this one; it would be rather application dependent, real measurements would show if there's anything significant in it. Have you seen any numbers? I haven't.

"Will a 64-bit program run faster? Undoubtedly;"

Seen any actual evidence (numbers, not architectural theory) for this?

"In practice very little of the data in a program consists of absolute addresses"

Probably true, but I cannot see how there can be any argument about the impact of using 64bit addresses where 32bit would do - if you have a collection of pointers, the 64bit one is twice as big, therefore fewer pointers fit in any given amount of memory (be it cache memory or main memory). There are compiler/linker-dependent ways of bodging a given app's code such that it sees only 32bit addresses. The only case where unnecessarily using 64bit addresses isn't a performance loser is where ALL the data of interest fits in registers, which I see as unlikely.

"It is most emphatically not true that, as you often see stated, the only difference between 32- and 64-bit OSs is the amount of RAM they can address."

Yes, in the AMD64 world (and that is where we are). On the other hand, if we were talking about MIPS processors, or other Linux-capable alternatives...


"I am an interested amateur, not a professional."

Nowt wrong with that, sir.

Summary: Unnecessarily using 64bit addresses because of 64bit ("long") mode is not helpful to performance. It may not typically be a disaster either. There may be other benefits in using the different instruction set which outweigh the impact of using more memory for the same application's code+data. These benefits aren't so much to do with being in 64bit mode as from being in AMD64 native (or "long") mode where more registers and more interesting instructions are available, which is generally a winner. Actual performance comparisons for common apps don't seem to be widely available, which leads me to believe that in most cases, contrary to the hype, there's not much in it.

Complicated, isn't it.
Standard User camieabz
(legend) Fri 18-Mar-11 11:01:49
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
I get the feeling that Win 7 is to Vista as Win 2K was to NT. The better developed, more rounded system. Certainly with multi-thrading and multi core usage growing it should be better in some aspects. Perhaps it's fair to say that Vista is/was the Beta of Win 7.

~~~~~~~~~~



© Camieabz 2002-2011 - All rights and lefts reserved.

report this link
Standard User AEP
(fountain of knowledge) Fri 18-Mar-11 11:21:51
Print Post

Re: 32- and 64-Bit


[re: Anonymous] [link to this post]
 
The extra width of the CPU registers doesn't matter unless you're working with an operand bigger than 32 bits. How much code does that cover?
Well, any code that is processing strings, audio data, video data, images, etc. for starters. And that's not that unusual nowadays. The important part of the data of many programs consists of arrays and structures rather than simple variables. Loading this sort of data from memory, and storing it again is more efficient when the data bus usage is twice as wide.
Have you seen any numbers?
Much of my experience is just that, rather than formal benchmarks. But I have seen (and no, I can't lay my hands on them offhand) benchmarks that show that video processing and database processing, for example, are much faster with a 64-bit OS.
how there can be any argument about the impact of using 64 bit addresses where 32 bit would do
There's no impact other than, as you mention, possibly on cache. And don't forget all the pointer access that you are saving by storing data in those 8 extra registers rather than having to read and write it from memory. Not to mention the reduced use of pointers in the function calling convention.
The only case where unnecessarily using 64 bit addresses isn't a performance loser is where ALL the data of interest fits in registers, which I see as unlikely.
ALL the data of interest - really? Suppose that we have a function that uses 9 local variables. A 32-bit program will have to store all of those on the stack with a consequent memory access every time that it wants to refer to that variable. A 64-bit one will be able to store 8 of those variables in registers; that's quite a saving on memory access. How many functions use a small number of local variables? Probably more than you think.
Yes, in the AMD64 world (and that is where we are).
I'm not sure if that was meant to imply that the only difference in the x86 world is the amount of RAM that can be addressed. If so I hope that I have demonstrated otherwise. I certainly know that when I'm writing 64-bit assembler I use a lot less memory accesses and I have the availability of processor instructions that wouldn't be the case in the 32-bit world. And compilers are cleverer than I am.
Complicated, isn't it.
It certainly is. My challenge to anyone who says there is no difference is to try a bit of 64-bit x86 assembler programming and then come back and argue some more. (Apologies if you already fit into that category.)
Standard User AEP
(fountain of knowledge) Fri 18-Mar-11 11:23:49
Print Post

Re: 32- and 64-Bit


[re: camieabz] [link to this post]
 
Although Vista has improved over it's lifetime it doesn't hold a candle to 7, especially with the newer hardware. Your comparison to the difference between NT 4 and Windows 2000 (I loved 2000) is most apposite.
Standard User camieabz
(legend) Fri 18-Mar-11 12:07:33
Print Post

Re: 32- and 64-Bit


[re: Anonymous] [link to this post]
 
I've seen 8-bit systems, 16-bits systems, 32bit and now 64-bit.

Generally the overall speeds are similar, but the amount of data and quality of output has increased massively. Perhaps that's the benchmark. Speeds are the same. Everything looks better.

~~~~~~~~~~



© Camieabz 2002-2011 - All rights and lefts reserved.

report this link
Standard User AEP
(fountain of knowledge) Fri 18-Mar-11 12:20:41
Print Post

Re: 32- and 64-Bit


[re: camieabz] [link to this post]
 
Perceived speed of systems tends to stay the same. (it's fast enough.) But it takes a lot of power to manage all that eye-candy. Not to mention the fact that computers now do many things at once. I certainly remember the days when if, for example, you wanted to print a document you couldn't do anything else until it had finished.

As in many areas of life, innovation always leads to calls of "do we need it". I'm pretty sure that people realised why we needed 8-bit processors rather than their 4-bit predecessors but ever since then it's been "Do we need...?".
Standard User awoodland
(regular) Fri 01-Apr-11 16:10:26
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
Complicated, isn't it.

It certainly is. My challenge to anyone who says there is no difference is to try a bit of 64-bit x86 assembler programming and then come back and argue some more. (Apologies if you already fit into that category.)


I think you missed another benefit of x64 - you can safely assume that all such processors have at least SSE2 available, which means less branching (and development time) in the tight loops where profiling shows it's worth doing this manually.
Pages in this thread: 1 | 2 | 3 | 4 | 5 | (show all)   Print Thread

Jump to