backtop


Print 24 comment(s) - last by Trisped.. on Apr 4 at 1:21 PM

Looking through 2006 into 2007, AMD's upcoming line of Turion processors will be taking Intel's Core Duo head on

AMD's market share is developing well and the company has been successful in shipping a large number of processors this past quarter. Sources close to AMD have informed us that coming early this second quarter, AMD will be announcing a slew of new Turion 64 processors. However, some products may encounter delays.

Our contact indicated to us that AMD's new dual-core Turion 64 processor, codenamed Taylor, was slatted to launch on May 9th of this year but now may be delayed to June. The processor is a low wattage processor designed to be used on socket S1 boards. The processor has twin 256KB L2 caches and supports DDR2-667MHz memory. Taylor will be the first mobile AMD processor to support DDR2-667MHz and be placed squarely up against Intel's Core Duo. AMD will also be releasing a version of Taylor, called Trinidad which has the same specifications but be equipped with twin 512KB L2 caches.

On the single core side, AMD will also be launching a new processor currently codenamed Keene. The processor will be identical to Taylor, but only have one core. In terms of power usage, AMD will be pushing the envelop in low power usage. No exact details were given but current usage numbers for Taylor and Keene are 35 watts and 25 watts respectively. No specific date for Keene was given but it looks as though Keene will be available not long after Taylor.

In the first half of 2007, AMD will be making a change to Taylor. The successor, called Tyler, will be based on similar specifications but move to a smaller 65nm fabrication process and support DDR2-800MHz. Tyler will remain dual-core and by the same time frame, Intel will also be showcasing Merom.


Comments     Threshold


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

HRM!!!
By covertbit on 3/29/06, Rating: 0
RE: HRM!!!
By mino on 3/29/2006 3:16:28 PM , Rating: 3
It wil help them on power, for sure.

Also it is proven K8 architecture is almost insensitive to L2 cache size. Even 128k L2 Semprons perform pretty well - i.e. 1.8GHz 128k outperforms 1.6GHz 256k.

This considered, 2x1M L2 would bea a waste of power and silicon for AMD.

Rememeber, Core NEEDS big cache, K8 likes it too but can live pretty happily without it.


RE: HRM!!!
By stephenbrooks on 3/29/2006 3:37:00 PM , Rating: 2
quote:
Also it is proven K8 architecture is almost insensitive to L2 cache size. Even 128k L2 Semprons perform pretty well - i.e. 1.8GHz 128k outperforms 1.6GHz 256k.

That's very true. I once ran speed tests of a program and had an overclocked Sempron64 beat all the P4s in the benchmark.
http://stephenbrooks.org/groupee/f orums/a/tpc/f/14...


RE: HRM!!!
By Araemo on 3/29/2006 4:04:27 PM , Rating: 3
To elaborate on Mino's post a bit with the Why's:

In intel's lineup, if the CPU has to request data, it first looks at level1 cache.. which is nice and speedy, and comes back with the data within a couple clock cycles. Level 2 cache is slower, but much bigger. If the data isn't in level 1, you wait 10-30 cycles(I'm WAY too lazy to look up the details on Centrino, and I don't even know if they're out there for Core Duo yet.). BTW, larger level 2 caches generally have higher latencies(Measured in cycles) than smaller level 2 caches.

All of the above is 99% the same in AMD's lineup.. L1 cache is practically no-delay, L2 is usable, but an order of magnitude slower. But the differences comes when neither L1 nor L2 have your data- and you have to go to main memory. On the intel chips, the CPU has to put a request out on the FSB, which gets to the northbridge a few cycles later(and how many cycles depends on the difference between FSB speed and CPU speed.. since they're rarely even multiples anymore, you sometimes get a request that gets to the cpu-norhtbridge interconnect, and has to wait 2 or 20 CPU cycles before the next FSB cycle comes around), and then it makes it to the northbridge, which goes out to memory - a slow(relatively speaking) procedure. When the answer comes back - usually a half dozen memory clock cycles later(a few hundred CPU cycles later), it has to go back to the cpu(another dozen cycles, give or take 10. ;P), and then it can be used.

Memory latencies from the memory controller are largely the same between AMD and Intel. The difference is that AMD's controller is coupled to the CPU, so you get noticebly lower memory latences in the worst case scenario, and in best case to best case comparisons, they're often 2 times lower or better. This means, Main memory looks more like an L3 cache to an Athlon64, while it looks like a distant data store to an intel chip. Intel has done marvelous things with their memory controller and limited FSB. I'm amazed that their memory latencies are as low as they are. They aren't a full order of magnitude slower than AMD, like many people expected them to be, but they are noticebly slower.

