P4 Prescott 64-bit edition available now!

C

coz

[H]ard|Gawd
Joined
Jan 11, 2002
Messages
1,664
Intel Pentium 4 "LGA775 64-Bit Prescott" 3.4F (800FSB) with HT Technology - Retail

So, Intel's desktop answer to AMD's 64-bit marketing machine is finally here! I'm not really that bothered but it's interesting news nonetheless. Ok, maybe in a couple of years time I'll be worried about 64-bit but not now. I wonder if this chip uses the new E-0 stepping tho? That fixes a lot of power issues and has other new features too. If I was going for a PrescHOT then it'd be an E-0 step for sure.
 
dude if this is true, than I might be looking more into the Intel side of things. And for the price, thats even better than AMD. The question now is if they OC as well as there 32bit brothers, hmmm very intresting.
 
The 3.20F (84W TDP) looks ok, but the power is pretty high for the 3.40F and 3.60F versions (115W TDP each):

ftp://download.intel.com/design/xeon/datashts/303128.pdf I know it says Xeon in the link, but the document is:
"Intel® Pentium® 4 Processor
Supporting Hyper-Threading
Technology

Datasheet
3.60F GHz, 3.40F GHz, 3.20F GHz on 90 nm Process in
775-land LGA Package and supporting Intel® Extended
Memory 64 Technology for single processor
workstations"

I'd wait for the 3.20F version.
 
time for amd to get rid of all those annoying banners all over the web stating "amd 64, the only windows compatable 64 bit processor..."


yay for intel!

long live the king!
 
err, intel sent me a dev-preview chip and some materials on it, and from what I can tell, it's not really 64-bit. It has a 64-bit memory controller, but it doesn't actually execute 64-bit code. I'll have to open up an Intel 925XCVK tomorrow and give it a try with XP64.

Another interesting point worth mentioning is that Intel was very insistant that the 925XCVK is the only board that will support it -- not even the P5AD2 which as everything else and the kitchen sink.
 
Intel may be saying that because there has to be a BIOS update to support the chips. The hardware of the P5AD2 is compatible, but the BIOS probably isn't. Whereas the Intel desktop board ships with the correct BIOS.
 
but can anyone else confirm that it's a 64-bit memory controller, but it doesn't actually execute 64-bit code?
 
I seriously doubt they would create a "64-bit Processor" which couldn't execute 64-bit code.

Already, the LGA775 has processors in 3 forms... E, J, and F.
 
Someone correct me if I'm wrong please, but I didn't think Intel was trying to move the memory controller onto the processor until this specific chip?
I don't remember any talk about the other LGA775 release P4 chips having onboard memory controllers. If that was handled through the North bridge still on standard 925/915 chipset, wouldn't it be obvious that this would probably cause problems/latencies/conflicts for a onchip memory controller if you were to run it in a board based on those chips?
Anyway if the above is the case as a quick read about the recent chipsets suggests to me, doesn't it stand to reason that Intel would need to rework their motherboard and chipset design somewhat to give the processor's onboard controller direct control of the ram and not some proxy control through the north bridge's memory controller?
 
potroast said:
but can anyone else confirm that it's a 64-bit memory controller, but it doesn't actually execute 64-bit code?
Click to expand...

That may refer to the fact that the Pentium 4's 64 bit code execution is through emulation and dual 32 bit registers. Believe it or not the Athlon 64 and the G5 are the same. The only native 64 bit processor that I know of is the Itanium.

The emulation is internal to the processor and they do execute 64 bit code. Just not as effeciently as a native processor. In this case the 64 bit part of their architecture is mainly for marketting reasons. As right now it serves very little purpose if any at all.

Although the 64 bit Prescott can in fact execute 64 bit code, thier implementation is different than AMD's X86-64 instructions and therefore not compatible with them. Windows XP Pro 64 bit Edition is older than Prescott. Since the EMT64 instructions weren't finalized or published when XP 64 was under the major part of it's developement, theres going to be issues running XP 64 on the 64 bit Prescott.

Microsoft is working on correcting the issues from what I've been reading.
 
Sir-Fragalot said:
That may refer to the fact that the Pentium 4's 64 bit code execution is through emulation and dual 32 bit registers. Believe it or not the Athlon 64 and the G5 are the same. The only native 64 bit processor that I know of is the Itanium.

