64 bit question

[Guest]

Got a question about 64 bit.

I seem to recall P3/P4/Tbirds (?) can theoretically address up to 64 GB of RAM (36 bit adressing lines I think). However, due to the fact that they use 32 bit only registers, they can only address 4 Gb at once, ie, a single process can only be 4 Gb. Is this correct ?

Regardless of wether it is data or code ? Is was just thinking about good old EMS/EMM (?) on a 286.. where you could only have 640 Kb of code, but by using a special translation scheme, your application could access a few megabytes of data.. but data only. Anything beyond 640 Kb/ 1Mb could not be used to run code. Is this thing similar ?

My point is.. I dont think you will require very often to have more than 4 gb available for a process/application.. but you might want much more to store data in. Is that possible ? could you have like a 10 Mb application accessing 10+Gb of data in memory on current cpu's ?

If you can, I fail to see the point of 64 bit cpu's.. Have you got any idea how much code a compiled 4 Gb process is ?? I dont know how compiled code compares to source code, but lets say about 1/20 (please correct me, Im no developper). If I'm right, that would mean 80 gb of sourcecode. that is 80.000 mb or about 80.000.000.000 bytes. Lets say an average line of code is what, 100 bytes (?), thats 800.000.000 lines. It would take a team of 100 developpers maybe 10 years to just *type* that. Am I missing something ?

What do we need 64 bit cpu's for then ? Dont we just need 64 bit adressing ?

---- Owner of the only Dell computer with a AMD chip

 

[Guest]

Not too sure about the 36 address lines .. there does not appear to be any support for memory banks > 4gig with normal X86 systems (Win or Linux).

My experience of source code to compiled code is that source is seldom larger than the compiled executable (in 'C').

There can be wide variations of course but remember that your source does not usually include library and operating system functions (or in my case comments ... bad bad bad!)

Try looking at an assembler version of some trivial 'C' functions to get some idea.

This does not invalidate your premise however since the major requirement of 64 bit is probably as working storage (RAM tables & buffers etc), as you suggest. I have not seen too many executables over 5 mbyte except from M$.

The extra dynamic range of integers would come in handy from time to time (the 32 bit limit of +- 2000000000 is sometimes too small), although this could be changed on current processors by compilers generating multi step arithmetic for higher precision (or using doubles).
I can only talk from a commercial application view, probably get a different answer on scientific or graphic intensive apps.

 

[Guest]

"there does not appear to be any support for memory banks > 4gig with normal X86 systems (Win or Linux)."

Very few x86 systems (if any) offer >4 Gb physical memory
.. The cpu can handle it though, as can windows 2000 AS. Have a look here:
<A HREF="http://www.microsoft.com/windows2000/en/advanced/help/default.asp?url=/windows2000/en/advanced/help/paex86_2.htm" target="_new">http://www.microsoft.com/windows2000/en/advanced/help/default.asp?url=/windows2000/en/advanced/help/paex86_2.htm</A>

"My experience of source code to compiled code is that source is seldom larger than the compiled executable (in 'C'). There can be wide variations of course but remember that your source does not usually include library and operating system functions "

I dont believe this. Maybe your executables are larger after compilation because of the added linked libraries, but thats because you probably only write relatively (very) small apps. If you write something 10x or 100x the size, the libraries will remain the same size, and the compiled code will become *much* smaller in size.





---- Owner of the only Dell computer with a AMD chip

 

[Guest]

Maybe not that much of a reference, but look at the table here: http://www.pctechguide.com/02procs.htm

Any cpu (intel or amd) beyond the P6 has 36bit address lines, giving you 64 Gb of addressible memory

---- Owner of the only Dell computer with a AMD chip

 

[leonov]

Yes CPUs can address more memory than the normal 32 bit limit of 4GB. However you have to write the application specifically to be able to handle it correctly. This is exactly like it used to be with the old segemented memory with 16 bit apps.

Why haven't people done it so far. Well until fairly recently few have needed to access such large amounts of memory so few programs have used the extensions. Now more people want to use larger amounts of RAM it is better to extend the memory and internal address registers properly rather than using some hacked architecture.

You are right about memory usage and programs. Database systems rely on large amounts of memory to increase their speed. A database system may only use 15-20MB of memory for the code but store gigabytes of data to make it quick to access. If it didn't store the data in memory it would have to get it from disk which would make it potentially thousands of times slower. Some databases can be more than 1000GB in size so you can see more memory *is* required to cache these effectively.

BTW databases are growing in size because of the Internet and the desire of companies to use larger machines to extract more useful information from the vast amounts of raw data they have.