Some time in the future, intel will be integrating a memory controller on their CPU as well.. but.. well, last I saw that was 2H 2007?

This makes sense for both companies though - Intel has huge economies of scale, and many more 300mm production lines than AMD does. It costs very little(relatively speaking) for them to build huge L2 caches.

AMD on the other hand, would be straining themselves by giving every chip 2-4MB of L2 cache, and would be even more expensive than they are. It takes less transistors and die space to give you an on-die memory controller than increasing L2 cache. And as a bonus, it makes L2 cache less important.


RE: HRM!!!
By Phynaz on 3/29/2006 5:04:25 PM , Rating: 3
quote:
I'm WAY too lazy to look up the details


You just invalidated your entire argument. Why do all the writing if it's based upon numbers you made up?

And memory latencies 2 times lower or better? I call BS - prove it.


RE: HRM!!!
By Xenoterranos on 3/29/2006 10:48:32 PM , Rating: 2
Pick up a computer architecture book, everything he says is basically correct. And besides, exact clock timing information for current tech chips is either A) very hard to get or B) Very hard to understand (underneath hundreds of pages in a whitepaper or whatnot). I suggest Computer Organization and Design by Patterson and Hennesy, the guys who practically invented the RISC arcitecture.
For the record, I think he was actually being generous on those numbers, and indeed intels FSB is orders of magnitude slower than L1 cache (read: registers). The point is that Intel has architechted the chips so that they very rarely need to go to main memory, and if so, those reads get done as fast as phyisically (I mean, actual physics here) possible.


RE: HRM!!!
By Trisped on 4/4/2006 1:21:24 PM , Rating: 2
I beleive registers are not Lv1 cash. Registers is where you work with the data, not where it is stored for easy access.


RE: HRM!!!
By ShadowD on 3/30/2006 12:14:23 AM , Rating: 2
Lets see.. I have an AMD64 Opteron 146, and I just used Everest home edition to check my memory latency, oh look! I keep getting 35.4ns or less! And down the list of other systems, down below 4 AMD64+ Athlon systems and 1 Opteron 246 system, there is Intel at 78.9ns.

Seeing as the memory controller on my mobo is in a state of pre-death, and I have to run my RAM 30mhz slower than it can run, properly tuned AMD systems might be able to get below 30ns.


RE: HRM!!!
By Phynaz on 3/30/2006 11:39:26 AM , Rating: 2
Memory controller on the MB on an AMD system??



RE: HRM!!!
By dexvx on 3/29/2006 7:43:07 PM , Rating: 2
quote:
Rememeber, Core NEEDS big cache, K8 likes it too but can live pretty happily without it.


No, thats false.

The performance difference between Pentium-M/2MB Dothan to Celeron-M/1MB is about 10-15% at clock speed. Why do you think the Celeron-M/1MB can spank Mobile Sempron64's 100-200Mhz higher (not PR rating).


