Forgot your password?
typodupeerror

Octopiler to Ease Use of Cell Processor 423

Posted by Zonk
from the ps3-where-are-you dept.
Sean0michael writes "Ars Technica is running a piece about The Octopiler from IBM. The Octopiler is supposed to be compiler designed to handle the Cell processor (the one inside Sony's PS3). From the article: 'Cell's greatest strength is that there's a lot of hardware on that chip. And Cell's greatest weakness is that there's a lot of hardware on that chip. So Cell has immense performance potential, but if you want to make it programable by mere mortals then you need a compiler that can ingest code written in a high-level language and produce optimized binaries that fit not just a programming model or a microarchitecture, but an entire multiprocessor system.' The article also has several links to some technical information released by IBM."
This discussion has been archived. No new comments can be posted.

Octopiler to Ease Use of Cell Processor

Comments Filter:
  • Re:Makes you wonder (Score:2, Interesting)

    by general_re (8883) on Sunday February 26, 2006 @03:52PM (#14805061) Homepage
    ...they didn't have a decent compiler untill now.

    Actually, it sounds like they still don't have one, just some ideas on how to make one someday.

  • Octointerpreter (Score:3, Interesting)

    by yerdaddie (313155) on Sunday February 26, 2006 @03:55PM (#14805072) Homepage
    Reading this is making me nostalgic for LISP machines [comcast.net] and interpreter environments that let programmers really play with the machine instead of abstracting it away. What I'd really like to see is someone who takes all the potential for reconfiguration and parallelism and doesn't hide it away but makes it available.
  • by stedo (855834) on Sunday February 26, 2006 @04:24PM (#14805182) Homepage
    Microsoft's Todd Proebsting claims that compiler optimization only adds 4% performance per year, based on some back of the envelopes on x86 hardware.

    Then Microsoft's Todd Proebstring is wrong. Ask some Gentoo users. Personally, I recently wrote a bit of fairly simple mathematical code (computing difference sets). The total runtime on my 3 gig P4 was 22 seconds. I shaved off 2 seconds by optimizing the algorithm myself. By using gcc -O3, I shaved off a further 10 seconds, halving the runtime.

    Anyway, this compiler isn't so much optimization as taking code intended for one paradigm (simple single-threaded code) and converting it to another (code with 8 cores of execution).

  • by porkThreeWays (895269) on Sunday February 26, 2006 @04:38PM (#14805231)
    I'm glad to see some real progress in the processor world. We are so guided by the enterprise market that we've had to support x86 WAY longer than we should have. The cell looks like it has a real chance of becoming the next big advancement. For one, IBM is working heavily with the open source community. This is possibly one of the best things they could have done to help the cell. By doing this, you make open source developers happy and more inclined to port over their applications. One of the hardest things to do in getting a new arch out is getting application support, and they've pretty much guaranteed a modest amount of applications by going open source. The nokia 770 is a pefect example of this. They've supported open source and made available more than enough tools for quick porting of applications, and look at the huge amount available already in the first few months. The nokia 770 probably sets records in how many applications were ported in such a short period of time.

    Make the developers happy, and they will port their apps. With large amounts of available applications, the consumers will buy. When the consumers buy, you have a successful new arch.
  • by Animats (122034) on Sunday February 26, 2006 @04:59PM (#14805304) Homepage
    Games, as a rule, don't give a damn about 64-bit floating point.

    You wish. In a big 32-bit game world, effort has to be made to re-origin the data as you move. Suppose you want vertices to be positioned to within 1cm (worse than that and you'll see it), and you're 10km from the origin. The low order bit of a 32-bit floating point number is now more than 1cm.

    It's even worse for physics engines, but that's another story.

    If the XBox 360 had simply been a dual- or quad-core IA-32, life would have been much simpler for the game industry.

  • by Inoshiro (71693) on Sunday February 26, 2006 @05:04PM (#14805332) Homepage
    "All that really matters is wether the launch titles will be 'good' enough. Then the full power of the system can be unleashed over its lifespan."

    Yea, but what's the full power of a system? Prettier graphics?

    The "full power" of the PS1 seemed to be that its games became marginally less ugly as time went on, although FF7 was very well done since it didn't use textured polygons for most of it (the shading methods were much sexier). When I think about FF9, I don't like it more because it uses the PS1 at a fuller power level than FF7, I like it better because the story is cuter.

    I like PGR2 better than PGR3 because PGR2 has cars I know and love from Initial D and my own experience, whereas PGR3 has super cars I've never driven or seen before.

    I don't think Rez taxes the PS2 more than Wild Arms 3, but I like it better than Wild Arms 3. I also like most of the iterations of DDR, and they're not taxing in the slightest.

    The full power of a system is not its graphics capability or how easy it is to control or its controller or its games -- it's the entire package. Does the PS3 have a good package? The Xbox 360 sure doesn't -- the controller power-up button is nice, but there is nothing new or interesting; it's a rehash. The PS3 is a rehash too.

    The Sega Saturn was a rehash of the 8-bit and 16-bit 2D eras. It died. The PS3 and Xbox 360 are rehashes of the 64-bit and 128-bit 3D gaming eras.
  • Re:CISC? (Score:2, Interesting)

    by tarpitcod (822436) on Sunday February 26, 2006 @05:10PM (#14805355)
    A key problem with CISC was that doing virtual memory and handling page faults on a CISC processor was so incredibly insanely complicated that you ended up going insane and designing your pipeline could throw multiple page faults on one instruction and you had a god-awful mess to clean up.

    The problem with the Cell is actually pretty interesting. They decided to go for in-order CPU's for the SPE's which means that to get good performance you sure as hell better know what your dependencies are and take into account memory latency etc.

    OTOH modern RISC CPU's normally do nice out-of-order stuff which whilst making the CPU more complicated makes life easier for the programmer - compiler.

    Itanium took the clean approach - and it flies on FP workloads that the compiler can do a good job on. The PS3 (like Itanium) should rock - once programmers get lots of nice little kernels that do groovy stuff (think super shader programs) in the SPE's. Just that will make the eye candy pretty.

    The counter argument is the 'Look at what happened with the i860'. It had amazing performance on kernels but was just totaly evil to program and compiler writers pulled out their hair.

    I don't know enough about modern game programming to know if the PS3 route is a good one to take - and it's easy to bitch at Sony for going too far - OTOH look at the PS2 games now vs at release. The PS3 games should slowly get better and better and better if they don't crash and burn and give up...

    --Tarp
  • by stedo (855834) on Sunday February 26, 2006 @05:13PM (#14805373) Homepage
    True

    Actually, what I can't figure out is why you want floating point at all. Floating-point data stores a certain number of bits of actual data, and a certain number of bits as a scaling factor. To use your example, this would mean that while items near the origin would be picture-perfect, the object 10km away would be out by well more than a cm.

    Back when integer arithmetic was so much faster that floating point it was worth the effort, game coders used to use fixed-point arithmetic. This kept a uniform level of accuracy around the entire world, not like floating point which makes data near the origin more accurate. It was also very fast, and easy to implement. Why hasn't anyone implement fast fixed-point arithmetic in hardware? You could afford to go 64-bit if it was fixed-point since it is so much easier to compute (think integer arithmetic versus floating point), and 64-bit is accurate enough for very small detail in a very large world.

  • Time to let C die ? (Score:2, Interesting)

    by DichotomicAnalogist (955934) on Sunday February 26, 2006 @05:19PM (#14805396) Homepage Journal
    (Warning : troll venting off.)
    Let me summarize
    1. take one of the most unsafe, slowest-to-compile, pitfall-ish, unspecified languages in existence (ok, I might be exagerating on the "unspecified" part)
    2. add even more #pragmas and other half-specified annotations which are going to change the result of a program near invisibly
    3. don't provide a debugger
    4. require even more interactions between the programmer and the profiler, just to understand what's going on with his code
    5. add unguaranteed and slow static analysis
    6. ...
    7. lots of money ?
    Am I the only one (with Unreal's Tim Sweeney [uni-sb.de]) who thinks that now might be the right time to let C die, or at least return to its assembly-language niche ? I mean, C is a language based on technologies of the 50s 60s (yes, I know, the language itself only came around in the late 60s), and it shows. Since then, the world has seen
    • Lisp, Scheme, Dylan, ... -- maximize code reuse and programmer's ability to customize the language, automatic garbage-collection
    • ML, Ocaml, Haskell, ... -- remove all hidden dependencies, give more power to the compiler, make code easier to maintain, check statically for errors
    • Java, C#, VB, Objective-C ... -- remove pitfalls, make programming easier to understand, include a little bit of everything
    • Python, Ruby, JavaScript -- maximize programming speed, make code readable, make writing prototypes a breeze ...
    • Erlang, JoCaml, Mozart, Acute -- write distributed code (almost) automatically, without hidden dependencies, with code migration
    • Fortress -- high-performance low-level computing, with distribution
    • SQL, K, Q -- restrict the field of application, remove most of the errors in existence
    • and probably plenty of others I can't think of at the moment.

    And what are C and C++ programmers stuck with ?
    • a macro system which was already obsolete when it was invented
    • slow compilers
    • no modules or any reasonable manner of modularizing code
    • neither static guarantees nor dynamic introspection
    • no static introspection
    • an unsafe language in which very little can be checked automatically
    • mostly-untyped programming (not to be confused with dynamically-typed programming)
    • about a thousand different incompatible manners of doing just about everything, starting with character strings
    • manual garbage-collection (yes, I know about the Boehm garbage-collector -- but I also know about it's limits, such as threads)
    • a false sense of safety with respect to portability
    • extreme verbosity of programs.

    So, now, we hear that IBM is trying to maintain C alive, under perfusion. IBM, please stop. Let granddaddy rest in peace. He had his time of glory, but now, he deserves that rest.

    Oh, and just for the record. I program in C/C++ quite often as an open-source developer and my field is distributed computing. But I try to keep these subjects as far away from each other as I can.
    (well, venting off feels good)

  • by MobileTatsu-NJG (946591) on Sunday February 26, 2006 @05:26PM (#14805432)
    "I recall a common complaint by development houses about Sega consoles were that they were very difficult to code for because of hardware complexity. Isn't Sony now making the very same mistake that doomed Sega's console business?"

    Sega didn't make a single mistake, they made a LOT of them. I imagine you're thinking of the Saturn. It was supposed to be a SNES killer. In other words, all the fancy technology it had was meant to throw sprites on the screen. Then Sony showed up with it's fancy ass 3D architecture, and Sega said oops. So they band-aided some hardware in there to perform 3D functions. Unfortunately, this added another processor to the mix. The result? It was a bitch to program for, and it never really reached the performance levels of the PS. The result? Saturn games looked inferior to PS games. However, in the 2D fighter realm, the Saturn did quite well. As I recall, the Saturn was actually fairly successful in Japan for this.

    The Genesis was pretty easy to program for, at least compared to the SNES. The SNES had a weaker CPU, but it had extra hardware to beef up its graphics. In the end, the SNES won, but not without a couple of years of Genesis superiority. I remember lots of people bitching about the SNES slowing down when it came to a lot of sprites on the screen. This complaint died when Donkey Kong Country hit the scene.

    The Dreamcast... well I don't know as much about it. As I understand it, it wasn't too hard to program for. It even had some great hardware for throwing textures on the screen. This gave the DC an edge against the first generation of PS2 games despite having considerably weaker specs.

    The Saturn definitely hurt Sega. One could attribute this to the difficulty of programming for the system, and they'd likely be correct. PS ports to the Saturn often came many months after the original release, and they simply didn't do as well graphically. Sega had also flooded the market with hardware. Between the Genesis, the Sega CD, the 32X, and the Saturn, the market was pretty confused. Sega wasn't focused where they should have been and it came back and bit them in the keyster.

    Sega was in pretty sad shape financially when the DC was released. I vaguely recall that the president of Sega at the time had given up most of his shares of stock to keep the company afloat. (I want to say it was around 100 million dollars roughly, but I don't recall the specifics. I do remember thinking "wow, that's one dedicated dude.") In the end, though, Sega needed several hundred million dollars in order to get 10 million DCs out there in order to really start raking in money. But they simply didn't have the assets to do it. Kerplunk, the Dreamcast died, and Sega focused on software.

    With all that said, I'm sure a number of people will chime in with their own contribuatory reasons for Sega's demise. They wouldn't necessarily be wrong, either. It took a number of things to take Sega down, not one key one.

    "Speaking of which, is XB360 easier to code for than PS3?"

    I read an interview with Carmack not too long ago, and his answer was basically 'yes'. He did NOT go one to say that the difference would be a huge huge factor or not, though. Frankly, I have difficulty imagining it making all that big of difference, at least from a financial point of view. As these machines get more powerful, the weight of development shifts more towards the artists than the actual programmers. That is just an opinion, though. I'm a 3D artist by trade. Maybe my view is biased. But I know how much it costs to keep me seated at my desk. I know about how the work piles up by orders of magnitude as projects get more ambitious. And I have a pretty good sense of how artistry in video games has evolved over the last decade. Compare Super Mario 64 to Resident Evil 4 and you'll see what I mean.
  • by CarpetShark (865376) on Sunday February 26, 2006 @06:06PM (#14805580)
    The Cell doesn't seem to be that complex. It's a powerful processor, with multiple elements and associated timing issues that you have to be aware of, but that's nothing like the Gamecube or similar, which had all these weird modes and issues that I can't even recall now, probably because my brain blocked it out ;) It'll be a challenge for people who don't know parallel programming, and it might frustrate some who imagine that a cpu with 8 SPEs should act like 8 entirely independent machines, each with its own SPE. But, I think games developers these days will take it as par for the course. There seems to be a trend now that only the biggest and best games companies actually develop game engines (ie, right low-level optimised code), while the other companies just rent the technology and develop levels and artwork and scripting based on that engine. So, the big question is how many of the engine developers will get on board early and if they'll be sufficiently inspired and up to the task. I think they'll find a way :)
  • by SlayerDave (555409) <elddm1@gDEBIANmail.com minus distro> on Sunday February 26, 2006 @06:10PM (#14805594) Homepage
    Well, there's already been one parallel processing success story - the GPU. Granted, the GPU provides a more restrictive programming environment and memory model than the Cell, but with the right training and the right tools, it is possible to write code that effectively exploits parallelism.

    Let's also not lose sight of the big picture with regard to the Cell: the 8 parallel vector processors are coupled with a single CPU core derived from the PowerPC chip. So the overarching structure of the Cell isn't all that different conceptually from a typical CPU-GPU setup in most PCs today.

  • by Bazzalisk (869812) on Sunday February 26, 2006 @06:37PM (#14805684) Homepage
    C lacks a lot of features of more modern languages - but I think you'd be hard-pressed to find a modern autogarbage-collecting dynamicly typed modularise language which can handle low-level programming anything like as well as C.

    Certainly if I'm writing a pleasant little modern desktop application I'm going to write in Objective C or C# - would seem a little silly not to ... but for writing a compiler, a network stack, or gods forbid a kernel I don't know of anything that works even close to as well as C. C still has a niche, can't realy change that.

  • by Rufus211 (221883) <rufus-slashdot.hackish@org> on Sunday February 26, 2006 @06:42PM (#14805702) Homepage
    > And fixed-point isn't integer, bozo.
    Yes it is, as long as you're willing to put a few seconds of thought into it (or just google [gameprogrammer.com] for the answer).
  • by joshv (13017) on Sunday February 26, 2006 @06:54PM (#14805741)
    The problems IBM programmers are having are emblematic of the problems that the PC industry is going to be facing in a few years. Multi-core is the future of PC performance. Increasing GHz and IPC of single processors has pretty much hit a wall. Creating Dual and multi-core CPUs is the best approach we have left for increasing performance with future increases in transistor count/density.

    The problem is that single threaded programs will run just as slowly on your quad-core 'Core-Quattro' in 2008, as they did on your old Pentium 4 - c. 2005. Great, yeah, I know, server loads parallelize very nicely (witness the miracle of Niagra), but consumer grade CPUs are where the volume is at, and people are going to have to notice a real difference in performance in order to stay on the hardware upgrade treadmill. This necessitates that Intel/AMD/IBM come up with new programming models that make it easy to parallelize existing code. Parallelized libraries and frameworks are all well and good, but it will be 20 years before everyone gets around to recoding the existing codebade to the the new platform - and most of them are probably not going to generate optimal code.

    No, what we need are compilers that take programs written in a serial fashion, and emit code that scales well on multiple processors. The problems with the PS3 are only the beginning.
  • by ianpatt (52996) on Sunday February 26, 2006 @07:14PM (#14805777)
    >We can only wonder how things would have been if Intel had opened things up like IBM has, instead of making it so people have to figure things out on their own.

    It's not quite as clean as it looks. "Full specifications" doesn't include any information on instruction latencies, cache performance, etc. They've documented the platform itself, but not the specific implementation. This makes optimization difficult.

    I've had to distill information from several publications to determine even basic things like how many cycles it takes to retire a floating point add. So the information /is/ out there, you just need to do a lot of work to get it.
  • Re:Makes you wonder (Score:1, Interesting)

    by Anonymous Coward on Sunday February 26, 2006 @08:59PM (#14806054)

    The Cell is overhyped.

    There's another octuple processor that is better. The Sun UltraSparc T1. It blows Cell's doors off.

    The Cell only has 1 General CPU core and 7 flops.

    Why is everyone even talking about the Cell? The Sun T1 has 8 Cores with 32 threads each. These are 8 true cores (not 1 CPU and 7 half baked Floating Point cores like the Cell). The Sun T1 also has 4 DDR memory controllers and 72 Watts of power consumption. The Sun T1 also has a Sparc V9 architecture. Each of the Cores also has a floating point unit. The Sun T1 blows the doors off a Cell Chip.

    If it weren't for the 7 Synergistic Processors the Cell would be a Flop.

  • I remember (Score:3, Interesting)

    by DSP_Geek (532090) on Sunday February 26, 2006 @11:20PM (#14806415)
    About ten years ago VM Labs came out with something not too far off conceptually from the Cell - vector instructions, local memory you had to DMA in and out of, 4 processors on a chip. It wasn't floating point, however, and the development tools were best described as rudimentary: the best way of debugging was to deliberately crash the box and examine the register dump barfed back over TCP/IP.

    They called a developer's conference in August 1998, where after the presentation a veteran game coder shrugged: "Another weird British assembler programming cult".

    The Cell strikes me the same way, and for the same reasons, although Big Blue likely has more development tool budget than VM ever did. Not to take anything away from the smart guys at IBM, but I suspect they'll have a fun time working around the Cell's limitations. I can tell them from experience that DMAed local memory will be much more of a pain in the ass than they can imagine, and unless they can guarantee sync in hardware they'll be wasting a bunch of time schlepping spinlocks in and out of memory. The vector stuff will also be nontrivial: the best way to make that usable, apart from having everyone write vector code from the git-go, would be to provide a stonking great math library in the style of the Intel Integrated Performance Primitives.

    As an aside, the PS3 is in the tradition of Sony not caring about who programs their machine: the PS1 was easier to code than the Saturn, which was a true horror, the PS2 upped the difficulty a fair bit, and now even experienced coders are bitching about the PS3. Meanwhile Microsoft is learning from their mistakes: the X360 is easier than the X1, and if you doubt that makes a difference, check out game development budgets and time to delivery. I don't care, really: I eat algorithms and machine code for breakfast, so this just means more jobs and money for me.
  • by Animats (122034) on Monday February 27, 2006 @12:21AM (#14806551) Homepage
    The basic problem with the Cell processor is that the SPEs each have only 256K of private memory, with uncached, although asynchronous, access to main memory. It's the unshared memory that's the problem.

    This architecture has been tried before, for supercomputers. Mostly unsuccessful supercomputers you've never heard of, such as the nCube [wikipedia.org] and the BBN Butterfly. [paralogos.com] There's no hardware problem building such machines; in fact, it's much easier than building an efficient shared-memory machine with properly interlocked caches. But these beasts are tough to program. The last time around, everybody gave up, mainly because more vanilla hardware came along and it wasn't worth dealing with wierd architectures.

    The approach works fine if you're doing something that looks like "streaming", such as multi-stream MPEG compression or cell phone processing. If you want to do eight unrelated things on eight processors, you're good.

    But applying eight such processors to the same problem is tough. You've got to somehow break the problem into sections which can be pumped into the little CPUs in chunks that don't require access to any data in main memory. The chunks can't be bigger than 50-100K or so, because you have to double buffer (to overlap the transfers to and from main memory with computation) and you have to fit all the code to process the chunk into the same 256K. That's a program architecture problem; the compiler can't help you much there. Your whole program has to be architected around this limitation. That's the not-fun part.

    You have to make sure that you do enough work on each chunk to justify pumping it in and out of the Cell processor. It's like cluster programming, although the I/O overhead is much less.

    In some ways, C and C++ are ill-suited to this kind of architecture. There's a basic assumption in C and C++ that all memory is equally accessable, that the way to pass data around is by passing a pointer or reference to it, and that data can be linked to other data. None of that works well on the Cell. You need a language that encourages copying, rather than linking. Although it's not general-purpose, OpenGL shader language is such a language, with "in" and "out" parameters, no pointers, and no interaction between shader programs.

    Note that the Cell processors don't do the rendering in the PS3. Sony gave up on that idea and added a conventional NVidia graphics chip. (This guaranteed that the early games would work, even if they didn't do much with the Cell engines.) Since the cell processors didn't have useful access to the frame buffer, that was essential. So, unlike the PS2, the processors with the new architecture aren't doing the rendering.

    It's possible to work around all these problems, but development cost, time, and risk all go up. If somebody builds a low-priced 8-core shared memory multiprocessor, the Cell guys are toast. The Cell approach is something you do because you have to, not because you want to.

  • by rodac (580415) on Monday February 27, 2006 @04:16AM (#14807004) Homepage
    No that is not a good example of something that needs/benefits from better accuracy.
    The problem is that code cutters today have zero understanding of what they do or theory and then they blame lack of precision for the "error" terms.

    No matter how high you make precision there are lots of numberical calculations that just can not be done accurately without a proper education in computer science or numerical analysis.


    Question 1: Using Gaussean elimination, I want to invert a Hilbert-matrix with 100 rows and 100 columns, how many bits of mantissa do I need in the float representation if I want the residual error to be less than 1%?
    1, dont know. dont even know how to estimate ==> you should not write numerical software since you lack the tools and understanding required.
    2, make them really big. ==> see above. 3, 128bits. ==> see above 4, could estimate it bit it is pointless since that algorithm is not numerically stable. ==> almost there 5, 4+the Gershgorin(spelling?) circles show that we have to do partial pivoing (english name?) to stabilize the calculations. ==> congratulations right answer.


    I am in the unfortunate position to have to work with the 1-3 answer people. Todays cs degrees are just paper and dont even cover the most basic 101 skillsets. I bet they can hack together an example inventory database app in VB really quickly though.
  • by Macka (9388) on Monday February 27, 2006 @04:35AM (#14807054)
    The Itanium on the other hand was obsolete on it's launch. Even HP dumped it after killing their own better performing 64 bit processor for it and spending billions of dollars and ten years building it.
    HP most certainly have not dumped it. If anything they're pushing harder than ever. All I hear from HP these days is Itanium, Itanium, Itanium .... and I've been to a few HP pre-sales events in the last couple of months where they've been pushing it very hard. In a few months they'll be revising their Integrity line and introducing systems that are Montecito ready. Right now HP are saying that for Integrity, they will not be beaten on price. And if you're in the market for an Itanium server you can expect to get some pretty hefty discounts!

    Yes Itanium has failed to grab anything like the market share it was meant to. But that has nothing to do with its architecture. There's an arstechnia review from last year (I think) which talked about the Itanium architecture, and they were very up beat and complementary about it. The summary of that article was that as fabrication tech improves and die shrinks follow, and it becomes possible to cram more cores and larger and larger caches on to a chip, the Itanium architecture has more scope to grow and perform than any of its current competition. EPIC loves large caches.

    There is only one real reason why Itanium has been such a flop so far, and that's x86-64. Intel had no intention of bolting 64 bit tech onto the x86 architecture. If you wanted 64 bit computing you were meant to go Itanium. End of story. That was the way Itanium was going to get its market share, and large volumes were going to drive the costs down. Intel either didn't see AMD coming, or didn't see what they were doing as a threat until it was too late. The x86-64 bomb shell, when it hit, threw Intel into complete disarray. Not only was x86-64 way cheaper than Itanium, but it out performed it and it offered seamless backward compatibility. The Itanium volume market plan was doomed from that moment on. As a consequence Intel had to scrap their x86 road map and re-draw it with their own 64 bit implementation, i.e. EM64T. They've been playing catch up ever since.

    A side effect of the Intel's change in direction and focus has been a change in where they've put their resources. Itanium got starved of the resources it was originally planned to have and as a consequence Montecito is way late and isn't quite the kick ass design it was meant to be. Intel's partners like HP have suffered as a consequence.

    Never the less Itanium is not going away, and even though Montecito is late, the current crop of Itanium chips are no slouch. When Montecito arrives it's going to give a much needed boost to HP Itanium sales. That's what they hope for anyway.

The reason why worry kills more people than work is that more people worry than work.

Working...