Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Intel Hardware

Will Intel Ship an x86-64bit Chip This Year? 336

Posted by michael from the backward-compatible dept.
Solid Paradox writes "According to The Register, American Technology Research predicts an x86-64-bit processor will 'soon' arrive from Intel and in another story, they also predict that Sun and IBM will be the major players in the future 64-bit boom. Meanwhile the Inquirer has a somewhat related article entitled Senior Intel PR man talks 64-bit extension talk, which follows their Pentium V will launch with 64-bit Windows Elements article that says that the chip is to be sampled internally this month."
This discussion has been archived. No new comments can be posted.

Will Intel Ship an x86-64bit Chip This Year? More

Will Intel Ship an x86-64bit Chip This Year?

Comments Filter:

  • Pentium V (Score:5, Funny)

    by GameGod0 ( 680382 ) on Monday January 05, 2004 @08:20AM (#7879912)
    Quoted from the article:
    "The Pentium V is likely to fly along at between 5GHz to 7GHz, have 2MB plus of level two cache, be built on a 90 nanometer process, and have a stackable design." So, you'll have a 64-bit module sitting on top of your 32-bit CPU?
    Sounds like Sega's 32X to me... except it'll play Doom 1 faster.

    • Re:Pentium V (Score:3, Informative)

      by Crypto Gnome ( 651401 )
      And like most other good Vs (eg V8 and to some extent V6) it'll cost more than most people are prepared to pay.

      Especially considering that to date the HUMONGOUS push by Intel to rev up dem CPUs hase done nothing more than prove beyond any shadow of unertainty that high-RPM engines do not necessarily give the best performance.

      Anyone here old enough to remember the trend towards "turbo charged" engines not so long ago? How many of them are still around?

      • Re:Pentium V (Score:5, Informative)

        by JanneM ( 7445 ) on Monday January 05, 2004 @08:31AM (#7879970) Homepage
        Turbos? Yes, they're around, and quite common too. Difference is, they're not pushed as some kind of macho add-on anymore; instead, the technology is mainly used to improve efficiency (by, among other things, improving accelleration so you can use a smaller, more efficient engine and retain the performance you want). And among small diesels (common in Europe), I'd say turbo diesels are a lot more common than the non-turbocharged variety.

      • Re:Pentium V (Score:3, Informative)

        by bmajik ( 96670 )
        uh.. you might want to stick to talking about computers. because im not sure you know wtf you're talking about when it comes to cars.

        let me give you some basics:

        an engine is an air pump. the more air you send through it in unit time, the more power it makes.

        a great way to get more air into an engine is with forced induction. turbocharging is one route to acheive forced induction.

        where are the turbo cars indeed ?
        - subaru WRX
        - lancer evo 8
        - Audi RS6
        - Dodge SRT-4
        - Porsche 996TT

        these are some of the fast

      • Re:Pentium V (Score:2, Informative)

        by nelsonal ( 549144 )
        The only thing that killed the turbos was the Yen dollar exchange rate in the mid 90s. Let's say that a Supra or 300GT would have cost about 5,000,000 Yen through the entire decade of the 90s. In 1990, the car would be priced at a relativly low $32,000. However by 1995, you needed almost $59,000 to get the same 5 million yen. Too many american consumers would rather have a Corvette, and they begin to approach the price of something really nice from Europe at this point. This is obviously simplistic, a

    • Re:Pentium V (Score:5, Interesting)

      by swordboy ( 472941 ) on Monday January 05, 2004 @08:40AM (#7880015) Journal
      So, you'll have a 64-bit module sitting on top of your 32-bit CPU?

      I've been speculating (here and elsewhere) that this stackable thing is not going to be Intel's next big thing. I believe that the stacked module will simply contain NVRAM and not a 64-bit coprocessor. Why NVRAM? Well, it opens up some interesting possibilities. For example, if you had enough NVRAM on-chip (or reasonably close in terms of latentcy and bandwidth), you could simply shut down portions of the processor on-the-fly to save power. You could also stick the entire operating system on the stuff. The possibilities are amazing. If you haven't looked already, see my journal [slashdot.org] for much information on the subject as it relates to Intel.

      Of recent interest are some [intel.com] presentations [intel.com] by Intel on NVRAM. Of interest is that they've announced that they've found that OUM will take them beyond transistors in one presentation while another presentation actually shows a transistorless cell that is quite simple (two electrodes and a programming material sandwiched in between).

      A transistorless storage device could be the piece that stacks onto the P5.
    • And like the 32X nobody is going to be interested. Either people will buy the 32-bit unstacked version and never change it (but if Windows 64 shows up in 2004, why bother with 32 bits?) or you'll have to buy the pre-stacked system, which will almost certainly cost significantly more than a single-chip AMD x86-64 solution.

      I remember in the early 90s the crud you could buy to turn your 486/33 into a 486/66 DX2 processor. Even then these products were not wildly popular, and at that time it was significantl
      • Don't forget the 386 to "486" upgrade that was offered by Cyrix. I've got a computer somewhere with one of those, although I never noticed much of an improvement from it.
        • Basically, wasn't the 486SX a version of the 386DX with on-chip cache, and better layout internally? BTW, IBM made a 486 that worked on a 386 SX bus, and it went almost as fast as a 486 running on it's native bus.

  • But... (Score:3, Interesting)

    by NeoThermic ( 732100 ) on Monday January 05, 2004 @08:21AM (#7879929) Homepage Journal
    Can it do hardware 32bit as well? Currently the Intel Itanium 64 bit chip has to emulate 32bit for applications that are not 64bit compliant, and therefore the AMD64 which can do hardware 64 and 32 bit sweeps the floor.

    Plus, who is ready to receive 64 bit chips? Windows isn't quite yet there with their 64 bit OS, and many linux distros only have beta quality 64 bit OS'es.

    NeoThermic

    • Re:But... (Score:4, Insightful)

      by TeknoHog ( 164938 ) on Monday January 05, 2004 @11:15AM (#7880962) Homepage Journal
      many linux distros only have beta quality 64 bit OS'es.

      Just to nitpick, Linux has supported other 64-bit architectures (at least Alpha) from its early years, so it definitely has the 64-bitness sorted out already. X86-64 is a relatively new thing, but not quite the first one with 64 bits.

    • Can it do hardware 32bit as well?

      Who cares? You will be able to buy a 32bit machine for quite some time for your "legacy" apps.

      Plus, who is ready to receive 64 bit chips?

      Hmm, 64bit chips have been around for 10 years or so. Ask someone who works with real hardware this question.

      Windows isn't quite yet there with their 64 bit OS, and many linux distros only have beta quality 64 bit OS'es.

      a) this is slashdot, windows doesn't matter b) although my experience with 64bit linux distros is limited, Deb

      • Re:But... (Score:2, Insightful)

        by October_30th ( 531777 )
        Lastly, I do not understand people's obsession with x86. Disco died in the early 80's, but we still want to use a computer archetecture from the 70's?

        a) With the exception of the black magicians of the embedded systems, people people do not, in general, have to write bit-banging assembler code. Who cares if x86 is shite - and no-one's disputing that here - if the compiler/interpreter hides them nassty, nassty bitses.

        b) It is imperative that the legacy code runs fast or that it can be easily recompiled. Y

      • but even when programming in assembler, it isn't so bad. In fact using the x86_64 IA assembler is pretty nice in long mode (AMD is happy to send you the manuals gratis, to help out). Not as symmetric as say MIPS, but it's getting better.

        The IA is the IA. It has little to do with how anything else works (which is all modern at this point). The only pain is having non-fixed length opcodes, but we've solved that problem (TLBs) so we get to use instruction cache better. I don't really see the problem!

  • Windows XP 64-bit (Score:5, Insightful)

    by Zog The Undeniable ( 632031 ) on Monday January 05, 2004 @08:22AM (#7879931)
    But will MS write their 64-bit XP to work on Athlon 64 and the new Intel chip, or will we have three different versions (Itanium, Athlon 64 and Intel x86-64)? At this rate Windows will become as fragmented as Linux ;-)

    • Re:Windows XP 64-bit (Score:5, Interesting)

      by Anonymous Coward on Monday January 05, 2004 @08:31AM (#7879969)
      The rumour is that Microsoft said a firm no to Intel requesting support for an entirely new 64-bit variation, but they worked out a deal where Microsoft would delay their x86-64 version of Windows until Intel was able to develop a compatible processor. The Intel x86-64 processor might even contain a few extra instructions that AMD doesn't have, just to ensure incompatibility.

      These kinds of rumours may not not have anything to do with reality, but at least they can explain why Microsoft has not released the x86-64 Windows for sale even though there have been fully functional betas available for almost a year now.
      • Doing that would effectively lock microsoft out of a portion of the market, a portion that linux could fill well. Considering the pressure linux is beginning to put on MS, that seems unlikely.
      • Jerry Sanders must be well pissed off then. It's not going to help Athlon 64 sales at the expense of P4, if users still have to run 32-bit XP for the foreseeable future. I smell an Intel dirty trick.
      • I thought the first _public_ beta of W64 for AMD was released just a few months ago, and that people said it still needs a lot of work.

        Even if it were out, I think the problem is getting people to invest into the platform, be it large and small time developers. In short, the platform needs a "killer app" to make it a worthwhile transition for most people.

        • Re:Windows XP 64-bit (Score:3, Interesting)

          by WNight ( 23683 )
          Why does it need a killer app? It's an incremental upgrade that's no more expensive than the last incremental upgrade? It's pretty much a no-brainer for anyone who buys AMD, it's just as fast in 32bit code and 64bit code can be much faster on the right stuff (audio/video encoding, etc).

          It's great that MS is delaying though. All the companies that make 3d modelling and rendering software and haven't already switched to Linux are doing so now. Ditto companies making scientific analysis software and other com

  • Dumb question (Score:3, Interesting)

    by pubjames ( 468013 ) on Monday January 05, 2004 @08:23AM (#7879939)

    Ok, flame me if you wish, here's my dumb question:

    If I got a computer with a 64 bit processor, what difference would I notice compared to a non-64 bit resaonbly high-end PC? I mean, would it just be a bit faster? Or a hell of a lot faster? Or just faster at certain things? Or would it not make much difference at all for normal everyday office tasks and playing games etc.?
    • Absolutly nothing until programs start to utilize all 64 bits...and who knows when that will be
      • How about now?

        Running most anything but windows (everyone can probably remember "32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor written by a 2 bit company that can't stand 1 bit of competition.")

        The real question is what the 64 bit $BLANK tacked on to the front would be.

        Linux: it just works on 64-bit.
        Windows: please emulate a 32-bit (or lower) processor*
        *I have used NT 4 on alpha (pretty much just acted like it was

    • You would notice that 64 bits costs a lot more.

    • Re:Dumb question - deserves a straight answer (Score:5, Informative)

      by Crypto Gnome ( 651401 ) on Monday January 05, 2004 @08:32AM (#7879979) Homepage Journal
      The best answer to your question is : not necessarily faster. Variables in this equation include but are not limited to:
      • good motherboard support
      • good OS support
      • advanced multi-bit path to ALL hardware interfaces (eg them newsystem buses which are mostly not yet vailable)
      • good fast RAM
      • software recompiled to the 64-bit CPU
      • actual use of 'benefits' of 64-bit computing (eg consumes unearthly amounts of RAM)


      For you and I, JimBob and JoeBlow, a good fast 32-bit system will kick much 64-bit arse. At least until
      • full OS (and driver) support for 64-bit mode
      • apps recompiled for 64-bit
      • fast mother with fancy-schmancy ultra-wide ultra-fast system bus
      • new cards (*especially* video) on said new bus

      • Re:Dumb question - deserves a straight answer (Score:4, Informative)

        by Webmonger ( 24302 ) on Monday January 05, 2004 @09:10AM (#7880145) Homepage
        For you and I, JimBob and JoeBlow, a good fast 32-bit system will kick much 64-bit arse.

        This isn't valid. x86-64 systems can run 32-bit apps at full speed, so they'd be kicking their own arse.

        Also note that x86-64 corrects some of the weaknesses of the x86 architecture, so x86-64 apps are automatically faster. Counter-strike was 30% faster, clock-for-clock.
        • Also note that x86-64 corrects some of the weaknesses of the x86 architecture, so x86-64 apps are automatically faster. Counter-strike was 30% faster, clock-for-clock.

          That's an important point that people need to keep in mind. The 64-bitness in itself provides just about zero benefit to 99.9% of users.

          Many people fail to realize that 64-bit in this context only means 64-bit pointers. Apps have been using 64-bit data for years: 80-bit floating point has been implemented in the X86 since the 1980s, and a

          • You can't do MMX and floating point in parallel. But you CAN do 64-bit arithmetic (which used to require MMX) and floating point in parallel, or 64-bit integer arithmetic and MMX/SSE/3dnow in parallel. This opens up the door for lots of additional speed optimizations by internal instruction level parallelism. Also it lets you do things with less instructions (and hence clocks) which used to be cumbersome before (faster fixed point/arbitrary precision math, large multiply/acc. operations, saturation math wit
      • Anandtech recently had an article [anandtech.com] where they compared two-way systems running as web servers -- AMD Opteron 248 against Intel Xeon 2.8ghz. The AMD system was a stunning 40% faster running the same applications.

        Chip H.
    • The 64bit CPUs will have higher clock speeds than the 32bit. So automatically they will be faster if EVERYTHING ELSE WAS THE SAME (which isn't). In theory, 64bit should be better than 32bit (that goes without saying). The real answer will depend on the applications. It will take some time for developers to write applications that use 64bit. Since nearly all applications are 32bit right now, developers won't change overnight and you probably wouldn't notice a difference for a while. So 32bit is probably good

      • Re:Dumb question (Score:2, Informative)

        by Crypto Gnome ( 651401 )
        Actually, you're almost completely wrong. All things being the same (clock speed, on chip cache, etc) 64-bit computing should be measurably slower than 32bits.

        WTF???

        Yes, you heard right... slower.

        More bits per instruction means
        • more thrash-in-your-cache
        • more RAM bandwidth used just sucking down instructions

        And that's without even beginning to go into mega details of advanced CPU design.

        Repeat after me 64-bits does not magically change anything.

        The reasons these chips will most likely run apps faster

        • you are so wrong (Score:2, Informative)

          by ajagci ( 737734 )
          Repeat after me 64-bits does not magically change anything.

          Even if you run just 32bit applications under 64bit Linux kernels on the Opteron, your 32bit applications magically get almost the full 4G address space to themselves, because the 64bit kernel can relocate itself out of the user's address space. That alone is enough justification for a 64bit x86 for many server applications.

          The reasons these chips will most likely run apps faster is due to

          Yes, and you know what those changes are there for? T

          • But you don't move more bits per instruction if you don't have to. The Opteron chips run 32bit code faster than previous Athlons. 64bit processors, even those without a legacy 32bit architecture attached, have instructions for manipulating 32bit data just fine. It is just that when your program needs to work with 64 bits at a time, it can do so more efficiently.

            No, you're hosed when you use pointers, as you mention. Which is a LOT, no matter what language or programming style you use. (Not sure how

        • More bits per instruction means... more thrash-in-your-cache... more RAM bandwidth used just sucking down instructions

          Wrong! When someone says "a 64-bit chip" they mean the number of bits used to specify a memory location (ie., the size of a pointer). They are not talking about the size of the instructions!

          The main benefit is not wider arithmetic operations or higher performance. The main benefit is more addressable memory. Since the amount of memory in a machine has been doubling every year or two,

      • Re:Dumb question (Score:5, Insightful)

        by argent ( 18001 ) <peter@slashdot . ... t a r o nga.com> on Monday January 05, 2004 @08:52AM (#7880057) Homepage Journal
        In theory, 64bit should be better than 32bit (that goes without saying).

        Not actually true. The larger the word size, the more bits you have to move on every operation. Going to a larger word size is normally driven by application requirements: if an application doesn't need a larger address space or a wider ALU a larger word can actualy make it slower.

        What can you do with a 64-bit processor?

        Well, one thing you can do is directly address every byte on the largest disk drives we can get today. With an operating system that was designed for direct access, like Multics, you would never have to "read" any files: when you opened one, it would look just as if it had already been read in... all your physical memory would effectively be a big disk cache.

        For another, you can give each computer on the network part of the address space, so the same thing would be true for any file on your local LAN. Or any program on your LAN... no more messing around with protocols and remote file servers and databases... if you had the access rights, it would be as if they were local files.

        You could do the same thing for each instance of a program, so you wouldn't need complex mapping code when passing messages from one program to another... in fact you could just pass the address of a message and let the memory management system move it over when you actually need it. That would get rid of a LOT of redundant copying, since you probably don't need all parts of every message.

        The problem is, you'd need a whole new OS (or a whole old one... Multics is older than UNIX) to really take advantage of this kind of thing.
        • That rings a bell.

          There was some show-stopping problem with the way HURD [gnu.org] addressed discs which meant they could only support pathetically small discs. This was going to force a major rewrite and I have never heard anything of the project since.

          Would this new architecture fix that problem? (possibly not, it may have been something along the lines of large discs needing a large memory footprint - something x86-64 would help with but would be too wasteful to be used)
          • It will indeed fix it. HURD handles storage devices (Hard disks, CDs, etc) by memory mapping them into the address space. In a 32-bit system, you can only address 4GB (Forgetting such systems as PAE), thus HURD can't handle very big partitions on 32-bit systems. However, if you move to 64-bit, it become feasible with todays storage systems, along with tomorrow's for some time to come.
            • Something has to be wrong with that.
              A 32-bit system can access 4GB of memory without kludges. Are you implying that every byte on a disc partition has to map to a byte im memory? I can't believe that is what you are saying and it would mean that you will always need more memory than disc-capacity.

              That would be the mother of all design-errors.
              • You don't, because of the way virtual memory works. Let's assume you have a 16-bit address space, &0000-&FFFF. Now, each and every application gets 64MB of VM to play with. Now, if you memory-map a file to &F000-&FFFF, it doesn't actually take up RAM. When you attempt to write to those locations, data will be written to the file instead of to RAM.

                Virtual memory addresses don't necessarily correspond to phyisical memory addresses.

        • Well, one thing you can do is directly address every byte on the largest disk drives we can get today. With an operating system that was designed for direct access, like Multics, you would never have to "read" any files: when you opened one, it would look just as if it had already been read in... all your physical memory would effectively be a big disk cache.

          I dunno how Windows or Multics handle it, but on the UNIX side you can use mmap for that. It's slightly less elegant than an all-memory way of doin

    • Re:Dumb question (Score:3, Informative)

      by argent ( 18001 )
      Going to 64-bit isn't likely to make a difference to most programs. It will make a difference if you run software that needs a lot of address space, either because it wants to load or directly map more than 2-4GB of data, or because it's using sparse addressing for some reason (there are a number of algorithms where having a small amount of data scattered over a large address space is the most efficient way to operate). What's more likely to make a difference is using the change in address space to get peop

    • Re:Dumb question (Score:2, Insightful)

      by dimonic ( 688129 )
      Sorry, but I am not actually answering your question directly, but it is perhaps appropriate because your question begs a bigger question.

      I don't think anyone needs more speed than the best 32 bit CPUs provide today. The bigger problem today is bugs. Memory leaks, security flaws, memory protection errors, you name them. If I understand him correctly, Linus Torvals has weighed in to say that 64 bit architecture will allow a new way of addressing devices: 1:1 mapping. This will eliminate a huge amount of pag
      • I don't think anyone needs more speed than the best 32 bit CPUs provide today.

        You are very wrong. I'd like to do RF digital signal processing on my PC. Current CPUs are hopelessly underpowered for many of the DSP applications that would be useful to me.

        • Re:Dumb question (Score:2, Informative)

          by dimonic ( 688129 )
          I don't think "very wrong" is on the mark. I was perhaps over generalizing, as are you if you think that most people need the raw horsepower you need. I was thinking about folks that use word processors, browse the web, send e-mail, play games: you know, about 99% of CPU users. So for 1% of users, I am "very wrong" in my intentionally controversial opening statement.

          My main point (which you appear to have overlooked in your zeal to shoot me down) is that the 64 bit architecture offers something else other

          • Re:Dumb question (Score:4, Informative)

            by Grishnakh ( 216268 ) on Monday January 05, 2004 @02:51PM (#7882886)
            Don't be ridiculous. The main advantages of 64-bit architecture is memory addressability and large-number computation. There are many applications for this; just because Granny doesn't want to do anything besides send email is irrelevant to the rest of us that do have uses for this power.

            Some examples, some of which have already been pointed out:

            1) video editing. Digital video takes up tons of space, and 2GB of memory addressability just doesn't cut it when you're trying to edit something that takes tens of gigs or more.

            2) large-number computation. Scientific simulations, video rendering, etc. do tons of computation, and doing it 64 bits at a time will improve performance greatly.

            3) games. The way games operate isn't too different than the rendering that Hollywood studios do in massive quantities, and games need to do it in real-time.

            4) computation using large data sets. Simulators of all kinds (used for designing semiconductors, aircraft, automobiles, etc.) work with massive amounts of data. 2GB of memory addressability isn't enough.

            Whether you think "most people" need 64 bits or not is irrelevant. I really don't care about the masses of AOL users who just read their email; in my line of work, 64 bit systems will soon probide a very noticable benefit as the simulators we're currently using are pushing the limits of 32-bit memory addressability and will soon need more. Given that there's thousands of engineers here in my company alone, and untold hundreds of thousands more involved in other types of simulation, is alone enough of a market opportunity for these CPU manufacturers to be pushing this technology. As for the home users, I'm sure the game writers will come up with ways to use that power too.

    • Re:Dumb question (Score:3, Informative)

      by Sloppy ( 14984 ) *

      If I got a computer with a 64 bit processor..

      A better question would be to ask specifically about x86-64 vs i386, instead of 64-bit vs 32-bit.

      In general, comparing 64-bit processors to 32-bit processors is like comparing apples to oranges. Each side is going to be able to find situations where it is faster.

      But if you ask about x86-64 compared to i386, then it gets a bit easier. x86-64 is better and faster, at nearly everything. The 386 is finally dead (or at least seriously threatened), thanks to A

  • Other things up their sleeve (Score:5, Informative)

    by swordboy ( 472941 ) on Monday January 05, 2004 @08:24AM (#7879941) Journal
    I think that Intel have some other tricks up their sleeve. See my journal [slashdot.org] for some screwy wishful thinking. What is cool about loads of on-chip NVRAM is that it opens up the possibility for Intel to ship an embedded operating system. The Wintel duopoly will reach new heights with DRM and Trusted Computing.

  • Sample Results.. (Score:3, Funny)

    by MosesJones ( 55544 ) on Monday January 05, 2004 @08:30AM (#7879967) Homepage

    After Sampling the new Chip Internally the general view was :

    "Tastes like Chicken"

    Further Internal Samplings are being conducted using Tabasco and BBQ sauces.

  • Battle? (Score:2, Interesting)

    by Anonymous Coward
    Is this the beginning of a Linux+AMD vs. Windows+Intel battle?

  • x86-64??? (Score:5, Interesting)

    by Glock27 ( 446276 ) on Monday January 05, 2004 @08:33AM (#7879984)
    x86-64-bit processor will 'soon' arrive from Intel

    Do you mean AMD64? Will the Intel chips really be fully compatible with an AMD-designed instruction set?

    If this happens, it will only reinforce the fact that Intel has lost it's leadership position in the x86 compatible market. It will also severely impact any eventual large scale adoption of Itanium.

    AMD just needs to bite the bullet and actually do some marketing. It has clearly superior products at this point. The Athlon 64 3000+ looks like a great buy, and a nice way to check out 64 bit computing at a low price point. If you have the money laying around, though, you really can't beat the PowerMac G5s. :-)

    BTW, it's also too bad that Microsoft has delayed 64-bit Windows. It shows all too clearly that the "Wintel" partnership is alive, well, and smelly. On the other hand, it does provide a nice platform for Linux to tout it's superiority - "What's taking so long Microsoft, we've had an AMD64 version of Linux for months already!". So much for the "advantages" of Microsoft's software development practices... :-P

    • YES. M$ has put Intel on notice it will NOT support a third 64 bit processor under windows. If they want their x86-64 to run windows it WILL use the AMD64 instruction set, or it will NOT be supported.

    • Re:x86-64??? (Score:3, Insightful)

      by NanoGator ( 522640 )
      "If this happens, it will only reinforce the fact that Intel has lost it's leadership position in the x86 compatible market."

      What?

      Leadership is determined by who's got more out there, not by who's following whose standard. By your definition, AMD could never ever achieve leadership position because it's usinng Intel's instructions.

      AMD may be a threat, but it has not ousted Intel, not by a long shot.

      • Re:x86-64??? (Score:5, Interesting)

        by Glock27 ( 446276 ) on Monday January 05, 2004 @09:22AM (#7880214)
        Leadership is determined by who's got more out there, not by who's following whose standard. By your definition, AMD could never ever achieve leadership position because it's usinng Intel's instructions.

        No, leadership is determined by who introduces the technology that everyone will be using in the future.

        You're talking about "marketshare" which is a different concept. ;-)

        The fact that Intel has such a commanding lead in marketshare at the moment is mainly a glowing endorsement of effective marketing practices. The P4 has been a stunning failure as a technology - all it has really achieved is lower performance at 1/3 higher clockspeed (P4 3.2 GHz. vs. Athlon FX 2.2 GHz.). The only place that P4 excels is the SIMD instruction set, where latency doesn't matter - and those instructions don't help much at all with general purpose computing.

        Intel Inside - Just Say No. :-)

      • Re:x86-64??? (Score:3, Insightful)

        by ajagci ( 737734 )
        Leadership is determined by who's got more out there, not by who's following whose standard.

        No, the term "leadership" by itself is commonly understood to refer to "technical leadership", i.e., who sets the standard, not who moves more product. If there is any ambiguity, just be clear about it. In this case, from context, it should be clear that the term was used to talk about technical leadership.

        By your definition, AMD could never ever achieve leadership position because it's usinng Intel's instructi
    • My impression was that AMD are shipping all they can produce for a pretty high price.

      A marketing offensive under these circumstances would be counterproductive - they would be spending money creating a need for product they could not shift in those quantities. AMD have been there before and it hurt them.

      As for Linux and x86-64 support, the German C't magazine tested this recently and had some pretty major problems with some MotherBoards.
      One of the changes between the last 2.6.0-test and official 2.6.0

  • I don't doubt it at all... (Score:3, Interesting)

    by shfted! ( 600189 ) on Monday January 05, 2004 @08:35AM (#7879994) Journal
    Guess the Rumours are True [theinquirer.net].

  • Internal use only (Score:3, Funny)

    by ChaosMt ( 84630 ) on Monday January 05, 2004 @08:39AM (#7880011) Homepage
    "...article that says that the chip is to be sampled internally this month."


    Perhaps I'm up too late, but when I read the above, this image of a windows developer flashed in my mind. He's frustrated with a child-proof cap and resorts to reading the side of this bottle from Intel: "For marketing use only. Do note mix with alcohol or windows. New buffer exploits are inevitable. May cause loss of market share if ingested."

  • Linus' opinion on 64 bit desktops (Score:5, Informative)

    by anti-NAT ( 709310 ) on Monday January 05, 2004 @08:40AM (#7880016) Homepage

    Linus Torvalds on 64bit desktops [realworldtech.com]

    Linus Torvalds on 64bit desktops [realworldtech.com]

  • just what we need (Score:4, Insightful)

    by Anonymous Coward on Monday January 05, 2004 @08:41AM (#7880020)
    Great just what we need. another patch on a 20+ year old design. its not Apple who needs to switch platform's its us the whole x86 platform should be dropped. Apple has been able to pull off a proccessor change from the m68k to the PPC and they were able to mantain compatibly with legacy apps in emulation.
    • Apple has been able to pull off a proccessor change from the m68k to the PPC and they were able to mantain compatibly with legacy apps in emulation.

      And this month we will (finally) see how well AmigaOS has been able to do the same thing.

  • Did I Miss Something? (Score:5, Insightful)

    by los furtive ( 232491 ) <ChrisLamothe@NOSPam.gmail.com> on Monday January 05, 2004 @08:47AM (#7880043) Homepage
    ...they also predict that Sun and IBM will be the major players in the future 64-bit boom

    Isn't IBM already a major player [apple.com]?

  • for a change, to break backwards compatibility, but we have to ask them. WHAT THE HELL WERE THEY THINKING THIS TIME???? finally, x86 becomes THE commodity platform and they try to kill it ?? ? ? makes no sense. AMD knew what was up all along. IBM did the same with its 64 bit offering, and Sun still makes slow processors (fun to complain about hardware too).

    anyway, they screwed the pooch, but will never correct the mistake. when you've got a few billion dollars, you can wait just long enough to lose

    • I was at a Linuxworld talk around 14 months ago and someone from AMD (a VP?) held a keynote speech on this processor, one that was sufficiently convincing for me to go out and buy some shares in the company :-)

      He could not understand what Intel were up to either.
      Linus made a similar point later around the time he left Transmeta and added the rider that the Itanium was based on bad design decisions, irrespective of compatability.

  • NO (Score:2, Interesting)

    by 1ini ( 629558 )
    No they will not.
    Intel likes to keep its architectures separated. They have Pentiums/Xeons for 32bit and Itaniums for 6bit processing. Releasing a x86-64 CPU will kill the Itanium plain and simple.

    • Re:NO (Score:4, Funny)

      by Crypto Gnome ( 651401 ) on Monday January 05, 2004 @08:57AM (#7880077) Homepage Journal
      Itaniums for 6bit processing

      I always thought Intel was a few slices short of a loaf, but that's just ridiculous.

      • Re:NO (Score:3, Funny)

        by spektr ( 466069 )
        Yes, Intel's new 6bit processor (aka Hexium XR) will be ridiculous, but very successful. The 512k stage pipeline and the 6 bit architecture lets it run at frequencies above 35,000 THz. Faster than light speed - ridiculous speed! This high rpm wonder wins the race in the first gear - who needs a second one! Please pay attention to the specified safety margins and stay out of the way of the leaking X-rays.

  • Too Much Work (Score:4, Funny)

    by InvaderXimian ( 609659 ) <elvedinNO@SPAMods.org> on Monday January 05, 2004 @08:57AM (#7880080)
    I don't think MS could port Windows to all those different architectures (they can't get one right) so perhaps they'll either need more people, make it open source within a select few MS Devs or something or just make it really crappy.

    Think about it, optimizing an operating system for 4+ archs is no easy task and I doubt MS could do it in a reasonable amount of time.

    Maybe they'll hire the Duke Nukem: Forever developers on that one.

    • Re:Too Much Work (Score:2, Informative)

      by cchd ( 709773 )
      But Microsoft already did this. NT4 was originally developed on MIPS and then "ported" to IA32 and Alpha. Most of the original work on the 64bit Windows for Itanium was done on Alpha (as no Itanium chips were available). Assumint that no new 32 bit dependancies have been built into 2000 and XP (big assumption here) then a simple recompile should get things moving on other architectures again.
    • I don't think MS could port Windows to all those different architectures

      Thats why linux, solaris, the BSDs suck. For example:

      mlap:~/src/linux-2.6.0-test9/arch% ls -1
      alpha/
      arm/
      arm26/
      cris/
      h8300/
      i386/
      ia 64/
      m68k/
      m68knommu/
      mips/
      parisc/
      ppc/
      ppc6 4/
      s390/
      sh/
      sparc/
      sparc64/
      um/
      v850/
      x86_ 64/
  • architectures be compatible? If they aren't, that could be quite a hassle
    • Intel is free to implement AMD's x86-64 architecture in their own chips. And they most certainly will, since creating an entirely new, incompatible architecture is a lose for both AMD and Intel. Whereas making it a standard is a win for both companies and the sort of thing that can push new chips to consumers.
      • they will most certainly not support AMD's instructions. Their instructions set will have to be different otherwise they will license something from AMD which they will never do with their current market position.

        • they will most certainly not support AMD's instructions. Their instructions set will have to be different otherwise they will license something from AMD which they will never do with their current market position.

          Intel doesn't have to license anything from AMD to implement x86-64; Intel already has permission to use it without per-chip royalties because of previous cross-licensing agreements. The only thing preventing Intel from going that route now is because of pride and keeping the Itanic on life sup

        • I believe that Intel already has an agreement to use AMD's x86-64 instruction set, if they choose to. I don't know what the licensing terms were, and of course, Intel is free to develop their own extensions. But as another poster said, Microsoft would be very unhappy with that.

  • Very Likely (Score:5, Informative)

    by turgid ( 580780 ) on Monday January 05, 2004 @09:05AM (#7880111) Journal
    Intel will very likely release a 64-bit x86 processor, or kludge unit for Pentium V, this year (just like the math coprocessor was prior to the 486).

    However consider this:

    AMD has been shipping Opteron for nearly a year already, and ports of the main OSs (including Windows and Linux) have been done, with others already working in the lab. It also runs old 32-bit OSs with no change. It will run legacy x86 code at full speed along side new 64-bit code. It is more efficient in terms of useful work done per clock cycle compared to Pentium 4 and Xeon. It scales better in multi-way systems (very important in workstations and serves) : the logic is built in. Xeon does not have this (and plain P4 is limited to single-way). It has a built in memory controller. It has twice as many registers. It's very inexpensive. Go and look up your favourite component retailer right now and compare an Opteron to a Xeon (and even the "high-end" Pentium 4).

    The only place AMD may have trouble selling is to the ignorant masses who buy on MHz (or GHz) from highstreet stores, and pay too much.

    The corporate world is more clued-up, and so are the enthusiasts and power-users.

    Even if AMD does not knock intel off of it's perch, there is a huge potential market for Opteron. Several major corporations are behind Opteron. They've committed to it. It's going to be big business. 2004 will see a radical change in the hardware business. I predict that in the second half of this year, people will laugh a 32-bit PeeCees. They will be obsolete and bargain-basement by then.

    • Re:Very Likely (Score:5, Insightful)

      by The One KEA ( 707661 ) on Monday January 05, 2004 @09:47AM (#7880332) Journal
      It took 11 years for 32bit operating systems to finally displace 16bit operating systems. Your prediction of 32bit PCs being laughed at by December 2004 is probably a little too radical.

      However, your other comments about AMD and the Opteron are spot on, IMO - the enterprise world is NOT going to buy a competing, slightly incompatible 64bit platform when it has already invested in another 64bit platform that is ALREADY AVAILABLE and is KNOWN to be just as fast/faster than a 32bit commodity platform or an older 64bit platform like a PPC box from IBM. It's hard enough these days for IT departments to support the current heterogenous mix of 32bit commodity desktops and servers and the old/new 64bit platforms from AMD and IBM. Throwing in a third which could cost even more and add more headaches would be pretty hard to sell, IMHO.

      You were also right about marketing; AMD abolsutely MUST find a way to conclusively show that GHz != Speed. They need a new aggressive marketing campaign ASAP - unless the rumours about Prescott being a bit of a dud are true.....

      Either way, AMD knows that they're sitting on a goldmine; they just need to exploit it as much as they can.
  • The big problem with the Pentium isn't that it's only 32 bits wide, it's that the instruction set is so poorly designed. It's complex and hard to execute quickly, doesn't have enough registers, REALLY doesn't have enough floating point registers, has too high a cost to transferring data between the CPU and FPU, and huge chunks of silicon have to be used to cover for these faults.

    Intel has tried to patch this with extended instruction sets before, like MMX, but they haven't been able to discard the legacy design. The last big improvement in their architecture was when they went from the 286 to the 386, and were able (eventually) to shed the overhead of 16-bit segments. Mostly... and they did that by making it a completely different mode instread of a patch on the existing instruction set the way the 8086-80286 transition was.

    If their new "extensions" have a better instruction set, they will be able to perform the same kind of break without losing their existing user base. They tried to do this with IA64, but the processor was too slow and the IA32 "mode" was WAY too slow. It remains to be seen whether the new chip does a better job.

    If they had been smart, they'd have kept the Alpha EV8 team intact after they bought them from the Compaq fire sale, renamed it the "IAXP", and shipped it with a hardware IA32-Alpha recompiler for legacy support.
    • So what's your opinion on the AMD64 core and instruction set? Does it inherit the same problems in the core's 64bit modes, or do those 64bit modes actually remove some of the limitations of the original x86 instruction set? For example, you cited the lack of registers onn the x86 platform. The AMD64 platform has twice as many registers in the 64bit modes, both standard and SIMD registers; is this an improvement? Or does it come down to good compiler support?
    • The big problem with the Pentium isn't that it's only 32 bits wide, it's that the instruction set is so poorly designed. It's complex and hard to execute quickly, doesn't have enough registers, REALLY doesn't have enough floating point registers, has too high a cost to transferring data between the CPU and FPU, and huge chunks of silicon have to be used to cover for these faults.

      AMD has solved these problems in the Opteron (and Athlon 64) by doubling the number of integer registers (to 16) and making them

      • Sixteen registers is still pretty slim (about the same as the original 68000 or the creaky old 1802, and definitely on the low side compared to the Alpha or IA64), but sixteen general purpose integer registers and sixteen floating point registers is certainly a big step up.

        I would have preferred them to make a cleaner break with the legacy instruction set, but I suppose they figured their just-in-time recompiler makes the instruction set details less critical, and since x86 compatibility isn't going away t

  • Licensing? (Score:3, Interesting)

    by B5_geek ( 638928 ) on Monday January 05, 2004 @09:47AM (#7880338)

    Does anybody know if the extensive cross-licensing agreements that exist between AMD & Intel cover the x86-64 additions?

    Would that not be the cats meow if Intel had to pay AMD royalties for each chip they sold?

    AMD fan or Intel fan; we are damn lucky that there is competition.

  • Old News (Score:2, Informative)

    by explorer ( 42481 )
    Most of the articles linked to are pretty old. Only two are even from this month, and they're from Friday/Saturday. Yawn.

    Let's keep it current.

  • Intel, AMD, etc (Score:5, Interesting)

    by sjd ( 615519 ) on Monday January 05, 2004 @12:25PM (#7881518)
    All of the posts I've read only talk CPUs. Hasn't anyone noticed that MS now (quietly) has a multi-platform software virtual machine? .NET strives from cross-platform compatibility, just as Java did years, and years ago. MS realised this IA-32/IA-64 was going to happen, and .NET quietly solves the problem. MS is pushing people to migrate their IA-32/Win32 apps to it. As a current .NET software engineer, the specific Windows platform becomes irrelevant. You could easily argue that MS is delaying the 64-bit world to give developers more time to migrate to .NET. Sean

Slashdot Top Deals

Love may laugh at locksmiths, but he has a profound respect for money bags. -- Sidney Paternoster, "The Folly of the Wise"

Close