They're not AMD optimized DLLs. They're DLLs that somebody has compiled, probably using the Intel C++ compiler as its the best, using the publicly available source code. They boost P4 performance almost as much.

Erm, just because you go to 64 bit doesnt mean taht the cache is halved, as far as i can tell x86-64 is around 20% larger than x86-32

Mr Yes,

How do you store a 64 bits word, in 32 bits space in memory cache ?

L2 32 bits processor
|-----------------------|

L2 64 bits processor
|-----------------------||-----------------------|

This "graphic" represente 1 row in memory cache

So even you have in an Athlon XP and Athlon 64 similar amount of cache lines, you double the size of memory cache, it's mathematic.

But you use this memory ONLY if you use an operating system and a softwre specificaly written to you for exemple an int (in language C) 64 bits. Very usefull for encryption for exemple.

BUT ! AMD don't have a Windows 64 bits, so they are selling you a processor with a bad size memory cache for 64 bits applications. They tell you that you got a 64 bits processor, but there no more ugly 64 bits processor thant this one. AND i don't talk about the TRUTH about the UGLY limitations of this processor in real 64 bits environnement.

If you have time i recommend you to see that document :

http://www.amd.com/us-en/assets/content_type/Downloadable Assets/AMD_TechEdEMEA2003_Final.pdf

And go page : 35

You will read : Legacy 3Dnow! x87 and MMX are not supported for native 64 bit apps.

THAT CRAZY !!!!!! If you don"t understand what it mean i can explain : THAT mean that you CAN'T USE the floatting point unit, multimedia AMD instructions AND the old multimedia INTEL MMX instruction IN EVERY Athlon compatible AMD64 (Athlon 64, 64 FX AND Opteron)

In a other way that mean AMD RECOMMAND Multimedia instruction of INTEL for developping 64 bits applications.

And that mean also that you have to rewrite completly your programme if you what to have an 64 bits complient application OR that mean the compiler is translating in background ALL YOUR Floating point computation IN INTEL SSE2 Instruction, that's CRASY

So Mr Yes please read my comments and don't make confusion betwen INSTRUCTIONS, DIE SIZE and SIZE of the CACHE thanks ;)

Erm i might be wrong but the benchmarks ive looked at where they used 64 bit over 32 seems quite promising...

Anywhere from 200% gain to 1% gain so i don't think it's "all" marketing?

Im not an expert by any means and you might be correct on this matter, but seriously Athlons are not hurt as much by smaller caches compared to the P4. One reason being the gigantic L1 caches compared to the P4s.(64kb/64kb) vs. (8kb/12uOPS)

And if im not mistaken SSE and SSE2 are 128 bit already...

Mr Yes,

You're right about SSE and SSE2 that is 128 bit precision BUT 2 things :

1) SSE and SSE2 is ONLY 64 bits precison (for memory Floating Point Unit is 80 bits)

2) In 64 bits OS and Apps the processeur will do every computation on the SSE/SSE2 and only on it. Today a processeur in 32 bits can do in parallele interger computation, also FPU and SSE/SSE2. With Athlon 64/FX/Opteron you have ONLY interger and SSE2. You lose one unit.

So you have less computation unit AND you have less precision... in 64 bits


Quote :" Erm i might be wrong but the benchmarks ive looked at where they used 64 bit over 32 seems quite promising..."

I don't understand what you said ... i don't see any 64 bits benchmark there.


Quote : "Anywhere from 200% gain to 1% gain so i don't think it's "all" marketing?"

On more time, i don't know where you find a 200% gain in thoses benchmarks


Quote : " but seriously Athlons are not hurt as much by smaller caches compared to the P4"

I told you that is was "normal" due to architecture Athlon 64 used in 32 bits is like an Athlon XP that don't use more than 512 Ko in L2 to work perfectly.

