AMD 4x4 surprise

Status
Not open for further replies.
The General said:
Boy, you really have a hard-on for correcting people.

I wasn't wrong, yes, this time around, in this fluctuation, in this competition, this round, Intel wins. How is that wrong? Are you saying that because of Conroe, ALL COMPETITION STOPS AND PEOPLE BOW DOWN TO THEIR MASTERS? No! Intel wins this time, and will pull ahead for (most likely) a long time. Years even, maybe.

Though I do agree with you about your response to this. :p

The General said:
NO where in "This time round" is there any HINT of a time frame.

What didn't you understand about this? I don't know how else to tell you that "This time round" doesn't imply any sort of time frame.

The General said:
You and I know that AMD going out of business would be a VERY VERY BAD thing.

We'd better hope AMD has a come-back before they go out of business, because if they do, Intel will virtually have a monopoly, more so than Microsoft, and if you know anything about business, when all competition dies, development slows.
 
Why pay so much for so many AMD Processors when the Core 2 Duo is so cheap and effective at the same time?

Regaurdless of price, holding the crown of performance is something AMD wants to continue. It's more so they can say "We have the world's fastest CPU setup!", then the best bang for buck setup. But look at the AM2 OEM CPU's ... 3800+ ~ $125!!
 
I simply said that AMD will not be bringing out a better processor than what Intel has for a very long time.
Simple question, true or false: Conroe still uses EM64T extensions
 
lol I honestly don't know, I assume it is true as I haven't heard otherwise, but I wanted to make sure
 
I honestly don't know either, lol. I know that was the case with the first P4s to have 64-bit capabilities, but I haven't been following up. As long as it's capable of 64-bit, I guess it doesn't really matter?
 
Ah but this is where my point comes into play. It does matter if it is or is not EM64T depending on how hardware and software develop over the next few years, especially if you assume Intel sticks to EM64T extensions in their future processors

AMD64s are true 64 bit processors as they process 64 instruction sets both internally and natively. EM64T is different however; it's been demonstrated to only emulate 64 bit instruction sets through an internal 32 bit process. In other words, they aren't true 64 bit processors and thus as a result they bottleneck themselves as they have to keep emulating code that they can't really process in its native mode

This issue isn't really relevant now as 64 bit code is almost non-existant, but this is probably going to change after Vista is released (and forgive me as I haven't really followed Vista at all). Now, 32 bit processes are only capable of addressing 2^32 bytes or roughly 4GB. Assuming Vista is the resource hog it is, we'll have to shift to 64 bit processes in order to obtain a larger addressing size (2^64 bytes). This will basically result in an internal memory bandwidth bottleneck in any EM64T processor as it has to keep switching between two instruction sets.

So really, AMD does infact have yet another secret weapon that has been lying dormant for a number of years which has yet to reveal its full potential. And indeed, we haven't seen how AMD64s or conroes react in a 64 bit environment or compare to one another. That's why I'm saying you shouldn't underestimate the AMD64 architecture as it has infact not been harnessed to its full potential yet. That said, 64 bit instruction sets shouldn't sway the performance of a core very much from a 32 bit environment, unless of course the idea behind EM64T is correct and it is infact simply emulating x86-64 code.
 
I see, thanks for the explanation. I will now attempt to find out if Conroe does indeed use extentions to emulate or not.
 
Well this is interesting.

Conroe is real 64 bit. As was the P4. it was never an emulated thing. It can be argued that the implementation wasnt that good, but it was certainly "real."

As far as Conroe goes, it seems like a solid implementation. It should scale well with memory. And given the architectural enhancements made, it should be able to put thoise extra GPR's to good use as well. I think they did a pretty good job this time.

Well, technically the desktop chips that are 64-bit now aren't even "true" 64-bit.

..but yes, Conroe is "true" 64-bit.

edit: bah! too slow....laggy internet tonight

And this guy seemed to take some sort of personal offense;

What are you talking about? Pentium 4's don't "emulate" 64-bit capability. You can't emulate something like that. Either you support it or you don't. EMT64 P4's are just as capable as the A64's in 64-bit code.

In order to support x86-64 the cpu must have 16 64-bit registers (as opposed to 8 32-bit registers as in x86) as well as a host of other new things, and that's the end of the story.

You seemed to be right, though. Here's the link, I don't want to post any more.

Clicky.
 
Ok, I read that and just want to clarify a few things:

1) Yes I know that x86 microprocessors were neither originally built with 32 bit or 64 bit register extensions. However, saying that is like saying current x86 processors don't "natively" support updated SSE instruction sets or 3DNow! as they were never originally supported in x86 microprocessors. My intrepretation of native is a processor that is able to understand and process an instruction set without having to emulate it through yet another instruction set and as a result create an internal bottleneck. For example, Pre RevE AMD64s did not support SSE3 instruction sets and as a result had to emulate them and as a result would perform noticably slower on programs using said instruction set. If you want an example try comparing a Prescott to a Winchester core using SSE3 version of SuperPI

2) I am not saying that Intel processors using EM64T cannot use 64 bit extensions. The point I'm making is that EM64T was nothing but a response to AMD64 extensions. Intel had already previously developed their own native 64 bit processors, namely the Itanium with IA-64 support, however that core lacked IA-32 support and as a result had to emulate 32 bit code and severely choked in 32 bit environments. I'm not claiming I am a programmer or microprocessor engineer however based on what I have read on EM64T (and this was a while ago when Intel first released it, hence why I don't if it is accurate in regards to conroe), cores equipped with EM64T extensions in theory should suffer the same problem the Itanium had with IA-32 extensions.

3) Here's what you have to assume. AMD64s were built from the ground up to include full native support for all legacy bit extensions (16, 32 64) using AMD64 extensions. The Pentium 4 was not, it was a native 32 bit core that was taken back to the drawing boards and rather than try making IA-64 and IA-32 universal, they instead tried cloning AMD64 extensions (or rather, they had to as Windows x64 was being written with AMD64 extensions in mind as far as I am aware). Thus, EM64T was born and operated in a 32 bit mode internally. To compare, think of hyperthreading or reverse hyperthreading if you must. The core is able to trick the operating system into believing that the core is able to accept more than one thread at a time by duplicating the architectural state of the core. This gets hazey with me, but it seems to me that if a core is able to modify its own architectural state and manipulate software such as allowing an OS to schedule two threads to a processor that infact only has one physical core, it seems perfectly possible for it to modify the number of bit registers, bit intergers etc. present in the architectural state.

Like I say, I don't know the details nor am I up to date on this crap. I am not saying that EM64T are not 64 bit processors, I'm simply saying that they aren't designed to natively support 64 bit code IE Itanium not natively supporting IA-32. It's also not really relevent either and based on the woodcrest vs. opteron I just flipped through it looks as though I am incorrect
 
Status
Not open for further replies.
Back
Top Bottom