Pentium 4 Question

[Comedian]

This is an extra credit question,

How much memory can a pentium 4 processor address.

How many address lines does it have?

 

[Rtstrider]

up to 4 gigs of ram on the 32 bit and I believe 132 gigs of ram on the 64 bit

 

[Stugots]

4gb

 

[visaris]

No, the P4 can address up to 64GB of memory with PAE. Now, this will be terribly slow, but it will work.

http://en.wikipedia.org/wiki/PAE

 

[pstang]

up to 4 gigs of ram on the 32 bit and I believe 132 gigs of ram on the 64 bit

now i dont know about the P4 w/ em64t, but the a64 can use up to 256 terabytes of ram

from wikipedia: "AMD64 architecture can address up to 256 terabytes of memory in its current implementations. This is compared to just 4 GB for x86-32, only half of which is available to applications under the most common versions of Microsoft Windows. Future implementations of the AMD64 architecture may provide up to 2 exbytes"

 

[ScHpAnKy]

now i dont know about the P4 w/ em64t, but the a64 can use up to 256 terabytes of ram

from wikipedia: "AMD64 architecture can address up to 256 terabytes of memory in its current implementations. This is compared to just 4 GB for x86-32, only half of which is available to applications under the most common versions of Microsoft Windows. Future implementations of the AMD64 architecture may provide up to 2 exbytes"

It's funny, too, because 4 Dimms on all but later revisions of the AMD64 Architectures will run that extra memory at 2T and DDR333, haha

 

[pstang]

It's funny, too, because 4 Dimms on all but later revisions of the AMD64 Architectures will run that extra memory at 2T and DDR333, haha

yeah, could you imagine the timings you would have to run if you actually had 256TB of ram

 

[robberbaron]

yeah, could you imagine the timings you would have to run if you actually had 256TB of ram

It wouldn't be too bad. Make a gigantic motherboard with a ton of opterons, and latency shouldnt be so bad if the ram is divided amongst them. Though, 256TB... that sure is a lot.

 

[Scali]

No, the P4 can address up to 64GB of memory with PAE. Now, this will be terribly slow, but it will work.

http://en.wikipedia.org/wiki/PAE

At least one of them got the amount of memory right (32 bit pointer + 4 bit segment == 36 bit addressing -> 64 gb).
Too bad it had to be accompanied by some misinformed propaganda.
The real story is that PAE works with segments of 4 gb each, much like how 16 bit used to work with segments of 64k each.
Switching segments takes a bit of overhead, but as long as you stay in a single segment, there is no performance loss. It won't get "terribly slow" unless you actually start doing random access across two or more segments and have to switch segments a lot.

 

[Donnie27]

This is an extra credit question,

How much memory can a pentium 4 processor address.

How many address lines does it have?

Each time I read this forum, it seems like there are a bunch of AMD Employees (commonly called Plants)hanging out here. The spin is so consistanly Pro AMD it is unreal. Surely the posters here are smart enough to know Intel sells 32 and 64bit P4/P4 Xeon processors that address different amounts of RAM. Even as one poster points out "x86-32" while knowing full and well Intel also uses AMD's x86-64.

Donnie27

 

[visaris]

Too bad it had to be accompanied by some misinformed propaganda. ... It won't get "terribly slow" unless you actually start doing random access across two or more segments and have to switch segments a lot.

Like if you had a 32GB+ database serving more or less random reqests... or a few processes each using 4GB or more... For real world useage, I think it's fair to call PAE slow. Perhaps even really slow. Although, on some level you are right. If tha OS is written well, and one writes their applications with PAE and the OS in mind, performance might not be too bad. I still think PAE is horrible for adding >4GB in general. Might have been good in the pentium days, but not any more.

 

[Scali]

Like if you had a 32GB+ database serving more or less random reqests...

Probably not. The requests themselves probably have much larger overhead than the actual segment switching. Heck, oftentimes databases are too large to fit in memory anyway, so they are accessed from disk. PAE is certainly orders of magnitude faster than harddisks, so it would still improve performance considerably.

or a few processes each using 4GB or more...

No, because you need to do a context switch between processes anyway. PAE doesn't make a lot of difference there. It still depends on the applications themselves and how often they need to switch segments.