L

 

[Guest]

32 bit processor addressing limit is 2^32= 4.29*10^9 B. or 4.29Gigs
64 bit processor addressing limit is 2^64= 1.84*10^19B. or 18446744073Gigs.
Anandtech mentions it in the 760MP review.
http://www.anandtech.com/showdoc.html?i=1483&p=3

Anim88tor

 

[ajmcgarry]

Please somebody call me an idiot because I'm going nuts reading this thread and not understanding any of it.

Since when did 64bit refer to the size of the address bus in any CPU. Call the lecturers who taught me idiots, but I was always thought that the bit size refered to the data size of the CPU's data registers. I have extensively studied from 8086 through to Pentium II architechures, addressing, insruction sets etc. and that was the terminology I always used.
Current Intel type CPUs can address up to 64TB (Yes Terra) of data as far as I can remember although I'm a bit rusty.
The total size of the Instruction Register or IR reg for short is over 100 bits. Not quite sure exactly the size.

Here is a link to some basic principles as back up to my seemingly mental ideas in this thread.
<A HREF="http://www.stac.org/projects/curriculum/cpu.html" target="_new">http://www.stac.org/projects/curriculum/cpu.html</A>




<font color=blue>Smoke me a Kipper, I'll be back for breakfast!</font color=blue>

 

[Guest]

Thank you for the link .. It supports your contention, I need to examine the processor & chipset specs in order to ascertain how it works (some kind of virtual to physical address mapping probably).



"I dont believe this. Maybe your executables are larger ...."

I presume you mean that your experience is different not that you are imputing that I am lying? which is how an English speaker would interprete your statement.

I have written EDI translators and scripting interpreters in less than 5000 lines of code which have been commercially successful and efficient, I regard them as useful real world products which are not full of "bloat" but perhaps your world is different.

 

[ajmcgarry]

64 bit processor are not new, either are 64, 128 and 256 bit processors.
Most graphics chips since the Riva 128 have been 128bit processors. The N64 has a 64bit processor, the PS2 has a 128 bit processor. Sure they are graphics processors, but the terminology is the same. 128bit = 128 data bits. 64bit = 64 data bits.





<font color=blue>Smoke me a Kipper, I'll be back for breakfast!</font color=blue>

 

[Guest]

Read your link but don't see where it says that you can address terabytes of data. You may be confusing the data bus width (64 bits) on pentium pro upwards but that is only the amount of data transmitted to or from the cpu cache in a single memory access. The address and data busses are separate on current X86 processors so there is no relationship between them.

You are correct that register size does not necessarily limit addressing range although it does mean that a single process cannot address more than 4 gig on current processors.

You need virtual to real tables or segment base offsets (as used to be used on 16 bit processors) to allow greater physical address ranges (controlled by the operating system usually). I have just read the x86-64 white paper which clearly states that the Instruction pointer is 32 bits long and is extended to 64 bits in long(64 bit mode) so definitely not 100 bits on Athlon.

 

[ajmcgarry]

n-bit processor: register size(width) = <i>n</i> ==> processor word is <i>n</i> bit long.

<A HREF="http://www.hashimi.org/cs212/lectures/cs212s9.pdf" target="_new">http://www.hashimi.org/cs212/lectures/cs212s9.pdf</A>


<font color=blue>Smoke me a Kipper, I'll be back for breakfast!</font color=blue>

 

[ajmcgarry]

the Instruction pointer is 32 bits long and is extended to 64 bits in long(64 bit mode) so definitely not 100 bits on Athlon.

I'm not talking about the instruction pointer, I'm talking about the instruction register. The instruction Register hold the currently executing instruction, and consists of an OPCODE and an OPENAND. Depending on the OPCODE the OPERAND can contain various different things. Actual data values, addresses to data or combinations. The combined length of OPCODE and OPERAND is greater than 100 bits. The instruction pointer points to an instruction further into the program, used in the prefetch and fetch cycles.

Damn, wish I had my notes on this so I could set things straight.


<font color=blue>Smoke me a Kipper, I'll be back for breakfast!</font color=blue>

 

[Guest]

The internal storage locations within the processor used to hold the current instruction(s) are different depending on the internal implementation of the pipelines, they are not relevant to a discussion of the addressing capability of a processor so why mention them?.

 

[ajmcgarry]

I was just responding to what you said on the Instruction pointer, which I dodn't think was taken in the right context. Maybe I am going too deep, but I'm just trying to make the point that the 64bit refers to the size of the data registers in the processers, not the addressing.

In the 32 bit processors for example the register were made up as such