The emulation is internal to the processor and they do execute 64 bit code. Just not as effeciently as a native processor. In this case the 64 bit part of their architecture is mainly for marketting reasons. As right now it serves very little purpose if any at all.

Although the 64 bit Prescott can in fact execute 64 bit code, thier implementation is different than AMD's X86-64 instructions and therefore not compatible with them. Windows XP Pro 64 bit Edition is older than Prescott. Since the EMT64 instructions weren't finalized or published when XP 64 was under the major part of it's developement, theres going to be issues running XP 64 on the 64 bit Prescott.

Microsoft is working on correcting the issues from what I've been reading.
Click to expand...


While it is true that memory addressing and some other parts of the Athlon 64 are not fully 64-bit, I wasn't aware that there had to be emulation for 64-bit to run correctly.

Is there any linkage you've found to support this? I'd be interested in reading it.
 
potroast said:
but can anyone else confirm that it's a 64-bit memory controller, but it doesn't actually execute 64-bit code?
Click to expand...

Umm the memory controller is on the northbridge on a P4, not the CPU so it is not referring to that, and the data bus has been 64 bit sense the original Pentium, (see:http://www.pcguide.com/ref/cpu/arch/extDataSize-c.html) so it is not referring to that.. It does execute 64 bit code, otherwise it would be no different from any pentium 4.

==>Lazn
 
Sir-Fragalot said:
That may refer to the fact that the Pentium 4's 64 bit code execution is through emulation and dual 32 bit registers. Believe it or not the Athlon 64 and the G5 are the same. The only native 64 bit processor that I know of is the Itanium.
Click to expand...
You're way off on virtually all of what you said.

The internal GPRs of the Athlon 64 and EM64T Xeons/Prescotts are 64-bit, plus x86-64 adds an extra 8 64-bit GPRs (R8-R15) and another 8 128-bit SSE/SSE2 registers (XMM8-XMM15) . The x86 instructions set has been expanded to allow for manipulation of 64-bit integer data (x87-style FP has been 64-80 bit for years and SSE2 has been 64-bit FP/int SIMD since the P4 came out). Both the Athlon 64s and EM64T Prescotts/Xeons operate on 64-bit instructions natively, not through any kind of emulation. No tricks, no emulation... the registers and instruction set were expanded. http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_24592.pdf

Memory addressing was only increased to 40-bit physical and 48-bit virtual (from 32-bit physical and 36-bit PAE), but that should not be a problem for a long time since even 48- bits offers 256TB of addressable space (or 40-bit = 16TB of physical address space). The reason not to go to 64-bit addressing space has to do with 2 reasons: 1) it's not necessary and 2) it bloats code size since more bits are required to store a 64-bit address than a 48-bit maximum address size. You may use that point to say that x86-64 isn't a 100% 64-bit architecture, but don't say something silly like it's emulation. :p

As far as application compatibility goes, EM64T is 100% compatible with AMD's x86-64 instruction set. The very minor differences are only a concern to OS writers since the two instructions that are missing are only for specialized task management (SAHF/LAHF... fast context switching/multitasking). Initially AMD dropped those instructions, but re-enabled again. Intel probably dropped the instructions when AMD did. Oops. See Tom Halfhill's articles about that for more details. The only OS affected was Linux, with a Kernel developer complaining that he had to write 2 paths for task switching.

I really hope you didn't pick some random post on ace's and accept that as anything more than a generally uninformed opinion.
 
pxc said:
You're way off on virtually all of what you said.

The internal GPRs of the Athlon 64 and EM64T Xeons/Prescotts are 64-bit, plus x86-64 adds an extra 8 64-bit GPRs (R8-R15) and another 8 128-bit SSE/SSE2 registers (XMM8-XMM15) . The x86 instructions set has been expanded to allow for manipulation of 64-bit integer data (x87-style FP has been 64-80 bit for years and SSE2 has been 64-bit FP/int SIMD since the P4 came out). Both the Athlon 64s and EM64T Prescotts/Xeons operate on 64-bit instructions natively, not through any kind of emulation. No tricks, no emulation... the registers and instruction set were expanded. http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_24592.pdf

