Forgot your password?
typodupeerror
Intel Hardware

Pentium 4 6XX Sequence and New EE P4s Launched 198

Posted by timothy
from the james-bond-stole-this-stuff-in-1963 dept.
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."
This discussion has been archived. No new comments can be posted.

Pentium 4 6XX Sequence and New EE P4s Launched

Comments Filter:
  • by Anonymous Coward on Sunday February 20, 2005 @06:39AM (#11727874)
    The Tech Report also has an excellent writeup <URL:http://techreport.com/reviews/2005q1/pentium4 -600/index.x?pg=1>

  • by Anonymous Coward on Sunday February 20, 2005 @06:51AM (#11727903)

    Turn on HTML formatting next time, brother.

    http://techreport.com/reviews/2005q1/pentium4-600/ index.x?pg=1 [techreport.com]

  • Correction (Score:2, Informative)

    by Compact Dick (518888) on Sunday February 20, 2005 @06:51AM (#11727907) Homepage
    That's Shouldn't they have, not " Shouldn't they of".

    Cheers,
    CD
  • by Anonymous Coward on Sunday February 20, 2005 @06:52AM (#11727908)
    TR is good as usual. Here is another good one:

    http://www.hardcoreware.net/reviews/review-263-1.h tm [hardcoreware.net]
  • by Anonymous Coward on Sunday February 20, 2005 @07:16AM (#11727953)
    Binaries are interchangeable. The only differences are certain platform features which have always been different between AMD and Intel.

    In other word, you could say it's 100% compatible. Or 100% ripoff. :-)

  • Re:'lagging a bit' (Score:2, Informative)

    by Grounded0 (703575) <admingz@luukku.com> on Sunday February 20, 2005 @07:26AM (#11727971) Homepage Journal
    MIPS R4000 and Alpha 21064 were 64 bit processors back in 1992.
  • Re:2MB Cache? (Score:5, Informative)

    by Grounded0 (703575) <admingz@luukku.com> on Sunday February 20, 2005 @07:34AM (#11727988) Homepage Journal
    MIPS R12000 system that's sitting on my desk has 8MB of L2 cache. And yes, it's circa 2000.
  • by Grounded0 (703575) <admingz@luukku.com> on Sunday February 20, 2005 @07:46AM (#11728012) Homepage Journal
    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.
  • by Anonymous Coward on Sunday February 20, 2005 @08:02AM (#11728035)
    Gentoo has some nice benchmarks on this. You can find it in the AMD 64 FAQ found here [gentoo.org] . Where also they link to another forum post containing some very interesting performance differences, found here [gentoo.org].
  • by inflex (123318) on Sunday February 20, 2005 @08:06AM (#11728041) Homepage Journal
    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.
  • Re:'lagging a bit' (Score:3, Informative)

    by jizmonkey (594430) on Sunday February 20, 2005 @08:22AM (#11728067)
    You don't know what you are talking about. The Jaguar used funny math to get the "64-bit" number. Everybody knows that a 64-bit blitter does not a 64-bit system make, and so the only people to bring it up (like you) do so to build strawmen. The CPU of the Jaguar was a Motorola 68000.

    The page you link to, by making this analogy, shows that its author doesn't know jack about shit, either.

    The Nintendo 64 had an R4300i CPU. It was fully 64-bit. It addressed 64 bits (40 physical), the same as high-end SGI workstations. It had 64-bit integer registers and 64-bit floating point registers. The system had a 500MB/sec bus to the Rambus memory. There is only one "32-bit" part about the R4300i, and that was the system interface. But the memory connected to the RCP, not the CPU (and the RCP, obviously, had heavy bandwidth requirements of its own to do the graphics rendering and sound), and so it would have been wasteful to run the same wide bus between the CPU and RCP.

    The RCP was another 64-bit processor, also a customized MIPS chip.

    It is true that the R4300i had a 32-bit compatibility mode which was often used in games, but that is irrelevant. Most people run 32-bit software on their Athlon 64, too.

  • by cyclocommuter (762131) on Sunday February 20, 2005 @10:21AM (#11728310)
    Over at X-bit labs, they have a more comprehensive review of these chips' Thermal characteristics and power consumption [xbitlabs.com]. You will still need a big PSU and a good HSF if you are going to multitask or play games on these puppies.
  • by Anonymous Coward on Sunday February 20, 2005 @11:01AM (#11728474)
    Intel President Paul Otellini said on Jan 10th in his blog-
    "While I hate losing share, the reality is that our competitor has a very strong product offering"

    Further details on the story can be found here [siliconvalley.com]

  • Re:64-bit GPUs (Score:5, Informative)

    by cnettel (836611) on Sunday February 20, 2005 @12:14PM (#11728783)
    You're wrong. Or, rather, "bitness" is a very silly measure. In a general purpose chip, you can measure the maximum word size for single operations.

    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.

  • by Anonymous Coward on Sunday February 20, 2005 @12:59PM (#11728997)
    Ok, the extensions are not compatible, right? So why did intel put them in there?

    Sell those chips now and gain market share. That is it, nothing more or less. Those extension don't do anything at this point. Its all about adoption in the market.

    Its business people not technology.
  • by bani (467531) on Monday February 21, 2005 @08:15AM (#11734929)
    actually what happened with itanium is intel made a number of huge gambles on technology.

    in order for itanium to be successful, every single one of them had to pan out.

    what happened is virtually none of them panned out.

    intel blew their load on a high risk gamble, and lost.

Never test for an error condition you don't know how to handle. -- Steinbach

Working...