RE: HRM!!!
By ShadowD on 3/30/2006 12:22:53 AM , Rating: 2
2 x 1mb l2 is where diminished returns kicks in for the K8 architecture. 512kb is better than 256kb for games by something like 10-20% (depending on game), but an extra 512kb (1mb total) makes less than 10% difference (as in I remember seeing a few forum members on an OCing website attempt to find a benchmark where a plain 512kb extra L2 provided more than 10%, and from memory they didn't find any such benchmarks.


RE: HRM!!!
By ViRGE on 3/29/2006 3:20:55 PM , Rating: 2
You're a bit confused on the cache sizes there; the Core Duos always report their sizes as the total L2 cache, so using Intel's definition it's 512k(2x256k) and 1MB(2x512k). It still puts AMD behind by a factor of 4, but it keeps things in perspective.


RE: HRM!!!
By inthell on 3/29/2006 3:28:37 PM , Rating: 2
dude you're confused Core duo (Yonah) are 2x1MB L2 cache.

but keep in mind AMD has a MUCH larger L1 cache and also lower latency cache plus the integrated mem controller helps AMD as well


RE: HRM!!!
By Marmion on 3/29/2006 3:38:33 PM , Rating: 2
Dude! Core duo (Yonah) is 2mb cache, not 2x1mb! Its 'dynamicly' shared between the cores. If one core is doing all the work, then that core will get the full 2Mb, or however much it needs.


RE: HRM!!!
By Furen on 3/29/2006 3:50:35 PM , Rating: 2
Core Duo has a single, unified 2MB L2 cache. Unified caches have the advantage of not having duplicated data, as separate caches will. Also, K8s are not insensitive to caches at all. There are huge performance differences between a 256k Sempron and 1MB one. Sure, both perform pretty well but the 1MB L2 part will always outperform the sempron.

What's very nice about the decrease in L2 is that we'll probably see some cheap dual-core parts from AMD.


RE: HRM!!!
By saratoga on 3/29/2006 4:15:04 PM , Rating: 4
>Core Duo has a single, unified 2MB L2 cache.

Correct.

>Unified caches have the advantage of not having >duplicated data, as separate caches will.

Although it would be possible to build a cache like this, I don't believe Yonah is. Intel's info suggests that Yonah's cache is divided into 2 seperate caches, with the smallest allocatable block being the cacheline (or maybe a little larger, depending on who you believe). Though if you've got some Intel docs I haven't seen, please link them :)

Regardless, the advantage of doing that would be very small. The real reason for shared cache is cost. Its much, much cheaper to fab. In reality, the logic used on Yonah's cache actually made it quite a bit slower, since there is now a 2-3 cycle cost to figure out which core can access where.

>There are huge performance differences between a 256k >Sempron and 1MB one.

No, really there isn't. I'm sure you can find a benchmark were it makes a difference, but even at 256KB, adding more L2 doesn't make a noticable difference. 5% seemed to be towards the best of the improvement from doubling cache size. The large L1 and fast memory access time negates a lot of the usual L2 benefit.



RE: HRM!!!
By Xajel on 3/29/2006 4:38:35 PM , Rating: 3
just to note some thing

Intel always uses inclusive cashing system when AMD is using exclusive cashing system

different is simple...

in Intel, what ever data in L1, is also in L2, and if there's L3 all data in L2 will be also in L3... and all data in L1+L2+L3 if the last is found.
so the total cash size in any Intel CPU will be the size of the largest cash level.. so if we have L3 the total size of cash system will equal the size of L3. but if there's no L3, the total chash size will be the size of L2 it self...

in AMD, when data copied from L2 to L1, it will be deleted from L2 and adding new data from RAM so and data in L1 will not be dublicated in L2.
thats why the total size of AMD cash system is calculated but L1+L2

conclution

Intel's total cash used = L2 ( or L3 if there's L3 )
AMD's total cash used = L1+L2


RE: HRM!!!
By Xenoterranos on 3/29/2006 10:53:42 PM , Rating: 2
sources? Im not being facetious, I'm actually quite interested.


RE: HRM!!!
By blckgrffn on 3/29/2006 11:44:42 PM , Rating: 2
Google it dude, its all there. I wrote a paper in computer org on the different cache sizes on the p4's and A64's and the cost vs speed trade off you always have to make. You can actually find the latencies for all the p4 and A64 caches and compare them in a n-set associative manner as well. Nifty stuff, but you can google it as well as I can. :)


AMD is going shared cache?
By MrKaz on 3/30/2006 4:10:24 AM , Rating: 2
I can only see one justification for AMD going 256kb+256kb:
-Shared cache, totaling 512KB instead of 2x256kb?
-Improve Yields?
-New DDR2 memory controller is more powerful; decreasing the requirement of larger caches?
-Power consuming goes down a bit?

ALL of above?




RE: AMD is going shared cache?
By finalfan on 3/30/2006 1:17:18 PM , Rating: 2
The only reason I can see for a smaller L2 is for the power sake. 2x256K sits at 35W. Is there any data about the 2x512K?


RE: AMD is going shared cache?
By josmala on 4/3/2006 10:37:42 AM , Rating: 2
The power is not the reason. Pentium M has large cache for POWER SAVINGS.
The key here is that getting stuff from main memory consumes over order of magnitude more power than getting from L2 cache. And the sit idle cache won't consume that much power, especially if its power optimized.

The real reason is that AMD is manufacturing constrained right now. If they want to sell more CPU:s they need to make them smaller, so that they can make enough of them. Easiest way of making them smaller is reducing the cache.


It's time for some new marketing AMD
By Samus on 3/31/2006 4:13:13 AM , Rating: 2
Ok AMD, twist intels (strong)arm and start marketing the clock-speed thing again.

Chances are AMD will now have higher ramped clock-speeds than Intel.

It worked for Intel, and most of the suckers in the public still think more MHz is better. Let'em have it. They already have a 3GHz Opteron. Time for Intel to eat their own marketing. They won't have Core Due beyond 3GHz for at least a year.




By josmala on 4/3/2006 10:39:53 AM , Rating: 2
What was the 3.3Ghz extreme edition they mentioned?
The key here is for normal low power desktop design they won't go at veryhigh clockfrequencies, but then there is the extreme edition, which probably costs as much as AMD:s top speed.


"This is from the DailyTech.com. It's a science website." -- Rush Limbaugh

Related Articles
Intel Mobile Processor Roadmap: Merom, Yonah
February 15, 2006, 11:05 AM













botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki