Slashdot Mirror

← Back to Stories (view on slashdot.org)

HP Shows Off PA-8800 SMP-On-A-Chip CPU Plans

Posted by timothy on from the chips-within-chips dept.

Eric^2 writes: "At last week's MicroProcessor Forum, HP's David J. C. Johnson unveiled the details of HP's latest RISC processor destined to redefine performance in Server-Class processors. Following a relatively simple strategy, the PA-8800 processor combines two PA-8700 cores on a single chip to enable symmetric multiprocessing (SMP) on a single processor. Aside from bumping the core speed up to an initial 1 GHz, enhancements include the addition of combined 35 MB L1+L2 cache. The article contains the full text. AMD, please steal an idea..."

176 comments

  1. And Get Sued? by tomblackwell · · Score: 1, Offtopic

    These companies tend to patent anything that will give them a competitive edge in the marketplace. "Stealing an idea" would probably get them into some legal hot water, just like stealing a TV, or your car.

    1. Re:And Get Sued? by Anonymous Coward · · Score: 0

      I think he's saying this jokingly. It is very feasible that AMD could come up a similar idead or license the rights to build SMP chips from HP.

    2. Re:And Get Sued? by Mifflesticks · · Score: 2, Informative

      It wouldn't be stealing an idea. This idea has been around for a long time in academia. Maybe the poster forgot this, but the POWER4 from IBM does this, and comes with 32Mb of L3 cache, plus an ondie shared L2 cache. The idea isn't new, it's known as CMP (Chip-level Multi-Processing). Really, "SMP on a chip" is merely called CMP.

      Also, though Sun has decided not to use the MAJC architecture for anything (they were hoping to try to get it to become a video-accelerator, but that's not even going to happen, most likely), that too was fully spec'ed out to have multiple cores on a chip...it's really nothign new :)

      The longstanding rumour is that AMD will be coming out with a dual-hammer processor (ie, CMP). In academia, the idea has been used frequently as well.

      The idea of using CMP isn't even that big a deal to most consumers. While it would be nice for AMD to come out with a chip that does multithreading (merely because it increases real-world throughput quite a bit, depending upon the type of multithreading), the average PC running windows 9x/ME/ XP Consumer won't be able to multithread anyway. The only reason for AMD to multithread is for the server-space, which is what they're aiming for with the hammer series...but I digress.

    3. Re:And Get Sued? by C0vardeAn0nim0 · · Score: 2

      Not likely. HP is Intel's partner in the development of Itanium, which is based on PA-RISC.

      If AMD has a desire to cram two AMD-64 in one package they better come with their own solution or license IBM's one...

      --
      What ? Me, worry ?
    4. Re:And Get Sued? by Anonymous Coward · · Score: 0

      Heck, I still have a paper from a C.S. class (1992) where I was suggesting the idea of combining cores on one chip to enable faster SMP. Would that be prior art? Funny thing is, the prof said it as a stupid idea.
      Hey Dale Grit, are you listening?

    5. Re:And Get Sued? by Anonymous Coward · · Score: 0

      He said "idea", not end result. It's not illegal to use someone else's idea as long as you don't build the same product using his method (which is likely patented).

    6. Re:And Get Sued? by c_g_hills · · Score: 0

      Just how much did you want to melt your pc anyway :)

    7. Re:And Get Sued? by Amazing+Quantum+Man · · Score: 2

      the average PC running windows 9x/ME/ XP Consumer won't be able to multithread anyway

      Not to defend MS, or anything, but XP Consumer is still based on the NT core. It'll multithread.

      --
      Fascism starts when the efficiency of the government becomes more important than the rights of the people.
    8. Re:And Get Sued? by Anonymous Coward · · Score: 0

      Yeah, but M$ will probably cripple it and/or have some kind of per-thread licensing scam.

  2. Hmmm Sounds Like IBM by devinoni · · Score: 2

    The IBM p690 server uses POWER4 processors. Each
    chip has 2 POWER cores with high-speed interconnects. Even better is that each chip is connected to 3 other chips to make up 8 CPU packs.

  3. Now if i could only get that i my pda by Anonymous Coward · · Score: 0

    then i'd be happy.

  4. How much cache??? by larien · · Score: 2

    Wow... And I thought the 8MB L2 cache on UltraSPARC IIIs was a lot, not to mention the 16MB on some IBMs. Now we're talking about 3MB just in L1 with 32MB L2 cache. This beasty should have some impressive benchmark scores (yeah, I know, benchmarks aren't everything...)

    1. Re:How much cache??? by yobbo · · Score: 0

      What is faster - a large high latency level 1 cache, or a small but low latency level 1? Intel bet on the latter with pentium 4, having an extremely small level 1 but making up alot of performance due to the fact that it was single latency, as opposed to the Athlon which is either 2 or 3 cycle (?) Sun seems to think more along the lines of AMD. Have a large level 1, and hope that the sheer amount of stuff that fits in your level 1 makes up for the performance you lose due to the fact that it takes longer to actually access the data. Only in this case, Sun is going with a..... absolutely *huge* L1... interesting

      It'll be very interesting to see how future processor designs go, if we do in fact see designs branch in different directions. Then again, it may appear awkward that i'm comparing x86 designs to SPARC, but seeing AMD will be hoping to compete head on using x86-64, i think it will be relevant. Especially considering the initial spec number published for Sledgehammer. 1400 in specint, WOAH!

    2. Re:How much cache??? by LenE · · Score: 1

      The latency issue just isn't an issue with the SPARC, or any other modern RISC-ish architectures. Out of order execution and branch prediction techniques can accomodate latencies. Cache size though, is much more important, as a larger cache can hold many queued instructions and data, which will be fed in a constant stream to the processor without having to revert to slower memory.

      In the P4, 20 stage pipeline and it's prediction logic are much more succeptible to cache latency problems. Waiting two or three cycles for data on a P4 could cause major pipeline hiccups.

      -- Len

    3. Re:How much cache??? by CBravo · · Score: 1

      don't lie. Latency problems are totally program dependant. You can't cache new data ...

      The L2 cache of the P4 probably has a # cycles latency, but I don't think it is a problem. In fact it could be a reason to implement extreme pipelining (so you can make 'small' steps towards computing the result instead of only being able to take big steps). Waiting for main memory _is_ a problem, _BIG_ problem.

      I really wonder where you get your ideas.

      --
      nosig today
    4. Re:How much cache??? by LenE · · Score: 1

      I'm not lying and latency problems are not "totally program dependent."

      RISC takes many more instructions to do the same thing as a CISC chip, so caching the instructions will improve the performance for repeated actions. The P4 is RISC like on the chip level, so it would probably benefit from a much larger cache. I believe that the size of it's cache has less to do with the fact that it's low latency than it does with chip yields for making memory that runs reliably at 2Ghz.

      I will concede that some programs would definately show the large cache as superior to a small low latency cache. Witness the older SPEC benchmarks which became obsolete when they would fit entirely into the L1 and L2 caches of some processors. In this case, the large cache is superior to the small low latency cache.

      Think about what these processors will be used for. Most likely, they will be used for large database servers, as that is what HU-UX is good for. While an entire database will not fit into 32 Meg, a lot of repetitive queries and essential system and program code can fit into this large cache. In this way, this processor would be superior to a raft of P4's which would be constantly fetching from main memory for this particular type of service. So the first search for "Pam Anderson" web sites would take the same amount of time on a P4 as it would on this PA-8800, but every successive search would have a much higher possibly of being a cache hit on the PA-RISC chip.

      I agree completely that waiting for main memory is a huge problem.

      -- Len

    5. Re:How much cache??? by madhuhr · · Score: 1

      1. The extremely large amount of cache will not really affect m/cs with small number of processes, as a small amount of cache is usually anough for a very high rate of hits. After that the latency issues arise, which can be taken care of by aggressive pre-fetching.

      2. It will make a major difference when there are a large number of processes... prevents thrashing...only between the L1/L2 cache and the memory....as must be obvious...HP is targetting Servers with that processor.....where in a large difference can be expected....For single user workstations...an 8MB L2 cache is more than what you will ever ever need.

      Opinions welcome

    6. Re:How much cache??? by aanantha · · Score: 1

      No SPARC or UltraSPARC processor supports out of order execution.

    7. Re:How much cache??? by LenE · · Score: 1

      I stand corrected. The Alpha, Power, PowerPC and the RISC-ish P6 core (not the x86 interpreter) use out-of-order execution. I think that the MIPS IV and later also use this, but I'm not sure.

      I just assumed that the Ultra SPARC would use it as well. Mea culpa.

      -- Len

    8. Re:How much cache??? by CBravo · · Score: 1

      Since this discussion is going nowhere, lets be specific:

      > The latency issue just isn't an issue with the
      Name me a processor that is high end and it will have a latency problem. If you say that isn't true you haven't designed or thought about architectures. Besides that all designs are aware of it and try to hide latency problems. Designs would be _drastically_ different without latency problems.

      >Cache size though, is much more important, as a larger cache can hold many queued instructions and data, which will be fed in a constant stream to the processor without having to revert to slower memory.
      You just defined cache and it's importance, but not why it's size is important. More is not better. More is a choice with it's drawbacks. I take your point on how this processor would often be used (databases).

      >Waiting two or three cycles for data on a P4 could cause major pipeline hiccups.
      But since 2 stages in a P4 are equivalent to 1 stage in an Athlon what is the difference? (P4 has 20 stage, athlon has 10 stage i think).

      --
      nosig today
  5. duplication of effort by Anonymous Coward · · Score: 0

    wow, that sounds a lot like IBM's release re: the Power4... except not as interesting

  6. just to make sure nobody is misled... by turbine216 · · Score: 4, Interesting

    ...a 1 GHZ processor may not sound like much, even in this dual-core configuration, but keep in mind that this is a RISC processor. None of that Super-mega-ultra-long-50-bazillion-stage pipeline crap that Intel uses to pump up their MHz rating. The article kind of sells this point a little bit short. The RISC architecture allows this processor to do roughly twice as much work in the same amount of time - or, to put it in a more concrete scenario: imagine a pair of 2GHz Pentium 4's running in SMP configuration.

    Now that's FAST .

    1. Re:just to make sure nobody is misled... by Ozric · · Score: 1

      It is not just the cpu, Think about the I/O in the HP9000. Now that's FAST

    2. Re:just to make sure nobody is misled... by Anonymous Coward · · Score: 0

      Now now... you and I both know that's a bit of bull. You really can't compare Mhz between a RISC and a CISC, simply because the CISC processor likely has instructions which, translated to a RISC architecture, would require 2 or 3 instructions. The result, RISC programs are much larger, and the processor has to execute many more instructions to perform the same task as a CISC. OTOH, on the RISC, there is more opportunity for pipelining and other optimizations, but the point is, comparing a RISC to a CISC based purely on Mhz is really like comparing Oranges to Lemons. They're similar, but really not the same.

    3. Re:just to make sure nobody is misled... by Anonymous Coward · · Score: 0

      Gawd, talk about a troll-o-rama. Yeah, and the Macintosh is "twice as fast" as the equivalent Intel processor.

      Sorry bud, but RISC is not some magic incantation.

    4. Re:just to make sure nobody is misled... by warpSpeed · · Score: 1


      It might be fast, but imagine the heat sink on that puppy. It could heat my pool... in the middle of winter.

      ~Sean

    5. Re:just to make sure nobody is misled... by svirre · · Score: 5, Informative

      Risc or cisc architecture primarily affect the complexity of the fetch and decode stages of the CPU.

      The famous Intel-pipeline is in the execute stage (ALU).

      Pipelining is a strategy which is equally valid for both risc as in cisc architectures, and a risc architecture do not offer any complexity advantage in the execute stage. After all a multiplier is a multiplier regardless of overlaying architecture.

      Nowdays we don't really see much diffrence in performance between risc and cisc architecures for upscale processors. This is because the savings in fetch and decode logic are dwarfed by other costs like prefetch, reordering and brach prediction (which are used for both architectures).

    6. Re:just to make sure nobody is misled... by buckeyeguy · · Score: 1

      Hehe... well, let's see: the heat sink on the K-class CPUs (180/240Mhz) is a big metal plate, essentially, with some sort of cooling channel in it; the 550Mhz PA-8600s in our N class have a square-socket style stack heat sink, amid a bunch of high-volume fans... that sink is about 3-4 times as tall as an Intel/AMD socket chip. So this new one would have to be a big beastie... active cooling this time? Maybe?

      --
      I'd have a personalized plate on my car, but "toxic bachelor" won't fit into 7 letters.
    7. Re:just to make sure nobody is misled... by Anonymous Coward · · Score: 0

      RISC -vs- CISC is about instruction efficiency.

      PA-RISC and others (Alpha, UltraSparc, ...) achive
      the speed you're describing because they are
      superscalar processors.

      By superscalar (in case you didn't already know)
      I mean that the processor pipeline can carry out
      more than one instruction per clock cycle (cpi1.0).

      Each PA 8800 cpu core is a 4-way processor, i.e.
      it can retire up to 4 instructions per cycle. And
      at 1 GHz. that's quite a few.

      The huge caches help alot too, since the latency
      between the caches and the core are really low,
      keeping you from stalling your pipelines as often.

      Pipelines are used of course, but pipelines are
      a microarchitectural feature that don't necessarily make your CPU faster than a non-pipelined model.

    8. Re:just to make sure nobody is misled... by mrm677 · · Score: 1

      RISC vs. CISC doesn't matter anymore. Both AMD and Intel convert the CISC architectural instructions into RISC-like internal instructions called "micro-ops".

      The Iron Law of microprocessor performance states:

      time = Instructions/Program * Cycles/Instruction * Seconds/Cycle

      Notice that the above cancels to Seconds/Program.

      So given the same program, you can do one of two things to reduce the execution time:

      1. Reduce Cycles/Instruction. This is done by executing more instructions at a time (Superscalar execution), and reducing the penalties of speculation (predicting what the program will do).

      2. Reducing the Seconds/Cycle (increasing clock rate). This is the approach Intel has taken with Netburst (Pentium 4).

      By making the PIV pipe 22 stages long, this helps Intel increase the clock rate. It also helps throughput. Assuming an ideal world where no data dependencies exist, more stages == better throughput. However, Control and Data Hazards always messes up a pipeline and the longer the pipeline, the more of a penalty on a branch misprediction. This increases cycles/instruction (CPI).

      The average CPI of AMD and PIII is much lower than the P4, however it makes up for this in clock rate.

    9. Re:just to make sure nobody is misled... by psergiu · · Score: 2

      As i handled a few of them, I think the K-class cpu (pa8000 - 8200) coolers are active ones. Not sure about the ones in L and N class servers (which have BIG radiators cooled by HUGE fans) or about the SD ones (which are cooled by 4 BIG M-F turbines and some fans)

      --
      1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
  7. An old idea.... by gatkinso · · Score: 0, Troll

    Intel jammed two 486 cores on a chip and called it a "Pentium."

    Gross simplification is a viable debating tactic, BTW.

    --
    I am very small, utmostly microscopic.
    1. Re:An old idea.... by Anonymous Coward · · Score: 0

      Or, hee's trolling for idiots... WOAH! Looks like he caught another one!

    2. Re:An old idea.... by gatkinso · · Score: 1

      What part of "gross simplification" did you not understand?

      At any rate, read for yourself:

      http://developer.intel.com/design/pentium/manual s/ 24319001.pdf

      --
      I am very small, utmostly microscopic.
    3. Re:An old idea.... by Anonymous Coward · · Score: 0

      I thought they called it a 486DX2

  8. Practical Ideas by Renraku · · Score: 0

    It doesn't seem too practical to me. Most apps don't benefit greatly from SMP anyway. Add to that the potential heat problems caused by two cores on one chip...Why not just go with a more traditional SMP approach? At least you won't have to worry too much about heat then.

    --
    Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
    1. Re:Practical Ideas by Anonymous Coward · · Score: 0

      These type of processors are designed for servers. The machines often have at least 8 or all the way up to 256 processors in them. Doing this allows the processors to communicate with each other at a higher speed.

      These type of machines run in air conditioned enviroments and have jet engines for cooling fans.

    2. Re:Practical Ideas by psavo · · Score: 0, Troll

      It doesn't seem too practical to me. Most apps don't benefit greatly from SMP anyway. Add to that the potential heat problems caused by two cores on one chip...Why not just go with a more traditional SMP approach? At least you won't have to worry too much about heat then.

      Yo! Helloou? Where are you living man? In what decade? This is year 2001 and most of "cooperative multitasking" crap is buried in hell with windows 3.1 and alikes. Even MacOS is phasing out (though that one worked out pretty nicely [because of interface built that way])
      You get tremendous boost when using SMP. There's no way to describe it, it's just awesome!

      Remember, you run pretty many tasks continuously, and simultaneously! There's maybe apache, mozilla, bluefish, emacs & others running all the time! For chrissakes, why do you think distros make X 'nice -10'? Most of the applications are multithreaded by now, not doing it is just insane, simply because of different overheads & application responsiviness.

      Just think for a moment before posting something like that..

      --
      fucktard is a tenderhearted description
    3. Re:Practical Ideas by NerveGas · · Score: 4, Informative

      It doesn't seem too practical to me. Most apps don't benefit greatly from SMP anyway.

      They don't? What kind of server do you run? Most all pieces of production-class server software that I know of benefit from multiple processes. Look at Apache, forking off five, ten, or even more processes to handle requests. MySQL, I believe, uses threads. PostgreSQL forks off a new backend for each connection. Shoot, even your telnet, ftp, ssh, and mail daemons will fork off for each connection, allowing you to take advantage of more than one CPU.

      If you're sitting at home working on a spreadsheet, you're right, SMP isn't for you - and this machine isn't targetted at you. When you're running a server that may have tens, hundreds, or thousands of SIMULTANEOUS processes fighting for CPU time, every processor counts.

      And, to make things even better, even if you're only running a single, non-threaded process, having two processors still makes the machine much more "responsive", as the second CPU can handle kernel code for file IO, network code, interrupt handling, writing to logs, and a lot of other tasks. Ever seen how much CPU time even syslog can chew up?

      steve

      --
      Oh, you're not stuck, you're just unable to let go of the onion rings.
    4. Re:Practical Ideas by arielb · · Score: 0

      maybe he wants to play solitaire on his server :)

      --
      ---
    5. Re:Practical Ideas by sketerpot · · Score: 1
      True, most apps don't benefit from SMP. Your word processor won't, unless you have some sort of super-souped-up emacs thing. Your web browser wouldn't benefit much even if it were made multi-processed, despite all the Intel hype about enhancing your internet experience.

      But some programs will benefit. Have you ever run a heavily used web server? They fork off lots of processes. It will benefit greatly from SMP.

      Most processor intensive programs have become multithreaded, and the rest can be if SMP becomes popular.

      I see too many people asking what the use of something is if all their existing stuff wouldn't benefit from it. This is often because their stuff hasn't had any reason to adapt to this cool new thing that people are going to reject because their stuff doesn't benefit from it now. Take the plan9 OS for example. It does the Right Thing for a great networked internal structure, but the GUI stinks. It is not popular, partly because people don't like the UI. But if poeple used it, the GUI would be improved and we would have all its cool benefits.

  9. Did I read that right? by ruiner13 · · Score: 4, Insightful

    Did that say 35MB of L1 + L2 cache? I may be rusty, but I think I remember reading in my Processor Design for Dummies book that increasing cache size actually can slow down processor performance after a certain amount. Could someone please clarify this?

    --

    today is spelling optional day.

    1. Re:Did I read that right? by Mifflesticks · · Score: 1

      It can hurt performance because the larger the cache, the higher it's latency is going to be. Of course, the larger it is, the higher the hit-rate in that cache, so it's less likely to have to go down another level in the memory hierarchy.

      Using more caches of varying sizes is actually better than a monolithic cache, for reasons you described. If there are more caches, the primary one can focus upon low-latency, the second for high-bandwidth, and the third for high-hit-rate.

      But yes, it is indeed 35Mb of caches, though it's worthy of note that the L2 cache is off-die.

    2. Re:Did I read that right? by NerveGas · · Score: 1

      As the CPU frequencies outstrip memory frequencies by larger and larger margins, the cost of a cache-miss increases - and so does the number of cycles a chip can afford to use looking through the cache. Because of that, the amount of cache where it stops making sense to add more is much, much higher than it was five years ago.

      Intel chips, though, keep using about the same overall amount of cache, to keep costs down.

      steve

      --
      Oh, you're not stuck, you're just unable to let go of the onion rings.
    3. Re:Did I read that right? by bmajik · · Score: 2

      the ratios between memory heirarchies should be taken into consideration when designing any layer. For instance, increasing vastly the size of the L2 cache will make the L2 hit ratio go up, but the L1 hit ratio go down (assuming the inclusion policy is in effect - this is not always so anymore -- see the 1st generatino Duron chips)

      Similarly, adding more ram to a machine _could_ slow it down in some situations because the "overall" cache hit ratio could go down.

      Also, when caches get to be too large, the cache policy may need to be changed. A fully associative cache is the most flexible placement policy and can give great hit ratio for a large working set, however, a fully associaive cache search takes longer than a direct map "search" or a set-associative search.

      So, if to get a large cache size they had to go to set assoc or direct mapped, then that will generally lower the hit ratio vs a cache of the same size which is fully assocaitive.

      It's all tradeoffs basically. You could write a cache simulator to play around with this :)

      --
      My opinions are my own, and do not necessarily represent those of my employer.
    4. Re:Did I read that right? by be-fan · · Score: 2

      Yea, I gagged a little myself the first time I read it. Until I remembered that HP was the one who put 1.5 MB caches on chips in the PII era.

      --
      A deep unwavering belief is a sure sign you're missing something...
    5. Re:Did I read that right? by AndroSyn · · Score: 1

      Sun has been putting 8MB of L1 + L2 cache on the Ultrasparc 3 cpus. Of course..this cpu is really out there now and not just an idea on the drawing board..

    6. Re:Did I read that right? by Looge+Over+All! · · Score: 0

      They haven't been putting anywhere near 3MB of L1 cache in them though.

      They're not even in the same league.

    7. Re:Did I read that right? by ruiner13 · · Score: 1

      So then, theoretically speaking, a combination of a large cache and a long pipeline ala Pentium4 would be very bad, as it would take up more spaces in the pipeline while it waits for the cache to be paged through, or do I have this backwards? Would a larger cache on the P4 help it with its ungodly long pipeline since cache misses would be reduced?

      --

      today is spelling optional day.

    8. Re:Did I read that right? by T-Punkt · · Score: 1

      > For instance, increasing vastly the size of the L2 cache will make the L2 hit ratio go up, but
      > the L1 hit ratio go down (assuming the inclusion policy is in effect - this is not always so
      > anymore -- see the 1st generatino Duron chips)

      This is wrong - the size of the L2 cache has no effect on the hit rate of L1 cache(s). Just think about what a hit or miss really is and then ask yourself why 0MB, 1MB, 2MB ... of L2 cache should make a difference for the hit-rate of the L1 cache.

      And - since L1 caches usually work with virtual and not physical adresses - the L1 hitrate is not even influenced (much) by the amount of RAM.

    9. Re:Did I read that right? by bmajik · · Score: 2

      if L1 is implemented as a direct-mapped cache of L2, then if L2 increases, L1's hit ratio goes down.

      It may be the case that no L1 is implemented this way. It is certainly the case that adding more ram will decrease the HR of an L2 cache

      Wether the L2 miss penalty * frequency of L2 miss vs the PF penalty * frequency of a page fault turns out to be greater is probabably

      1) workload specific
      2) generally in favor of more ram at the expense of lower L2 hit ratio (because PF servicing is abysmally slow)
      3) you can probalby generate a pathological case that shows either result :)

      Apologies, I'm rusty on this stuff :)

      --
      My opinions are my own, and do not necessarily represent those of my employer.
    10. Re:Did I read that right? by christophersaul · · Score: 1

      Good point. And Sun aren't killing their CPU line and replacing it with Itanium. I just can't see the logic in HP's strategy.

    11. Re:Did I read that right? by T-Punkt · · Score: 1

      > If L1 is implemented as a direct-mapped cache of L2, then if L2 increases, L1's hit ratio goes
      > down.

      Yes, *if*, but it can't work this way, since the L2 cache isn't used as a direct access memory.

      The L2 cache is a associative memory, i.e. you use the normal (physical, in seldom cases maybe even virtual) adresses to adress memory. (Otherwise it wouldn't be a cache...)

      Which means that the adress space the L1 cache has to handle is not affected by the size of the L2 cache and that means the L2 cache has absolutely no influence on wether a access to the L1 cache results in a hit or miss - it doesn't even matter if there's a L2 cache or not.

    12. Re:Did I read that right? by larien · · Score: 2
      And IBM have some systems with 16MB of cache.

      They even have one system with a 128MB L3 cache!

    13. Re:Did I read that right? by psergiu · · Score: 2

      Remember that those cpu's are intended for some machines which come with a reccomended minimum of 1GB Ram of more ...

      --
      1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
  10. Smokin by thetechweenie · · Score: 1, Informative

    Why hasn't someone else done something like this? I would pay whatever it cost to get even an 8MB L1 & L2 Cache. Anyone want to make me one?

    --


    Um, this is my sig.
    1. Re:Smokin by Anonymous Coward · · Score: 0

      Because it's expensive, the yields are low, and in bigger processes (> 0.2um), the chips would have been huge.

    2. Re:Smokin by Anonymous Coward · · Score: 0

      Sun's been selling them for a while now. Go check out the Blade 1000, dual 900MHZ CPUS each with 8MB L2...

    3. Re:Smokin by thetechweenie · · Score: 1

      Do any /. readers have one of these? I'ld love to see a benchmark of one of these, and a similair sparc or something. Maybe TomsHardware could pull something like this off? Anyway, the price would be worth the geek factor.

      --


      Um, this is my sig.
    4. Re:Smokin by T-Punkt · · Score: 2, Informative

      "whatever it cost"?

      Then go an buy something from Sun, IBM, Compaq -> AFAIK all three buy servers with that large L2 Caches. (Maybe HP and SGI as well).

      E.g. something from IBM's z900 serie (mainframe - up to 32 MB L2 (per CPU?)) or pSeries 620 (workgroup/midrange server - up to 8MB L2 per CPU) or Sun Enterprise 450 (workgroup server - up to 8MB L2 Cache per CPU), Sun Fire 15K (High End Server, 8MB L2 per CPU), Compaq Alphaservers GS/ES series (up to 8MB per CPU).

      And if you want just total of 8MB a SGI Origin 300 with more than 4 CPU should do it as well (2MB L2 per CPU).

  11. Re:What about? by Anonymous Coward · · Score: 0

    Wow, modded down in less than 0.3 seconds! Light speed moderation, I have a patent, and you owe me.

  12. WOW!!! by Anonymous Coward · · Score: 0

    Just imagine a Beowulf cluBLAM!!! Thud.

    1. Re:WOW!!! by Anonymous Coward · · Score: 0

      cooled with hot grBLAM!!!... uh, smells like nataBLAM BLAM!!! Thud. goaSTOMP!! urghh...

  13. Siroyan's OneDSP by Anonymous Coward · · Score: 2, Informative

    The most interesting parallel architecture I heard about at the MPF was Siroyan's OneDSP architecture. This is a clustered VLIW machine that can execute up to 64 instructions each cycle! See the EE times article and their MPF paper

    1. Re:Siroyan's OneDSP by Mifflesticks · · Score: 1

      I bet the compiler guys are gonna have fun statically scheduling 64 instructions each cycle! (if you can't tell, I'm dripping with sarcasm, as Intel is even having a tough time scheduling 6 per cycle...though this is a DSP, so that makes it's application much better).

  14. Thanks, Rob! by Anonymous Coward · · Score: 0

    " One guy wrote that we should take all these Legos and build giant robots with which to attack Afghanastan. " -- Rob Malda, Founder of Slashdot, a "News for Nerds" website, in a NPR report on post WTC gen-X, 10/22/2001

    I, for one, would like to take a moment to thank Rob for setting us "Nerds" back where we belong. Way to make us look like a bunch of childish tech-heads with no conception of the real world! As a troll, I think it's high time that you slashdotters got slapped down for the idiotic geeks that you are! (That was sarcasm, you nincompoop!)

  15. Official HP presentation at MPF 2001 by Yumpee · · Score: 2

    The official HP presentation on the PA-8800 is
    available as a PDF from http://www.cpus.hp.com/technical_references/mpf_20 01.pdf.

    Y.

  16. Of course... by Anonymous Coward · · Score: 0

    It has the clock frequency of a 300bps modem's dsp. That's still pretty darn cool! *shrug*

    1. Re:Of course... by Anonymous Coward · · Score: 0

      It should be noted that this is a synthesizable processor core (like ARMs) and so 200MHz is pretty respectable. (The fastest synthesisable core is about 360MHz and issues 1 instruction per cycle).

  17. Two CPUs on a chip. by Animats · · Score: 5, Informative
    That makes sense. Two CPUs on a chip isn't a new idea, though. The IBM Power4 PowerPC chip is very similar, with two PowerPC processors on the same die. There's even a module with 4 such chips (8 processors) inside a machined aluminum block. That's intended as a building block for supercomputers.

    Earlier steps in the multi-CPU direction included the 8-way DEC Alpha (killed in the merger with HP?) and a little National Semiconductor product for embedded systems with two very modest CPUs on a chip.

    1. Re:Two CPUs on a chip. by questionlp · · Score: 1
      Earlier steps in the multi-CPU direction included the 8-way DEC Alpha (killed in the merger with HP?) and a little National Semiconductor product for embedded systems with two very modest CPUs on a chip.
      The IP for Alpha is now in the hands of Intel rather than Compaq (or Hewlett Paqard). I'm not sure if Intel will assimilate the technology into their IA-64 processors, release it as a high-end EV7 processor, or just kill it altogether.
    2. Re:Two CPUs on a chip. by jacoplane · · Score: 1

      Remember that the IA-64 is being developed jointly by Intel and HP, so maybe they will share the information.

    3. Re:Two CPUs on a chip. by dmallery · · Score: 1

      if you can remember wayyyy back, there was another single processor 8700 that was re-issued as an 8800

      they were vaxen.

    4. Re:Two CPUs on a chip. by questionlp · · Score: 1

      Yup... I remembered that. Kind of funny how technology passes around and gets back to the hands of the co-owner of the company that sold it off :)

  18. Chuck Moore by LazyDawg · · Score: 1

    Doesn't Chuck Moore's 25x already do SMP-like things, at a few billion instructions per second? Last time I checked he was using a 20-word instruction set on a stack-based computer, which IMO counts as RISC.

    This is hardly new, but HP's version probably uses some fancy new lithography, and wins when it comes to clock speed.

    --
    "Look at me, I invented the stove!" -- Ben Franklin
  19. 1GHz, that is sooooo slow by Red+Moose · · Score: 0, Troll

    1GHz? Man my Pentium 4 2GHz beats all these supposedly "fast" chips. It's HALF the speed, for christ's sake. That is sooooooooo quarter 3 2000.

    --

    Acting stupid isn't much fun when there's someone around who knows better

    1. Re:1GHz, that is sooooo slow by Anonymous Coward · · Score: 0

      shut up

  20. HP PA-8800 integer numbers by Spootnik · · Score: 3, Offtopic

    PA-8800 lets you create two opposite predicates in one instruction, for example the predicate a=b.

    This seems to indicate that there are no separate "do this if predicate is true" and "do this if predicate is false" instructions, so for opposite predication you would have to specify two different predicates.

    The processor cannot know that these two predicates are related, so this would give you quite a problem.

    As has been publicly disclosed, in general in PA-8800, an instruction reading any resource (such as a predicate) must be in a later instruction group (cycle) than the instruction writing that resource. As a special case, branches are allowed to use a predicate written by another instruction in the same instruction group (as shown in the IDF slides).

    So, the straightforward (but slow) PA-8800 schedule for the earlier example:

    if (a < 0)
    b += a;
    else
    b -= a;
    c += b;
    d += b;

    would be:

    cmp.lt pLT, pNLT = a, 0 // pLT & pNLT are 2 complementary preds
    ;;
    (pLT) add b = b, a // add to b [then]
    (pNLT) sub b = b, a // or sub from b [else]
    ;;
    add c = c, b // uses of b
    add d = d, b
    ;;

    which takes 5 instructions in 3 cycles. (Note: In PA-8800 assembly, ";;" indicates the end of an instruction group, "=" separates the target operand(s) from the source(s), "//" begins a comment, and (pred) specifies the controlling predicate.)

    An alternate (faster) schedule in PA-8800 is as follows:

    sub bTmp = b, a // speculatively sub from b (into temp)
    add b = b, a // and add to b
    cmp.lt pLT, pNLT = a, 0
    ;;
    (pLT) add c = c, b // uses of b [then]
    (pLT) add d = d, b
    (pNLT) add c = c, bTmp // uses of b (temp) [else]
    (pNLT) add d = d, bTmp
    (pNLT) mov b = bTmp // move bTmp to b [else]
    ;;

    This takes 8 instructions in 2 cycles and one extra register. The final move of bTmp to b can be eliminated if b isn't live out at that point.

    1. Re:HP PA-8800 integer numbers by Anonymous Coward · · Score: 4, Informative

      Interesting, but the PA-8800 is a PA-RISC processor, not an IA-64/IPF processor. It doesn't have predicated execution or instruction bundles. What you said is true, just for a different instruction set architecture and processor family.

    2. Re:HP PA-8800 integer numbers by Jah-Wren+Ryel · · Score: 2

      Mod this Anon up guys, he knows what he is talking about, that first guy is just spurting random IA64 (aka Itanic) talk which has very little to do with PA-RISC - PA does not have predication, nor does it have instruction grouping.

      --
      When information is power, privacy is freedom.
    3. Re:HP PA-8800 integer numbers by pm · · Score: 1

      You are right. This post describes the Itanium, not the PA-8800. It's kinda scary that it got mod'd up to a 5.

  21. Er... by Glock27 · · Score: 2, Interesting
    A couple of points:

    Following a relatively simple strategy, the PA-8800 processor combines two PA-8700 cores on a single chip to enable symmetric multiprocessing (SMP) on a single processor.

    It doesn't enable SMP "on a single processor". It provides two processors on a single die. There is a distinction.

    AMD, please steal an idea...

    The big rumor regarding the third version of Hammer is that it'll be a dual-CPU module. Any guesses as to Hammer's clock speed on release?

    299,792,458 m/s...not just a good idea, its the law!

    --
    Galileo: "The Earth revolves around the Sun!"
    Score: -1 100% Flamebait
    1. Re:Er... by Max+von+H. · · Score: 1

      299,792,458 m/s...not just a good idea, its the law!

      Er... I'm afraid it's 299,792,458 km/s...

      Sorry, it's the law! ;)

      /max

      --
      -- It's always darker before it goes pitch black.
    2. Re:Er... by Glock27 · · Score: 1
      Er... I'm afraid it's 299,792,458 km/s...

      Check your references again...you're mistaken. In English units it's 186,282 mi/s.

      Sorry, it's the law! ;)

      Perhaps in some alternate universe... ;-)

      299,792,458 m/s...not just a good idea, its the law!

      --
      Galileo: "The Earth revolves around the Sun!"
      Score: -1 100% Flamebait
    3. Re:Er... by Max+von+H. · · Score: 1

      *bangs head on keyboard*

      My mistake, apologies.

      /max

      --
      -- It's always darker before it goes pitch black.
  22. The BIG difference between PA8800 and Power4 by zensonic · · Score: 3

    ...is that you actually can go out and buy a new mainframe using Power4. Nothing wrong with looking ahead, but if you remember, AMD said that the Athlon should have been made in an "Athlon Ultra" version spotting 8MB L2 cache. .... I still stick to the motto: "I'll belive it when I can buy it"

    --
    Thomas S. Iversen
    1. Re:The BIG difference between PA8800 and Power4 by CrazyDwarf · · Score: 1

      You'll believe it when you can buy it? I'll sell you some dehydrated water. It's great for camping.

      --
      It's easy to stand out when the general level of competence is so low.
    2. Re:The BIG difference between PA8800 and Power4 by Jah-Wren+Ryel · · Score: 2

      No, you can ORDER a Power4 box. If you are a super-special customer, you can get a beta machine delivered. If you aren't a special buddy of IBM, then you can wait until December, or more likely January for a regular box.

      --
      When information is power, privacy is freedom.
  23. Wait a minute! by UltraBot2K1 · · Score: 0

    This is getting rediculous. Symmetric Multiprocessing on a single chip? That's impossible, unless you're just screwing around with semantics. I mean, think about it. You need TWO chips, at least, in order to engage in SMP, and anyone who says otherwise is putting out meaningless hype. SMP on one chip, or just vaporware?

    --

    Slashdot: Open Source, Closed Minds.

    1. Re:Wait a minute! by NerveGas · · Score: 1

      If you had taken even thirty seconds to read the blurb, you would see that they have indeed put two cores on one chip, which gives you two processors on a chip. Remember, "processor" != "chip".

      It's the same idea as Via combining the north and south bridges on some of their motherboard chipsets. They take the two cores, and put them on a single wafer, with a bus (still on the same wafer) between them.

      The idea really isn't revolutionary. Ever since microprosessors were invented, the trend has been to pack more and more onto a single chip, as it reduces cost, complexity, and design complexity while increasing compatibility and (most importantly) bandwidth. While your fastest P4 front-side bus chugs along at 400 MHz, busses that are kept on the wafer can run at full core frequency, even in the gigahertz range. Plus, you can run a lot more of them, and since the distances covered are shorter, it's easier to avoid external RF interference. And in multi-processing computers, the connectivity between cores is vitally important.

      Look at a lot of motherboard chipsets these days. In one or two chips, they'll have circuitry for video, audio, modem, network, IDE, floppy, serial, USB, PCI, and memory controllers, to name just a few. One of the long-term goals that some companies have been talking about is "SOC", or "System On A Chip", where a single chip will have everything you need for a computer. At the point where the CPU has all of the other controllers inside of it, not only could performance increase dramatically, you could potentially use a motherboard for any CPU that you wanted, as all the motherboard would do is provide power to the CPU and traces from the CPU to the connectors for external componants.

      steve

      --
      Oh, you're not stuck, you're just unable to let go of the onion rings.
    2. Re:Wait a minute! by Anonymous Coward · · Score: 0

      two cores on one chip. not that hard to do.

      idiot.

    3. Re:Wait a minute! by polarkittycat · · Score: 1

      Think of it as two cores....

  24. *cough*IBM*cough* by Anonymous Coward · · Score: 0

    IBM unveiled its SMP-on-a-chip solution, the Power4, almost 2 weeks ago. 64 bit PowerPC. And only 2 OS'es run it.

    One of them is Linux.

    1. Re:*cough*IBM*cough* by Anonymous Coward · · Score: 0
      64 bit PowerPC. And only 2 OS'es run it. One of them is Linux.
      This is why I love Linux. When you have a new chip, all the chip makers know that Linux should be the first OS to run on it. For example, Linux was the first OS to run on AMD's 64 bit chip, and Linux was the first OS to run on Intel's Itanium 64 bit chip, the flagship of the Intel line . Linux is changing the way we think about computing.
    2. Re:*cough*IBM*cough* by Anonymous Coward · · Score: 0

      Paper filing can be good. There used to be a special type of filing cards that had holes and notches that could be punched out and you could sort the cards in various ways by inserting steel rods into the cards. Different notches would correspond to different characteristics assigned to the information on the card. Simple, and easier to learn than MySQL.

  25. Its MISC and its slow by Anonymous Coward · · Score: 0

    With no such niceties as virtual memory, large address spaces, fast additions etc etc there is not a lot of software which would run well on them.

  26. Its compatible with Itanium moterboards by DABANSHEE · · Score: 2

    That seems practicle enough to me.

    You know when AMD 1st brought out the Athlon they were spose to be compatible with Alpha 21264 boards too.

    AMD even made a couple of engineering samples in slot B packages for testing but that's as far as it it.

    If someone could hack a slot A/Slot B adaptor then they could hypothetically do the same thing. They might have to hack a bios update to though.

  27. How much will one of these cost? by Anonymous Coward · · Score: 0

    compared to say a 2.2GHz P4 or an Athlon XP 1800+. Inquiring minds want to know.

  28. Here is a link to an IBM white paper by Anonymous Coward · · Score: 0

    http://www-1.ibm.com/servers/eserver/pseries/hardw are/whitepapers/p690_config.html#arch

  29. 2GHz, that is sooooo slow by Anonymous Coward · · Score: 0

    You asked for it; here's some yummy troll food fer ya:

    For the last time, clock speed doesn't compare between architectures. This is a RISC processor with a short pipeline, the pentium 4 you drool about (but don't really have) is a CISC with an extra-long needlessly-clock-boosting pipeline. Of course, you'd know this if you read the article.

    If you read the specs, you'd see: "Speaking of performance, each PA-8700 RISC core delivers a SPEC performance of around 550 (for both Int and FP) at 750 MHz and the dual core PA-8800 running at 1 GHz will start out at a minimum of 900 / 1000 SPEC2000 int/fp scores, according to very conservative estimates."
    A 2GHz P4 is in the 650 SPECINT/670 SPEC2000FP range, so basically each PA processor is about 10% faster.

    Was it trolliscious? satisfied? oh, furry troll, why do I even bother feeding you?

  30. What about Itanium? by Grishnakh · · Score: 2

    I thought HP had committed itself to ditching the PA-RISC and moving to Itanic, err, Itanium.

    1. Re:What about Itanium? by dprice · · Score: 1

      I thought HP had committed itself to ditching the PA-RISC and moving to Itanic, err, Itanium.

      Yes, that is still the story as far as I know. It was the intended direction years ago, but IA-64 (Itanium) has taken longer to develop than originally expected (way longer), and the customer base hasn't shift to IA-64 yet. Until the customers start paying $$ for IA-64, HP will continue to make revenue from their existing PA-RISC customers.

      The bottom line is that customers don't really care what the underlying processors is. Customers care that their legacy applications continue to run on new machines, that they run with good performance, and that they run reliably. The processor type is just a piece of the total compute environment. HP's motivation is to move to a higher volume microprocessor (IA-64). The current PA-RISC processor volumes are relatively low, and they have to factor in all the R&D expense that goes into a low volume processor. The more complex the processors get, the more R&D expense goes into the design of the chips and into the fabs to build them.

      I'm still curious what the effect of AMD's Sledgehammer will be for customers. For those customers using IA-32, Sledgehammer (64bit enhanced IA-32) takes less porting effort than IA-64. I have yet to see any reports of a deployed IA-64 application in the real world. Everything so far has been lab results and marketing blubs.

    2. Re:What about Itanium? by David+Breneman · · Score: 2, Insightful

      Even last year, HP reps at the "HP World" conference were letting it be known that they were seriously hedging on the IA-64/Itanium/whatever chip due to Intel's notoriously crummy product reliability history. HP's got PA-8900 and PA-9000 chips in the pipeline. PA-RISC is not going away soon, if ever.

    3. Re:What about Itanium? by Anonymous Coward · · Score: 0

      thats what they said about domain OS and HP/UX when they bought apollo and it cost them their biggest customer they ever had.

    4. Re:What about Itanium? by David+Breneman · · Score: 1

      Would you care to elaborate on your response, at least to the point that it might make sense? :-)
      "That's what they said about domain OS" doesn't convey much in this context. HP's "official line" is that they're on board with IA-64, but if you talk to the people in the "back room" you get a much less confident outlook.

    5. Re:What about Itanium? by swb · · Score: 2

      It read to me like the opposite situation, but the same kind of outcome. HP says one thing, but does another.

      In this case, it's that they're saying semi-officially that "...PA-RISC is here for the forseeable future, so relax already..".

      In the past when they bought Apollo they officially said "Domain/OS is here to stay, we won't be cramming HP/UX down your throat" and then Domain/OS goes away.

      It's very clear to me that marketing people are trying to have it both ways. One camp wants to ditch PA-RISC and do Itanium everywhere, another camp that has happy PA-RISC customers wants to make like Itanium ain't happening. Corporate america, fscking the customer. Go figure.

    6. Re:What about Itanium? by David+Breneman · · Score: 1

      OK, maybe I wasn't too clear, so here goes again: HP's official policy is that IA-64 will eventually replace PA-RISC, but the scuttlebutt within the company is that they don't want to bet the farm on Intel and so they're leaving themselves an out by continuing PA-RISC developmant past PA-9100. So, in effect it's like saying Apollo systems will eventually go away, but don't stop work on the Motorola 68080 just in case. Clearer? (Proud owner of a 425...)

    7. Re:What about Itanium? by Ars-Fartsica · · Score: 2
      The bottom line is that customers don't really care what the underlying processors is.

      You couldn't be more wrong. Enterprise customers often have technical support staff as versed in the tech as the vendor. They have to be - they are making budget and platform decisions that have huge ripple effects in their organizations.

      The viability of the platform will figure keenly in the minds of anyone looking at further extensions of the PA line. Seeing as SuperDome has been a dud, you can presume that the SuperDome successor will thud even louder.

    8. Re:What about Itanium? by Ars-Fartsica · · Score: 2
      Well this has been a problem for HP for a couple of years at least. The merger with Compaq will only complicate matters.

      As it stands the market for this chip just doesn't justify production. SuperDome has been a failure (although HP is loathe to admit it), and the market for HPUX is dwindling rapidly.

      The Alpha offers the concise history - a great core, but no marketing vision. Its just a product guys, if no one wants it, it isn't worth the billions to produce.

    9. Re:What about Itanium? by psergiu · · Score: 2

      > SuperDome has been a failure

      Care to explain why ? I (the VBC i work for) have one and it does its work fine (_way_ faster than we expected)

      --
      1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
    10. Re:What about Itanium? by Anonymous Coward · · Score: 0

      They haven't sold nearly as well as HP wished. I'm sure its a capable machine, but HP can't seem to sell it.

  31. When do you think they will have Transparent SMP? by AnonymousCowheard · · Score: 0

    Who says the OS needs to know there are two or 4 or 6 CPUs in a system? Threaded programming works best only on Clusters. SMP scales poorly on Intel Pentium IV's because maybe that isn't a reason to use two Pentium IV CPUs...Each CPU provides more resource management. Someone should've written some supporting text on "the SMP myth" which includes why SMP is not a good and efficient solution to increase calculation performance on a given workstation. Pentium Pro CPUs provide BUS Mastering in SMP mode and the secondary CPU provides upto %30 of extra system performance. Of Course, for every extra CPU in a Pentium Pro system, it adds 30% - (NumCPUs*5) performance due to scheduling in the software. It is always the Primary CPU in a multi-cpu system that must schedule events for the Secondary, Tertiary, and Quaternary cpu in software. On a Pentium Pro CPU, that requires somewhere around 10% of that Primary CPU's processing power to schedule software for that second CPU; it's around 15%/20% for the 3rd, etc. That's why you see Dual Pentium IV Workstations not performing upto par with another workstation with only one Pentium IV. It's SMP doesn't scale well. The only value of multiple-CPUs is for BUS Mastering and providing more system resource management. Intel abandoned BUS Mastering in SMP systems after the Pentium Pro. So, for the extra cost of using a second Pentium IV CPU, it isn't worth it. Just get a nice Pentium Pro Server on eBay and you will get your money's worth for those extra CPUs; which provide BUS Mastering. Pentium Pro has always been a nice CPU. You can scramble an egg in 5 minutes, versus 15 for the Pentium IV.

    --

    But I'm sure you already Gnu that.
  32. How does it compare to the MAJC spec? by zor_prime · · Score: 1

    Reading through the article, this design seems to share a lot in common with Sun's MAJC architecture. Both allow for multiple cores on a single chip. Anyone else notice the similarities?

    I guess the biggest difference would be that the HP chip is actually going to be built, while the MAJC chip seems to still just be a design.

    It is interesting that a number of designs lately seem to be looking to the integration of multiple CPU cores on a single chip to increase performance in server applications.

    zor_prime

    --
    "We all do no end of feeling, and we mistake it for thinking." -Mark Twain
  33. how about a beowolf cluster of these by atif_ghaffar · · Score: 0

    sorry, could resists, there was no single grep of beowolf.

  34. Old News by Pemdas · · Score: 1
    As has been mentioned, IBM is doing this with POWER. SiByte/Broadcom has done this with an embedded processor:

    EEtimes Story

    Everyone in the high-performance CPU market (except itanic) is doing either this or multiple concurrent thread contexts to speed overall system computational throughput.

    1. Re:Old News by Anonymous Coward · · Score: 0

      And read this article carefully -- SiByte has one smoking processor. Besides two MIPS cores, they have two DDR channels and three Gigabyte Ethernet MACS in the chip package. Expect everyone and their mother to be using this one next year in their networking gear designs...

    2. Re:Old News by Anonymous Coward · · Score: 0

      Broadcom realeased this chip. It's the BCM1250. Check out the press release, they have a reference design and Linux is one of the choices for the OS (the only one that fully supports the hardware).

  35. AMD won't be using this anytime soon... by duffbeer703 · · Score: 1

    When you consider that the PA-RISC team has been transferred to that "evil" company Intel.

    --
    Conformity is the jailer of freedom and enemy of growth. -JFK
    1. Re:AMD won't be using this anytime soon... by Anonymous Coward · · Score: 1, Informative

      Bullshit. No we haven't. We're still right here.

    2. Re:AMD won't be using this anytime soon... by Anonymous Coward · · Score: 0

      Don't think so....

      I still work for HP, not Intel.
      You'd better stop listening to all that EE Times
      crap.

    3. Re:AMD won't be using this anytime soon... by Anonymous Coward · · Score: 0

      The HP server chip set team went to Intel, not the processor team.

      BTW, If you look carefuly at the AMD presentation for Hammer you can see in the "northbridge" section support for two processors on one die. It was brought up at the panel discussion but Weber wouldn't confirm the dual-CPU-on-one-die Hammer, but neither did he deny it.

    4. Re:AMD won't be using this anytime soon... by Anonymous Coward · · Score: 0

      Not for long.

      Carly will turn HP into the next Lucent.

      ____________________
      If you this error seems to be incorrect, please provide the following in your report to SourceForge:

      Browser type
      User ID/Nickname or AC
      What steps caused this error
      Whether or not you know your ISP to be using a proxy or some sort of service that gives you an IP that others are using simultaneously.
      How many posts to this form you successfully submitted during the day
      * Please choose 'formkeys' for the category!
      Thank you.

  36. "Single-transistor SRAM"? by Christopher+Thomas · · Score: 2

    I *thought* the cache density looked a bit high for ordinary SRAM - the article mentions something they're calling "single-transistor SRAM".

    Does anyone know how on earth they're managing this? Or is this just some low-leakage variant of DRAM with added marketing spin?

    1. Re:"Single-transistor SRAM"? by be-fan · · Score: 2

      Actually 1T-SRAM has been around for awhile. The GameCube uses some for main memory. See the /. article

      --
      A deep unwavering belief is a sure sign you're missing something...
    2. Re:"Single-transistor SRAM"? by Christopher+Thomas · · Score: 2

      Actually 1T-SRAM has been around for awhile. The GameCube uses some for main memory. See the /. article

      I checked the article and Mosys's site, but the only detailed descriptions of the technology are behind registration scripts.

      Could you give a brief description of the operating principles of single-transistor SRAM, or should I just bite the bullet and register on Mosys's site?

    3. Re:"Single-transistor SRAM"? by Anonymous Coward · · Score: 0

      Bite the bullet ... otherwise you're asking him to go to more effort to type it up than it would take for you to register.

    4. Re:"Single-transistor SRAM"? by Anonymous Coward · · Score: 0

      here is pretty much all the info you need:

      http://www.edram.com/aboutesram/ddresram.htm

      Very briefly: 1 Transistor SRAM uses an ultrafast DRAM core and broadside addressing instead of a multiplexed address bus. The high speed is possible because of a fixed connection instead of a standard bus interface with trace delays as in current DIMMs. 1 transistor SRAM is, therefore,
      not SRAM but DRAM using an SRAM interface.

      Regards

      MS

      (p.s. I just don't believe in accounts and registrations for forums)

    5. Re:"Single-transistor SRAM"? by Anonymous Coward · · Score: 0

      the original palmpilot pro's used to use this ..its called PSRAM. just do a google search for PSRAM and you'll get detailed stuff on it.

  37. imagine... by vsync64 · · Score: 2, Funny

    ...a Furbeowulf cluster of these things!

    --
    TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
  38. AMD onchip SMP? Imagine pulling the heat sink off! by rwa2 · · Score: 2, Funny

    In news today, a small chunk of Austin TX vaporized when an engineer tripped over a Thermaltake vortex containment field, causing an experimental single-chip SMP AMD processor to go critical in its 1024 pin socket...

  39. Re:When do you think they will have Transparent SM by fitten · · Score: 1

    Less crack. Go study modern OSs and stay away from SunOS and old Slackware "SMP" kernels.

  40. PA-8800 boxes by Anonymous Coward · · Score: 0

    Imagine a Beowolf Cluster of THESE!!!

  41. Not the best way to go by CigarBuff · · Score: 3, Interesting

    AIUI, there are two competing methods of scaling CPUs now - Symmetric Multi-threading (SMT), and Chip-level Multi Processing (CMP). HP is going CMP because SMT is too difficult in terms of writing the compilers. Both Compaq (with the Alpha CPU) and IBM (PowerX) are going SMT. In fact, the biggest thing Intel got out of it's purchase of Alpha technology, other than the engineers themselves, is the Alpha SMT work.

    1. Re:Not the best way to go by NerveGas · · Score: 1

      AIUI, there are two competing methods of scaling CPUs now - Symmetric Multi-threading (SMT), and Chip-level Multi Processing (CMP).

      Are they really competing technologies? I can't think of why SMT cpu's couldn't be used in SMP systems. SMP is a way of adding more CPU's, SMT is a way to keep each CPU busy more of the time. They sound kind of complementary to me.

      steve

      --
      Oh, you're not stuck, you're just unable to let go of the onion rings.
    2. Re:Not the best way to go by Graymalkin · · Score: 2

      IIRC the Xeon processor from Intel uses SMT but is complimented by being SMP capable. You're right that SMT has really no bearing on whether or not you can use multiple processors in a system. I don't know why the dude was seeing them as competing technologies because they most definitely aren't. Just look at the POWER4, they have several processors on a single chip and you can use more than a single chip in a system as well as using SMT which IIRC they are also going to stick in them once they're released.

      --
      I'm a loner Dottie, a Rebel.
  42. Hammer's Clock Speed by Anonymous Coward · · Score: 0

    I heard it will start at 3 GHz?

  43. Re:When do you think they will have Transparent SM by cfriesen · · Score: 1

    Sorry, while it may be true for Pentium series, it is not true for SMP in general.

    1) It is actually possible to get better than linear improvement under certain conditions (like if something is already in a shared cache because it was fetched by the other cpu).

    2) It is possible to have each cpu schedule itself based on contents of ram.

    Yes, there is overhead of having two cpus, but it is very variable dependent on OS and workload.

  44. Re:Trolls and Slashbots by Anonymous Coward · · Score: 0

    Are you coming on to me?

  45. just like 3dfx did with 2 processors by Anonymous Coward · · Score: 0

    it looks like artificial breathing attempts when resources don't allow for better chip designs anymore. 3dfx did it with voodoo2, and it's such a cheap solution that I'm surprised HP even bothers to this show'n'tell. "look, we didn't have enough money to do 1 good and new solution so we slapped together 2 old ones!! all hail the new ultrafast processor!"

  46. 35 MB cache??? by ca1v1n · · Score: 1

    Sounds like more kernel work. I'm won't be happy until I can mount file systems in my cache. Think about it. My 286 only had a 40 MB hard drive. Hello, solid state!

    --
    WARNING: there is a trojan on your
    1. Re:35 MB cache??? by Bert64 · · Score: 1

      If you only required a relatively small (by todays bloated standards atleast) application to run at highest possible speeds, you could run it ENTIRELY from the cache, without any main ram atall.. I upgraded to 6mb on my amiga a few years ago and thought i had more ram than anyone would ever need..

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  47. MIPS the original RISC by johnjones · · Score: 2

    well yes HP PA-RISC is nice but really its catch up

    MIPS 1GHz Dual core on same die for a while

    and that its 64bit

    check
    http://www.electronicstimes.com/story/OEG20010612S 0002
    or
    http://www.pmc-sierra.com/products/details/rm9000x 2/index.asp

    oh yeah did I mention that PA-RISC is a MIPS decendant
    but shhh they made so many changes they fscked the pipeline(they might have got it working again but I dont know any more)

    may the SPECINT and SPECFP fight it out

    regards

    john jones

    p.s. I wonder what the HP layout guys think of Intel chips (-;

  48. And for breakfast... by Anonymous Coward · · Score: 0

    I'll bet you could fry eggs on it pretty well with that much silicon cranking out heat in one chip.

  49. Yaaaaaaawnnn.. by gwichman · · Score: 1

    As has been pointed out above, this is just HP playing catchup to IBM. IBM has taken a leap ahead of their competitors and now they have to play catchup.

    HP's announcement is nothing compared to what IBM has in development.

  50. hppa cpu's are cool! by The_Dougster · · Score: 1
    I have a HP 9000 715/80 with PA7100LC cpu. It can boot hppa Debian, has ethernet connectivity, and has its console on a dumb terminal. It is pretty cool, and from what I have read, I believe it has something like 24 general purpose registers, which is quite a lot for a typical cpu. This one is an older 32 bit cpu, but thats still seems like a lot of registers to work with for high performance code and such.

    HP workstations certainly seem to be very solid and nifty and they have a lot of potential for linux boxes. Assembly programmers will appreciate all of the registers that are available.

    --
    Clickety Click ...
  51. And IBM actually has a business model behind it by Ars-Fartsica · · Score: 2
    HP can't bring this chip to market, I don't care how cool it is. HP and Compaq are merging to bring about volume manufacturing and economies of scale, largely to fend off Dell, which is destroying them both individually using advanced manufacturing and distribution methods.

    With an agenda based on scale, you don't get there by introducing a new CPU in a dead line. HP's SuperDome line is getting creamed by Sun and IBM - HP cannot afford to go back to the front lines with another enterprise offering unless SuperDome pans out a hell of a lot more than it is currently.

    HP has always had impressive technology but still loses market share . HP-UX has dwindling market share and software support. The merger with Compaq will derail any plans for further proprietary architectures.

    If you want to look at the gee-whiz value here, fine, but don't expect to see this in a product.

  52. Compiler shouldn't be more difficult. by Christopher+Thomas · · Score: 2

    HP is going CMP because SMT is too difficult in terms of writing the compilers.

    Actually, I think they're doing it because it means they don't have to design a new processor core.

    As far as each thread being executed in an SMT chip is concerned, they're running on a single-thread processor. The same scheduling optimizations that benefit code in a single-thread system will benefit the code running SMT with other threads. SMT actually makes this job a bit easier, by reducing the effective latency of instructions (if neither thread's stalled, each thread will execute every other clock, making a 10-cycle-latency instruction look like a 5-cycle-latency instruction, which in turn makes each thread less _likely_ to stall; nice feedback loop here).

    The only extra complexity would be in the operating system's scheduling and context switching routines, and that wouldn't be much more complicated than on a multiprocessor system.

  53. Re:HP PA-8800 integer plagiarism by Anonymous Coward · · Score: 0

    Tricky. This time Spootnik copied and pasted from not one but two Usenet articles, neither of which has anything to do with PA-8800.

    Not just article hijacking, but blatantly false article hijacking.