Memory addressing was only increased to 40-bit physical and 48-bit virtual (from 32-bit physical and 36-bit PAE), but that should not be a problem for a long time since even 48- bits offers 256TB of addressable space (or 40-bit = 16TB of physical address space). The reason not to go to 64-bit addressing space has to do with 2 reasons: 1) it's not necessary and 2) it bloats code size since more bits are required to store a 64-bit address than a 48-bit maximum address size. You may use that point to say that x86-64 isn't a 100% 64-bit architecture, but don't say something silly like it's emulation. :p

As far as application compatibility goes, EM64T is 100% compatible with AMD's x86-64 instruction set. The very minor differences are only a concern to OS writers since the two instructions that are missing are only for specialized task management (SAHF/LAHF... fast context switching/multitasking). Initially AMD dropped those instructions, but re-enabled again. Intel probably dropped the instructions when AMD did. Oops. See Tom Halfhill's articles about that for more details. The only OS affected was Linux, with a Kernel developer complaining that he had to write 2 paths for task switching.

I really hope you didn't pick some random post on ace's and accept that as anything more than a generally uninformed opinion.
Click to expand...

/ set_ass_kissing_mode 1

Let me be your lackey... you are truly [H]

/ set_ass_kissing_mode 0
 
Warmonkey said:
/ set_ass_kissing_mode 1

Let me be your lackey... you are truly [H]

/ set_ass_kissing_mode 0
Click to expand...

Shouldn't you remove the comments from your code for them to be correctly executed?

:)

Code: 
set_ass_kicking_mode=1;
getcommentary();
unset_ass_kicking_mode();
:cool:
 
hehehe...

Well, what can i say, my designers gave me an easy to use console interface.
 
pxc said:
You're way off on virtually all of what you said.

The internal GPRs of the Athlon 64 and EM64T Xeons/Prescotts are 64-bit, plus x86-64 adds an extra 8 64-bit GPRs (R8-R15) and another 8 128-bit SSE/SSE2 registers (XMM8-XMM15) . The x86 instructions set has been expanded to allow for manipulation of 64-bit integer data (x87-style FP has been 64-80 bit for years and SSE2 has been 64-bit FP/int SIMD since the P4 came out). Both the Athlon 64s and EM64T Prescotts/Xeons operate on 64-bit instructions natively, not through any kind of emulation. No tricks, no emulation... the registers and instruction set were expanded. http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_24592.pdf

Memory addressing was only increased to 40-bit physical and 48-bit virtual (from 32-bit physical and 36-bit PAE), but that should not be a problem for a long time since even 48- bits offers 256TB of addressable space (or 40-bit = 16TB of physical address space). The reason not to go to 64-bit addressing space has to do with 2 reasons: 1) it's not necessary and 2) it bloats code size since more bits are required to store a 64-bit address than a 48-bit maximum address size. You may use that point to say that x86-64 isn't a 100% 64-bit architecture, but don't say something silly like it's emulation. :p

As far as application compatibility goes, EM64T is 100% compatible with AMD's x86-64 instruction set. The very minor differences are only a concern to OS writers since the two instructions that are missing are only for specialized task management (SAHF/LAHF... fast context switching/multitasking). Initially AMD dropped those instructions, but re-enabled again. Intel probably dropped the instructions when AMD did. Oops. See Tom Halfhill's articles about that for more details. The only OS affected was Linux, with a Kernel developer complaining that he had to write 2 paths for task switching.

I really hope you didn't pick some random post on ace's and accept that as anything more than a generally uninformed opinion.
Click to expand...

I don't remember where I read it. I did read the part about memory registers, but I read that it was dual 32 bit not 48 bit. That emulation was used to get 64bit memory registers. As far as code execution I must have totally misread that somewhere. I have no idea where. But I never read anything that contradicted what I read earlier. Until now. But what you said makes sense.

I stand corrected.
 
any reviews yet?

do u reckon they'll compare to the a64's in gaming?
 
