Slashdot Mirror
Pentium 4 6XX Sequence and New EE P4s Launched
Mojo-Dog writes "Today Intel took the wraps off their new
Pentium 4 Processors with EM64T extensions for 64-bit computing. The
Pentium 4 6XX Sequence and Pentium 4 3.73GHz are based on Prescott 2M cores with
a full 2MB of on-chip L2 cache as well.
HotHardware.com has a full review with benchmarks posted of these new P4s,
many of which also offer Intel's SpeedStep technology for power savings and
improved thermals, which has been available in Pentium Mobile CPUs for some time
now."
"It's no secret that Intel has occassionally been playing a bit of catchup this year in the desktop and workstation processor arena"
No kidding. Nintendo had a 64 bit processor back in like, '96.
Don't you mean.. BIZZARO!
and just in time for Windows XP 64-bit!
how lucky!
And how much did intel pay for this story on slashdot . It reads like a marketing blurb
I think you misunderstand the way stories work on Slashdot. The first one is free. Intel has to pay for the duplicate story six hours from now.
I certify that I, anonymous coward, have reviewed this article in comparison to other recent articles and have found it to NOT be a dupe.
This certification provided 'as is', all guarantees and warrantees are disclaimed.
This has been a public service posting.
Shouldn't they of released their space heaters at the *beginning* of Winter?
Your hair look like poop, Bob! - Wanker.
Quick summary for gamers:
This P4 still lags behind the Athlon FX-55 and 64 4000+ for Doom3, HL2, UT2004, and the general 3dMark benchmark. Pricewatch has the FX-55 at 900$ US and the 64 4000 at 620$, which is cheaper than the best chip of the bunch at 999$. Granted, video cards are probably the biggest system decision for gamers, but if CPUs figure into your decision, you might want to consider the comparisons.
I have been trying to find out what the performance of the AMD and Intel chips is really like with 64 bit apps on a 64 bit OS and have yet to find anything that covers it. This article as usual goes on about 32 bit apps on a 64 bit OS which really doesn't help. I want to know if the Intel implementation is as efficient as AMDs and this would be easy enough with Linux but none of these reviews ever consider running on Linux. Just saying that 64 bit support isn't an issue at the moment doesn't cut it, I want to know now!
"I have the attention span of a strobe lit goldfish, please get to the point quickly!"
MIPS R12000 system that's sitting on my desk has 8MB of L2 cache. And yes, it's circa 2000.
IRC: Grounded0 @ IRCnet. "I was lucky get into computers when it was very young & idealistic industry" -Steve Jobs
Basically they're just IA-32 architecture without it's most worst design errors.
1. 8 registers increased to 16 (it still sucks compared to SPARC's 128).
2. Larger addressing width (eg. can allocate more than 4GB of memory limited by 32-bit architectures). Alpha and MIPS had this capability in 1992.
3. NX bit (can prevent buffer overflows). Has been available for ages on good CPU architectures.
IRC: Grounded0 @ IRCnet. "I was lucky get into computers when it was very young & idealistic industry" -Steve Jobs
Normally I don't pay much attention to these reviews, but damn this review smacked of Intel fanboyism and anti-AMD'ism. In summary, the comments fell into two catagories:
1. If Intel beat the AMD in a test
"Once again it's game over for AMD"
2. If AMD beats Intel in a test
"AMD struggles to keep ahead of Intel in this test"
I thought at first it was just a one off comment - but the almost all of the evaluations were like that.
Obviously we each tend to have a preference for one brand over another but please can we have consistent commenting.
Paul.
wow... the name really does reflect the stuff they cover
Item 2 isn't a "design error", it's a trade-off at any moment in time whether you support 64-bit addressing, doing so means a lot more transistors, and if (as with Intel) most of your customers are buying mid-range desktop machines that's a bad trade in 1992, in fact it was still a bad trade as recently as 5 years ago.
Item 3 is an improvement, but you mis-described NX, it doesn't "prevent buffer overflows" at all. It's a _marginal_ defense again deliberate stack smash attacks in which executable code is written during a buffer overflow. Buffer overflows have been used by Black Hats quite happily on Alpha, MIPS etc all these years despite non-executable stacks. It remains to be seen whether the development cost for this feature pays for itself in terms of raising the bar for black hats.
Item 1 is a trade-off again, but one that Intel should have made years ago, perhaps when they designed the 386. 128 registers means a lot more silicon, yet many inner loops will never use more than a dozen or so registers, meaning you either make price/performance worse, or you sacrifice something else (maybe vector instructions) to keep costs down. Every designer makes their own decisions here, and they're validated in the market. Eight wasn't enough, Sixteen is definitely closer to the sweet spot.
AMD made good trade offs with x86-64, they were rewarded in the marketplace and Intel are jumping on the same bandwagon now with EM64T.
Then, you realize that the current SSE/3Dnow etc stuff will actually handle 128-bit data.
Then, you can think that you should measure the bandwidth of the memory bus. With dual channels, that's generally 128 bits now for CPUs, but for Intel, the memory bus is of course still a part of the chipset. Most GPUs top out at 256, with lower counts and basically the same architecture for the cheaper models. The front-side bus in Intel chips is 64-bit, but running on a higher frequency. Also, most accesses, IIRC, are aligned to be the size of one cache line - 64 bytes or 512 bits. Also, note that the 8088 was an 8-bit CPU and the 80386 sx a 16-bit CPU by this definition. Obviously not what we want.
Finally, we can measure it by the addressing model. This makes some sense and then we also get to the result that AMD64 was the first x86-like ISA to achieve 64-bit flat space addressing. The "flat space" requirement is important, as we want to consider the 8086 (/8088) 16-bit and not 20-bit (16-bit segment + 16-bit offset with locked segment spacing). In this area, many GPUs are tailored to their actual memory capacity. Why should we waste addressing bits and consequentially lines on stuff we can't use?
By this definition, a modern GPU isn't "even" 32-bit, but why the heck should we care. The number of bits as a performance metric is stupid unless one has to take extra measures to avoid the boundary. That was the case in 16-bit x86 code, and is currently the case in some heavy-iron 32-bit code. The number of bits "of" a GPU is not a relevant metric.