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.
Yeah, gaming and high-end CAD. Seriously, the truth is that AMD and Intel could have milked the performance market for another ten years (much like Microsoft is still milking the desktop GUI market) but now, even commodity PCs are so fast that the mass market isn't feeling the slightest pressure to upgrade. At least, they aren't upgrading their CPUs. Printers, cameras, MP3 players, sound cards, WiFi ... sure. But for the vast majority of applications the current crop of CPUs is just total overkill.
The higher the technology, the sharper that two-edged sword.
That's not necessarily true. I switched motherboards in one of my systems, keeping the same AMD 2000+ processor, and switching the motherboard alone, added about 30watts to my total power consumption. Sometimes the motherboard chipset makes a huge difference.
The new power-sapping motherboard in question is an Asus A7V600-X. I exchanged it twice, assuming a problem, only to find all of them have the same extremely high power consumption.
Beware the VIA KT600 chipset! Buy an nForce (I guess) or an older KT400 (actually supports the same bus speed).
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
The thing that bothers me about benchmarking software is this: At some point, someone compiled that software. In most cases, you could track down who produced which benchmarks, but identifying the machine the final product was compiled on, the architecture used, compile flags, and so forth is a different matter. So you have benchmarks, but you have no verifiable means of determining if they're biased towards any particular processor/architecture.
I was at a LAN party over the last weekend, and actually can't concur with that. We were out in a small house in the landside, outside temperatures just above the freezing point, without any heating. Naturally there were mostly high-end computers, but until there were more than about five of us there, the room didn't really get uncomfortably hot. ;)
This must have been quite a while ago, before AMD's XP "quantispeed" numbering got everyone to forget about the MHz. Now you look for a 3200+, not a 2GHz processor.
Processor makers (namely, Intel) have been the ones who have pushed the MHz myth upon the public. Now that they aren't able to continue it without being far hotter (and they notice a good number of sales are being lost because of that) they are backpeddling, and giving up the MHz race.
While I/O bandwidth, the interrupt model, and many other crufty pieces of the PC architecture have become a bottleneck, there are still many CPU-bound applications.
I'm doing a huge ammount of video compression (TV capture, conversion to MPEG4) and even though I'm using very the very fast mplayer/ffmpeg for compression, CPU time is the bottleneck, and it would be much more convienient for me if I could do it faster. I'm sure I'm not unique, as many people are doing MPEG-2 encoding now, to master/covert/copy DVDs.
Encryption is a big CPU-drain as well. Anything I'm doing over the network, tends to need encryption. Remote log-ins, file copy, etc. This is a real CPU-hog. While it only costs about $100 to get a basic PCI crypto card, most people don't spend the money, and leave their CPU to do all the work. Even if you buy the hardware, it limits you to only one or two methods, which forces your CPU to handle any other cases. And even if you can do hardware crypto all around, you'll probably also want to compress the data, which will load down your CPU pretty good.
Compression is one way people work-around the other computer bottlenecks. If your storage or network connection isn't as fast as you'd like, you can use compression to speed the process up, which taxes the CPU. Compression speeds up my own network backups by about an order of magnitude.
Personally, I'm willing to stay back from the cutting edge, as a hundred MHz here and there isn't worth the premium. I'm also concerned with the heat output, and the power draw, and doing what I can to reduce those. However, I certainly do need number-crunching CPU power in some of my machines.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
It's interesting to note that the idle power consumption is actually lower that a 3.0 Ghz P4 530. Could this be an indication that Intel are trying to rectify the problems with the 90nm process?
That Intel has already announced that it is stepping away from the "Bigger Clock Speeds mean Better Processors" theory. The release of a higher clock speed processor seems to fly right in the face of that announcement. This is probably one of the last releases in that department they are going to make. I know that a 4 GHz will not be manufactured by Intel. As a matter of fact, you can search for the article here on Slashdot to find that they are lowering clockspeeds, and going for more efficient CPU's.
Help me, help you. - Jerry McGuire
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
Yeah, gaming and high-end CAD.
I'd like to add applications that are almost infinitely scalable. For example, anything that you tell your computer to do and you walk away for an hour. The first thing that comes to mind is trans-coding DVDs. Mabey with a 3.8 it will take 4 hours instead of 7 with my 1800+ AMD.
Still not buying one, but there are reasons.
~Will
sig?