8bit 8bit
-AL- -AH-

Or combined together to give one 16bit regeister AX.
To the left of AX was 16bits that could be referenced as EAX and included AX as the right 16bits to give a 32bit register.
The same for the other registers EBX, ECX etc.



<font color=blue>Smoke me a Kipper, I'll be back for breakfast!</font color=blue>

 

[Phelk]

This isn't to difficult. Any address space consists of 8 bits or 1 byte. Each byte has an address space which can 'normally' only be addressed by one instruction line. The width of the instruction line is based on the CPU ie 32bit or 64 bit. So the math goes something like this.

2^32(bits) = 4,294,967,296 or roughly 4GB of address space

2^64(bits) = 18,446,744,073,709,551,616 or roughly 18 million Terabytes of address space

While 4GB of address space is good for your PC it is rather limiting for large databases where a single table or even index could exceed 4GB quite easily. 18 million Terabytes on the other hand provides a fairly impressive increase which realistically will only provide limits to some of the extreme areas of science like analysis of genetics and the universe.

Basically this just makes core programming far easier as you can utilise large quantities of memory very easily. This will become more important in PC's as speech & video recognition becomes more prolific. Also, considering that mainstream PC's now come with 256MB it will not be long before 4GB is standard.

Back to the original question...

~ What do we need 64 bit cpu's for then ? Dont we just need 64 bit adressing ? ~

64 bit addressing is needed to ease programming of large data spaces. 64 bit processing though not entirely necessary, makes 64 bit addressing easier and will allow for faster processing of larger data chunks in one go.

To put things into perspective Sun has recently released a system with 24 * 64bit UltraSPARC III processors with 192GB of memory (and this is only the midrange machine). These systems have swap spaces well in excess of 1 Terabyte far beyond the 4GB restrictions of 32bit addressing.

<font color=blue> The Revolution starts here... as soon as I finish my coffee </font color=blue> <P ID="edit"><FONT SIZE=-1><EM>Edited by phelk on 06/08/01 07:50 PM.</EM></FONT></P>

 

[Guest]

-post deleted..

I missed page 2 ;-)

 

[Guest]

"I presume you mean that your experience is different not that you are imputing that I am lying? which is how an English speaker would interprete your statement."

No and no. I mean, no, I am not calling you a liar, nor am I questioning your experience or expertise. And no, I dont have other experiences since I never got beyond basic VB programming.

What I was trying to say though, was that your experience of compiled code being larger than source code is related to the fact that you write relatively small programs. As you just said, 5000 lines code is pretty small in the face of this discussion. Im pretty sure these 5000 lines would be compiled into something like 1/10 the original size PLUS all required libraries which might be larger than your code. All I am saying is, when you'd write a 1.000.000+ line program, the size of these libraries would become relatively unimportant. Just to say, that compiled code should be *much* smaller than source code, if you do not take into account those libs, which become unimportant in size if you are about talking multi gigabyte executables.

Maybe you test this for yourself. See how large those libraries are. Subtract that size of the size of your compiled executable, and compare that to your source.

If this is not possible for whatever reason, compile a "hello world", but using the same libraries, and compare it to your 5000 line compiled program. Im pretty sure the difference is neglectable.

---- Owner of the only Dell computer with a AMD chip

 

[rcf84]

Well 64-bit will last along time no matter what.

Nice Intel and AMD users get a Cookie.... Yummy

 

[Guest]

Phelk..
I do agree that 4 Gb and even 64 Gb is (or will very soon become) a limitting factor for specific applications. You wont catch me saying '4Gb should be enough for everyone' ;-)

And, though you may be right on in most of your post, please note current intel and amd cpu's can in fact adress 64 Gbyte since they use 36 bit addressing.

My question however, remains. If they could hack it from 32 to 36, why not to 64 bit adressing space ? Why do we need 64 bit instructions and registers, except to calculate PI perhaps ? I dont see how databases could benefit from this.

Also, the other question remains. Is it true that current apps (on 32/36 bit cpu's) are limited to 4 Gb per proces, while each process they can access up to 64 Gb of data ?

---- Owner of the only Dell computer with a AMD chip

 

[Guest]

Did you just update your post ? I was just typing a reply to your benchmark question...

---- Owner of the only Dell computer with a AMD chip

 

[rcf84]

I moved it <A HREF="http://forumz.tomshardware.com/modules.php?name=Forums&file=faq&notfound=1&code=1" target="_new">here</A>

Well it was in the wrong topic. Sorry about that.

Nice Intel and AMD users get a Cookie.... Yummy