I don't believe that the latest P4's with EM64T technology will compare much better than the 32bit P4 Prescotts have thus far. The reason for this is the architecture behind the P4. The 31-pipe architecture is innefficient in comparison to the AMD 64 processor which is why it has to be clocked to much higher in the first place to perform on the same level in games and applications (and don't tell me HT fixed the inherant inneficiency of the design either, cause HT is effectively a bandaid that helps it compensate for said inneficiencies). Clock for clock, the Athlon64's are doing more work and thus requiring less ghz power to get the job done. The other problem is the P4 architecture still has the memory controller on the northbridge. Well actually, I'm not certain thats as much a problem for P4's as it was for Athlon64's since A64's benefit greatly from significantly lower latencies that are achieved via the on-die memory controller. Since the P4 architecture already has large latencies built into its architecture (ie 31pipes to fill before any calculations take place thus causing huge delays if a read prediction is incorrect since even with HT at least half the pipeline will have to wait to be flushed and re-filled), significantly lower memory latencies from an on-die memory controller might not benefit it as much as we've seen from the AMD camp, but I'm sure it would give it some kind of boost anyway. Anyway, based on the information about the P4 EMT64 I've seen and read, its not going to be any different really for processing 32-bit code than the 32-bit Prescotts are.
 
CVNet1 said:
... The 31-pipe architecture is innefficient in comparison to the AMD 64 processor which is why it has to be clocked to much higher in the first place to perform on the same level ...
Click to expand...

I hate this "inefficient" argument.

Do what needs to be done to go fast. Whether you are fast (GHz) or wide (IPC), I don't care. Neither concept is inefficient on it's own. Some days the GHz seems to win out, and other days the IPC is more important, but after the dust settles they achieve the same performance. Now if AMD64 could be clocked at 4GHz without sacrificing anything, we'd have a winner. Same can be said for the P4, if you could bring the IPC up to drastic levels while keeping the clock speed sky-high.

Now if you're talking efficiency in other means, like power (how many joules does it take to load photoshop?), or code size (ARM Thumb comes to mind), those arguments make more sense. In the go-fast world, these sorts of things tend to get ignored or simply dealt with (giant heatsink and 2GB of RAM).
 
Are these the new chips intel released with the buffer overflow protection bit, stepping J I think they called it? Or are they just the old 64bit prescotts that they've kept away from the retail channel finally making their way here?
 
I can see why you might not like the "innefficient" argument, but I still think it holds a good deal of truth to it. In fact, from what I've been reading, Intel's been changing up the roadmaps a good deal recently. It seems like Intel has decided that the 4ghz+ clock rate isn't the best way to go either since they are now looking into dual core solutions and the Pentium-M (in a possible desktop type solution). But back to the Prescott, the discussion of how many joules (actually I'm going to talk about watts and thermal distribution) is very valid for the efficiency, because I'm looking at the solution as a whole package. The top of the line Prescotts as we all know have terribly high thermals in comparison to what we saw with Northwoods and the AMD64 processor lines. Its also pretty well known that the poor thermal performance is somewhat related to the 90nm die size, but more specifically is because of the Strained Silicon approach at this die size in conjunction with the transistor designs (creating high current leakages) that are required for 3.4+ghz operation. Consequently, the poor thermals and some trouble with poor yields is why we haven't seen Intel just ramping up the clock speed much since the beginning of this year.
Another point, I remember when Prescott originally came out clocked at 3.0 and 3.2 ghz and was performing slower than the P4 Northwood counterparts. Even now I think that is still the case if you have a Northwood and Prescott at the same clockspeed. But my point there is that if the efficiency arguement doesn't apply, then how do you explain that the Prescotts aren't as fast when clocked the same as the Northwood. The pipeline is simply too long to process information efficiently at lower clock speeds. Even at higher clockspeeds, its largely inefficient if the pipeline stalls. HT is the only thing that has enabled the processors performance to reclaim some of those lost clock cycles. But for those high clock speeds, Intel has to deal with poor thermal performance and transistor leakages that will continue to rise. So as a package, in order for Intel to get its Prescott design to do the same job in the same real time as the Athlon64, it must rely on higher and higher clockspeeds for the architecture resulting in poor yields, poorer thermals, and higher transistor leakages which would inevitably (and probably much sooner than we think) lead to a situation where it would be infeasible for Intel to continue ramping up the clock speed. In this situation what is Intel going to do with its high Ghz low IPC P4/Prescott line? Reading at ARSTechnica, it seems to me Intel is going to have dual core processing to increase performance (IPC) without increasing the clockspeed. Thus Intel is going to increase how efficiently they handle each clockcycle. So yes I think that given a full consideration of the package that is the P4 Prescott, Intels design is currently inefficient at achieving that performance which is on par with the AMD Athlon64, and because of that inefficiency, Intel is struggling with processors that generate much higher thermal ratings than the AMD64 line.
 
