K8l to have 6mb cache

Printable View

Show 100 post(s) from this thread on one page

11-28-2006, 05:42 PM
agenda2005

Quote:

Originally Posted by metro.cl

Also i was kidding couse you put 4x512MB no 4x512kb as it should be

do you know how much ipc improoved from p4 to c2d?

why cant amd improove 25%? time will tell im not making up i got this info from the same person that told me 9 months before that:

C2D would kill amd
C2D would have cold bug
C2D would get over 3.6GHz OC

so i trust him

Alright, thanks for the correction. I will wait and see what AMD can bring to the table.
11-28-2006, 05:58 PM
dinos22

Quote:

Originally Posted by brentpresley

As usual, your statement is a bit misleading and incomplete.

K8 (like K8L) also has 3 complex decoders.

C2D uses 1 complex and 3 simple decoders (4 total, for the math challenged).

With C2D, in CERTAIN instances, two x86 instructions can be "fused" and operated on at once. So under optimal conditions there are 5 instructions issued at once, not just 4.

Complex decoders are not the end-all be-all in the x86 world. They take up more die space than simple decoders and there are only SPECIFIC instances where they are useful (decoding longer instructions into subsets, etc.). Simple decoders take up less die space and work on the more common instructions seen in the CISC architecture.

More about the K8 vs C2D architecture here:
http://www.anandtech.com/cpuchipsets...oc.aspx?i=2748

outch!!!! that makes these look pretty obsolete .......... amd will take a beating in 2007 big time it seems
11-28-2006, 06:09 PM
nn_step

Quote:

Originally Posted by dinos22

outch!!!! that makes these look pretty obsolete .......... amd will take a beating in 2007 big time it seems

ummm, a little secret for you. Normal number of Integer operations is under two at a time.

if you don't believe me. http://www.cpuid.com/perfmon.php
Use the log function and find out for yourself
11-28-2006, 06:10 PM
dinos22

Quote:

Originally Posted by nn_step

ummm, a little secret for you. Normal number of Integer operations is under two.
if you don't believe me. http://www.cpuid.com/perfmon.php
Use the log function and find out for yourself

it really is a pointless discussion without any benchmarks still so let's see what happens...........AMD is getting severely beaten at the moment. How long will we have to wait until a decent CPU for an extreme overclocker will come one
11-28-2006, 06:15 PM
nn_step

umm if you didn't know the only weak point about AMD is the Floating point performance. Which from what we hear should be the new king
11-28-2006, 06:41 PM
dinos22

Quote:

Originally Posted by brentpresley

BS. My E6600 will spank the living CRAP out of anything AMD has to offer right now in terms of integer performance.

You just make this garbage up as you go along don't you?

i think he is saying that AMD is about to correct Integer floating point performance in new CPUs

let's wait and see i say :cool:

i'm going with whoever is fastest on the day. Right now Intel is a country mile ahead
11-28-2006, 09:48 PM
breakfromyou

http://www.amd.com/us-en/assets/cont...alystDayV2.pdf

there, take a look at that. im sure it would set a few of you clear on some info thats been going around at the inq :\

about my previous post, i said it was 4mb of L2 cache...i was wrong :( it says 2+ in the tech docs i just linked to. so it will be 4x512kb + 2+kb. so thats a total of 4mb...not too shabby. just keep the latency low, and it should be more than good enough.

i thought the 3/4 issue thing wasn't something to worry about? isn't it visible in the pictures of the core? eh, it better be 4. AMD did say that nothing about the K8 architecture went untouched. so...lets hope it really is a 4 issue core.
11-28-2006, 09:50 PM
Shadowmage

^^ Integer and FP operations are independent of each other. There's no such thing as "Integer floating point" operations.

nn_step: AMD's FPU was and still is one of the best on the market. All Intel did was add 2 more to make 3. It's ALU and memory performance is what's lacking. The memory controller does make up for some of the problems though.
11-28-2006, 09:54 PM
Shadowmage

Quote:

Originally Posted by vitaminc

uh, if you double the number of cores, the IPC should also double, aight?

and if you are talking about K8 vs K8L cores, 40% IPC improvement is not unreasonable but still pretty far fetched.

When doing 2 threads at a time, IPC of the ENTIRE thing would double. AMD's referring to single thread performance, in which the number of cores does not matter (only makes things worse). Increasing the number of cores LOWERS IPC in single-threaded situations due to bus contention, cache coherency misses, etc.

Plus, OoO loads itself adds 40% performance in some extremely limited situations (from Intel tech docs).
11-29-2006, 01:48 AM
kl0012

Quote:

Originally Posted by LOE

So if even K8L features only 3 compex decoders, which is something that is to be seen, it will still be superior to C2D when it comes to multithreading

3 complex decoders x 2 = 6
1 complex x2 and 3 simple = 5

Your calculation is useless, because only 4 uop can be handled by the next stage of the pipeline (3 uops for K8 and probably for K8L). Core dosn't realy need more compex decoders, because most instructions can be handled by simple decoders. For example in Core SSE instructions are translated in one uop, whereas in K8 it needs 2 uops (because of 64-bit execution units).

Quote:

EDIT: Amd says up to 4 double precision flops per cycle - is this possible with only 3 complex decoders?

They means for two vector SSE2 instruction which can execute two 64-bit multiplications and two 64-bit additions in the same cycle. Core already can do it.
11-29-2006, 01:52 AM
kl0012

Apropos, what about anti-HT? Is it still not out yet? :D
11-29-2006, 05:42 AM
Cooper

Closed

Show 100 post(s) from this thread on one page