For real world useage, I think it's fair to call PAE slow. Perhaps even really slow. Although, on some level you are right. If tha OS is written well, and one writes their applications with PAE and the OS in mind, performance might not be too bad. I still think PAE is horrible for adding >4GB in general. Might have been good in the pentium days, but not any more.

I think you don't understand what PAE is. You HAVE to write applications with PAE and the OS in mind, it's the only way to make use of it. Looks like you're just making uninformed guesses about PAE and performance.
Obviously EM64T is a better solution, but that doesn't mean PAE is 'horrible'.
Oh, it didn't exist in the Pentium days by the way. Pentium Pro was the first model to support it.

 

[visaris]

Well, you make good points. I can see PAE being a huge advantage for databases, esspecially when it would allow them to get data off the disc.

I think you don't understand what PAE is. You HAVE to write applications with PAE and the OS in mind, it's the only way to make use of it.

Though, this isn't one of them. One does not have to write PAE apps specifically. There are some implementations where the OS handles all the PAE work. Linux has support for this, and there are other OS's as well (though I'm not familiar with them). Now, it is true that this setup only increases the physical address space, but it's still worth it. This is the context where my remarks about performance fit a bit better, though, again, if apps are aware of PAE you're right that the overhead wouldn't be that much of a problem for a good many cases. Though again. I don't see why you are so bothered when I say it's really slow. Compared to AMD64/EM64T it is really slow.

 

[Scali]

One does not have to write PAE apps specifically. There are some implementations where the OS handles all the PAE work. Linux has support for this, and there are other OS's as well (though I'm not familiar with them).

Please explain to me how that would work. Without modifying a standard 32-bit program, there are no pointers that are larger than 32 bit, hence it is impossible to address anything beyond 4 gb, you still have a physical address space of 32 bit, as far as the program is concerned.
The only thing PAE can do for apps that do not specifically use it, is to create each program in a different segment, so you can have multiple programs, each having access to the full 4 gb in their segment, rather than having to share the memory by paging. But as mentioned before, this will not require extra segment switching outside of the context switches themselves, so there is no extra performance cost.

Though again. I don't see why you are so bothered when I say it's really slow. Compared to AMD64/EM64T it is really slow.

Well, you'll have to quantify 'really slow' then. Because the way you described it, with words like 'terrible' and 'horrible', it sounded to me that PAE is absolutely useless and is better left unused. I think that's a huge exaggeration. It's still an improvement over standard 32-bit.

 

[visaris]

Please explain to me how that would work. Without modifying a standard 32-bit program, there are no pointers that are larger than 32 bit, hence it is impossible to address anything beyond 4 gb, you still have a physical address space of 32 bit, as far as the program is concerned.

Yes. Linux will support PAE in the following fashion (possibly others as well). Linux will create an environment such that the address space is effectively 36-bits physical, and 32-bits virtual. I think is more or less what you describe below. I swear I read somewhere that windows can do this as well, but I don't know if IRC or not.

The only thing PAE can do for apps that do not specifically use it, is to create each program in a different segment, so you can have multiple programs, each having access to the full 4 gb in their segment, rather than having to share the memory by paging. But as mentioned before, this will not require extra segment switching outside of the context switches themselves, so there is no extra performance cost.

Well, you'll have to quantify 'really slow' then. Because the way you described it, with words like 'terrible' and 'horrible', it sounded to me that PAE is absolutely useless and is better left unused. I think that's a huge exaggeration. It's still an improvement over standard 32-bit.

Bah. I don't think either of us are all that fond of benchmarks so let's just leave it at "It's slower than current technology, so why use it?"

 

[Scali]

Yes. Linux will support PAE in the following fashion (possibly others as well). Linux will create an environment such that the address space is effectively 36-bits physical, and 32-bits virtual. I think is more or less what you describe below. I swear I read somewhere that windows can do this as well, but I don't know if IRC or not.

Yes, but that's not what you were talking about at first. Each program will still have a 32 bit address space, so it can not ever address more than 4 gb that way. If you want to use that feature of PAE (like you suggested with your examples of a 32+ gb database or processes that use more than 4 gb), you MUST specifically write your program to do so.

Bah. I don't think either of us are all that fond of benchmarks so let's just leave it at "It's slower than current technology, so why use it?"