Intel's actually quite good at designing processors with high IPC. The Pentium M and Pentium III lines prove that.

Intel went with a higher speed lower IPC processor for marketting reasons. If you look at the Pentium M a 2.0GHz Pentium M is just as fast as pretty much everything else on the higher end scope. I might also point out that those chips have a lower FSB than Prescott's or Athlons. Yet they still keep pace with all but the 3.4GHz+ and AMD 3200+ offerings.

Intel stopped the Pentium III line for the reasons that they couldn't ramp up clock speeds on the P6 core. Now Intel's been able to bring those clock speeds up to the 2GHz range and with multiple cores on a single chip the old P6 architecture that comes from the Pentium Pro line is suddenly very viable again.

Performance is performance. It doesn't matter how you get there. Either IPC or MHz is fine. It's just now Intel has reached it's manufacturing ceiling on what it can do with MHz. So Intel is going to have to concentrate on IPC.
 
CVNet1 said:
I can see why you might not like the "innefficient" argument, but I still think it holds a good deal of truth to it. In fact, from what I've been reading, Intel's been changing up the roadmaps a good deal recently. It seems like Intel has decided that the 4ghz+ clock rate isn't the best way to go either since they are now looking into dual core solutions and the Pentium-M (in a possible desktop type solution). But back to the Prescott, the discussion of how many joules (actually I'm going to talk about watts and thermal distribution) is very valid for the efficiency, because I'm looking at the solution as a whole package. The top of the line Prescotts as we all know have terribly high thermals in comparison to what we saw with Northwoods and the AMD64 processor lines. Its also pretty well known that the poor thermal performance is somewhat related to the 90nm die size, but more specifically is because of the Strained Silicon approach at this die size in conjunction with the transistor designs (creating high current leakages) that are required for 3.4+ghz operation. Consequently, the poor thermals and some trouble with poor yields is why we haven't seen Intel just ramping up the clock speed much since the beginning of this year.
Another point, I remember when Prescott originally came out clocked at 3.0 and 3.2 ghz and was performing slower than the P4 Northwood counterparts. Even now I think that is still the case if you have a Northwood and Prescott at the same clockspeed. But my point there is that if the efficiency arguement doesn't apply, then how do you explain that the Prescotts aren't as fast when clocked the same as the Northwood. The pipeline is simply too long to process information efficiently at lower clock speeds. Even at higher clockspeeds, its largely inefficient if the pipeline stalls. HT is the only thing that has enabled the processors performance to reclaim some of those lost clock cycles. But for those high clock speeds, Intel has to deal with poor thermal performance and transistor leakages that will continue to rise. So as a package, in order for Intel to get its Prescott design to do the same job in the same real time as the Athlon64, it must rely on higher and higher clockspeeds for the architecture resulting in poor yields, poorer thermals, and higher transistor leakages which would inevitably (and probably much sooner than we think) lead to a situation where it would be infeasible for Intel to continue ramping up the clock speed. In this situation what is Intel going to do with its high Ghz low IPC P4/Prescott line? Reading at ARSTechnica, it seems to me Intel is going to have dual core processing to increase performance (IPC) without increasing the clockspeed. Thus Intel is going to increase how efficiently they handle each clockcycle. So yes I think that given a full consideration of the package that is the P4 Prescott, Intels design is currently inefficient at achieving that performance which is on par with the AMD Athlon64, and because of that inefficiency, Intel is struggling with processors that generate much higher thermal ratings than the AMD64 line.
Click to expand...

A high IPC does not equal high efficency. If that were the case the Itanium would be the most effecient processor available today.. but I don't see any Itanium laptops. (an 800mhz Itanium can keep up with multi GHZ x-86 cores in many benchmarks)

High efficency has only to do with joules (or watts if you prefer, though watts are an electricity only measurement joules are valid through all calculations) per instruction.

