AMD Previews New Processor Extensions

An anonymous reader writes "It has been all over the news today: AMD announced the first of its Extensions for Software Parallelism, a series of x86 extensions to make parallel programming easier. The first are the so-called 'lightweight profiling extensions.' They would give software access to information about cache misses and retired instructions so data structures can be optimized for better performance. The specification is here (PDF). These extensions have a much wider applicability than just parallel programming — they could be used to accelerate Java, .Net, and dynamic optimizers." AMD gave no timeframe for when these proposed extensions would show up in silicon.

Comments

Just performance counters?

[Erich]

Looks like there isn't a whole lot there that you couldn't get using existing performance counters and a tool like oprofile....

Re:Just performance counters?

[imgod2u]

Looking at the PDF, it supposedly gathers profile data in the background (in local caches on the chip itself) and dumps periodically depending on the OS/application settings. This allows it to profile on-the-fly with very little impact on application performance.

The application can then gather the information, which is stored in its address space, and do with it what it will (optimize on-the-fly).

Of particular interest is that the OS can allow the profile information to be dumped to the address space of other threads/processes as well as the one that the data is collected on. The OS controls the switching of the cached profile information during a context switch.

This is both cool (in that a secondary core/thread can help optimize the first) and scary (one thread getting access to another's instruction address information). I predict there will be exactly 42 Windows patches released 3.734 days after the service pack that allows Windows to take advantage of this feature because of security reasons.

I wish AMD and Intel teamed up for once

[rolfwind]

and did away with the aging x86 instruction set and came up with something new.

Yeah, I know, Intel tried with Itanium.

Re:I wish AMD and Intel teamed up for once

[Chris Burke]

Yeah, I know, Intel tried with Itanium.

And you want them to try *again*? As far as I'm concerned the most amazing achievement of IA64 was that they got to start over from scratch, and ended up with an ISA with a manual even bigger than the IA32 manual! Going to prove that the only thing worse than an ISA developed through 20 years of engineering hackery is one developed by committee.

Re:I wish AMD and Intel teamed up for once

[realmolo]

Yup. They tried it with Itanium, and it didn't work.

The thing is, at this stage in processor design, the actual instruction set isn't all that important.

But *compilers* are more important than ever, and writing a good compiler is hard work. x86 compilers have been tweaked and improved for nearly 30 years. A new instruction set could NEVER achieve that kind of optimization.

Interestingly,the Itanium and the EPIC architecture were designed to move all the hard work of "parallel processing" to the compiler. Unfortunately, they could never get the compiler to work all that well on most kinds of code. The compiler could never really "extract" the parallelism that Itanium CPUs needed to work at full speed.

Which is *exactly* the problem we have now with our multi-core CPUs. Compilers don't know how to extract parallelism very well. It's an *incredibly* difficult problem that Intel has already thrown untold billions of dollars at. Essentially, even though Itanium/EPIC never caught on, we're having to deal with all the same problems it had, anyway.

Re:I wish AMD and Intel teamed up for once

[Slashcrap]

and did away with the aging x86 instruction set and came up with something new.

Yeah, I know, Intel tried with Itanium.

They already did. I believe the 486 was the last CPU to run x86 instructions natively. Everything since the Pentium has decoded them to a RISC like ISA which can be changed every generation if desired. The only drawback is that a relatively small area of the chip needs to be dedicated to decoding x86 instructions to whatever the internal ISA is.

And guess what? One of the things that people dislike about x86 is the variable length instructions. Turns out that it actually leads to more compact code. And the speed gains from reduced cache usage more than make up for the effort and chip real estate expended on those decoders.

So let's stick with x86 for now, since the gains you foresee are either non-existent or tiny and are never, ever going to outweigh the drawbacks.

Re:I wish AMD and Intel teamed up for once

[Vellmont]

and did away with the aging x86 instruction set and came up with something new.

They did, at least with the FP (floating point) instructions. FP instructions were based on this awful stack architecture, and it's gone away with all the SSE and 64 bit extensions.

The x86 instruction set has evolved greatly over time, and will continue to evolve. Why replace it entirely from scratch? Who's to say that an entirely new instruction set won't have a whole new host of problems?

Re:I wish AMD and Intel teamed up for once

[LWATCDR]

Well we had the 68000 family which had much better instruction set then the X86.
We have the Power and PowerPC which had a much better instruction set than the X86.
We have the ARM which is a much better instruction set then the X86.
We have the MIPS which is pretty nice.
And we had the Alpha and still do for a little while longer.
The problem with all of them is that they didn't run X86 code. Intel and AMD both made so much money from selling billions of CPUs that they could plow a lot of money into making the X86 the fastest pig with lipstick that the world has ever seen.
What made the IA-64 such a disaster was that it was slow running X86 code.

Re:I wish AMD and Intel teamed up for once

[Chris Burke]

I believe the 486 was the last CPU to run x86 instructions natively.

Close, it was the original Pentium. The Pentium Pro -- which despite the name which just made it sound like a minor improvement to the Pentium for business/servers was actually a completely new architecture -- is where they introduced the CISC->RISC conversion. This was in part to make it feasible to have out-of-order execution which many said CISC processors would never have. Turns out they were both right and wrong.

So let's stick with x86 for now, since the gains you foresee are either non-existent or tiny and are never, ever going to outweigh the drawbacks.

As much as I hate x86 from an aesthetic point of view, I must agree with you here.

Re:I wish AMD and Intel teamed up for once

[Chris Burke]

If true, maybe they should enable a way for the processer to use that RISC code without the conversion.

I don't think that's a good idea. The internal micro-ops are machine-dependent, and they will change as the microarchitecture changes. By designing the micro-ops specific to the architecture, they can try to make the x86 instruction translate into an optimal sequence of micro-ops. As hardware functionality changes, existing x86 instructions can have the underlying ops changed to suit without you having to re-code or even re-compile your program.

For example: Barcelona is introducing 128-bit wide floating point units for SSE instructions. The previous ones were 64-bits wide, so it would take two operations (and most likely two separate micro-ops) to perform a 128 bit SSE add instruction. Whereas now it will only take one op, and the same x86 instruction can take advantage of that fact without having to know what architecture it is running on. Another example is divides, which on a machine with a hardware divide unit would be only a few instructions, but on a different machine would require a lengthy microcode routine. Your code doesn't have to know; it just runs faster on the code with the hardware DIV.

Not that you can't optimize your x86 code for particular architectures, or that there aren't x86 codes that run on one machine and not another -- though you can check whether the machine can run the code, and you aren't having the entire instruction set change out from underneath you. I'm just saying that only exposing one side of the CISC->RISC conversion gives the chip designers a lot of leeway and you probably don't want to give that up.

Re:I wish AMD and Intel teamed up for once

[Anonymous Coward]

IBM's PPC compiler kicked the shit out of every x86 compiler. (Apples and oranges, but the quality was much better). Same for ARM's compiler and Sun's (SPARC) compiler. Fact is, x86 is the ugly girl at the party, but it gets more attention from GCC, MS, Intel, etc. Native compilers on other architectures beat the shit out of it.

Re:I wish AMD and Intel teamed up for once

[Criffer]

Not again.

Why is this nonsense still perpetuated? The instruction set is irrelevant - it's just an interface to tell the processor what to do. Internally, Barcelona is a very nice RISC core capable of doing so many things at once its insane. The only thing that performs better is a GPU, and that's only because they're thrown at embarassingly parallel problems. The fastest general purpose CPUs come from Intel and AMD, and it has nothing to do with instruction set.

AMD64, and the new Core2 and Barcelona chips are very nice chips. 16 64-bit registers, 16 128-bit registers, complete IEEE-754 floating point support, integer and floating-point SIMD instructions, out-of-order execution, streaming stores and hardware prefetch. Add to that multiple cores with very fast busses, massive caches - with multichip cache coherency - and the ability to run any code compiled in the last 25 years. What's not to like?

Re:I wish AMD and Intel teamed up for once

[wonkavader]

No, the problem with the IA-64 was not that it was slow running x86 code. The problem was that it was slow running x86 code and not that great at running non-x86 code. Spectacular performance on non-x86 would have made it a much greater success, but it was lackluster from the start. After so long spent on designing a new chip, you'd expect some real results -- it was not much better than the alternatives. "Why bother?", the world said, and says even now.

Re:I wish AMD and Intel teamed up for once

[jguthrie]

Okay, I'll feed the troll. Tell me where I can buy an ATX (or smaller) PPC motherboard and CPU new for, oh, say $200, and I'll look at PPC again. The reason that x86 gets all the software is because it's the cheapest, it's the cheapest because all the motherboard manufacturers make motherboards for it, and all the motherboard manufacturers make motherboards for it because it gets all the software.

Re:I wish AMD and Intel teamed up for once

[Chirs]

The instruction set *is* relevent to low-level designers. Working with the PowerPC instruction set is much nicer than x86...for me at least.

As for "the fastest general purpose CPUs come from Intel and AMD", have you ever looked at a Power5? It's stupid fast. Stupid expensive, too.

Re:I wish AMD and Intel teamed up for once

[Chris Burke]

Why is this nonsense still perpetuated? The instruction set is irrelevant - it's just an interface to tell the processor what to do.

Sure, now it is, since the decoding of CISC instructions into micro-ops has largely decoupled ISA from the microarchitecture, allowing many of those neat-o performance features you meantion like out-of-order execution. However in the past this wasn't the case and a lot of x86's odd behaviors that seemed like good ideas when they were made were serious performance limiters. Like a global eflags register that is only partially written by various instructions (and they always write even if the result isn't needed).

Even today, I would say that all those RISC ISAs are better than x86, simply from the standpoint that they are cleaner, easier to decode, have fewer tricky modes to deal with, fewer odd dependencies, and all the other things that make building an actual x86 chip a pain in the arse. No, in the end it makes no difference in performance. Yet, if you had it to do all over again, building the One ISA to Rule Them All without concern for software compatability, and you decided to make something that was more like x86 than Alpha, I'd slap the taste out of your mouth.

But we do have to be concerned with software compatability, and that I think was the GP's main point. All of those other ISAs failed to dominate -- even when there were actual performance implications! -- simply because they were not x86 and hence didn't run the majority of software. IA64 failed not because it was itself all that bad, but because it couldn't run x86 software well. So when AMD came out with 64-bit backward-compatible x86, everyone stopped caring about IA64. Because it wasn't x86, and AMD64 was.

So ultimately I agree with you both, and I don't think the GP was nonsense at all. It's a very valid point -- backward compatability is king, so x86 wins by default no matter what. Your point -- that x86 isn't actually hurting us anymore -- is just the silver lining on that cloud.

Re:I wish AMD and Intel teamed up for once

[Verte]

AMEN! The lack of general purpose registers is a serious drawback to x86. The MMU is the same- well, it's not that it isn't feature packed, but it's so slow that we need a TLB, and the TLB can't handle threads, so all non-globals need to be flushed when context switching. Yuck.

All the other features the GP mentioned, except for the last one if you mean COMPILED code, are also available on most RISC chips :P and the performance data really spoke for itself [Alphas had four times the floating point performance of the Pentium II clock for clock].

Re:I wish AMD and Intel teamed up for once

[servognome]

and did away with the aging x86 instruction set and came up with something new.

I wish they'd do away with English and come up with something new - a language based on consistant & logical rules.
I don't know how anything gets done using a set of words cobbled together over hundreds of years with all sorts of special rules and idioms.

Re:I wish AMD and Intel teamed up for once

[x2A]

So what we need really is a "native" x86 compiler, say, from Intel, that would maybe outperform the multi-platform GCC compiler... an Intel C/C++ Compiler, or 'ICC' we could call it... maybe...

Oh who am I kidding, that could never happen.

Re:I wish AMD and Intel teamed up for once

[wirelessbuzzers]

Why is this nonsense still perpetuated? The instruction set is irrelevant - it's just an interface to tell the processor what to do...

What's not to like? To start with, the complexity makes it a total pain in the ass to write kernels, compilers, runtime systems, analyses, debuggers and verifiers for x86. On top of that, it costs lots of engineering time, silicon and power to implement all those microcode crackers and fancy superscalar optimizations; this is why x86 can't hold a candle to ARM in the embedded world.

But maybe you meant missing instructions? No load-linked/store conditional or bus snooping. No double (or even 1.5) compare-and-swap. No hardware transactional memory support. Those three make it pretty hard to write fast concurrent code. And streaming operations are improving, but could be much better; there's a reasonable chance that cache coherency will soon be too expensive for practical use.

Maybe you're interested in single-threaded, native code performance; this is, after all, what x86 traditionally shines at. Here you'll find the lack of 3-register instructions to be a performance problem, even if the chip reduces this burden. There's no shuffle (like Altivec, although something like that is coming in Penryn, I think?), finite-field or bit twiddling operations, or conditional operations (a la ARM).

So yeah. There are a lot of things that the x86 instruction set could do better. I don't expect it to do them all, but there are certainly a lot of reasons to change it.

Re:I wish AMD and Intel teamed up for once

[x2A]

"the TLB can't handle threads, so all non-globals need to be flushed when context switching"

Isn't this not true on modern processors, at least up to a point? With some space per TLB entry put aside for a task ID, means that when you switch to a different process, it will won't use TLB entries with a different task ID. Of course the OS has to support this (tell the processor when it's task switching which memory space it's switching to), and I'm not sure how big the space on the TLB is for this (it may be only a few bits, so you might have to flush the TLB still between different processes, but keep not have to flush the kernels TLBs, ie, kernel has pages marked with zero, processes have pages marked with a one, you only ever flush TLBs marked with one, and tell the process when you want the zero or one TBLs). I can't remember where I first read this, it was a few years ago now I think, I'm sure it would have come along a way since though, seemed like a very sensible idea.

Re:I wish AMD and Intel teamed up for once

[Chris Burke]

The people who really suffer from this are Intel and AMD. They're the ones that have to design the nasty decoders for x86. They obviously find the advantages of decades of expertise in x86 ISA throughout the industry is worth the effort.

This is true, they're the ones who have to make it actually work. I think who it -really- hurts is anyone who isn't Intel or AMD trying to make an x86 chip. Unfortunately there's a lot of x86 behavior that isn't actually documented -anywhere- except inside the heads of Intel and AMD engineers and the HDL they write. Whereas a couple grad students could code up a fully Alpha-compatible cpu in a few weeks (it wouldn't be fast, but it would work). It creates a higher barrier to entry into the x86 market, and to me that's unfortunate. AMD and Intel obviously have a handle on the ISA.

And in reality a lot of the complexity of x86 decoding has been moved into the microcode engine so that the actual hardware decoders are pretty efficient.

Well, in so much as getting every operation that has to occur when you do something like a protected mode code segment load, sure the microcode deals with that. But the really hard part of x86 decode is dealing with variable-length instructions. To have a super-scalar architecture you need to be able to decode more than one instruction in a cycle, which means you need to know where the second instruction starts. A few ways of dealing with this include speculatively decoding the 2nd instruction assuming it starts at various points using parallel decoders (doesn't scale well at all), or saving marker bits in the instruction cache that tell you where instructions start (unavailable the first time you see an instruction so you have to use a slower method). Also fun to deal with is when an instruction crosses a cache-line boundary. And the essentially arbitrary number of prefixes that can be used.

Also, people shouldn't forget some of the advantages of x86, like variable instruction lengths. PowerPC and ARM may be easier to decode but they take up a ton more space and that causes a significant decrease in cache and memory efficiency. For example, I think the average x86 instruction is only 2 bytes (many are only 1 byte, if your program uses mostly 1 byte instructiosn you can get a LOT of performance this way). PowerPC is fixed at 4 bytes.

You aren't going to get very far using just 1 byte instructions. The average x86 instruction going by the spec may be 2 bytes, but the average x86 instruction in actual code is going to be more. If you're doing FP then you would be using SSE instructions which mostly use 3 bytes *just* for the opcode, not including register or memory arguments which could use 1-3 more bytes and potentially more if you're using any prefixes. In general I think this advantage of x86 isn't very significant. I think it would be interesting to measure the average instruction size used in actual code. Personally, I'd take fixed-width instructions any day.

Re:And so it goes on...

[edwdig]

There's very little difference between the instructions in the different modes. The memory management unit is where most of the differences are. Properly written 16 bit real mode code will still run in 16 bit protected mode. The only difference is how the segment portion of the pointer in interpreted.

As for 16 bit vs 32 bit modes. The instructions are mostly the same. A code segment is specified as being either 16 or 32 bit. That size is the default data sized used by instructions within that segment. There is a "size override" prefix, which if found immediately before an instruction, tells the CPU that the following instruction should use the opposite of default size.

I don't remember the specifics, but 64 bit mode just continues along with the same ideas. There aren't many changes from 32 bit code to 64 bit.

Re:And so it goes on...

[Ant P.]

It was at least 200 last time I read - and the source was an 80486 programming book. I think there's at least that many more in the different versions of SSE.

Re:Will Intel Adopt These Instructions?

[The Real Nem]

EM64T?

I think this is great

[P3NIS_CLEAVER]

I for one
think this
is good
news.

Re:Nice, but let's get Barcelona out the door, OK?

[HandsOnFire]

What happened is that the P4 architecture was more of a marketing scheme to push MHz, but not performance. AMD came out with an architecture directed at high performance. Intel came out with the Core 2 products which also focused on peroformance instead of clock speed. Intel has a lead in the manufacturing process side with respect to node size. This helps them to produce a lot at a lower cost. And If you look at Intel's and AMD's financials, you'll see how much each has to spend on R&D. Intel has a lot more money to put down on more designs and more engineers than AMD does.

You can get the x86/EMT64 documentation from intel

[Gazzonyx]

If you root around Intel's site a bit, you can get the developer manuals for asm on their chips; I think there's like 5 of them @ 300 pages+ each. It's all the documentation, I think only 1 book is the actual language specs. Anyways, if you ask them nicely via email, they'll send the manuals to you for free. I got mine in under a week from when I emailed them. They even pay shipping.

Also, I know from asm on SPARC that many op codes are really just variations of other ops (and/or pseudo ops). For instance, (I'm not sure of the x86 equivalent) .mul is a pseudo op for sll (shift left logical), IIRC. And almost every op has a data type specific variation (byte, half, word, double, etc), on top of that.

Re:Nice, but let's get Barcelona out the door, OK?

[Surt]

Major architectural changes (historically) have been years between. AMD had the lead arch, and intel took years to respond with core. Now intel has the lead, and AMD won't compete until their new arch. The problem is compounded for AMD by intel deciding to make a major push to speed up their arch cycle time. AMD's new arch will have to do battle with intel's refined core2 shortly after release, and intel's next arch is due as soon as next year, so their window is tight. AMD is of course also trying to accelerate their cycle, but intel has a lot more money to spend on this battle.

Re:Silicon Problems.

[Anonymous Coward]

94.3% of all statistics are made up on the spot.

Re:Nothing special for Java or .NET

[Wesley Felter]

Performance counters could be used by JITs to generate more optimized code. I wonder which programming languages use JITs...

Re:Hardware Accelleration == Bad Trend

[kiddygrinder]

Java never made anything easier for anyone and you know it.

Map and reduce?

[tepples]

Compilers don't know how to extract parallelism very well. It's an *incredibly* difficult problem It's not that compilers can't extract parallelism. It's that the C and C++ language standards lack a way to express parallelism. Often, you want to compute a function for each element in an array, resulting in a new array. In some languages, this is called map(). In Python, this is [expression_involving(el) for el in some_list]. An ideal language would provide a way to express that a function has no side effects, allowing map() to farm out different slices of the array to different CPUs. However, iterators in C++ and many other popular languages assume that the computation may have side effects, and provide no way inside the standard language to ask the compiler to break the computation into slices.

Re:Map and reduce?

[Josef Meixner]

An ideal language would provide a way to express that a function has no side effects, allowing map() to farm out different slices of the array to different CPUs.

And would be terrible for performance. Why on earth does everybody assume that fine grained parallelism will ever work? You need a very highly specialized processor to make it work and those have failed a decade ago as the "standard CPUs" just blew them away. Remember the Connection Machine, that was a box with exactly that fine grain of parallelization? It was programmed in C and Fortran with specialized extensions to express parallelism, incidently they live on in the way you program GPUs and the SSE is also another example of even finer grained parallelism.

Fine grained parallelism only works on very small and specific tasks. In general you want high level parallelism with very little communication and very little dependency on each other. As that is another extreme you have to find a compromise, but to assume the compiler can magically extract a real speed up from a bunch of simple for-loops is just completely unrealistic.

You will have to learn to handle the parallelism. It takes different algorithms and a different way to structure programs. Also you will have to accept that there are things which will not work in parallel. You can parallelize them, but the speed up is just not there to make it useful.

Parallel programming is hard and blaming it on programming languages and claiming another one will solve all problems is just the usual silver bullet. Those languages have been around for ever, functional programming languages can be parallelized automatically. So if they make it so much easier, why aren't they not used? Could it be, that you have to pay for the easy parallelization with something?

Re:Is it really that hard?

[Short Circuit]

I see all fuss about programming. easy. don't what the is parallel It's
I see all fuss about programming. easy. don't what the is parallel It's I hereby propose that execution is in order for out of order speech.

Logical reasons to buy AMD

[Enderandrew]

Funny. I've seen a $59 Brisbane core (1.9 out of the box) overclocked to 2.9 GHz with just air cooling, so I'm not sure why everyone insists AMD can't hit the 3GHz barrier, especially when AMD keeps displaying 3GHz Barecelonas.

There are three reasons to buy AMD right now.

1. Price, price and price. AMD knows Intel has the better fab, but AMD is selling super cheap. You can get a dual-core processor for half what Intel charges, and for the average user, it is more than enough. I'm running Oblivion at 30 FPS with a $59 processor, and I've barely overclocked it. The cheapest Intel dual-core proc was $120 when I bought my $59 proc. Most people have no idea that their proc these days often underclocks itself, and you rarely touch the full potential of your proc. Intel is faster, and no one doubts that today, but if you never see the speed benefit, why spend the extra dollars? On a performance per dollar basis, AMD wins hands down.

2. There is a mountain of evidence against Intel for anti-trust violations, and I try not to financially support evil. The EU is also coming down on Intel for anti-trust violations.

3. Even if the anti-trust suits both come through, AMD is near bankruptcy, and I prefer choice in the marketplace. I am terrified of the day when Intel has no competition pushing them and they can just sell what they want and whatever price they want.

Re:Logical reasons to buy AMD

[Wavicle]

Funny. I've seen a $59 Brisbane core (1.9 out of the box) overclocked to 2.9 GHz with just air cooling, so I'm not sure why everyone insists AMD can't hit the 3GHz barrier, especially when AMD keeps displaying 3GHz Barecelonas.

Gosh, maybe you should go tell AMD that they aren't having any trouble with leakage, the yield of their 65nm parts is optimal and they can start volume production right now! The time AMD has spent not shipping Barcelona has been costing them dearly. Did you see the loss they posted last quarter? Did you notice their market cap right now is just a tad over what they paid for ATI?

AMD knows Intel has the better fab, but AMD is selling super cheap. You can get a dual-core processor for half what Intel charges

Yeah, you can get a share of AMD for about half of what Intel's cost as well.

On a performance per dollar basis, AMD wins hands down.

So rush out and buy an AMD now, before their super-low margins bankrupt them altogether!

There is a mountain of evidence against Intel for anti-trust violations, and I try not to financially support evil. The EU is also coming down on Intel for anti-trust violations.

You know if Intel did what AMD has done back when AMD had the faster product - cut their margins down to almost nothing to undersell AMD and gain market share - you would be screaming about the evil monopolist Intel. Somehow it is exactly the opposite of evil when AMD does it.

Even if the anti-trust suits both come through, AMD is near bankruptcy, and I prefer choice in the marketplace. I am terrified of the day when Intel has no competition pushing them and they can just sell what they want and whatever price they want.

Oh please. Regulators would never allow Intel to buy AMDs IP and there are plenty of companies out there willing to jump in and try their hand at the x86 game. If Intel starts driving up prices, that just makes jumping in appear much more appealing.

Re:Jombeewoof, get off the Internet.

[jombeewoof]

It looks like I have a fan.
good times. I guess I'll have to start wearing pants now though.