If that is true, then yes. However, there are plenty of machines in the world, that have not been upgraded to 64-bit ones yet, and have been happily running in PAE mode for years. If you don't have 64-bit, but do have PAE, then there's a good reason to use it.
In Windows you can enable it with just a switch in boot.ini.

 

[visaris]

Yes, but that's not what you were talking about at first. Each program will still have a 32 bit address space, so it can not ever address more than 4 gb that way. If you want to use that feature of PAE (like you suggested with your examples of a 32+ gb database or processes that use more than 4 gb), you MUST specifically write your program to do so.

Well, we can sit here all day and and find ways to find faults in what the other is saying, but really that's just a waste of time. So to come up with an unfair (but technically correct) way to prove that what I was saying isn't necesserily wrong, consider a database implemented with multiple processes, each with their own 4GB segment. This would run under linux's kernel PAE mode, and would not need to be written specifically for PAE. So, from this odd implementation, one could conclude that you're statement that an app "must" be written for PAE is incorrect... Now, you could argue that this multi-process model doesn't really slow anything down because there will be context switches anyways, etc, etc. Though, again, we're just wasting our time fighting about it.

If that is true, then yes. However, there are plenty of machines in the world, that have not been upgraded to 64-bit ones yet, and have been happily running in PAE mode for years. If you don't have 64-bit, but do have PAE, then there's a good reason to use it. In Windows you can enable it with just a switch in boot.ini.

I realize that many companies hold on to legacy hardware for much longer than they should. And I realize that PAE might be a great solution for them, but for any new systems being built, I just can't see PAE being a competitor to AMD64/EM64T at all. These reasons lead me to the conclusion that PAE is lame for all current intents and purposes.

 

[Scali]

consider a database implemented with multiple processes, each with their own 4GB segment.

How would that work then? You want multiple processes to work as one big database server? Then you'll get a lot of synchronization overhead, and obviously the application needs to be designed to be able to do this, which I don't think any database server actually is (it only makes sense this way if you actually have PAE, so you could argue that it would still be written for PAE).
Looks like you're going out of your way to try and talk your way out of it, but you can't.
There's no way to use more than 4 gb on a system with a 32-bit app unless you specifically build in some kind of PAE support, either directly or indirectly.

I just can't see PAE being a competitor to AMD64/EM64T at all. These reasons lead me to the conclusion that PAE is lame for all current intents and purposes.

Obviously it's not a competitor. It's a technology that's been around since 1996, and it is now being replaced by EM64T.

 

[visaris]

How would that work then? You want multiple processes to work as one big database server? Then you'll get a lot of synchronization overhead, and obviously the application needs to be designed to be able to do this, which I don't think any database server actually is (it only makes sense this way if you actually have PAE, so you could argue that it would still be written for PAE).
Looks like you're going out of your way to try and talk your way out of it, but you can't.
There's no way to use more than 4 gb on a system with a 32-bit app unless you specifically build in some kind of PAE support, either directly or indirectly.

Well, again, I think I called my multiprocess example unfair myself. There is really no reason for you to restate that. Though, on the other hand, you made the claim that PAE is worth the overhead to get things off disc. Here, I make the claim that PAE (from the OS) and context switches/synchronization from multiple processes is worth getting things off disc. (I don't see how you could possibly dissagree with that).

Obviously it's not a competitor. It's a technology that's been around since 1996, and it is now being replaced by EM64T.

Hey, that was the point of my comment form the get go. I don't know why you insisted on making a big deal about it.

 

[Scali]

Hey, that was the point of my comment form the get go. I don't know why you insisted on making a big deal about it.

Well, the question was how much memory the P4 can address. You answered 64 gb, and added that it was terribly slow.
Since you said it was the maximum, I suppose we are assuming a processor that supports PAE, but not EM64T. In which case using PAE is not actually terribly slow, but often faster than not using PAE, since that would mean 32-bit addressing, and only 4 gb max.

 

[BlindedByScience]

Each time I read this forum, it seems like there are a bunch of AMD Employees (commonly called Plants)hanging out here. The spin is so consistanly Pro AMD it is unreal.

< begin_threadcrap >

This forum is currently getting lots of attention. Efforts are being made to end the bulk of the flaming, thread crapping, and trolling. We're working on it.....

< end_threadcrap >

Thanks - B.B.S.