Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Linux Software

Linus: Praying for Hammer to Win 487

An anonymous reader writes "The boys at Intel can't be happy with the latest opposition to the IA-64 instruction set. According to this Inquirer scoop, Linus himself has weighed in, and it appears he's putting his eggs in the x86-64 basket. In the original usenet post, he goes so far as to say that 'We're ... praying that AMD's x86-64 succeeds in the market, forcing Intel to make Yamhill their standard platform.'"
This discussion has been archived. No new comments can be posted.

Linus: Praying for Hammer to Win

Comments Filter:
  • by Kenja ( 541830 ) on Monday July 29, 2002 @03:36PM (#3973426)
    is the same as the problem with OS/2. People dont want to re-write their applications for native support. I expect very few apps to be codeed for Hammer because its 32bit compatiblity is so good. An application devloper can write for old 32bit x86 and target Hammer and x86 at the same time. Just like devloeprs could once write applications for Windows 3.1 and have them run on Windows and OS/2. Not that the CPU wont do well, but I dont expect it to ever get the kind of support it wants.
  • by Marx_Mrvelous ( 532372 ) on Monday July 29, 2002 @03:38PM (#3973438) Homepage
    Considering that Linus is almost fanatical about needing to "break" backwards compatibility in the Linux kernel in order to develop it as fast as possible.

    Now he's supporting a CPU scheme that, well, doesn't break anything and may even sacrifice performance for that compatibility.
  • by Amiga Trombone ( 592952 ) on Monday July 29, 2002 @03:48PM (#3973520)
    ...considering the alternative. Itanium is certainly a decent high end processor, but really, what advantage does it have on the high end not offered by Power, Sparc, PA-Risc, etc? Also, in x86 compatibilty mode, it suffers a rather significant performance hit, so as a drop in replacement for x86 it's value is limited. And the complexity of writing decent VLSI compiliers calls into question whether software will ever be able to take advantage of the performance the processor is theoretically capable of. Where as x86-64 can run current software with equal or better performance, and new applications written to the 64 bit instruction set can be phased in non-disruptively. Itanium may be nice, but for the kinds of applications where it could be used to advantage, I don't see where it has any advantage over other common RISC processors.
  • by Jeppe Salvesen ( 101622 ) on Monday July 29, 2002 @03:49PM (#3973527)
    I thought we supported this stuff for the other 64 bit processors? Aren't we fully 64-bit yet?
  • Re:Not surprising... (Score:5, Interesting)

    by Anonymous Coward on Monday July 29, 2002 @03:58PM (#3973606)
    Beside that, who cares for the CPU's instruction set? Nobody, except compiler designers and very few assembler programmers.

    Umm, you are correct, but you have to keep in mind that Linus Torvalds is in that set of very few people. He may not be the one writing the compiler himself, but he is extremely close to the compiler-- he works on the operating system kernel, the one position that has to be most sensitive to obscure conditions of the microprocessor in order to optimise. Which is why he is weighing in on this subject.

    Anyway, most of us have heard of Torvalds' fondness of hand-writable assembly language. (I.e., the huge portions of early Linux that were written in x86 assembly and C code which is written in such a way it may as well be assembly.. I had heard things indicating he had mostly grown out of that lately, though, now that non-x86 platforms are closer to his chunk of the kernel tree.. is that the case?) And i think we are all well aware of Linux's famed nonportability to non-GCC compilers due to dependence on obscure GCC bugs and nonstandard features. So, yeah. Linus may not be The Compiler Guy, but he will definitely have to be talking to the Compiler Guys on a regular basis, and he is in the group of people (the linux kernel development team) most likely to be the first ones to run into trouble with any new bugs which crop up in gcc. So he definitely has a good reason to have an opinion on this subject, especially given the subject increases compiler complexity so much that it is somewhat likely to increase the number of small compiler bugs that make no difference to you or i but huge amounts of difference to those persons who know what "spinlocks" are..

    - super ugly ultraman
  • by 3seas ( 184403 ) on Monday July 29, 2002 @04:03PM (#3973651) Homepage Journal
    Don't you see it comming.....all the way down to hardware...on one side the DRM and such products and the other the open systems
  • by Junta ( 36770 ) on Monday July 29, 2002 @04:07PM (#3973675)
    Yes, he's praying for standardization, using AMD's standards which is directly related to Hammer's success. Itanium was to be Intel's one and only 64-bit future, and only when faced with AMD's 32-bit backward compatible architecture did they design a fallback, the Yamhill, which would be compatible with the Hammer and legacy apps. The headline is *not* misleading at all, for once, he wants AMD's Hammer standard, not IA64.

    It seems odd though. Putting aside market situation and prices to look at the pure technology aspect of it, IA64 is a better architecture, it isn't burdened with backwards compatibility. Especially with linux (which already works with IA-64, as well as most apps), there is little reason to hold on to the dated IA32 architecture, which inherits stuff from early 80s. I could see why MS would be on the x86-64 bandwagon (if users' upgrade paths force them to change architectures, they may be just as likely to go PPC as they would IA64), but not Linux...

    It made sense when moving to 32-bit from 16-bit to keep backwards compatiblity, assembler was widely used back then out of necessity, and thus porting applications was non-trivial. Now, in an age where most everything is written in high-level languages, this is the perfect opportunity to start with a clean slate. Companies can easily recompile and do additionaly testing and earn back the money it cost to do so in short order, if their application is important to the market.... Of course all of this is from a technological standpoint....

    The fact of the market is that Yamhill/x86-64 is the future of x86. Itanium was a nice dream and all, but when you look at the two platforms and the variety of software they support, the choice is clear. Not everything will be ported to IA64 and knowing that it is hard to justify the jump...
  • by cmowire ( 254489 ) on Monday July 29, 2002 @04:15PM (#3973728) Homepage
    OTOH, it makes some sense to keep things the way they are.

    Consider that the internal core of a perfect-new RISC chip and a x86-64 chip are more-or-less the same. x86-64 instructions come in, are translated to internal RISC code, and are then executed. The main difference is an extra translator and the register-renamer. But any architecture that lasts long enough will need such trappings, as it starts being used for things that nobody would have thought of when the designer thought the chip up.

    Remember that, for a long time, the 286 instructions that aren't easily mappable to the RISC core aren't particularly efficent.

    I used to think exactly the same thing as you are thinking now. I want a MIPS or Alpha inside, not Intel. But, given that 99% of programming is not done in assembley and the cost of adding a hardware instruction set translator is minimal compared to the difficulty and risks of switching instruction sets, the instruction set of a processor ceases to matter.
  • by emil ( 695 ) on Monday July 29, 2002 @04:27PM (#3973813)

    If AMD is successful in forcing Intel to adopt x86-64, great harm will be inflicted upon:

    • HP-UX
    • VMS
    • Tru64 (what is left of it that is rolling into HP-UX)
    • To a lesser extent, AIX-5L

    While recent interviews with HP execs (on The Register) indicate that HP is taking some steps to "roll with the x86-64 punch," I sincerely doubt if HP can be convinced to port VMS to Opteron should it become necessary.

    What is even more troubling for the Itanium is the fact that HP's compilers are faster than Intel's, but the HP compilers have not been released outside of HP-UX. The standoffish attitude of other ISVs (Dell, IBM, etc.) is not hard to understand given these circumstances.

    You will also have noticed Microsoft's (now infamous) "leaked" memo on Windows-64 running on Opteron. Such a leak I believe has been carefully crafted to throw FUD upon all things Itanium. Furthermore, it is in Microsoft's best interests for Opteron to prevail, as such a victory will destroy not only DEC/Compaq's high end, but also HP (as much as HP-UX deserves to die, it should not fall to Microsoft).

    If Intel and HP truly want Itanium to flourish, Intel must reduce the price immediately (to at least a SPEC-to-SPEC match with Athlon/Opteron, and possibly lower), and HP must release fast compilers under an open license.

    If the Itanium market remains fragmented, AMD wins, and Microsoft's interests are advanced.

  • by colostomy_net ( 592411 ) on Monday July 29, 2002 @04:28PM (#3973826)
    Setting aside all the Linux kernel issues, Linus has a decidedly vested interest in the AMD part as Transmeta has already taped it out. So when he speaks of the kernel issues, keep in mind that his Transmeta stock options may speak loudly in his mind.
  • Re:Clarification (Score:4, Interesting)

    by roca ( 43122 ) on Monday July 29, 2002 @04:31PM (#3973854) Homepage
    Have you compared the die size of Itanium vs a Xeon or Hammer? Itanium is much larger --- and slower --- and more expensive. Who's wasting die space?

    But hey, at least it's pure!
  • Thats because... (Score:1, Interesting)

    by Anonymous Coward on Monday July 29, 2002 @04:40PM (#3973917)
    The IA 64 will require too much rewriting of code for Linus' child (Linux etc.), so of course he wants a transitional implementation to 64 bit processing.
  • DEAR STEVE JOBS (Score:4, Interesting)

    by roca ( 43122 ) on Monday July 29, 2002 @05:05PM (#3974116) Homepage
    Please port OSX to Hammer and stick AMD chips in your Macs. You can save face by pretending it's not x86 (even though it will make customers happy when they can run WINE and VMWare on OSX). Your programmers will enjoy the relatively clean 64-bit mode. You won't face the risk of being the sole customer of your CPU vendor. Best of all, you will be able to make cheap Macs with competitive performance. I promise to buy one if you do it.

    Sincerely,
    Robert O'Callahan
  • by roca ( 43122 ) on Monday July 29, 2002 @05:35PM (#3974339) Homepage
    > using SSE2 instead of x87 is a decent compromise

    In fact, it's significantly faster. Latest gcc has a switch to do this.

    BTW, you're ignoring the fact that x86-64 is a significant improvement over x86, not just a 64-bit stretch. 8 new general purpose registers, 8 new SSE2 registers. It starts to look a lot like a real architecture, yet compiling to it is very little different from compiling to x86.
  • Stop being ignorant (Score:1, Interesting)

    by Anonymous Coward on Monday July 29, 2002 @07:09PM (#3974927)
    It's sad to see how close minded some of the people are here. "Itanium is slow slow slow" and "X86-64 is the future."

    First off the IA-64 archietecture is completely new unlike X86-64. True, Itanium sucked in performance, but just because it doesn't work too well the first time means we give up on it? True innovations require great leaps rather than mere small increments. Itanium is a whole new design that will eventually take full advantage of the new technology, whereas X86-64 is an increment with some improvement. If IA-64 is continually developed it will surpass X86-64 for sure. BTW its funny how some people complain of Itanium II's slow clock speeds when they were supportive of AMD's adoption of a misleading system that tried to mislead consumers about the clockspeed of their processors.

    Furthermore look at Intel's roadmap. The ultra-high end segment is meant for Itanium, while Xeon will exist for lower end segments. I don't understand why everyone is comparing Itanium to Opteron in the first place. Opteron will most likely be competing against faster Xeon Processors with larger caches and perhaps Hyperthreading technology once it matures a bit more. Its extremely unlikely that any well-managed company will use Opteron in a 64 bit oriented environment. It would most likely be used as a 32bit replacement with its chief competitor being again, Xeon.

    Also the idea that Microsoft is conspiring with AMD against Intel is lunacy. Microsoft is not going to surrender any market to Linux whether it be IA-64 or X86-64. It will make the best OS it can possibly make for IA-64 because corporate software has a higher profit margin than consumer software, and they certainly will not let Linux dominate the IA-64 market, where linux already has a sizable share of the server OS market. Furthermore, Linus's support of AMD is completely irrelevant to the situation. IA-64 linux is already in development, and many corporations are behind because they hedged a lot on IA-64 and it will survive because Intel wills it, HP wills it, and many other companies do as well. And the fact that Intel and HP has a good overall execution record, how else did they get where they are today without one?

    I'm also surprised that I haven't seen too many questions about a weakness in the entire Hammer line of processors, the built in memory controller. Is AMD going to have to revise the Hammer core each time a new type of memory is on the horizon? If they do, it'll be costly constant R&D and if they don't, then they lose out on memory bandwidth advantage as Intel chipsets can just get a new chipset. Also more importantly, what about backward compatiblity? Is AMD going to have to manufacture many different variants of the same processor for different memory types? If they don't, then they cut off the upgrade path for their userbase which would have to buy a new motherboard each time. And as we know, much of AMD's support comes from hardware enthusiasts on a budget. Also many large companies will build systems with older memory types cause it makes economica sense. If AMD does manufacture several versions of the same processor it will be extremely costly since not all inventory will be sold. AMD cannot afford to screw up like Intel initially did with Itanium. If AMD screws up its execution, which there is a large chance of it happening, then we lose AMD as a competitor, and as bad as having to put up with AMD fanatics, it would be worse to have intel be able to jack the prices up at will.

    Anyways, I may have been divergent a little, but if you have nothing better to say then "X86-64 is the future," "Itanium sucks" and especially "Itanium ownz j00" please don't post.

"If anything can go wrong, it will." -- Edsel Murphy

Working...