Slashdot Mirror

← Back to Domains

Domain: arstechnica.com

Stories and comments across the archive that link to arstechnica.com.

Comments · 9,494

  1. Or perhaps you just can't read so well by ToLu+the+Happy+Furby · · Score: 3 · on RISC vs. CISC in the post-RISC era
    Now let's see. Why is it that the author of this article is so "clueless", as you say?

    1. When the first RISC machines came out, superscalar execution hadn't been invented yet.

      Some processors (Cray for one) had been doing this years before RISC came out.
    Unfortunately, the actual quotation from the article is "When the first RISC machines came out, Seymore Cray was the only one really doing superscalar execution." Whoops. Looks like ya' dropped the ball on that one.

    1. I also think that the ideas behind RISC such as "move the complexity from the chip into the compiler" also apply today and that VLIW is an example of this applied to scheduling
    Well, that's very forward thinking of you. Of course, I guess that makes you clueless as well, because, once again, it's exactly what the author of the article wrote: "VLIW got a bad wrap when it first came out, because compilers weren't up to the task of ferreting out dependencies and ordering instructions in packets for maximum ILP. Now however, it has become feasible, so it's time for a fresh dose of the same medicine that RISC dished out almost 20 years ago: move complexity from hardware to software."

    So this leaves us with your remaining "point":

    1. The fast CISC chips (PII, Athlon) do instruction conversion into RISC...so if the debate is over, its because RISC won -- big time.
    Well that's a brilliant insight you've uncovered there (covered in the article here), but the point of this "clueless" article (which you obviously did not read) was that there no longer is a debate. The term RISC refers to a CPU design philosophy which was invented in 1981. That was 18 years ago. It was intended as a replacement to "CISC", the CPU design philosophy which came about in the early 70's.

    That is to say, the CPUs of today, whether P6 or PA-RISC or G4, and the systems that they are in, bear almost no resemblence whatsoever to either a "CISC" chip or a RISC chip. The only similarity is that the P6's and K7's of the world are compatible with the x86 ISA, which was originally written (back in 1977 IIRC) for a "CISC" chip. Yes, this adds an extra decoding step (to break down instructions into "RISC-like" ops), and yes, theoretically that means increased die-size and complexity, which of course means lower clock speeds. Oh wait--that reminds me: which currently shipping chip has the fastest clock speed?? Oh yeah--the 700MHz Athlon. With a 750 part set to be shipped later this week. And, looks like, a 900 in time for New Year's. One of those ungainly "CISC" chips, huh.

    Hmm...but let's take a look at how all those competing "RISC" chips have used their incredibly simple architectures to keep die size down. Like the PA-RISC, which is, IIRC, about 6 or 7 times the size of a PIII. Or those new G4's, with their impressive yield of 0% at 500MHz. The simplicity of today's modern "RISC" chips in action.

    Now, none of this is to say that the G4 or the PA or whathaveyou isn't a great design. Just that the resemblence of today's CPU's to a true "CISC" or RISC chip is so tangential as to make the categorization meaningless. And as for your "debate"--of course RISC won big time. It came out nearly 10 years after the first chips made with the "CISC" philosophy. As was, IMO, rather compellingly and insightfully explained in the article, "CISC" chips were the best possible solution to the awful state of complilers and memory available at the time. By 1981, the state-of-the-art had advanced to the point where RISC was a better solution. Duh.

    Since then, compilers have gotten better, transistor densities have increased, and RAM prices have plummetted, allowing all the advancements which the author termed "post-RISC". And, looking at the CPU's of tomorrow, we see all sorts of new techniques on the horizon: optimization based on advancements in compiler/software technology, ala IA-64, MAJC, and (apparently) Transmeta; or optimizations based on incresing transistor densities, like some of the new physical parallelization designs that appear to be a couple generations down the road for Alphas and IBM chips.

    But as long as people like you insist on categorizing these chips into meaningless 20-year design philosophies, the tech world will be a more ignorant place.

    What a dissappointing comment.
  2. Or perhaps you just can't read so well by ToLu+the+Happy+Furby · · Score: 3 · on RISC vs. CISC in the post-RISC era
    Now let's see. Why is it that the author of this article is so "clueless", as you say?

    1. When the first RISC machines came out, superscalar execution hadn't been invented yet.

      Some processors (Cray for one) had been doing this years before RISC came out.
    Unfortunately, the actual quotation from the article is "When the first RISC machines came out, Seymore Cray was the only one really doing superscalar execution." Whoops. Looks like ya' dropped the ball on that one.

    1. I also think that the ideas behind RISC such as "move the complexity from the chip into the compiler" also apply today and that VLIW is an example of this applied to scheduling
    Well, that's very forward thinking of you. Of course, I guess that makes you clueless as well, because, once again, it's exactly what the author of the article wrote: "VLIW got a bad wrap when it first came out, because compilers weren't up to the task of ferreting out dependencies and ordering instructions in packets for maximum ILP. Now however, it has become feasible, so it's time for a fresh dose of the same medicine that RISC dished out almost 20 years ago: move complexity from hardware to software."

    So this leaves us with your remaining "point":

    1. The fast CISC chips (PII, Athlon) do instruction conversion into RISC...so if the debate is over, its because RISC won -- big time.
    Well that's a brilliant insight you've uncovered there (covered in the article here), but the point of this "clueless" article (which you obviously did not read) was that there no longer is a debate. The term RISC refers to a CPU design philosophy which was invented in 1981. That was 18 years ago. It was intended as a replacement to "CISC", the CPU design philosophy which came about in the early 70's.

    That is to say, the CPUs of today, whether P6 or PA-RISC or G4, and the systems that they are in, bear almost no resemblence whatsoever to either a "CISC" chip or a RISC chip. The only similarity is that the P6's and K7's of the world are compatible with the x86 ISA, which was originally written (back in 1977 IIRC) for a "CISC" chip. Yes, this adds an extra decoding step (to break down instructions into "RISC-like" ops), and yes, theoretically that means increased die-size and complexity, which of course means lower clock speeds. Oh wait--that reminds me: which currently shipping chip has the fastest clock speed?? Oh yeah--the 700MHz Athlon. With a 750 part set to be shipped later this week. And, looks like, a 900 in time for New Year's. One of those ungainly "CISC" chips, huh.

    Hmm...but let's take a look at how all those competing "RISC" chips have used their incredibly simple architectures to keep die size down. Like the PA-RISC, which is, IIRC, about 6 or 7 times the size of a PIII. Or those new G4's, with their impressive yield of 0% at 500MHz. The simplicity of today's modern "RISC" chips in action.

    Now, none of this is to say that the G4 or the PA or whathaveyou isn't a great design. Just that the resemblence of today's CPU's to a true "CISC" or RISC chip is so tangential as to make the categorization meaningless. And as for your "debate"--of course RISC won big time. It came out nearly 10 years after the first chips made with the "CISC" philosophy. As was, IMO, rather compellingly and insightfully explained in the article, "CISC" chips were the best possible solution to the awful state of complilers and memory available at the time. By 1981, the state-of-the-art had advanced to the point where RISC was a better solution. Duh.

    Since then, compilers have gotten better, transistor densities have increased, and RAM prices have plummetted, allowing all the advancements which the author termed "post-RISC". And, looking at the CPU's of tomorrow, we see all sorts of new techniques on the horizon: optimization based on advancements in compiler/software technology, ala IA-64, MAJC, and (apparently) Transmeta; or optimizations based on incresing transistor densities, like some of the new physical parallelization designs that appear to be a couple generations down the road for Alphas and IBM chips.

    But as long as people like you insist on categorizing these chips into meaningless 20-year design philosophies, the tech world will be a more ignorant place.

    What a dissappointing comment.
  3. Or perhaps you just can't read so well by ToLu+the+Happy+Furby · · Score: 3 · on RISC vs. CISC in the post-RISC era
    Now let's see. Why is it that the author of this article is so "clueless", as you say?

    1. When the first RISC machines came out, superscalar execution hadn't been invented yet.

      Some processors (Cray for one) had been doing this years before RISC came out.
    Unfortunately, the actual quotation from the article is "When the first RISC machines came out, Seymore Cray was the only one really doing superscalar execution." Whoops. Looks like ya' dropped the ball on that one.

    1. I also think that the ideas behind RISC such as "move the complexity from the chip into the compiler" also apply today and that VLIW is an example of this applied to scheduling
    Well, that's very forward thinking of you. Of course, I guess that makes you clueless as well, because, once again, it's exactly what the author of the article wrote: "VLIW got a bad wrap when it first came out, because compilers weren't up to the task of ferreting out dependencies and ordering instructions in packets for maximum ILP. Now however, it has become feasible, so it's time for a fresh dose of the same medicine that RISC dished out almost 20 years ago: move complexity from hardware to software."

    So this leaves us with your remaining "point":

    1. The fast CISC chips (PII, Athlon) do instruction conversion into RISC...so if the debate is over, its because RISC won -- big time.
    Well that's a brilliant insight you've uncovered there (covered in the article here), but the point of this "clueless" article (which you obviously did not read) was that there no longer is a debate. The term RISC refers to a CPU design philosophy which was invented in 1981. That was 18 years ago. It was intended as a replacement to "CISC", the CPU design philosophy which came about in the early 70's.

    That is to say, the CPUs of today, whether P6 or PA-RISC or G4, and the systems that they are in, bear almost no resemblence whatsoever to either a "CISC" chip or a RISC chip. The only similarity is that the P6's and K7's of the world are compatible with the x86 ISA, which was originally written (back in 1977 IIRC) for a "CISC" chip. Yes, this adds an extra decoding step (to break down instructions into "RISC-like" ops), and yes, theoretically that means increased die-size and complexity, which of course means lower clock speeds. Oh wait--that reminds me: which currently shipping chip has the fastest clock speed?? Oh yeah--the 700MHz Athlon. With a 750 part set to be shipped later this week. And, looks like, a 900 in time for New Year's. One of those ungainly "CISC" chips, huh.

    Hmm...but let's take a look at how all those competing "RISC" chips have used their incredibly simple architectures to keep die size down. Like the PA-RISC, which is, IIRC, about 6 or 7 times the size of a PIII. Or those new G4's, with their impressive yield of 0% at 500MHz. The simplicity of today's modern "RISC" chips in action.

    Now, none of this is to say that the G4 or the PA or whathaveyou isn't a great design. Just that the resemblence of today's CPU's to a true "CISC" or RISC chip is so tangential as to make the categorization meaningless. And as for your "debate"--of course RISC won big time. It came out nearly 10 years after the first chips made with the "CISC" philosophy. As was, IMO, rather compellingly and insightfully explained in the article, "CISC" chips were the best possible solution to the awful state of complilers and memory available at the time. By 1981, the state-of-the-art had advanced to the point where RISC was a better solution. Duh.

    Since then, compilers have gotten better, transistor densities have increased, and RAM prices have plummetted, allowing all the advancements which the author termed "post-RISC". And, looking at the CPU's of tomorrow, we see all sorts of new techniques on the horizon: optimization based on advancements in compiler/software technology, ala IA-64, MAJC, and (apparently) Transmeta; or optimizations based on incresing transistor densities, like some of the new physical parallelization designs that appear to be a couple generations down the road for Alphas and IBM chips.

    But as long as people like you insist on categorizing these chips into meaningless 20-year design philosophies, the tech world will be a more ignorant place.

    What a dissappointing comment.
  4. The Coming XISC Evo/Revolution by Effugas · · Score: 4 · on RISC vs. CISC in the post-RISC era

    Before I say anything, I want to commend Hannibal on an absolutely excellent article that clarified issues I thought I understood and illuminated much of the technological history behind the technology we each use every day.

    I am completely impressed.

    That being said, I'd like to take a moment and theorize on the direction microprocessor design is likely to go. This is my theory; you're welcome to disagree and in fact eagerly await commentary from those far deeper in the industry than I. Insert Slashdot Self-Correcting Nature here.

    Of all the chasms in the computer world, there are few as vast as the speed differential between general purpose processors programmed to execute a given task and hard-coded ASICs(Application Specific Integrated Circuits) designed to meet the functional needs of a given process. (OK, granted, Internet -> Local Network -> Hard Drive -> System Memory -> Processor Cache -> Processor Registers is pretty vast too, but cut me some slack here.)

    Telephony is a joke without ASICs--I haven't found a voice over IP solution that operates in software well enough to even be used as a room to room intercom over a 100BaseT Lan--but it's actually reasonably lag-free with hardware encoding.

    Similarly, huge banks of boxen rendering frames for movies became significantly less impressive to me when I realized how many banks of Pentium Processors it would take to match, say, a single Voodoo 2. While, in recent times 3D Rendering has gotten shots in the arm on the general purpose x86 architecture via both MMX and KNI, the order of magnitude difference in speed makes CPU rendering of realtime 3D graphics almost useless.

    (Then again, Sumea is probably the single coolest thing I've done with Java, short of Mindterm.)

    As I observed in the Amiga newsgroup, shove a couple of custom ASICs in a box and you can run a highly competitive multitasking OS in 512K of RAM, with unmatched graphical support to boot.

    But ASICs have their limitations--while they're fast at what they do, they're extremely inflexible. You can't merely program in a new transparency algorithm, nor implement Depth of Field in an architecture that totally lacks it. The inflexibility of ASICs dooms their long term viability.

    CPU's are flexible but slow, ASICs are inflexible but fast. It's a dichotomy the industry is on the verge of smashing.

    I dub the coming processor design specificiation(which, as the article correctly noted, is all RISC/CISC really are) XISC, for eXtensible Instruction Set Computing. XISC essentially specifies that the underlying computational structures--be they microcode or raw gate arrays--ought to be dynamically reconfigurable to meet the needs of the process.

    Just as the lack of a quick bilinear filter function(SIMD stuff) on older Intel chips doomed them as far as efficient 3D in relation to customized ASICs, the ability to insert such a command directly into the internal microcode of a processor has a theoretical chance of executing at extremely high speeds for a non-dedicated processor.

    Transmeta, also known as the only reason many people willingly acknowledge the US Patent Office, appears to be spearheading the XISC drive. Their patents refer to technologies that automatically cache microcode translations, that provide backwards-flow in case of a broken emulate, and so on. They've often been "accused" of developing a chip that can emulate any chip--in the XISC context, a chip optimized to execute the instruction set most required by any given process.

    If you accept that performance drops in the orders of magnitude are suffered when a processor lacks the appropriate design for a given set of requests, it's quite obvious that intelligent designers seeking to execute a quantum leap in system performance would try to allow processors to acquire any necessary designs to achieve much higher speeds.

    Of course, most of my chip designer friends would be happy to remind me that much of the speed of ASICs comes from their hard coded nature--the literal gates correspond to whatever output is desired, no translation is necessary.

    Of course, here's where FPGA's come in. Field Programmable Gate Arrays are chips whose internal gate structure can be rewritten on command, sometimes many thousands of time per second. They can't be clocked as fast as true ASICs, nor are the yields as high, but one quickly morphing chip can do the job of three or four in a digital camera. With at least one company(someone give me a name!) developing a language for programmatically defining instruction sets for a FPGA processor, the technology for XISC is obviously in development.

    Ah, but not all is not fair thee well. In fact, while on the topic of 3D chips, the Rendition Verite chipset had a programmable RISC core, and the chip ended up failing because it could not scale in speed like 3DFX's Voodoo could. Developers could write new 3D instructions, but didn't (in general) because it was just too hard. (Yes, Carmack did.)

    That's why there's such a powerful force towards automation in this XISC evo/revolution, such as the FPGA language and Transmeta's automated Microcode translations that stay in memory so as to speed up future similar instruction requests. In an ideal world, a developer merely compiles a chunk of code that profiles as heavy usage directly into CPU microcode, or at least specifies in some way that a given routine ought to be run through the "special ops" part of the system.

    Whether the world will become ideal is a point of question. Whether we will have instruction sets that morph is almost obvious, it's just a matter of when will the bridge between ASICs and CPU's finally be resolved.

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com

  5. Earlier RISC vs. CISC articles on Ars Technica by vrt3 · · Score: 1 · on RISC vs. CISC in the post-RISC era
    Some time ago there was another series of RISC-CISC articles on Ars Technica, well worth the reading:

    RISC vs. CISC
    RISC vs. CISC II: Hellazon fires back
    RISC v. CISC III: The last word?

  6. Earlier RISC vs. CISC articles on Ars Technica by vrt3 · · Score: 1 · on RISC vs. CISC in the post-RISC era
    Some time ago there was another series of RISC-CISC articles on Ars Technica, well worth the reading:

    RISC vs. CISC
    RISC vs. CISC II: Hellazon fires back
    RISC v. CISC III: The last word?

  7. Earlier RISC vs. CISC articles on Ars Technica by vrt3 · · Score: 1 · on RISC vs. CISC in the post-RISC era
    Some time ago there was another series of RISC-CISC articles on Ars Technica, well worth the reading:

    RISC vs. CISC
    RISC vs. CISC II: Hellazon fires back
    RISC v. CISC III: The last word?

  8. This guy doesn't know what he's talking about. by LocalYokel · · Score: 1 · on MSN Lists 10 Dumb Things NT Users Do

    I know a *little bit* about NT, but this guy knows nothing.

    I never make an NT Emergency Repair Disk. Why? They don't work. About the only thing that can really be done with them is preserve elements like the system's security ID that can't be recreated if you were to just reinstall. It doesn't save your configuration -- all it will say is that the system cannot be repaired with that disk...

    This guy also is confusing NT Administrator with UN*X root. NT can have multiple, fully privileged users, and the first two things you should do when starting NT for the first time are to rename the Administrator account to something else, then create *personal* administrator accounts -- when a few people share a password, it becomes a dozen people. If you give several people root, a lost root password is no problem.

    Service Packs are saviors. When peculiar things start happening with NT, a Service Pack is almost always the answer. If something isn't working right in the first place, where's the harm in doing something that *might* ruin it, or more likely will fix it? If this is a production server, you *do* make backups, don't you?

    This lamebrain really needs to get information from sources other than his parent company. Sheesh, Ars Technica has much more informative articles on NT...

  9. Re:Doesn't scale by Anonymous Coward · · Score: 0 · on Building an 1100Mhz "SuperStation"
    Hrm. According to this article a dual celeron SMP beat a dual P3 SMP. What's of particular interest is the celeron's performance on a FPU intensive 100 mb photoshop file. Perhaps this'll change when Intel puts L2 cache back on die with the coppermine :)

    Then there's the celeron Beowulf clusters (e.g. Anandtec's 24 celeron "warpcore" cluster). So I suspect the Celeron is relatively scalable :)

    Regarding an early comment about whether or not there will be any SMP chipsets for the K7. I've been waiting for a response from VIA on this. However, they usually take 1-3 weeks to respond to e-mail, in much the same way Dinosaurs were rumored to respond to pain (read: veeeerrrryyyyy sllloooooowwwwwlllyy)

  10. there should have been links in there by lost_packet · · Score: 1 · on Obi-Wan speaks out against franchise
    Bringing Back the Force (article)

    thread at ars

  11. there should have been links in there by lost_packet · · Score: 1 · on Obi-Wan speaks out against franchise
    Bringing Back the Force (article)

    thread at ars

  12. Missing the point by Anonymous Coward · · Score: 1 · on Apple Prevents G3 Owners From Upgrading to G4

    When was the last time you saw a 486 motherboard that was upgradeable to a pentium? Or even a pentium motherboard that was upgradeable to a pentium 2?

    Yeah, and I'm sure it's real easy to swap out the motherboard in a PowerPC from, say, two years ago for a new G4 motherboard, and count on having all your components work with it.

    Due to the commodity market (and mostly open architecture) on the x86 platform, it is trivial to replace almost any component with another from a different vendor. Don't like the motherboard? Swap it out get another one. Don't like Intel? Get an AMD motherboard/CPU combo.

    Apple's schizophrenic and closed hardware platform decisions, on the other hand, leave a lot of people out in the cold as far as upgrades go. Nor is this a recent change in policy: Apple has been treating customers with indifference since the earliest days of the Macintosh, when they left IIGS owners high and dry.

    I'd like to remind you that the new G4, classified as a supercomputer by the government, thus a weapon (and as of yet, unexportable to other countries), is available for a starting price of 1599.

    Yes, that's the 400MHz version with a measly 64 MB of RAM and no monitor. It is too much to pay, despite your pontificating. This link will tell you how to build an SMP x86 system with 128 MB RAM, a better video card (Ultra TNT2 AGP), a hard drive twice as big, a CD-RW instead of a CD-ROM, and a high-quality 17" trinitron monitor for less than that cost, from brand-name commodity components, all of which you can upgrade or replace anytime you want.

    And if you want John Carmack's opinion on the real-world impact of the G4's so-called "supercomputer" performance, read his finger update on that subject. According to him, it's not all it's cracked up to be. I doubt anyone at Apple, or indeed on the planet, knows more about fast 3D rendering on microcomputers than John Carmack. And I can't think of any common application your average home user's going to need that's going to be affected more by AltiVec than 3D rendering.

    For anyone complaining about the OS: Install LinuxPPC. Or, realize that the OS is getting better with every revision, and the OS X is going to put Microsoft, and particularly NT, to shame.

    That it is. Unfortunately, the stories I have heard about LinuxPPC, Yellow Dog Linux, and MkLinux ease of install, general stability and hardware compatibility, tend to make me believe that those distributions don't measure up to Red Hat or Debian. And why? Not due to any weaknesses in the platform-- it's because Apple, in its arrogance, believes it can completely own both the hardware and the OS on PowerPC platforms, and therefore refuses to release specs for its best and brightest hardware. [0]

    OS X will probably be excellent. Unfortunately, the history of OS X merely presents another example of how Apple's roadmap for the future spins on a dime and leaves everyone else in the lurch. Remember Rhapsody? Apple shipped out developer's kits for Rhapsody to all Apple developers and told everyone to learn it, because Rhapsody Was The Future. Soon after they brought Steve Jobs back, Rhapsody was promptly gunned and MacOS became the order of the day once more.

    ~AC (not takin' cookies today)

    [0] Fortunately, PowerPC lovers won't have to put up with Apple's idiocy much longer, if IBM manages to get widespread industry adoption for their new motherboard specification.

  13. Re:What are you talking about? by patSPLAT · · Score: 2 · on Apple announces the G4

    well... an easy reply is that if you get oem pricing for nt while buying all that hardware you can get it for around $100... plus, ars technica lists a dual processor Tyan S1832 Tiger 100 for $157. throw those two options together and you've saved about $300, which goes a long way (256Mbytes of memory is one option...)

  14. G4 is NOT fast as hell by patSPLAT · · Score: 3 · on Apple announces the G4

    Apple claims that the a 500 Mhz G4 is 2.94 times as fast as a 600Mhz PIII.

    What you have to realize is you should compare performance for price, not raw cpu performance. I'm sure a sun workstation could run circles around everybody, but it is obviously in another price range.

    The 400Mhz G4 with 64mbytes of RAM costs $1499. Let's assume that it will run Photoshop 3 times as fast as a PentiumIII 500Mhz. For competition, let us look at the Ars Technica Hot Rod, picking the dual overclocked celerons. This system costs $1287, and includes much better peripherals (20gb harddrive, 128mb ram, tnt2 video).

    According to Ars's benchmarks, dual processor systems are significantly faster than single processor systems at performing Photoshop tasks. You could make a dual processer PIII 450 for the same price as the 400Mhz G4 (PIII 450 = 2x cost of Celeron 366). That's a bench mark I'd like to see, and one which might reflect the true cost/performance comparisons between a high end mac and a high end x86.

    What does this mean? Apple claims that the G4 Velocity engine complete 2-4 times the computation of standard CPUs. But single processor x86 boxes are not the competition for the g4 (except maybe the Athlon, but Apple didn't benchmark that, did they?), since you can easily afford smp systems for the prices that they are charging.

    Furthermore, this is hardware optimized for graphics production work only. Apple servers are a long way away. LinuxPPC is probably your best option, but since apple has been stingy about releasing the details of their architecture in the past, you probably wouldn't get a Linux box as optimized for the G4 as the Apple OS is. If you could get similar (and more flexible) performance on another box, why else would you want to deal with the only OS more fubared than MS?

  15. G4 is NOT fast as hell by patSPLAT · · Score: 3 · on Apple announces the G4

    Apple claims that the a 500 Mhz G4 is 2.94 times as fast as a 600Mhz PIII.

    What you have to realize is you should compare performance for price, not raw cpu performance. I'm sure a sun workstation could run circles around everybody, but it is obviously in another price range.

    The 400Mhz G4 with 64mbytes of RAM costs $1499. Let's assume that it will run Photoshop 3 times as fast as a PentiumIII 500Mhz. For competition, let us look at the Ars Technica Hot Rod, picking the dual overclocked celerons. This system costs $1287, and includes much better peripherals (20gb harddrive, 128mb ram, tnt2 video).

    According to Ars's benchmarks, dual processor systems are significantly faster than single processor systems at performing Photoshop tasks. You could make a dual processer PIII 450 for the same price as the 400Mhz G4 (PIII 450 = 2x cost of Celeron 366). That's a bench mark I'd like to see, and one which might reflect the true cost/performance comparisons between a high end mac and a high end x86.

    What does this mean? Apple claims that the G4 Velocity engine complete 2-4 times the computation of standard CPUs. But single processor x86 boxes are not the competition for the g4 (except maybe the Athlon, but Apple didn't benchmark that, did they?), since you can easily afford smp systems for the prices that they are charging.

    Furthermore, this is hardware optimized for graphics production work only. Apple servers are a long way away. LinuxPPC is probably your best option, but since apple has been stingy about releasing the details of their architecture in the past, you probably wouldn't get a Linux box as optimized for the G4 as the Apple OS is. If you could get similar (and more flexible) performance on another box, why else would you want to deal with the only OS more fubared than MS?

  16. Overclocked Celerons by zanzar · · Score: 1 · on New Dual-Celeron PC's Encourage Overclocking

    I'm using an overclocked dual celeron machine right now... This article was VERY VERY misleading about a lot of things related to overclocking these beasts...let's begin:

    * You can't change the multiplier for the celerons with any celeron except for the 300a. After the 300a, intel installed a multiplier "lock" on their celerons after that. The 366, 466, etc., all have a locked multiplier that you must use to make the machine boot. I have a celeron 366, and I use the 5.5 multiplier that the chips specifies.

    * To overclock the celerons, rather than upping the multiplier, you increase the bus speed of the board. Celerons default to 66MHz bus. If you increase that in small increments, you can get higher speeds. I managed to get my bus speed to 95MHz, so I'm running my dual 366's at 523MHz. It's hot, and requires a BIG case, with a LOT of fans. (8 in this computer)

    *Disadvatage: When you change bus speed to anything other than 66MHz or 100MHz on this motherboard (abit bp6), you are overclocking or underclocking your AGP bus, and your PCI bus. This does WEIRD things to hardware, sometimes. If the hardware doesn't have a high tolerance for this sort of thing, you can have problems, like frequently losing data on the hard drive.

    I was pretty lucky with my setup. I ordered two celeron 366's "guaranteed" to reach 550MHz. This would be ideal, because I'd be running the 5.5 multiplier at the 100MHz bus speed. The AGP and PCI buses would be running at their standard speeds. Unfortunately, I cannot get the machine to stay stable at 550MHz. To make it reach that speed, I have to change the voltage on the chip from 2.05 volts for 523MHz, to 2.3 volts for 550... If I don't change the voltage, the machine refuses to boot any os before getting an error. If I change the voltage, the computer is only marginally more stable, and quickly overheats and locks up, despite my cooling.


    To make a long story short, BE CAREFUL with this offer. The 366->550 is about as far as you can really take the celeron chips. The chance of doing that successfully is 1/4 per chip, I think. The 466 isn't going to overclock to the full 100MHz bus speed, because the celeron fabrication process maxes around 600MHz. Maybe you can squeeze 620 or so out, but you're really pushing it. If you really want to be guaranteed a good overclocking experience, get yourself some 300a celeron chips. They go to 450Mhz (100MHz bus) 80% of the time... But they are rare, and are as expensive as the 366 multiplier-locked chips, sometimes.

    Don't buy one of these pre-built machines and expect to run 8x anything... The author was very confused. Go to http://www.arstechnica.com/ and read about overclocking a little, and you'll be a lot safer in the end.

    Also, don't ignore the advantage to running these machines without overclocking... Dual processor is nice. Celeron 533's are going to max out the celeron line, before they hit a new chip-fab...so... If you wait a little while, maybe 3 months or so, you can pick up some 500 or 533 MHz celeron chips, pop them in one of these boards, and maybe do some slight overclocking to squeeze another 50MHz out of it... and you've got yourself a great dual processor board that will outperform comparable pentium II's, due to the higher cache speed. :)

    -Larry

    sorry about the length of the rant.


  17. performance of dual pIII vs dual celeron by antic · · Score: 1 · on New Dual-Celeron PC's Encourage Overclocking

    not sure if anyone else has posted this yet, but arstechnica did some benchmarking, and you can read the article here.

    2 celeron 300A's OCed to 504MHz each
    vs
    2 PIII 500's OCed to 560MHz each

    there were a couple of differences in the systems, but the celerons beat the pIII's in almost every test... they're the only numbers i've seen on this issue - interesting at the very least

  18. Re:Could happen by Jonathan_S · · Score: 1 · on Petition Intel Not to Disable SMP Celerons

    Two things. First Coppermine dispite its name doesn't use copper interconnects. Intel isn't scheduled to use copper interconnects until the first proc they design for .13 (Deerfield if memory servers) sometime in 2001. Second Ars Technica has an article that covers why it would be difficult for intel to disable SMP. Basically the SMP pin has to have voltage to work, so not only does intel have to cut the pin, they then have to run 1.5V power to it inside the chip casing or on-die.

  19. Celeron faster than PIII? by larien · · Score: 1 · on Petition Intel Not to Disable SMP Celerons

    It's also worth bearing in mind that sometimes the Celeron can be faster than an equivalent MHz PIII (I think it's something to do with having a faster cache speed). Check out this article over at Ars Technica. Disabling Celeron SMP would effectively reduce the chances of Intel having the fastest x86 based system even more (especially now that AMD have managed to overtake Intel FPU performance).
    --

  20. Celeron faster than PIII? by larien · · Score: 1 · on Petition Intel Not to Disable SMP Celerons

    It's also worth bearing in mind that sometimes the Celeron can be faster than an equivalent MHz PIII (I think it's something to do with having a faster cache speed). Check out this article over at Ars Technica. Disabling Celeron SMP would effectively reduce the chances of Intel having the fastest x86 based system even more (especially now that AMD have managed to overtake Intel FPU performance).
    --

  21. Ars Technica by coj · · Score: 1 · on Tom on the Athlon (And an Intel Conspiracy?)
    There are lots and lots of hardware sites, but the best one I've seen is Ars Technica.

    http://www.arstechnica.com

    -Ed

  22. Perhaps, how about the G4? by ToLu+the+Happy+Furby · · Score: 1 · on Athlon Reviews

    As has been pointed out, the "Pentium Toaster" ads only used the Bytemark benchmark, which is extraordinarily old and has very little relevance to the sorts of things CPUs do these days. For one thing, it includes no floating point tests at all, IIRC--and these days, most things the average user (i.e. no compiling) runs into that'll tax his/her CPU are floating point dependant. And furthermore, (also pointed out before), the MacOS hampers performance considerably. And if you want to do any sort of multitasking at all, it hampers it hilariously. Obscenely, even. Check out this article at the always impressive Ars Techinca for some ROFL confirmation. To be fair, this was benched before OS 8.6, which allows (gasp!) multithreading...but if I understand correctly, apps need to be rewritten to take advantage of it anyways.

    As for real, cross-platform, general CPU benchmarks, there's pretty much only SPEC, limited as it is. Yes, to some degree it depends on issues of compilers, chipsets, RAM, etc. But it's good enough to at least be relevant.

    Apparently, as far as SPEC95 goes, the G3 is about 14% faster/MHz than a P3 in SPECint, and about 9% slower/MHz than a P3 in SPECfp. Course, the G3 doesn't come anywhere near close to the P3 or K7 in MHz terms anyways.

    And double of course, what really matters is app performance. Here, assuming one stays with the MacOS, we run into some serious problems. Essentially, ClarisWorks (now AppleWorks?) was way more optimized for Mac than PC (duh), and it showed. Photoshop is probably equally optimized for both--and no, contrary to what you've heard, it isn't necessarily faster on the Mac. Look a bit further in the Ars article above: turns out that while the Mac wins the Gaussian blur test w/64 megs RAM...it loses with 128 megs on a 100MB file...it loses on the lighting effects (FP intensive) tests...and, this is the big one, it takes 3 times longer to load the 100 MB TIFF in the first place. Woops. And as for, say, anything made by the Microsoft corporation, don't even bother: to say it's better optimized for PC is the understatement of the year. IIRC, MacOffice97 worked by just porting the relevant Win95 API's and keeping the program itself the same. MacOffice98 might be better...but not by too much.

    Obviously, none of the above applies to K7 vs. P3 discussions--except, of course, for 3DNow(!) stuff, but by now most all video card drivers etc. are quite well optimized for 3DNow, and with AMD having the fastest chip on the market, that'll only improve. In any case, just read all the K7 reviews above, and you'll see that this thing doesn't just chew up the P3 in one or two CPU benchmarks...it whups it handily in just about everything. Synthetic benchmarks, Winstone, games, encoding, rendering, you name it. And this is before apps are optimized for it (new 3DNow instructions; 3-issue FPU unit, etc. all could benefit from optimizations).

    [Note: from here on out, I'm pretty much talking out the ass of this page here on JC's News. Dunno how accurate it all is, but JC generally knows quite a bit about what he's talking about. And I've read some other stuff that backs him up.]

    Now about the G4...well, it seems that the design goals of the G4 were to get SPECint 20 and SPECfp 20 @450MHz (I've heard this elsewhere, although I don't recall a mention of 450 specifically)--implying that it will run at around 450 on introduction. Now, the K7 at 600 beats both of those marks handily, and indeed if you assume, as JC does, that SPEC scales linearly (course it doesn't, but...) then the G4 is just a hair slower at SPECint (and exactly the same at 500MHz as the G3. Anyone else out there know if the G3 and G4 have exactly the same integer unit?), and a bit faster at SPECfp. Note that I'm not sure if he's using old guesses at the K7's SPEC marks, or real numbers...and I'm too lazy to figure it out right now.

    Now, of course the target goals for the G4 were made back when they said it'd be coming out...well, by now. Instead it's going to ship in "Q3 1999"--where Q3 1999 is read, "January." So we can expect higher MHz on intro than 450.

    Of course, by then, the Athlon'll be at 750 at least. Probably 850. Rumor has it 1GHz. We'll see. In any case, JC goes ahead and pits a projected G4-550 against a (projected?) K7-750...and guess what, the K7 is a hell of a lot faster.

    On the *other* hand, the real wild card in all of this is the G4's AltiVec vector processing unit (for those who don't know, vector processing is the sort of thing Crays (used to?) use--very very good at many things that normal CPUs use floating point to do). On paper, it totally totally kicks ass. Like orders of magnitude faster than SSE/3DNow. And from what I hear, it'll be way easier to optimize for than SSE/3DNow, and waaaaaay easier than MMX (which required assembly programming)--i.e., it might just require a recompile with the "optimize for AltiVec" box checked.

    On the other other hand, with the recent emphasis on nonupgradable machines (with comparitively poor 3D acceleration) in their consumer line, and a reported general lack of attention to gaming among Apple bigwigs (course, this was in some ZDnet story, so who knows if it's true), the amazing power of AltiVec might only end up being used in embedded DSP machines by Motorola and IBM.

    On the fourth hand, if I had an iBook I could surf the internet while I was in the bathroom. Draw your own conclusions.

  23. Perhaps, how about the G4? by ToLu+the+Happy+Furby · · Score: 1 · on Athlon Reviews

    As has been pointed out, the "Pentium Toaster" ads only used the Bytemark benchmark, which is extraordinarily old and has very little relevance to the sorts of things CPUs do these days. For one thing, it includes no floating point tests at all, IIRC--and these days, most things the average user (i.e. no compiling) runs into that'll tax his/her CPU are floating point dependant. And furthermore, (also pointed out before), the MacOS hampers performance considerably. And if you want to do any sort of multitasking at all, it hampers it hilariously. Obscenely, even. Check out this article at the always impressive Ars Techinca for some ROFL confirmation. To be fair, this was benched before OS 8.6, which allows (gasp!) multithreading...but if I understand correctly, apps need to be rewritten to take advantage of it anyways.

    As for real, cross-platform, general CPU benchmarks, there's pretty much only SPEC, limited as it is. Yes, to some degree it depends on issues of compilers, chipsets, RAM, etc. But it's good enough to at least be relevant.

    Apparently, as far as SPEC95 goes, the G3 is about 14% faster/MHz than a P3 in SPECint, and about 9% slower/MHz than a P3 in SPECfp. Course, the G3 doesn't come anywhere near close to the P3 or K7 in MHz terms anyways.

    And double of course, what really matters is app performance. Here, assuming one stays with the MacOS, we run into some serious problems. Essentially, ClarisWorks (now AppleWorks?) was way more optimized for Mac than PC (duh), and it showed. Photoshop is probably equally optimized for both--and no, contrary to what you've heard, it isn't necessarily faster on the Mac. Look a bit further in the Ars article above: turns out that while the Mac wins the Gaussian blur test w/64 megs RAM...it loses with 128 megs on a 100MB file...it loses on the lighting effects (FP intensive) tests...and, this is the big one, it takes 3 times longer to load the 100 MB TIFF in the first place. Woops. And as for, say, anything made by the Microsoft corporation, don't even bother: to say it's better optimized for PC is the understatement of the year. IIRC, MacOffice97 worked by just porting the relevant Win95 API's and keeping the program itself the same. MacOffice98 might be better...but not by too much.

    Obviously, none of the above applies to K7 vs. P3 discussions--except, of course, for 3DNow(!) stuff, but by now most all video card drivers etc. are quite well optimized for 3DNow, and with AMD having the fastest chip on the market, that'll only improve. In any case, just read all the K7 reviews above, and you'll see that this thing doesn't just chew up the P3 in one or two CPU benchmarks...it whups it handily in just about everything. Synthetic benchmarks, Winstone, games, encoding, rendering, you name it. And this is before apps are optimized for it (new 3DNow instructions; 3-issue FPU unit, etc. all could benefit from optimizations).

    [Note: from here on out, I'm pretty much talking out the ass of this page here on JC's News. Dunno how accurate it all is, but JC generally knows quite a bit about what he's talking about. And I've read some other stuff that backs him up.]

    Now about the G4...well, it seems that the design goals of the G4 were to get SPECint 20 and SPECfp 20 @450MHz (I've heard this elsewhere, although I don't recall a mention of 450 specifically)--implying that it will run at around 450 on introduction. Now, the K7 at 600 beats both of those marks handily, and indeed if you assume, as JC does, that SPEC scales linearly (course it doesn't, but...) then the G4 is just a hair slower at SPECint (and exactly the same at 500MHz as the G3. Anyone else out there know if the G3 and G4 have exactly the same integer unit?), and a bit faster at SPECfp. Note that I'm not sure if he's using old guesses at the K7's SPEC marks, or real numbers...and I'm too lazy to figure it out right now.

    Now, of course the target goals for the G4 were made back when they said it'd be coming out...well, by now. Instead it's going to ship in "Q3 1999"--where Q3 1999 is read, "January." So we can expect higher MHz on intro than 450.

    Of course, by then, the Athlon'll be at 750 at least. Probably 850. Rumor has it 1GHz. We'll see. In any case, JC goes ahead and pits a projected G4-550 against a (projected?) K7-750...and guess what, the K7 is a hell of a lot faster.

    On the *other* hand, the real wild card in all of this is the G4's AltiVec vector processing unit (for those who don't know, vector processing is the sort of thing Crays (used to?) use--very very good at many things that normal CPUs use floating point to do). On paper, it totally totally kicks ass. Like orders of magnitude faster than SSE/3DNow. And from what I hear, it'll be way easier to optimize for than SSE/3DNow, and waaaaaay easier than MMX (which required assembly programming)--i.e., it might just require a recompile with the "optimize for AltiVec" box checked.

    On the other other hand, with the recent emphasis on nonupgradable machines (with comparitively poor 3D acceleration) in their consumer line, and a reported general lack of attention to gaming among Apple bigwigs (course, this was in some ZDnet story, so who knows if it's true), the amazing power of AltiVec might only end up being used in embedded DSP machines by Motorola and IBM.

    On the fourth hand, if I had an iBook I could surf the internet while I was in the bathroom. Draw your own conclusions.

  24. Go to Ars-Technica by Anonymous Coward · · Score: 0 · on Athlon Reviews

    Check out the review at Ars. the benchmarks are clearly explained, IMO, and thye writer doesn't just kiss Athlon ass like so many other sites are doing. Sure, they recognize that the performance is superior than that of the P6, but any red-blooded CPU lover knows that AMD has been in a similar position before: capable of kickin' Intel, but not capable of producing in quanity, while making money.

  25. Re:what about the one at ars? by lost_packet · · Score: 1 · on Athlon Reviews
    check it

    wherever your socks go (you know, the ones that don't come out of the dryer), I bet you'll find a whole lotta HTML tags that disappear from comments.

  26. Re:How will the SGIs and HPs survive? by The+Dodger · · Score: 1 · on SGI Faces Another Reorganization

    I just don't get it. How can companies such as SGI and HP bank on Intel chips for their future servers?

    FYI: IA-64 was a joint development between Intel and HP.

    Without control over such a key piece of technology,

    Control has little to do with it. If Intel stopped supplying SGI with hardware, the DoJ would stomp all over them.

    these companies will have little to distinguish themselves from the competition.

    SGI's Intel machines have a heck of a lot to distinguish them from the Dells, HPs and Compaqs... See this interesting and informative article at Ars Technica for details.

    Sun made the right decision to not embrace their technologies as Sun's core future direction.

    Note, however, that they intend to port and support Solaris on IA-64.

    D.
    ..is for Deadly.

  27. Go to ars technica by Anonymous Coward · · Score: 0 · on Another Wierd Linux Box

    On ars technica and to the right there is a column of links. Find the one called open forum and there one of the topics is case and cooling fetish. There is alot of suggestions there on cases ,style wise and whatnot. Ars technica also has many case reviews. I prefer arstechnica over slashdot cause they don't post half truths like slashdot. Slashdot has no professionalism, ie spelling errors in coverage and just too linux religious . These guys have a more level headed view of stuff. You use stuff cause it works, not because Rob Malda said it was cool.

  28. Re:Micro$oft wouldn't MATTER *IF* by Digital_Fiend · · Score: 1 · on Review:The Plot to Get Bill Gates
    You ever used Visual C++, big guy?


    And no, Linux will never ever ever ever ever take down the dominance of Windows in the desktop environment.


    Please get help if you think otherwise.


    You have to remember that many people can do little more than turn it on and click mouse buttons.


    The open source movement is kind of cool for geeks, but it will never take down Windows.


    In the server market, I don't know. It will probably grow in there.


    But like, the common user wants to turn it on and have it work, not mess with configuration files (you think they're going to use console only? YEAH RIGHT) and log output of the X server to see what's going wrong. Hell, they probably wouldn't even want to run a configuration program (XF86Config) if they didn't absolutely have to.


    All the power to linux, it is becoming less of a nerd OS. It is becoming more of a "power user" OS. And one thing.. WORK ON THE BLOODY TCP/IP KERNEL ALREADY!@#$%^!

    and one last thing.. many open source advocates are really ssholes. I'm serious. one reviewer at arstechnica.com got an email saying,"if the cure to cancer were not 'open source' (?), then I'd rather have everyone die!". Umm. Okie dokie, then.


    The whole point behind open source is so that you can make modifications to the program (or OS) and make it better. I wonder what percentage of the Linux user base has contributed to the kernel?


    In many cases, open source is not necessary. If a text editor you are using does not have a certain feature, just find another one that does. It'd be a lot simpler than implementing what you wanted yourself. Oh, wait, I forgot, lots of Linux users are perfectly happy using an editor that has "insert mode" and "editing mode". How gay and unnecessary.

  29. What makes SGI great graphics machines... by The+Dodger · · Score: 3 · on NVIDIA and SGI Align

    It's not just the video card that makes SGIs good boxes...

    Exactly. One of SG's strengths in the workstation market has long been their ability to shift data around the motherboard at very high speeds. Have a look at Ars Technica's article about the new SGI NT machines for some information on the sort of approach SG have to designing boxes.

    Best of all, they're planning to support Linux on this range of beasts!

    The Dodger

  30. Celeron SMP Performance by James+Lanfear · · Score: 2 · on SMP Linux on the Cheap

    Here's a story at Ars Technica comparing dual Celerons to dual PIII's, both oc'ed. Results were suprising, to say the least.

    (I don't believe this is a fluke, either. My machine is basically the nerd box, but at 464, and it is thus far is proving to faster than I expected, close to PIII 500 speed (without SSE, of course).)

  31. Re:Apples and Oranges - no, CPU and CPU by ToLu+the+Happy+Furby · · Score: 1 · on Intel Undercuts AMD

    Just a nitpick, but the original Pentium was a P5--it came after the 486, Intel's 4th generation chip. The first P6 chip was the PentiumPro, released way back in 96, which amazingly enough contained a full-speed L2 cache of up to 1MB--essentially, a Xeon years before the PII!

    And, no, CPU generation numbers aren't arbitrary at all--for a CPU to be a new generation, it needs an entirely new core, not just a little tack-on unit like MMX or KMI, or a change in packaging like socket to slot.

    Now, the PII was a generation above the Pentium and Pentium MMX, because it used, that's right, a completely different core--the PPro core. The slot packaging was required because they decided to have an external 512k L2 cache, and couldn't fit it on the processor die; but that is irrelevent with respect to generation number. Thus, the celeron, available in both slot and socket configs, is a P6, as will be the Coppermine PIIIs, also available in both slot and socket, as are the PII/III Xeon's, which have the enormously humongous Slot 2 packaging.

    Now, of course, in a sense generation numbers are arbitrary; if I personally design 7 different CPU cores, the 7th one won't be better than a PIII, because I don't know what the hell I'm doing. And furthermore, the K7 isn't actually AMD's seventh generation chip, AFAIK--I think their first chip core was a 386 clone.

    But still, the point remains that the K5 was essentially equal to a P5, and the K6 to a P6, so calling the K7 (which is indeed completely new compared to the K6) a seventh generation chip seems fair to me.

    On a related note, Intel's 7th generation IA-32 (as opposed to IA-64, the new 64-bit VLIW instruction set chips that will be inaugurated next year (perhaps!) with Merced) chip, Willamette, isn't expected until Q3 of next year. Rumor has it it will have a SPECint of ~40 at 1100Mhz when introduced--probably putting it slightly, although definitively, ahead of the K7 at the same Mhz. And, just as the K7 should scale to much greater clock speeds than the P6 core, Willamette will presumably (of course this is complete speculation) scale higher than the K7 core. Of course, if the laughingstock that Merced has become is any indication, Intel is having trouble designing new chips these days (to be fair, a chip based on an entirely new instruction set, and an entirely new philosophy (VLIW vs. CISC) presents a larger engineering challange than a new chip generation).

    Meanwhile, AMD took the K7 design from 0 to production in 17-months--and they're already started on the K8. Which means that if they finish that one as quickly as they did the K7, Willamette's stint at the top of the x86 performance heap could be very short indeed...

  32. Re:this is just silly by ToLu+the+Happy+Furby · · Score: 1 · on Intel Undercuts AMD

    Actually, in effect Intel did underclock the celerons, ridiculous as it may seem to you and your father. And ridiculous as it may sound to most of us. I'm guessing the reason you think it's so ridiculous, is that your father used to work in a fab. Because, up until about a year ago, the single-minded goal of every semiconductor fab was indeed to produce the highest yield of the fastest chips at the lowest cost. But then, in the case of Intel at least, this rosy picture was forever shattered by the nefarious forces of [cue dark clouds and threatening music]...marketing.

    You see (and it amazes me how many slashdotters seem not to know this--I suppose it's because most of you play with computers at work, where such things are a no-no, or perhaps because as Linux users you prize stability over flashy game performance), there was a period of time--about nine months or so IIRC, starting early last summer--when the most expensive consumer CPU money could buy was the PII 450, and the fastest consumer CPU money could buy was...the celeron 300A.

    Yup, I just said that. Huh? Well, suspiciously enough, it turned out that ~95% (maybe more; hard stats are of course impossible to come by, so most people just said 95% to emphasize that it wasn't guranteed or anything) of 300A's could be overclocked to 450, with completely perfect stability (well, since the overclocking community is mostly gamers, and gamers are generally stuck with Win9x, it's hard to know how stable the things really are;), and often no extra cooling required. Plus, since the jump from 300=>450 corresponds to changing the bus speed from 66 Mhz to 100, all your peripherals run fine and dandy as well (some PCI cards, RAM, etc, fare poorly when asked to run at unorthodox bus speeds like 82 Mhz).

    And, for many tasks, including just about the only comsumer-oriented programs these days that can use more computing power than, say, a K6-300 can offer--3D gaming--these celeron 300/450's and their full-speed 128k cache were actually faster than those PII 450's and their half-speed 512k cache...which cost around 8 times as much.

    Now, why, you may ask, did such a silly situation come about? And why, if all these celerons they were turning out could run just fine at 450, and they could sell 450 Mhz chips for ~$600, did Intel brand them at 300 Mhz and sell them for ~$80??

    Well, remember the ominous mention of marketing at the end of the first paragraph?? Well that was just foreshadowing for the part that comes here:

    See, around the middle of last year, Intel was running into a bit of a problem, alluded to above: namely, that Moore's law was churning along fine and dandy on the hardware side, but that the software corrolary to it--that, as fast as CPU's get faster, there will be applications developed that will seem to run slow--was falling worrisomely behind. Half of this was Microsoft's fault: their bloatware, which Intel had always been able to count on in the past to consume resources at an exponential rate, was now becoming so bloated that they couldn't cobble together new versions of it that would work--thus, the year-plus long delays on the products which have since been renamed Office2000 and Win2000. The other half, of course, was the internet's fault; or, more precisely, the phone wire's fault: when your connection is peaked out at its theoretical limit of 56k, adding processor speed ain't gonna do you much good, no matter what the funny dancing space people in the shiny suits tell you.

    AMD, heretofore the company-of-the-cheap-knockoff-486, was suddenly in a position to be a respectable CPU company--first off, because their new K6 was just as fast as the PII in integer computations, and secondly, because you suddenly didn't need the fastest CPU out there to have a computer that would run the latest software and do the latest cool thing--surf the net. Thus, the sub-$1000 market was born. And Intel's marketing departement, being the little monopolizers that they are, and realizing that the more people bought non-Intel PC's and found that the things still worked, the more likely they'd be to do it again, decided that they needed to mingle with the rabble and offer a chip for the sub-$1000 market themselves.

    Now we come to the point in our story where marketing and technology tragically collide. You see, the way fabs are run today, there simply is no "cheaper and less effective manufacturing process" to use, especially if, like Intel then, you didn't realize a couple years ago that you'd want to have one. That is, using a less effective manufacturing process would paradoxically have been more expensive.

    This is because, for one thing, semiconductor fabs basically only have one assembly line each; that is, if you already have a fab that you've upgraded to the state of the art, and now you for some odd reason want to have a process that's less than state of the art, you need to build a new fab. And, for another, the cost of building a fab that is state of the art compared to one that's a bit less lies mainly in R&D, which in this case had already been done.

    And--this is the kicker--the three things that determine the top speed a chip can run at stably are 1) core design; 2) manufacturing quality; and 3) process size. Now, obviously if Intel wants to make the cheapest chip they can, they don't want to come up with a new core design, so they didn't--they used the PII and just lopped off the L2 cache; and other than changing to a lower process size, manufacturing quality issues are mainly R&D things that got ironed out in the course of pushing the Mhz of their PII line. And besides, you save more money making chips the best you know how, so that absolutely none of them will not run at 300 Mhz, than you do making them purposely badly and having some that don't pass the test. Now, they may still have had some .35 micron fabs around when they decided to make the celeron...but using them to make a low cost chip would have been especially stupid, because higher process size means larger die size, means more silicon per chip, means higher cost per chip.

    Thus, the original celeron--a PII with no L2 cache, and SMP crippled. (This only involves grounding a single pin which otherwise is used to assign which chip is #1 and which is #2 in a dual-PII system, and is thus easily surmounted--until, as is rumored, Intel comes up with a trickier way to do it. My point in including this little tidbit is that it forms a parallel to underclocking the chips--that is, it's a change included not because it costs any more or less for Intel to manufacture--it's exactly the same--but because it disables a feature for the customer.) However, with no cache, they ran about as fast as a dead three-legged hippopotamus, and therefore sold about as well.

    So, realizing that it was even worse for customers to begin to associate them with horrible chips than to begin to associate AMD with decent ones, Intel took the plunge, added 128k of full speed on-die L2 cache to the celeron, thus creating the wonder that was (sadly, it's no longer manufactured) the 300A (A to differentiate it from the cacheless 300), and marking the first time in a hell of a long time that Intel had sold a chip for less than 20% more than it costs to make it (IIRC, it costs them ~$60 to fab a celeron, and ~$70 for a PII/III--the difference, as we should have learned by now, is not in getting higher clock speeds, but in the extra silicon required for the 512k cache, and, in the case of the socket-based celerons, in the extra packaging of a slot as opposed to a socket design).

    Now, we may ask--if these puppies could run at 450 Mhz (and in fact it proved much easier to get a chip + full-speed on-die cache to run at 450 than the chip + half-speed external cache of the PII), why only sell them at 300? The answer, of course, is that terrible marketing thing: the entire reason for the celeron line was because Intel needed something at the sub-$100/CPU price-point. Now, at the same time, they didn't want anyone stupid enough to pay them $600 for a (slower, remember) PII 450 to realize they were being royally ripped off. And same with the goofball (in my woeful ignorance, that'd be me) who spent $250 for a PII 350. And so on down the line.

    And, as we've seen, there was no good way to make chips that couldn't technically run at 450--in fact they discovered a better way to make chips run at high speeds, and that's why starting with Coppermine, all Intel chips will have on-die caches. But they could configure the chips to run at a much slower speed than they were capable of.

    And that's exactly what they did.

    And are still doing, although to a much lesser extent; nowadays, the .25 micron process is running out of room: that's why you can't expect to take a celeron 400 and clock it up to 600 and still, say, boot. Plus, the celeron is of course lacking the P!!!'s whoop-de-do SIMD instructions (so it can't browse the web worth a damn;).

    And, whew, this ended up being a lengthy post. What I've said can be backed up at pretty much any website for hardware enthusiasts ( ArsTechnica has a particularly well-written explanation of the marvel that was the 300A here and especially here.)

    Bottom line is, the x86 market is all about marketing and price points. And now that AMD has the technology to beat them in every segment of that market, Intel is gonna have to do a lot of the former and start giving in on the latter. And if you've read this whole thing, you must be bored.

  33. Re:this is just silly by ToLu+the+Happy+Furby · · Score: 1 · on Intel Undercuts AMD

    Actually, in effect Intel did underclock the celerons, ridiculous as it may seem to you and your father. And ridiculous as it may sound to most of us. I'm guessing the reason you think it's so ridiculous, is that your father used to work in a fab. Because, up until about a year ago, the single-minded goal of every semiconductor fab was indeed to produce the highest yield of the fastest chips at the lowest cost. But then, in the case of Intel at least, this rosy picture was forever shattered by the nefarious forces of [cue dark clouds and threatening music]...marketing.

    You see (and it amazes me how many slashdotters seem not to know this--I suppose it's because most of you play with computers at work, where such things are a no-no, or perhaps because as Linux users you prize stability over flashy game performance), there was a period of time--about nine months or so IIRC, starting early last summer--when the most expensive consumer CPU money could buy was the PII 450, and the fastest consumer CPU money could buy was...the celeron 300A.

    Yup, I just said that. Huh? Well, suspiciously enough, it turned out that ~95% (maybe more; hard stats are of course impossible to come by, so most people just said 95% to emphasize that it wasn't guranteed or anything) of 300A's could be overclocked to 450, with completely perfect stability (well, since the overclocking community is mostly gamers, and gamers are generally stuck with Win9x, it's hard to know how stable the things really are;), and often no extra cooling required. Plus, since the jump from 300=>450 corresponds to changing the bus speed from 66 Mhz to 100, all your peripherals run fine and dandy as well (some PCI cards, RAM, etc, fare poorly when asked to run at unorthodox bus speeds like 82 Mhz).

    And, for many tasks, including just about the only comsumer-oriented programs these days that can use more computing power than, say, a K6-300 can offer--3D gaming--these celeron 300/450's and their full-speed 128k cache were actually faster than those PII 450's and their half-speed 512k cache...which cost around 8 times as much.

    Now, why, you may ask, did such a silly situation come about? And why, if all these celerons they were turning out could run just fine at 450, and they could sell 450 Mhz chips for ~$600, did Intel brand them at 300 Mhz and sell them for ~$80??

    Well, remember the ominous mention of marketing at the end of the first paragraph?? Well that was just foreshadowing for the part that comes here:

    See, around the middle of last year, Intel was running into a bit of a problem, alluded to above: namely, that Moore's law was churning along fine and dandy on the hardware side, but that the software corrolary to it--that, as fast as CPU's get faster, there will be applications developed that will seem to run slow--was falling worrisomely behind. Half of this was Microsoft's fault: their bloatware, which Intel had always been able to count on in the past to consume resources at an exponential rate, was now becoming so bloated that they couldn't cobble together new versions of it that would work--thus, the year-plus long delays on the products which have since been renamed Office2000 and Win2000. The other half, of course, was the internet's fault; or, more precisely, the phone wire's fault: when your connection is peaked out at its theoretical limit of 56k, adding processor speed ain't gonna do you much good, no matter what the funny dancing space people in the shiny suits tell you.

    AMD, heretofore the company-of-the-cheap-knockoff-486, was suddenly in a position to be a respectable CPU company--first off, because their new K6 was just as fast as the PII in integer computations, and secondly, because you suddenly didn't need the fastest CPU out there to have a computer that would run the latest software and do the latest cool thing--surf the net. Thus, the sub-$1000 market was born. And Intel's marketing departement, being the little monopolizers that they are, and realizing that the more people bought non-Intel PC's and found that the things still worked, the more likely they'd be to do it again, decided that they needed to mingle with the rabble and offer a chip for the sub-$1000 market themselves.

    Now we come to the point in our story where marketing and technology tragically collide. You see, the way fabs are run today, there simply is no "cheaper and less effective manufacturing process" to use, especially if, like Intel then, you didn't realize a couple years ago that you'd want to have one. That is, using a less effective manufacturing process would paradoxically have been more expensive.

    This is because, for one thing, semiconductor fabs basically only have one assembly line each; that is, if you already have a fab that you've upgraded to the state of the art, and now you for some odd reason want to have a process that's less than state of the art, you need to build a new fab. And, for another, the cost of building a fab that is state of the art compared to one that's a bit less lies mainly in R&D, which in this case had already been done.

    And--this is the kicker--the three things that determine the top speed a chip can run at stably are 1) core design; 2) manufacturing quality; and 3) process size. Now, obviously if Intel wants to make the cheapest chip they can, they don't want to come up with a new core design, so they didn't--they used the PII and just lopped off the L2 cache; and other than changing to a lower process size, manufacturing quality issues are mainly R&D things that got ironed out in the course of pushing the Mhz of their PII line. And besides, you save more money making chips the best you know how, so that absolutely none of them will not run at 300 Mhz, than you do making them purposely badly and having some that don't pass the test. Now, they may still have had some .35 micron fabs around when they decided to make the celeron...but using them to make a low cost chip would have been especially stupid, because higher process size means larger die size, means more silicon per chip, means higher cost per chip.

    Thus, the original celeron--a PII with no L2 cache, and SMP crippled. (This only involves grounding a single pin which otherwise is used to assign which chip is #1 and which is #2 in a dual-PII system, and is thus easily surmounted--until, as is rumored, Intel comes up with a trickier way to do it. My point in including this little tidbit is that it forms a parallel to underclocking the chips--that is, it's a change included not because it costs any more or less for Intel to manufacture--it's exactly the same--but because it disables a feature for the customer.) However, with no cache, they ran about as fast as a dead three-legged hippopotamus, and therefore sold about as well.

    So, realizing that it was even worse for customers to begin to associate them with horrible chips than to begin to associate AMD with decent ones, Intel took the plunge, added 128k of full speed on-die L2 cache to the celeron, thus creating the wonder that was (sadly, it's no longer manufactured) the 300A (A to differentiate it from the cacheless 300), and marking the first time in a hell of a long time that Intel had sold a chip for less than 20% more than it costs to make it (IIRC, it costs them ~$60 to fab a celeron, and ~$70 for a PII/III--the difference, as we should have learned by now, is not in getting higher clock speeds, but in the extra silicon required for the 512k cache, and, in the case of the socket-based celerons, in the extra packaging of a slot as opposed to a socket design).

    Now, we may ask--if these puppies could run at 450 Mhz (and in fact it proved much easier to get a chip + full-speed on-die cache to run at 450 than the chip + half-speed external cache of the PII), why only sell them at 300? The answer, of course, is that terrible marketing thing: the entire reason for the celeron line was because Intel needed something at the sub-$100/CPU price-point. Now, at the same time, they didn't want anyone stupid enough to pay them $600 for a (slower, remember) PII 450 to realize they were being royally ripped off. And same with the goofball (in my woeful ignorance, that'd be me) who spent $250 for a PII 350. And so on down the line.

    And, as we've seen, there was no good way to make chips that couldn't technically run at 450--in fact they discovered a better way to make chips run at high speeds, and that's why starting with Coppermine, all Intel chips will have on-die caches. But they could configure the chips to run at a much slower speed than they were capable of.

    And that's exactly what they did.

    And are still doing, although to a much lesser extent; nowadays, the .25 micron process is running out of room: that's why you can't expect to take a celeron 400 and clock it up to 600 and still, say, boot. Plus, the celeron is of course lacking the P!!!'s whoop-de-do SIMD instructions (so it can't browse the web worth a damn;).

    And, whew, this ended up being a lengthy post. What I've said can be backed up at pretty much any website for hardware enthusiasts ( ArsTechnica has a particularly well-written explanation of the marvel that was the 300A here and especially here.)

    Bottom line is, the x86 market is all about marketing and price points. And now that AMD has the technology to beat them in every segment of that market, Intel is gonna have to do a lot of the former and start giving in on the latter. And if you've read this whole thing, you must be bored.

  34. Re:Why must we use 3com's mail service? by CrezzyMan · · Score: 1 · on Palm VII vs BlackBerry
    If this device has real Internet connectivity

    From what I read of Ars Technica's report on the Palm VII it uses two-way pager technology, which is

    1. very slow
    2. doesn't provide a constant connection
    I'm sure someone will eventually write a PQA (Palm Query App) to go and get your mail from a POP server, unless the palm.net proxies aren't built for this kind of service.
  35. Re:I have removed teh cards with no problems... by tzanger · · Score: 1 · on CPU Cooling Insanity

    this is what I was looking for

    Thank you!

  36. There are MOBO'S and there are MOBO's by Griffone · · Score: 2 · on Ask Slashdot: Reliable Powering of ATX Systems?

    Some of the comments I've seen hit it on the head: The Brand + Model + Revision of Motherboard you buy is key for ANY system (esp. a server).

    Myself I don't like buying anything I haven't researched to death; I also really want to hear what other people's experience has been with the stuff. (note: people I trust... not some script kiddie; though on /. you can usually tell which are which)

    Checking Tom's Site and Ars Techina to see what they think doesn't hurt either.

    As far the Power-Always-On feature you want well, 3 things:

    1) I would not recommend any soldering at all as your warranty will most likely go out the window. This can be a very bad thing in a corporate environment.

    2) Most high quality Motherboards come with either a CMOS or Jumper setting (or combo) which tells the PS what to do when power is applied.

    3) A good case goes a long way... both in ensuring you have a quality PS, and that you won't slice your fingers when you need to work on it. (Can we have a poll on how many times we've done that? :) ) You'll want to make sure the PS is compliant with ATX 2.01 to be on the safe side too.


    As far as personal choices, I'm a big fan of both Supermicro Motherboards and Cases - my personal fav is the SC-701a style case - it's a beauty! but unfortunately its soon to be discontinued... :(

    Anyway, just my $0.02 (which is worth even less as its Canadian...)

  37. Weblogs are great by yoz · · Score: 3 · on Here Come The Weblogs

    These days I get most of my web reading from links on weblogs of one kind or another - I'd personally count Slashdot as a weblog. I read Ars Technica, Scripting News, Robot Wisdom and Tomalak's Realm, and I'm on Haddock which has several great links every day.

    NTK is often listed as a weblog, innaccurately - it's a weekly mag. But it's completely brilliant. Subscribe.

    Also, h2g2.com (The HitchHiker's Guide To The Galaxy, online) has, amongst its many fab features, the ability for users to create their own weblogs on their homepages, with forums hanging off each entry. Worth a look, and I'm not just saying that 'cos I work there.

  38. Ars Technica article, Chron X by Robotech_Master · · Score: 2 · on Virtual Property Revisited

    Y'know, over on Ars Technica there's a very interesting interview with the lady who paid $2025 for an Ultima Online account, which sheds some light on the decision from her point of view.

    It all boils down to the old economic principle of "opportunity cost" in making a decision . . . she had the money, and of all the alternatives on which she could spend it, this was the most attractive to her.

    She's no rank newbie trying to buy her way into riches, either--she'd played the game since October 1997. The main reason for the purchase, she says, was the impossibility of acquiring "real estate" in UO anymore.

    And of course, games involving real money for virtual property aren't new. I've yet to see anyone mention Chron X, an Internet CCG where you use your credit card to pay real money for virtual cards...

  39. The benchmarks are fake by Anonymous Coward · · Score: 0 · on K7 vs. Pentium III benchmarks

    Check out this thread on Ars Technica's BBS.

    http://www.arstechnica .com/forum/ubb/Forum1/HTML/001407.html

  40. Re: ISO mirror list from Ars Technica by Latrell+Sprewell · · Score: 3 · on Free Red Hat 6.0 CDs

    Here's a listing of places that you can download an ISO of the RedHat 6.0 CD, courtesy of Ars Technica.

    ftp://o su-linux.capital.ous.edu/pub/linux/redhat/iso/hedw ig.i386.iso9660.gz

    ftp://pricie.ccl.kuleuven.ac.be/pub/rh 60.iso

    ftp://ftp.s ervers.cx/pub/mirrors/linux/hedwig-27apr1999.i386. iso9660.gz

  41. If LOC is the ultimate measure of productivity... by sundae · · Score: 1 · on American Programmers are Slackers
    ... then Beethoven is definitely a slacker, when comparing to Mozart. Afterall, Beethoven only wrote 9 symphonies, Mozart wrote over 40.

    However, both Beethoven and Mozart are considered to be masters of all Ages, with equal fame and respect. Yet, nobody ever would say Beethoven is a slacker. One of the underlying reason is, Beethoven carefully crafted and tweaked his work to make sure they're Perfect. I'm not saying Mozart does not care about the quality, it's just that Beethoven spent much more time on that.

    One may argue that things are different in the programming world. Yes, indeed. Here, "laziness" is actually considered a skill to master by many programmers. (Most of the time this has to do with Perl.) Often, it is the lazy nature of many programmers to motivate them into code reuse and optimization (and debugging and testing also, in some extent, to save their lives before the software crashes in front of the customers and get fired). I mean, who would like to type a 200-line code block over and over in the code base, each block only slightly different than others? We probably wouldn't have programming languages, and continue to program in 1's and 0's only, if we're not lazy, let alone the stdio.h, or even gcc itself!

    Using LOC to measure productivity is then essentially as effective as measuring time spent sitting in the cubicle, which, as we all know, is useless. Just as useless as measuring MIPS of the CPU (as seen in Ars Technica's article about benchmarking).

    That said, if LOC is used as "THE" measure of productivity... I guess many people are more "productive" in email + newsgroup + /. than in code. And, if it's actually considered the measure of productivity, I'll put in snipplets of "Hello World!" program -- 500-line version -- in my current code (it's just a matter of cut and paste).

  42. Computer styling by John+Siracusa · · Score: 1 · on Dell is Building iMac Lookalikes

    or, Why your computer will "come in colors" too.

    I hate to link off-site, but here's a lengthy (and refreshingly flame/troll free) discussion of computer styling.

    Check it out.

  43. Was it GUID? by RebornData · · Score: 1 · on Melissa suspect arrested

    The Wired article about this drew an implied connection that David Smith was Vicodin ES, with the obvious implication to us slashdot regulars that he was found via GUID. But I haven't seen any real evidence to back this up.

    As an excellent article on Ars Technica has pointed out, all the GUID shows is who the original document creator was. If someone had taken a previous Vicodin ES virus and modified it to create Melissa, his GUID / MAC address would remain in the "new" virus.

    So is David Smith Vicodin ES? And do they have anything stronger on him than the GUID?

  44. You hit it on the head . . . by pica · · Score: 1 · on Gingrich: No taxes on e-commerce, T1s for all

    Nah, I'm not reading it only for linux... I also read it for the in-depth, unbiased reports and reviews of the latest and greatest hardware. Oh, wait, no... thats Ars Technica. My bad =D