Slashdot Mirror
Intel Quietly Introduces 3.8GHz P4
BatonRogue writes "I didn't see this anywhere else, but it looks like Intel has quietly launched their Pentium 4 570J running at 3.8GHz. The J denotes Intel's Execute Disable Bit support, which they have also quietly introduced (it seems to save face of being 2nd to support it behind AMD). AnandTech seems to be the only place to have a review of the 570J. It performs reasonably well and even better than AMD in some areas, while falling behind in things like games. AnandTech has a nice one page benchmark comparison of the 570J to AMD's 4000+ as a quick reference."
I can't help but be amused at the way Intel have had to "sneak" the fastest model of their Flagship processor out of the door.
Does anybody remember a few years ago, the Athlon was outperforming anything Intel had to offer, yet they still claimed it was only competing with the Celeron.
Can someone justify that they compared Intel's 3.8 Ghz to AMD 4000+ (4 Ghz equivalent, theorically)? Maybe they wanted to compare both company highest speed CPU... anyway, the only positive side I see in these high speed CPU is that they'll drive prices of their (somewhat) slower counterpart down... the AMD 3500+ is already at a very interesting price/performance ratio, it can only get better... and HL2 is only days away!
Eureka Science News - automatically updated
while falling behind in things like games.
Perhaps that's why it was quietly introduced? Gaming is really the only reason for a CPU upgrade these days. Knowing that AMD would achieve another victory in that area, why would they spend money promoting yet another little bump to the P4's clock speed? My guess is that they're waiting for the real kicker; this is just something to keep their heads above the water until it's ready.
I once attended a lecture by one of the designers from AMD. He said, that the clock speed of the processor was a key selling point. In reality, all the development that went into making processors operate at a higher clock cycle could be spent in much better ways, making better and more efficient processors. But - alas - efficiency doesn't sell. High numbers on a package does.
Anyway, does any of you actually have a specific need for high frequency processors? Most of the projects I've been working on always had other bottle necks, preventing me from utilizing the CPU completly.
Underholdning.info
Intel's plans for a quiet introduction goes down the drain.
for a grad student at work (i work IT for the engineering college) and the grad student insisted on intel. I warned him that intels run hotter and louder (because they need more cooling) but he said intel anyways. Well once i delivered the machine to him, the first thing he said was "wow that thing is loud". I used a boxed intel cpu (which comes with the heatsink and fan) and when you put it under load, you can hear it clear across the room. Intel's heat problem is just ridiciously, and i am afraid to even hear what a 3.8 ghz would sound like when you ran it full steam.
Lawyers, MBA's, RIAA? A jedi fears not these things!
Look at the power consumption difference between this new P4 and the Athlon 64. It's big enough between the 90nm P4's and 130nm A64's, but a 90nm P4 system uses nearly twice the juice of a 90nm A64. Mind you, that's the difference between entire systems, so the consumption difference between just the CPUs is even more extreme.
Imagine a Beowulf cluster of these...
For a moment there I read "Executive Disable" bit. I'd have bought that gadget in a minute!
Cool. This should make my Word 97 fly.
A 3.8ghz P4 chip out in time for people who need an extra computer and an extra space heater.
"Some fight for law. Some fight for justice. What will you fight for? One day, you will see."
In fact, the only thing anyone noticed was the rise in ambient air temperature.
I blame Intel for global warming
I find that my 2.0 Ghz can hardly heat the room as quickly as I'd like it to. Maybe if I get the new Intel 3.6 Ghz, I could also have the added benefit of toasting marshmallows on it.
A blog like any other.
If this were a Linux comparison, I'd probably agree with you. But as it stands, outside of the Mozilla test, I saw almost entirely commercial Windows software, which you don't have the option of compiling yourself.
While a Linux comparison might give you a better idea of the raw capability of each processor, keep in mind that Windows has a 90% marketshare, and as such, the way Anandtech tests is closer to "real world" performance for most people.
The benchmark referenced in this article gives Intel a big break by not comparing the Athlon 64 in native 64 bit mode. The few articles that do typically don't come right out and show the graphs side by side with Intel. 64 bit support makes a big difference in an increasing number of applications.
Another important fact - a socket 939 based motherboard purchased today should accept a dual core Athlon 64 in about a year. The dual channel memory controller in the 939 version means there will be plenty of memory bandwidth for that upgrade.
Encoding and transcoding video and audio are two great examples of CPU intensive work that aren't "games".
I run natively compiled Gentoo on my Athlon 64 system.
...successfully introduces the first integrated I/O chipset which can sync up all critical peripherals to be on the same bus speed. Video cards and CPUs far exceed any processing capacities provided by memory or storage components. While there still may not be the "killer app" to justify all that extra power, it will allow the respective company to temporarily get a hearty headstart in the dick-waving contest.
There are a huge number of yeast infections in this county. Probably because we're downriver from the bread factory.
``Intel's Execute Disable Bit support, which they have also quietly introduced (it seems to save face of being 2nd to support it behind AMD)''
IIRC, VIA and Transmeta already support this. And, of course, all Real CPUs have supported it for years.
Please correct me if I got my facts wrong.
Neither. At least fourth, possibly not even in the points...
Back in atleast 1980 (and probably earlier), according to my VMS 2.0 Source listings[1] (no, it's not open source, you can't have it), the VAX processor supported no-execute.
Each program is made up of PSECTs (program sections), which have various flags which specify the properties of the memory section when the program is loaded into a processes virtual address space. Such flags as RD and WRT specify memory protection. Flags such as SHR specify whether pages can be shared among processes, and the EXE flag specifies whether a page can be executed. There are a bunch of other flags, concerned with whether code is position independant (PIC), or alter it's score (GBL,LCL), or relocateable (REL).
Typically executable code would go into a PSECT marked RD,NOWRT,EXE,SHR which would allow multiple users running the same installed program to save memory by simply mapping the executable pages into both processes, however neither process could write to those pages. Program data, on the other hand, would typically be mapped into sections marked RD,WRT,NOEXE,NOSHR which would provide each process with their own local data pages, to which they could write, but which they couldn't execute.
Any attempt to do so would trigger an SS$_ACCVIO (the VMS equivalent of a segmentation fault) and bring a typical program to an abrupt end, unless it could handle that error.
So, twenty+ years later, and the two manufacturers are making a big thing about NoExecute. Yawn...
While it will certainly do a lot to prevent the typical buffer overrun attack, by itself it isn't enough, as the overwhelming majority of development tools don't properly protect executable memory. Unless a program has very good reasons to be self-modifying, it needs to not only mark it's DATA pages non-executable, but mark it's code pages non-writable. As the GNU compiler was working on VMS well over a decade ago, if I were to bet on which platform would have the majority of it's compilers 'EXE != WRT' compliant, I know where my money would be.
Jim
[1] DEC Part number AH-H159B-SE ('VAX/VMS V2.0 SRC LST MCRF/226') for the truly interested.
NX/EDB should be the default mode for memory accessed by logic: unexecutable data. Computer science, engineering and other programming has shown that practically all memory is used for either data or instructions; only rarely do "metaprogramming" patterns call for processing the instructions as data. However, all memory space is typically treated equally, though some memory protection is instituted in VMs, like separate address spaces per process. A much better memory model for CPUs is an execution mask, which privileged processes can update to allocate instruction space for started child processes. Modern OS'es not only use VM (virtual memory) and MMU APIs, they usually have hardware support (MMU chips) for managing memory. Mapping the MMU index to a dedicated fraction of main memory (eg. 1b:KB = 1MB:8GB, or even a scaling factor configured dynamically) would let instruction vectors execute very quickly, probably adding negligible overhead to instruction execution as each memory access passes through an extra "NAND". Extra CPU/MMU cache dedicated to the execution mask is better spent on such a qualitatively beneficial feature than on just extra KB of instruction to hit. And the benefits in uptime alone make the performance proposition a win, running marathons compared to lots of sprints ending in halts and restarts. That reliability bubbles up in efficiency throughout the cycle, from running programs, to developing them, debugging them, maintaining them, managing them, and buying them - the human teams become much more efficient when the tools are always sharp with steady handles. And chip vendors would have another feature on which to compete, rather than just the pernicious price and MHz games. Intel, are you listening?
--
make install -not war
Not a lot.
For NoExecute to work properly, code sections need to be read-only. See notes in my previous comment. Merely marking data no-execute doesn't prevent valid instructions from being overwritten unless they are protected, and that protection is also protected. (I.e. it's no good having code sections which are marked no-write, if the latest IE bug-du-jour can merely change the permissions from user mode. It has to be a kernel mode operation).