Faster image rotation
|
Prev: Which is the most beautiful and memorable hardware structure in a ?CPU?
Next: Energy usage per application ?
From: "Andy "Krazy" Glew" on 18 Apr 2010 14:20 On 4/18/2010 7:40 AM, nmm1(a)cam.ac.uk wrote: >>> Itanium was just a hopelessly clumsy design. > What seems to have happened is that a few commercial compscis[*] > demonstrated that working on some carefully selected programs, and > persuaded the decision makers that they could deliver it on most of > the important, performance critical, codes. > [*] NOT a flattering term. Hmm... From my point of view, the Itanium was the first computer architecture driven mainly by academics with PhDs. Its immediate predecessor, the P6, has only one PhD amongst its 5 primary architects. (Bob Colwell.) Itanium had a lot more people who had piled it higher and deeper.
From: "Andy "Krazy" Glew" on 18 Apr 2010 14:25 On 4/18/2010 4:57 AM, Niels J�rgen Kruse wrote: > Andy "Krazy" Glew<ag-news(a)patten-glew.net> wrote: > >> The ARM Cortex A9 CPU is out-of-order, and is becoming more and more >> widely used in things like cell phones and iPads. > > Cortex A9 is not shipping in any product yet (I believe). Lots of > preannouncements though. The Apple A4 CPU is currently believed to be a > tweaked Cortex A8, perhaps related to the tweaked A8 that Intrinsity did > for Samsung before being acquired by Apple. Ref? Most of the articles that I have seen say that the iPad A4 is a Cortex A9. One conspiracy-theorist type seems to think that it might actually be the PA Semi OOO PowerPC, running an ARM emulator.
From: MitchAlsup on 18 Apr 2010 15:05 On Apr 18, 10:03 am, Robert Myers <rbmyers...(a)gmail.com> wrote: > On Apr 18, 10:40 am, n...(a)cam.ac.uk wrote: > My assumption, backed by no evidence, is that HP/Intel kept adding > "features" to get the architecture to perform as they had hoped until > the architecture was sunk by its own features. > > You think the problem is fundamental. I think the problem is > fundamental only because of the way that code is written, in a > language that leaves the compiler to do too much guessing for the idea > to have even a hope of working at all. I think the problem was/is fundamentally a political issue with the leadership of the design teams, especially in the ability of the leadership to say "No, let us not dedicate of expend resources investigating that corner of the design space." Mitch
From: MitchAlsup on 18 Apr 2010 15:06 On Apr 18, 1:15 pm, "Andy \"Krazy\" Glew" <ag-n...(a)patten-glew.net> wrote: > System code tends to have unpredictable branches, which hurt many OOO machines. I think it is easier to think that system codes have so much inherent serializations that the efforts applied in doing OoO are "for want" and that these great big OoO machines degrade down to just about the same performance as the absolutely in-order cousins. Its a far bigger issue than simple branch mispredictability. Pointer chasing into poorly cached data structures is rampant; "dangerous" instructions that are inherently serialized; and poor TLB translation success rates. Overall, there just is not that much ILP left in many of the paths through system codes. Mitch
From: "Andy "Krazy" Glew" on 18 Apr 2010 15:43
On 4/18/2010 9:31 AM, jgd(a)cix.compulink.co.uk wrote: > The second was that the instruction set was the key idea. That's really > an idea from the eighties, at latest. By the mid-nineties it should have > becoming clear, especially to people inside Intel with access to the > work being done on the Pentium Pro/II/III code design, that the limits > on processor power had a lot more to do with caches and the speed of > communications between processor and memory: instruction decode no > longer took up enough transistors to be worth pre-optimising at the > expense of code size. Itanium was designed by people who thought that P6-style out-of-order was going to fail. In many ways they were the P6 competitors. P6 was Oregon. Itanium was California. Many Itanium folk were from P5. |