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.
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.
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).