I agree that Athlon 64 512 or 1 Mo cache of L2 is a GOOD 32 bits processor. (not the best about me because it depend a lot of which kind of application you use : It doesn't interrest me to go faster in Word/Excel/IE and so on)

But i hate the marketing that sold this processor to be a 64 bits processor, it is very partialy true.

ooopps

i was meaning about the 1st point that the SSE/SSE2 was only 64 bits precision in FLOATING POINT

Ok, this thread is bound to confuse a lot of people because there is a lot of incorrect information here, so let me chime in with some points.

1) The L2 cache is for both code and data. For code, the opcodes defined by AMD64 do NOT double in size to 64 bits! Most opcodes themselves haven't changed from IA32. A lot of opcodes are still just 1 byte! Secondly, not all opcodes operate with 64 bit immediate operands either. Most in fact default to 32 bit operands and require a 1 byte prefix to the opcode to tell the cpu this opcode is using 64 bit operands. In other words, being in 64bit mode does NOT imply that the cpu will need twice as much cache just to break even for code. Code size will increase because of the prefix for opcodes using 64 operands, along with the 64bit operands themselves, along with some of the newer opcodes, but under almost all circumstances, code size WILL NOT double! AMD claims the size increase will only be ~10%. Even if they are grossly wrong we still aren't talking about anything more than a 25% to 35% increase, not 100%! Second, data size does not double either, only address pointers do. In 64 bit mode you can still manipulate 8/16/32 bit data without adding to the size of the opcode+operand (the operand being immediate data). If you manipulate 8 bit data for example using the older opcodes from the 8086, the immediate operand to the opcode is still only 8 bits! Data will grow more, since all address pointers will double in size, and a lot of data will be address pointers, but data won't double either.

2) Legacy media instructions (MMX, 3DNOW, SSE, and x87 floating point) are NOT restricted to legacy applications! Read the AMD64 Programmer's manual on x87 usage. You CAN use x87 floating point along with the SIMD operations of SSE2 at the same time! FYI: MMX and 3DNOW are opcodes that operate on data thats kept in the 80 bit floating point registers and some other FP control registers, so as far as AMD64 is concerned, MMX, 3DNOW and x87 floating point is all the "same thing". SSE/SSE2 however, uses DIFFERENT registers (128 bit XMM registers, and different control registers) which means there is nothing preventing the cpu from using both at the same time. Readers will please note that the document referenced by Harry is a document for MICROSOFT'S 64 bit version of Windows, it is NOT describing AMD's hardware, its describing how Microsoft's OS for AMD64 will work! Interestingly enough, the problem may be with their compiler technology, since at this point the open source GCC compiler also warns you that it doesn't handle very well the simultaneous use of multiple "function units" (MMX/3DNOW/x87 & SSE/SSE2), because until now GCC has assumed there is only one "mathematics coprocessor". AMD64 now has 2 completely independent ones, and even worse, both can work on either integer OR floating point data! GCC will handle this better eventually, its just a matter of extending the compiler's internal architecture, so why MS can't do this I don't know, they probably have their own reasons (related to Windows's internal architecture?) for wanting to prevent simultaneous use of both x87 and SSE2. Well, thats what you get for using a MS OS! :) Anyone using Linux/BSD (and future versions of GCC) will not have this limitation.

3) Clarification of "floating point precision". Precision is referred to as either "single", "double", or "double-extended". These 3 definitions allow for 24, 53, or 64 bits of precision in the fractional part of the number. Yes, only the x87 FP unit can do the later kind of FP math, but frankly most applications do just fine, thank-you-very-much, with 54 bit fractional precision, only extreme cases of scientific computing need that much precision, and the truth is most of this kind of computing is done on non-PC hardware that supports a whopping 128 bits of fractional precision. So I don't see this lack of 64 bits of fractional precision in SSE2 as the end-of-the-world as Harry does (never mind that, as I pointed out above, you CAN use x87 FP if you need the double-extended precison - at least in Linux). SSE2 supports double precision FP but unlike x87 FP, it can operate on *4* different floating point numbers at the SAME time (SSE is also known as SIMD instructions, which means "Single Instruction - Multiple Data"), so there are VERY good reasons to use SSE2 instead of x87 FP, and for most apps on a PC, you won't notice the difference.

