ASUS P6T Deluxe
core i7 ??? - work perk. faster than 965 EE.
Noctua NH-U12P SE1366
G.SKILL 6GB (3 x 2GB) DDR3 1333
Intel X25-M SSD for boot
Sapphire Radeon 4850 X2
everything else is irrelevant. hopefully all the parts arrive mid next week.
It is difficult to respond to a post that has no meaning (specifically, duby's posts). In regards to sentence 5, that was a rhetorical question.
To be honest, I can't really offer any more specifics from my point of view without violating NDA, and AMD's LWP specification is available for all...
Don't bother, you have no clue what you're talking about. I've been in the field long enough to know bullshit when I read it. You were confused by profiling and still don't know what it is, you are completely confused about the theoretical idea of "RHT", and your ideas about asymmetric...
Nice one.
I can hardly figure out what you're saying anyways, you've horribly mangled the concepts of thread level parallelism. Why were you talking about branches again:
WTF? I can barely link your stringy line of conceptual ideas together... :rolleyes:
Moving onto asymmetric processing...
Absolutely, this extension can be used to tweak anything. So the claim that this is especially beneficial for multithreaded apps seems like an AMD marketing pitch to me.
That's not even what LWP does. Go read the spec.
As for "RHT", it is the exact opposite of power efficiency, so why even bother doing it, especially when the processor is rarely "wrong" to begin with.
Those amdzone people are retarded. LWP is just perfmon with feedback to software. Intel has announced something similar months ago (RT, I believe)
Back to topic, big fat no. No matter how you cut it, LWP and RT do not allow one thread to execute on two or more cores.
You know, only the truly desperate fanboy would resort to crazy conspiracy theories about whether the conroe demos in March 06 were rigged. They weren't because there was absolutely no reason to rig a damn thing, as everyone knows by now. The thing was a genuine *underclocked* C2D, and it was...
Hah, I worked on P4D and I remember the exact day it came out publicly and there was a big bunch of hoorah about coming out to market before X2. Quit with the revisionist history.
Do you recall store availability? I doubt it, since there is no way you actually bought a P4D.
lol that article is just complete crap.
"AMD claims that its yields lead the industry, meaning that it consistently pulls more perfect chips from each manufacturing run than the average, so it hadnt the need to kick up to larger wafers to offset the number of bum chips per run"
gee, it...
that's just plain idiocy. if intel was dumb enough to force its employees to support its products, half the people in my engineering group (myself included) would leave. only the most fanatic amd !!!!!! could even say that.
also, your narrow-minded obsession with the on-die memory...
who the hell needs a sample. performance simulations are running before design work even starts.
so now you say speculation is silly, when you and others have been praising K8L's imminent awesomeness referencing a bunch of marketer slides, in this and other threads. hahaha hypocrites...
yeah, that's why im not speculating on k8l performance, unlike everyone else.
and since when did someone have to be a high level person to know the perf of a part.
yeah, some flaw. mobile merom and its crippled bus can beat a fx offering in plenty of traces... not to mention dual package will dominate the market well into 2008. yeah, that fsb is really hurting that segment. lol.
it is amusing so many fans are saying things like "wait til K8L...
- Wrong on "true 64 bit processors" (what is that?)
- Wrong on bottleneck (what bus?)
- Wrong on emulating (how do you emulate a definition?)
- Wrong on "addressing size" having an effect on performance (cutting out the latency of large memories, the pipestage delay from decode to memory...
If anything, the missing instructions further reinforce the fact that intel simply took the x86-64 specification and called the implementation "EM64T". At least now you understand there was no reverse-engineering going on. I only pursued this so far because it is irritating to be accused of...
Good point, prescott taped out with EM64T on-die before K8 was unveiled, and EM64T itself was approved and designed long before that, during the initial definition. So K8 shipping had nothing to do with the decision to add 64-bit support, but then again, everyone knew AMD was going to be first...
You got the design process wrong. First you come up with the specification. In this casee, intel got the list of new instructions and their functionality. Then the designers go figure out how to make the P4 execute the new functionality. The instruction set is nothing more than a...
OK, since I'm actually a member of that design team, I can tell you right away that the P4 backend has absolutely no "elements" in common with the K8 backend, whatever the hell "elements" is supposed to be. Whatever AMD did in the K8 backend does not apply on a P4 backend. Get it?
Hey, I...
The fact that P4 and K8 are both x86 architectures means absolutely nothing. From front to back, through microcode and datapth, everything is totally different. The only thing intel took from AMD64 is the new instructions, and beyond that, it is all new work in-house. Much like AMD taking...
You think AMD had to start over with K7? 64-bit support isn't nearly as complicated as one may think. Also, since the P4 backend is so radically different from the K8, the work required to support EM64T on a P4 is a totally new engineering problem when compared to AMD64 on a K8.
Saying...
"Smarter kids" is right, the guy is clueless. All control dataflow in the backend of modern processors is emulated with microcode, microcode performance is based purely on the availability of resources. And since when do people care about how the backend works anyways? That stuff is...