Calculate that out, and I bet a Athlon XP is better than a northwood which is better than a A64 which is better than a Prescott, which is close to an Itanium. But a Pentium M kickes everyone's ass.

==>Lazn
 
Lazn_Work said:
....

But a Pentium M kickes everyone's ass.

==>Lazn
Click to expand...

(Lazn, I agree totally with your post. Now to be sarcastic :)

The real winner if we start talking joules/instruction is something stupid like the processor in your calculator watch, or more reasonably the ARM(tm) architecture. I work with ARM CPU's, and I have a 400MHz beast that draws less than 1 Watt at full power with 256MB of SDRAM and multiple ethernet ports. Still, I don't play Doom3 on that.

CVNet1, you are sill missing the point of the word "inefficient" (and you also continue to misspell it). You continue to talk about "efficiency" per clock cycle. That doesn't make any sense. I agree with your argument about power consumption though. I'm not a fan of the current Prescott's and probably never will be, due to that fact at least.
 
Lazn_Work said:
though watts are an electricity only measurement joules are valid through all calculations) per instruction.
Click to expand...

A Watt is nothing more than 1J/s. Power is power, be it electrical, or mechanical, or whatever.
 
Well, you guys sure like to jump on each other for little mistakes. Either way i'm being more efficient in posting this than you guys since I'm doing so on my super duper efficient 2ghz pentium M laptop. Course since my pc mostly idle it is only clocked at 600mhz right now, so it is even more super duper efficient.

Ok, anyways, I have been to several internal intel meetings regarding performance vs power consumption. Actually their most efficient chip designed was the 486. From there the performance increase has been linear, but the power increase has been exponential.

So grab on to your old 486 boxes and make luv to them, cause they are probably the best in perf/watt we shall ever see :).
 
CyberCRAP said:
So grab on to your old 486 boxes and make luv to them, cause they are probably the best in perf/watt we shall ever see :).
Click to expand...

Check out the PDA-type processors. They're actually starting to be very fast (520MHz and above), and battery technology holds them firmly under one watt, usually much lower.

That beats a 486 for power efficiency.


P.S. nice laptop.
 
spock said:
Check out the PDA-type processors. They're actually starting to be very fast (520MHz and above), and battery technology holds them firmly under one watt, usually much lower.

That beats a 486 for power efficiency.


P.S. nice laptop.
Click to expand...


mhz != speed

I have an axim x30, 624 mhz, its still "slow" by desktop standards, probabily equivalent to a 133 Pentium. but in my hand, thats not bad considering.
 
kronchev said:
mhz != speed

I have an axim x30, 624 mhz, its still "slow" by desktop standards, probabily equivalent to a 133 Pentium. but in my hand, thats not bad considering.
Click to expand...

You're right of course, but I think you might be underestimating a little. It really depends what you ask it to do. Most PDA processors have no FPU, so it's gaming performance will be near-zero. Integer math, however, is quite fast on them.

It's still way better than a 486 for performance per watt.
 
I have a ABIT AA8 Duramax board with 925 chipset. Will this new 64bit processor work on it ? or will we need new boards for this new proc. ?
 
I believe the new chip needs a bios update for 64bit, but any board will be able to run the chip with or without the update.
 
ahh sweet this is amazing news... why isnt it hyped and brought into the news ? weird i mean a 64bit processor....
 
Anymore info on this? Will it work with the current 915P chipset? I am about to order a 3.4ghz prescott and it may as well be a 64bit if they are out.

Thanks!
 
Anymore info on this? Will it work with the current 915P chipset? I am about to order a 3.4ghz prescott and it may as well be a 64bit if they are out.
Click to expand...

I think only the 925 chipset will work with it, but I'm not positive,
 
According to Intel's site, the 925X of course supports EMT64, however no mention of support for the 915X chipsets and EMT64.

It may actually as it is a derived from the same basic chip design. It may be something like Intel PAT technology. Something the I875 had but the I865 didn't. Some board makers could find a work around to use EMT64 with I925x.

On the safe side though, you should make sure you get a 925X based board. Which means you must also get DDR2 memory.
 
This is weird how come there is no reviewing this :S there must be like no performance gain
 
You must log in or register to reply here.
Back
Top