4) Finally, here at the end I'm going to lose my cool a little :), and say that Harry's claim that AMD64 is an "ugly 64 bit processor" is utter bullshit, IMO. AMD64 is designed to extend the IA32 instruction set to 64 bits, unlike Intel's Itanium which THROWS OUT the old IA32 instruction set. Now thats not necessarily a bad thing by itself, but the problem is what Intel has replaced the IA32 instruction set with! I've seen plenty of comments which seem to suggest that the latest Itanium isn't exactly the "prettiest" 64 bit processor either! :) Itanium is far more radical than AMD64, but the bottom line right now is that with AMD64 you can run both 32 bit and 64 bit applications at hardware speed (Itanium has to emulate IA32 for 32 bit code, plus other limitations), meaning you can "upgrade" to 64 bit computing without having to throw out all the software you have now and start over, and AMD64 hardware will be MUCH cheaper than Itanium 2 systems. Just try to find a *quote* on an IT2 cpu on the net! They aren't being sold separately, you can only get them in expensive servers from a few companies, meanwhile I can get an AMD64 right now for less than the price of Intel's best 32 bit cpu!

Thanks Ed for all your comments, I will do my best to give you an interesting response

I will answer point to point but before I need to say that you aren't talking a lot about the architecture AMD64 working in 64 bits (Windows) environment, in where i point many problems.

So here my answers :

1) I totally agree with you about opcode, witch doesn't grow a lot. But like you said L2 cache contain both instructions and DATA. How do you store a 64 bits data in L2 cache ? Answer : You have to double space of the L2 cache, otherwise if you keep the same space as usual 32 bits processors (usually 256 or 512 Ko) you have fewer space for data. Yes it depend of programming habits from developer, but actually every coder think that he have 256 or 512 Ko of memory to put, for example many loop (which need fast memory). So on more time, IF you work in 64 bits environment, and use 64 bits words (int,float, … ) for a same loop (for exemple, there is other and better cases) you have to double the L2 cache, if not your processor will slow down (think about the Celeron with 128 Ko L2)

2) About legacy instructions, one more time it is a problem of environment. What I point before is the problem Legacy 3Dnow! x87 and MMX are NOT usable in 64 bits ENVIRONNEMENT : it's not me who said that , it's AMD during an Microsoft event (teched). May be it's true that the limitation is only under Windows, but do you really think that is normal that major computers users can't use it ? Don't you really think that AMD don't have to do a processor made for Windows OS ??? If you want problems under Linux environment with AMD64 architecture, try to use Dynamic link instead of Static links with your compiler, you will find a "little" problem.

3) Always under 64 bits environment, and specially under Windows 64 bits (Alpha version) I always don't thinks that is NORMAL to have a processor which have less precision in legacy mode. And one more time I always think that is very funny that AMD recommend INTEL technology (SSE and SSE2). Just a word about the *4* differents floating point numbers at the SAME time -> You forget to said that you have to REWRITE your code. For matrix computation it's easy, but that’s not possible (at least easy) for every source code, so for software.

4) A agree with you, Intel doesn't give a better solution than AMD for 64 bits computing. But the real problem is not that. The real problem is WE DON'T need 64 bits in consumer world ! Apple and AMD same combat ! Like you said we don't need more Floating point precision, PC don't need more 4 Go of memory today, nobody need 64 bits integer : Nobody (in consumer) need 64 bits processor TODAY (either tomorrow). IT's Marketing ! Like a said before, and I said again.

About me the REAL good idée from AMD is the integrated memory controller. A good but not the best because it will make some problems. The DDR "1" is going to limits (with frequency that make problems on motherboard) so we need to shift to other memory for bandwidth. So you need a NEW AMD processor to use a new memory WHEN Before you only need a new motherboard.

Anyway, I am only fighting with a consumer point of view, and about ME, and only me, the AMD64 is bullshit.

Hey "s182 ",
Your problem is due to your 3dcard. Try to put your cart on agp 0x in youre ati drivers and normally it will solve the problem...