Slashdot Mirror
AMD K7 550 Hands-on Preview
Kenn Hwang wrote in with the review to the new K7. Click below for a snippet-suffice it to say that these things /move/.
Winmark: In this particular synthetic test, the K7 continues to shine down on the
Intel competition. Here, we see it leap ahead by almost 25% over both the
Pentium III and the P3 Xeon. Note that as above, the hard drives differed
from system to system, though fact that the P3 systems were using
dedicated 7,200RPM Fast/Wide SCSI drives don't seem to help their case
much. Very impressive showing on the part of the K7.
For those of you clamoring for some REAL benchmarks, you're out of luck. This site is run by one of the best Quake players on the planet. It's not surprising that all of the benchmarks are geared towards gaming performance. This is exactly what most of his readers want/expect.
Please take into account the intended audience before ripping on his content. Be also advised that this was pretty limited by what AMD would let him test with.
Dan
They have said publically that they have no plans to put serial numbers on their chips. At least that's what their PR people have been saying all along. Who knows what they're actually thinking?
Come on!
Since this is a CPU we are talking about, why are they running tests which are more dependant on system then CPU.. Those tests are mostly I/O bound. This CPU is supposed to have a kick-ass FPU but nothing they do is really that FPU dependant (even quake does a lot of int stuff).
How about some real tests:
SpecInt
SpecFp
FFTW compiled with standard egcs compiler.
Hand tuned FFT benchmark from AMD.
Linpack w/ stock egcs
Any of the above with a tuned compiler (as long as they make it available)
Also how about a fpu smashing real world apps:
MP3 encoding, jpeg encoding, varrious gimp filters on vairous image sizes.
No, they unfortunately don't.
, 2194863,00.html) for a good rundown of why is was just really stupid and a good example of how far Intel has yet to go.
I have worked on UNIX boxes for years and regarded the furor over the chip IDs as really, really dumb.
Here's why:
SPARCs, ppcs, and other chips (let alone those big, ugly bipolar modules) always had IDs. They were expensive, it was very important to know if one failed which one it was, from which run, and so on. It was also important for service, asset control, and so on.
Of course, these chips also allowed stuff like switching to service mode via a switch that connected to a trace on the chip, board NVRAM that would pull off the last part of any error condition that had killed the box (or was supposed to, anyway), and so on -- they weren't cheap and they were designed with that in mind. They were designed for very long life and the ID made tracking easy.
When the Pentium ID thing came out, my first thought was "Good. Intel has finally decided to join the big boys and this will make asset tracking far easier." I was unimpressed, though, by the fact that this wasn't accompanied by specs that required network booting, enough NVRAM to bootstrap to that point, and other hallmarks of "real" systems. I was just flat surprised by the idea that they had to tract this over the web via software other than in the microcode. No, Intel still had no clue. And then the privacy nuts blew a gasket.
Well, it wasn't the ID that was stupid, boys and girls -- it was the idea of tracking it with userland software. That's the bottom line. Take a look at this article (http://www.zdnet.com/zdnn/stories/comment/0,5859
Want to know why I like the idea of Mips or ppc or microSPARC or ARM NCs on my networks? I know who they are and where they are, because I can track them at a low level and stuff like the firmware is a damned sight harder to fake without a huge amount of effort (out of proportion to the cost of a $600 NC). Theft is a big issue, so is tracking cost of support and allocating it to departments. IDs help me. IDs would also be good for theft issues with chips, which have become serious (as serious as RAM theft used to be).
With appropriate systems engineering, I would prefer chip IDs. Don't yelp until you look a little beyond the spectre of Intel knowing what pr0n you favor. It is a historical accident that two very unpleasant companies (Intel and Microsoft) have dominated so much of the computer market and this too will pass. Look at the larger issue and the longer record of use of chip IDs and don't freak out without a good reason.
I think that several trends that are ongoing and look likely will push chip IDs (IDs everywhere, actually) quite hard. My area of concern is asset control and keeping up with code patches and so on. Theft is less of a concern to me -- I don't have armed men running into the machine room and saying "drop that lousy coffee and hand over your Pentiums." But truck hijacking is getting common in California and all of us do pay in t he end (well, I have Alphas, but still, you see my point I am sure).
Anyway, aside from the asset control issue, this is a short summary of why I like IDs:
1. this allow automated updates of firmware. Keeping track of firmware is a pain. The x86 boxes are worse than the 9000s and the RS6000s, as then you have to work with the SCSI code, the motherboard code, the NIC code, and so on -- at least with the UNIX boxes it tends to be pretty stable, but it seems like we are adding something new onto the Compaqs every two weeks. Of course, they are running NT, so uptime is sort of a non-issue, but still. We are looking realtively quickly at everything having a small microcontroller. Everything, including lamps and toasters. They will run something tiny (I would bet on QNX, actually) that can do running updates. This will likely often be transmitted over the power lines. Having a chip ID would allow a small but far more powerful system in a home or office to keep track of what was out there and what revision level the microcode was at. I suppose that I might be mistakened and the code will be so good that it would never need to be updated, but the I wouldn't bet on it. The future will be full of rooms that turn out their own light and even tell you when the bulbs are burned out, toasters that keep up with the aging of the elements and adjust power to suit, and Dr. Pepper machines that take your fingerprint for a Dr. Pepper and charge your account. All of these will need occasional updates, and that is the way it will work, because as cheap as the chips get, the software will always be cheaper to change. Chip IDs and methods to keep track of them are coming. I would LOVE to have this on a database here so that I could categorize fixes according to severity the way I do patches and apply them as absolutely needed and know exactly what my risk and exposure will be if I hold off. I think that in large companies this would pay off in lower insurance or better ratings.
2. The same thing would work at home, but a little differently. At home, I also think that it would pay off in lower insurance and better ratings -- LoJack works, right? If someone would have a big problem ever using a stolen PC again, it would reduce the value, because not too many people would buy one. I would think that this would look like a good idea, not just for PCs but for VCRs, TVs, stereos -- the whole list of stuff you can buy out of a trunk in crack neighborhoods at 03:00. This could cut renter's insurance and homeowners insurance and I expect that a)it will and b)it will get standard.
3. Finally, just in terms of standard stuff, chip IDs really ought to make management easier. This would really help the less sophisticated users that you were describing. Time is rarely free of charge and I think that small businesses and home users would appreciate automatic upgrades of firmware, a real trampoline system that would allow you to fall back to a previous bios level if the update failed, better internal monitoring, and something like an RSA and ssh licence sold with every PC to connect to a trusted for-profit service on a regular basis to do the updates for them even more than me, because I can do this stuff. They may not be able to.
Again, I think that people should look down the road a little. Intel and Microsoft are outstandingly bad companies. They do bad things. Microsoft is skirting "evil" and easily is "dishonest." This is an accident of history. I would expect that a company like Sun or NCD might be on top in a few years (perhaps Moto will come back -- after all, Mips did) and would simply behave in an ethical fashion. Chip IDs aren't evil. People who don't want to have them may have a point that disabling them is a pain, they may have a point that Intel and Microsoft are essentially guaranteed to misuse them and should be stopped, but they do not have a point that the solution to the abusive behavior of Intel and Microsoft is to ban chip IDs. That is like someone saying, after having backed over the mailbox and Uncle Ed after flooring the car in reverse in the driveway "They shouldn't make cars that let you do things like that." No, you have missed the point. Or someone saying after the latest shootings that guns should be banned. No, loonies shouldn't have guns (I live in Texas -- lots of loonies, lots of guns, and I feel rather stongly that guns aren't the issue -- I have seen too many case studies up close and personal)(along the lines of that Jeff Foxworthy joke: You know you're a redneck if the last thing that you have ever said before losing consciousness is "Hey, y'all -- watch this!"). The solution to abuse of privacy isn't to make a move towards living in a cave (no, I am not suggesting that you are doing this exactly, but you are suggesting capitulation, like those huge speed bumps that are all over residential neighborhoods these days instead of police giving tickets, stepping bravely into a third world relationship with law and order and giving up any attempt to control the situation properly). It is to stop the abuse.
Anyway, this is way to long. I appreciate your points, but I respectfully disagree.
Perhaps the 512k cache at 1/3 CPU speed is
too meager to keep the FPU unit fed with
data? It can handle up to 8 meg(!) of L2
cache up to full CPU speed, so perhaps future
versions of the K7 will have better floating
point performance.
I imagine it's being released in its current
config because it will be affordable for us
and profitable for them. Expect future versions
to be waaay more pricy.
Well I guess that webserver is not running on a K7.
;)
Being a AMD K6 owner, I have found the AMD chips to be a cost effective and performance-comperable alternative to Intel. Plus, buying a non-Intel CPU is good karma
Four-digit slashdot ID. Recognize.
If you reread the article you'll notice they really haven't taken a step backwards between the K6-3 and K7, they both have large 128KB full speed caches on the die (compared to 32KB on the Pentium II/III), the 1/2 vs 1/3 speed backside cache will probably not slow things down much.
-P
"I'm nobody suspicious... That makes me sound even more suspicious, doesn't it?" - Spike (Cowboy Bebop)
I can see what you are saying about the usefulness of an ID, but that usefulness is specific to the type of environement that you are working in. For 98% of home users and probably 50+% of small businesses there is no use for a chip ID.
Also, with the inherent security, stability, and myriad of other flaws that the predominant OS of home/small business users, it's undoubtably better that a potential privacy flaw like the PIII ID is not put in place to be exploited.
Intel, and AMD produce their chips for the "low" end of the computer food chain. Maybe ID's are appropriate and necessary for chips at the higher end of the food chain, but I really don't believe they are at the end I operate at. Having a chip ID on a $5000 chip makes sense, on a $100 chip why bother?
I think if Intel and AMD want to push their chips up the food chain, then they should optimize them for that purpose, possibly by including an ID so that that they can fit in with the higher end chips that they are competing against.
First, I must agree with your comments on the cache. I am much more curious about how the K7s with half and full speed caches will perform compared with PIIIs and cooled K6-IIIs. On the issue of video cards, I'm not even sure why high end 3d cards are used when benchmarking these machines. I suspect a more useful Q2 benchmark would software render to a tried-and-true old card, like a Millennium II. Benchmarking a processor-and-coprocessor combination appears to horribly complicate the system, and hide what the processor itself is doing. (If you're benchmarking the busses on the various machines though, it makes more sense to use very intelligent cards which utilize all of the capabilities of the various busses.) On the issue of MMX/3dNow!, my belief is that the benchmarking code should be utterly un-optimized for either of these. Maybe this is unrealistic... perhaps the usual C compilers optimize for MMX naturally. In that case, if it's really that standard, go ahead and let the compiler do it, but don't go out of your way to optimize for a specific instruction set. I'd personally prefer to see how the FPU cores compare on the same playing field, with software I have now. If some new chip gets games to run faster because of new instructions, that'll be a special treat, but I'd rather not see it in mainstream benchmarks until that instruction set is common in compiled code. I tend to do scientific simulations, so I'd like to know how well hardcore floating point code, compiled with standard compiler options, works on various processors. I don't want to know how it could perform, if I went out of my way to optimize the assembly. :) Granted, my needs are different from those of people who primarily use precompiled games, since the coders there can spend the effort tweaking the details. What I need is probably close to what a lot of other free OS users need, though, since most of our binaries are optimized solely by the compiler. One last thing... Most of the benchmarks I've seen have compared different clock speed chips on the same graph! What's the deal with this? I'd a least prefer it if the benchmarkers divided the score by the clock speed, for instance, to give a more meaningful measure of the efficiency of the chip itself! (Sure, I do this in my head already, but its a pain, and just seems like sloppy plot making.) I'd love to see what a K7 does with the full speed cache installed... hopeful we won't have to wait to long before they start to appear! John
I know that this review is a review of non-production hardware. I still have to say that I'm very disappointed. Not so much in the numbers, but in the configuration of the system. Two points in particular:
(1) The L2 cache is only running at 1/3 speed. I don't care about the size of the cache, but to me this is a step backwards. The PIII 550 has 1/2 speed L2 cache. The Kryotech Kool K6-III 550 (a thermally accelerated K6-III 450) romps the both the PIII and the K7 in some benchmarks. Why? L2 cache - the Kool K6-III 550 has full speed, on die L2.
(2) An Ultra TNT2 video card was used, with older nVidia drivers. Near the end of the review, it's mentioned that there are newer drivers available with better 3dNow! optimizations. I think that either a 3dfx V2 SLI or V3 should have been used, since their 3dNow! drivers are better, or at the very least the newer nVidia drivers.
I still think that the K7 has potential. It had very high Business Disk and High-End Disk Winmark scores. This leads me to believe that the hardware _is_ capable. Don't write the K7 off until a shipping processor has been reviewed (and hopefully one with at least 1/2 speed L2 cache).
I can't imagine why exactly I need a kickass FPU. Last time I checked none of the software I used really cared especially if I had an FPU. Compilers, web servers, version control systems, databases. None of those need an FPU. A lot of people use their computers for things other than playing Quake.
Imagine that.
The more K7's that sell(to game market, server market, business market whatever) the cheaper they become. The more K7 motherboards they sell the cheaper they become.
If the K7's FPU makes it a dog for FPS games then it loses a very sizeable market share to intel. This means less hardware support and therefore less software support.
Games are important for the future of any platform.
I'll admit. I was a bit put off by the odd results. But after a little research I learned something that's telling me to wait.
The "Fester A3" board is apparently the same name of the board that's been used to demo K7's for quite a while now. The shipping board is supposed to be a "Gomez" board, with a "C3" number. So is A3 2 debug levels back? If so does that make this K7 2 debug levels back?
Early K7's were supposed to be quite buggy.
I'm just gonna wait for the real-deal before I jump to any conclusions.
I assume these things DON'T have the chip ID, yes?
---Joe Merlino gnupg public key ID: 1E91EBAF
You put a lot of cross-references in that article. You've obviously been reading Everything :-)
(btw, I'd not call The Register the European equivalent of Slashdot, as The Register is just a news site, not news/comments/opinion/flamage like Slashdot. I think The Register reads more like a bizarre cross between news.com and Segfault).
AMD has been completely absent from hyping the K7. Haven't you noticed? It's the *absence* from hype that's been causing all this speculation.
However, losing your head over this silly "preview" isn't the way to go, you know that. Remember that Tom's Hardware Guide posted up benchmarks of the PII shortly before it came out, and it was *annihilated* in benchmark comparisons with the Pentium MMX. Of course, the final version turned out far, far better than that. What you have to understand is that in the bugfix (no I don't know what it's really called, either) phase of a processor's design life, entire swaths of the product are turned off or tuned out to avoid major bugs in the current revision. Although the current C3 revision of the K7 is generally free of bugs (all processors out there have bugs, but production versions just don't have damning ones), earlier versions were wracked with self-destructive errors and problems of all sorts. So, basically, you have to take measures to get around those bugs for those revisions -- actions like this could severely cripple the processor and make benchmark results totally, completely unreliable compared to final revision.
On a more personal note, I've looked at the microarchitecture and there is no way that a PIII's x87 can outperform the x87 on a fully formed K7. Not a chance in all the universe.
And, yes, I do admit I'm biased. Do you?
-JC
PC News'n'Links
http://www.jc-news.com/pc