DailyTech - AMD Bumps AM2 Launch Date

Submit News

Hardware AMD Bumps AM2 Launch Date
Kristopher Kubicki (Blog) - April 19, 2006 2:05 AM

65 comment(s) - last by saratoga.. on Apr 28 at 12:51 AM

June 6, 2006 didn't fit AMD's schedule

We just got official confirmation from motherboard and chipset manufacturers in Taiwan -- AMD has moved the official launch date of Athlon 64 DDR2 up two weeks to May 23, 2006. AMD roadmaps have previously put the AM2 launch at June 6, 2006 (during Computex 2006), but since motherboards and CPUs are already completed, the launch will be pushed up. AMD insiders tell us Conroe's launch date was also a factor in pushing the AM2 launch date up, though even we do not know the exact date Intel's Conroe will launch.

AMD's latest advisories claimed the following:

May 16, 2006: Global announcement of Energy Efficient Processor roadmap and pricing
May 23, 2006: Global announcement of Socket AM2 and new desktop product availability and pricing
May 31, 2006: Global announcement of AMD LIVE! desktop system availability

Comments

Threshold

Username
Password
remember me

This article is over a month old, voting and posting comments is disabled

By hans007 on 4/19/2006 8:07:31 AM , Rating: 3

i've read conflicting reports that k8L is quad core's code name, or a k8 with a faster fpu.

reverse hyperthreading is not going to work. if you could even devise an algorithm that would split a thread onto 2 cores then, we'd have seen this technology on compilers already. and we havent. youc ant just take a thread, and by some magic spread it around. the idea that you can split a thread into 2 threads (which is basically what "reverse hyperthreading" would be) is idiotic. like the logic is impossible.

the only reasonably decent theory was that the 2nd core would be used to calculate the next instructions in the thread based on a guess which is sort of like branch prediction.

there is no magic cure to threading. i have had to read and understand countless things about writing threaded code and it is really up to the software developers to plan ahead. if the code is not written with that sort of plan then its screwed.

What about speculative execution?

By nrb on 4/19/2006 8:18:14 AM , Rating: 3

quote:
if you could even devise an algorithm that would split a thread onto 2 cores then, we'd have seen this technology on compilers already.

Well, we kind of have, in compilers intended for the EPIC architecture. Suppose you have a possible branch coming up in about 20 instructions time. The problem is: if we have to wait till we know for certain which branch we go down, we have to stall the pipeline until the decision has been made, which costs a lot of clock cycles.

Traditionally one has to try and predict which way the program will branch in advance , and proceed on the basis of that prediction. Sometimes the chip will get it wrong, which stalls things for quite a long time.

But if you have access to a second CPU core, you could start to evaluate both branches simultaneously, one on each core. Once the result of the branch-conditional calculation comes out of the pipeline you can choose which of the two CPUs will keep going, and which will just abandon what it was doing. This gives you the equivalent of 100% branch prediction accuracy.

Itanium does actually work like this, although I think it needs some intelligence in the compiler. Could something similar be done on the fly?

Parent

RE: What about speculative execution?

By HammerFan on 4/19/2006 9:18:00 AM , Rating: 2

That idea about computing both branches of a prediction sounds like a very neat way of boost AI performance in games. With more cores, more branches can be predicted. Perhaps with technology like this, we will begin to truly see dual-core performance shine where it previously had not.

Parent

RE: What about speculative execution?

By hstewarth on 4/19/2006 10:09:31 AM , Rating: 1

The best way to achieve better multi-core performance is for applications to better multi-threaded in designed. This not only helps with multi( not just dual ) core cpus but also with dual and multi cpu computers.

Trying to make dual cores work as single core will likely cause more overhead than hyperthreading itself.

Parent

RE: What about speculative execution?

By nrb on 4/19/2006 11:19:25 AM , Rating: 2

quote:
The best way to achieve better multi-core performance is for applications to better multi-threaded in designed. This not only helps with multi( not just dual ) core cpus but also with dual and multi cpu computers.

Well, obviously , yes, but a CPU can't dynamically recompile existing applications to make them multi-threaded! It's conceivable that something like speculative execution could squeeze a little bit more performance out of a single-threaded app. AMD have certainly got to do something .

Parent

RE: What about speculative execution?

By saratoga on 4/19/2006 4:40:11 PM , Rating: 2

The problem with such a scheme is that it massively increases power consumption, and by way more then you gain in performance (since at best you're just going to avoid the occasional branch mispredict but effectively double power consumption to do it). And at this point, performance is mostly limited by power consumption, so it doesn't pay off.

You'd do better with a wider core, or a deeper pipeline if you have that kind of power to throw away.

Parent

RE: What about speculative execution?

By glennpratt on 4/20/2006 6:08:30 PM , Rating: 2

The other core is already there! You think they are adding another core, just to strap this on it?

Parent

RE: What about speculative execution?

By saratoga on 4/28/2006 12:44:14 AM , Rating: 2

Think this through. The other core is added at the expense of clock speed to accelerate multithreaded loads. Speculative execution improves single threaded performance but requires a second core to not be used for a second thread. It also doesn't improve it as much as just not having a second core and upping clock speed would.

So whats the point? Help out people who bought a dual core chip even though they shouldn't have? Intel has the right idea here: keep power as low as possible and use that to RAMP UP THE CLOCK.

Parent

RE: .

By Araemo on 4/19/2006 4:56:45 PM , Rating: 2

I think it's less impossible than you think.

But it would blur the line between wether or not it's two seperate cores or one core with 'hyperthreading'.

Essentially, this would NOT be possible if the cores were using an external interface to talk to eachother.

There are already dual core CPUs that share cache.. you just need to set it up so they can share registers, and this could be doable. Would it be worth the trouble? I can't help but think it won't, except in the case mentioned below about calculating both branches instead of just prediction... and even that is of questionable importance.

For the record, 'branches' in code are much more low-level than flowchart 'branches' in AI. AI would do better by running each 'AI' as a separate thread, and let the CPU's paralellism run as many as possible. (When discussing AI for many in-game characters being simulated at once, anyway.. For one large 'true' AI, I don't have a clue.)

Parent

RE: .

By saratoga on 4/28/2006 12:50:11 AM , Rating: 2

quote:
I think it's less impossible than you think. But it would blur the line between wether or not it's two seperate cores or one core with 'hyperthreading'.

I think you overestimate your understanding of how complicated parallel processing really is.

quote:
There are already dual core CPUs that share cache.. you just need to set it up so they can share registers, and this could be doable.

I don't even know what to say. Sharing registers is the least of the concern here. HT can already do that just fine. Hell there have been machines doing that for years. The problem is, once you have two cores, how do you exact useful work from one thread on both cores? Essentially, the answer has been "you don't".

Or at best you do some hack like speculative execution or have one prime up the cache. Neither is all that appealing though if you're concerned about heat.

quote:
For the record, 'branches' in code are much more low-level than flowchart 'branches' in AI. AI would do better by running each 'AI' as a separate thread, and let the CPU's paralellism run as many as possible.

Well, the branches on a flow chart are often implemented as a single cpu branch, so I don't know about that. I'd say they can be more complicated, but typically, an if statement can be mapped directly to a branch (or at least a few compares and then a branch depending on the machine and how powerful it's instructions are).

Parent

"If they're going to pirate somebody, we want it to be us rather than somebody else." -- Microsoft Business Group President Jeff Raikes