Haswell will rival graphics performance of today's discrete cards!

[Nemesis 1]

There ya go.

http://llvm.org/
http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine
http://blogs.amd.com/developer/2011...utm_campaign=Feed%3A+amd/all+(All+of+AMD)
http://www.appleinsider.com/articles/08/06/20/apples_other_open_secret_the_llvm_complier.html&page=2

We all know AMD is going to use differant compiler. JF said in that topic thats locked that AMD would not use Intels compiler .

You really need to read about the Elbrus compiler . That worked started on in 1982 . and under intel is still in the making . Its ideal for vector . Haswell doesn't that have a vector unit built into it like larrabee did. Intel really doesn't talk alot about its compilers that I have seen . But the elbrus compiler back in 2006 there was much information about. Should still be around . I did a small copy and paste in that other topic that contains a small amount of info on it . At least all I was willing to copy and paste . I gave a link were the whole article could be found more than once on this forum .

If you think someone is going to through together a compiler that does a 3 digit prefix like intels does . You are dreaming .

 

[Nemesis 1]

If we havnt a clue as you say. How about you start a thread in cpu that covers AVX?

Already done. It includes Mitosis and the AVX intel documents and a small amount on the elbrus compiler . I used direct intel statements from the documents in the debate . Nothing came from me . It the locked topic they keep talking about.

Look you have the AVX instruction set OK . New apps can be created using that instruction set . NO prefix required

The prefix of Vex covers old apps . You simply add the Vex prefix and compiler automaticly recompiles . Now not all code benefits from these prefix, With AVX II integer was covered . Still not all apps are covered as intel is still adding software to the compilers when that occurrs you get another Vex prefix . Intel says it takes times to develop and I doubt them not. I can imagine it takes alot of work to do this

OT .

Who ever you be try it now.

 

[CPUarchitect]

It will have a different CPUID feature flag from Intel’s FMA extension. At some future point, we will likely adopt Intel’s newer FMA definition as well, coexisting with FMA4. But as you might imagine, we may wait until we’re sure the specification is stable.

Ya they will be waiting till hell freezes over.

There's no reason to assume that. AMD switched from SSE5 to AVX + FMA4 + XOP, with no significant delay in their design schedule (at least not apparent to us). Adding FMA3 support will be nearly trivial at this point as it's purely an instruction decoding task, and unless the business guys decide otherwise, the next iteration should have it.

In fact Intel will have a harder time adding FMA4 support (if they ever wanted it). It requires adding another register index field to the uop format, which they must attempt to keep as small as possible to store as many as possible in the uop cache. Note that although the vblendvps instruction takes four registers and is already supported by Sandy Bridge, it actually does not require this extra register field in the uop. vblendvps gets decoded into two uops: a vmovmskps operation, which turns the mask register into an 8-bit value, and an ordinary vblendps operation which takes the 8-bit value as the immediate field. It's a compromise.

But it's just an implementation detail in the grand picture. The important thing is that Bulldozer will support all of Intel's AVX instructions, and a few more, and has the full ability to extend on the VEX encodings in the future. In fact untill Haswell arrives, AMD will have a slightly superior SIMD ISA! It's only a short-lived advantage, and we'll have to wait to see what the actual performance is like, but clearly AMD isn't fundamentally held back from implementing any of Intel's instructions.

 

[CPUarchitect]

We all know AMD is going to use differant compiler. JF said in that topic thats locked that AMD would not use Intels compiler .

It's not up to AMD which compiler is used. That's the software developer's choice. And they've got plenty to choose from: Visual Studio 2010, GCC, LLVM, ICC, etc.

Extending an existing compiler to support AVX is straightforward. The VEX encoding simply compacts the legacy SSE and REX prefixes and adds a few new fields for 256-bit operations and non-destructive operands. It's a pretty clever encoding but not complicated at all to people familiar with legacy x86 encodings.

There is no strict need for AMD to have its own compiler to enable developers to make use of the AVX support in Bulldozer. There are plenty of other compilers. That said, I do expect AMD to update its compiler(s), and there's no reason to assume they'll have any trouble doing so.

Haswell doesn't that have a vector unit built into it like larrabee did. Intel really doesn't talk alot about its compilers that I have seen .

AVX2 is nearly the equivalent of LRBni, and will be built in just as much. Compilers have nothing to do with the hardware implementation. AMD is at no particular disadvantage, neither at the hardware support aspect, nor at the software support aspect.

 

[Nemesis 1]

Ya I took AMD to mean they were leaving the AVX instruction set when they made their last GNC announcement , Readung comprehension fail on my part.

JF said AMD will not be using intels compilers . Its in the locked thread .

Vex prefix contains 3 digit code that eliminates The longer code of preexisting apps . This is were we get A big part of the performance increase+256bit . Those 3digit means nothing to any off us or intel for that matter without INTELS compiler . AMD and INTEL do not share compiler tech period . Thats the part that seems to be fling over everyones head . AMD can scrape AVX or use it . Thats their choice . Its clearly written in intels AVX documents.
I don't know the correct terminology but its like a call .
Lets say your You want to convert an old app. to AVX . With intel You add the Vexprefix . The compiler sees these 3 digit prefix and than converts the apps to AVX . instructions . The VEXprefix isn't magic . Its only used on a recompile . Its a call to the compiler to set a path and shorten the code in the AVX instruction set . VEXprefix requires intels compiler . Vex prefix is used ONLy to recompile not to write new apps . Its for already existing apps.

Is what your saying is that all compilers Know what those 3 digits do . Its code inside of code to shorten code, Its recompile code only. When INTELS compiler reads the prefix the software inside the compiler does the rest .

Don't confuse AVX and the Vex prefix. If your tring to tell me other people compilers can copy intels compilers I find that impossiable to believe . AVX is an instruction set . Vexprefix is code and is used only for a recompile On intels compiler . AMDS XOP or what ever its called is also code But I not sure it strictly a recompile code . No were in AMDs AVX documents have I read the AMDS XOP prefix contains a 3 digit code inside of code . None have shown it . Including JF from AMDs AVX documents .

 

[CPUarchitect]

You simply add the Vex prefix and compiler automaticly recompiles .

Intel does not recompile code like Transmeta did. VEX encoded instructions are directly supported by the hardware, but only for Sandy Bridge and up. After generating the binary code, the compiler is no longer involved. In case of a JIT compiler, it will only generate instructions the hardware actually supports. That means on hardware prior to Sandy Bridge, it simply won't emit AVX instructions. And JIT compilation is not Intel technology.

AVX is not fundamentally different from say SSE2 in this respect. SSE2 added a new prefix to the encoding, and only hardware supporting this new encoding has the execution units to process SSE2 instructions.

VEX encoding consolidates previous SIMD encodings, that's all. It's just an ordinary ISA extension.

 

[Nemesis 1]

It's not up to AMD which compiler is used. That's the software developer's choice. And they've got plenty to choose from: Visual Studio 2010, GCC, LLVM, ICC, etc.

Extending an existing compiler to support AVX is straightforward. The VEX encoding simply compacts the legacy SSE and REX prefixes and adds a few new fields for 256-bit operations and non-destructive operands. It's a pretty clever encoding but not complicated at all to people familiar with legacy x86 encodings.

There is no strict need for AMD to have its own compiler to enable developers to make use of the AVX support in Bulldozer. There are plenty of other compilers. That said, I do expect AMD to update its compiler(s), and there's no reason to assume they'll have any trouble doing so.

AVX2 is nearly the equivalent of LRBni, and will be built in just as much. Compilers have nothing to do with the hardware implementation. AMD is at no particular disadvantage, neither at the hardware support aspect, nor at the software support aspect.

Again I must stress . AMD has every right to use AVX . But the Vexprefix is not AVX its code used for recompile. Intel has clearly documented it . When AVX was announced by Intel . It clearly stated in the documents that the VEXprefix is an INTEL exclusive.

. Here I will fetch something from wiki.

 

[Riek]

Ya I took AMD to mean they were leaving the AVX instruction set when they made their last GNC announcement , Readung comprehension fail on my part.

JF said AMD will not be using intels compilers . Its in the locked thread .

Vex prefix contains 3 digit code that eliminates The longer code of preexisting apps . This is were we get A big part of the performance increase+256bit . Those 3digit means nothing to any off us or intel for that matter without INTELS compiler . AMD and INTEL do not share compiler tech period . Thats the part that seems to be fling over everyones head . AMD can scrape AVX or use it . Thats their choice . Its clearly written in intels AVX documents.
I don't know the correct terminology but its like a call .
Lets say your You want to convert an old app. to AVX . With intel You add the Vexprefix . The compiler sees these 3 digit prefix and than converts the apps to AVX . instructions . The VEXprefix isn't magic . Its only used on a recompile . Its a call to the compiler to set a path and shorten the code in the AVX instruction set . VEXprefix requires intels compiler . Vex prefix is used ONLT to recompile not to write in apps . Its for already existing apps.

Is what your saying is that all compilers Know what those 3 digits do . Its code inside of code to shorten code, Its recompile code only. When INTELS compiler reads the prefix the software inside the compiler does the rest .

So basically its a flag on the compiler that recompiles the code...

Adding a prefix to a bunch of bits won't change a thing for the compiler. (so its just a flag) If that flag is set the compiler will convert some code to AVX. (since SSE is incompatible with AVX this should be expected)

Like you said, the VEX prefix isn't magic. I doesn't do anything! its an identifier of an operation range on the hardware side. Its a bit like a subnetmask.

A compiler doesn't care about all that, it converts bits to another series of bits. Wether you add bits or substract bits at the source code. The conversion tool detects structures and depending on the flags it will convert them to different binary code. This binary code will run on all cpu's that support those operations. Or at least that should be according to the legal actions that were done in that area.

Again I must stress . AMD has every right to use AVX . But the Vexprefix is not AVX its code used for recompile. Intel has clearly documented it . When AVX was announced by Intel . It clearly stated in the documents that the VEXprefix is an INTEL exclusive. . Here I will fetch something from wiki.

Yes the VEX prefix is exclusively intels. That means that only intel can add instructions that use the VEX pool. AMD can only use the operations defined by intel but cannot add their own operation within that reserved field.

 

[jones377]

Here we go again with the VEX obsession!

 

[CPUarchitect]

Vex prefix contains 3 digit code that eliminates The longer code of preexisting apps .

I'm not sure what you're talking about. Please be specific.

Are you perhaps referring to the VEX.pp field (AVX2 manual page 4-5)? That's a 2 bit field, not 3 "digits". These two bits replace the 66h, F3h and F2h byte prefixes. But that doesn't actually shorten the instruction sizes since VEX encoded instructions start with a C5h or C4h prefix instead. It just created space for the new VEX.L and VEX.vvvv fields. Likewise the REX prefix has been consolidated into the 3-byte VEX prefix. It allowed the addition of the VEX.m-mmmm field, but there's no net saving in instruction length. So really all VEX encoding does is move things around to create space for the new fields without making the instructions even longer. Actually note that the legacy SSE encoded instructions take 3 bytes, while as a VEX-128 encoded instruction they take 4 bytes...

VEX encoding is a nice compromise to keep the SIMD instruction encodings compact, but it's no magic.

 

[CPUarchitect]

I don't know the correct terminology but its like a call .
Lets say your You want to convert an old app. to AVX . With intel You add the Vexprefix . The compiler sees these 3 digit prefix and than converts the apps to AVX . instructions . The VEXprefix isn't magic . Its only used on a recompile . Its a call to the compiler to set a path and shorten the code in the AVX instruction set . VEXprefix requires intels compiler . Vex prefix is used ONLy to recompile not to write new apps . Its for already existing apps.

I'm sorry but that's completely wrong. AVX is no different than any previous ISA extension. You need a processor which supports it, and you can use any compiler you prefer to generate the binary code (or even write it manually).

Don't confuse AVX and the Vex prefix. If your tring to tell me other people compilers can copy intels compilers I find that impossiable to believe . AVX is an instruction set . Vexprefix is code and is used only for a recompile On intels compiler .

VEX is a binary encoding format. It is used to encode AVX instructions, FMA3 instructions, FMA4 instructions, XOP instructions, F16C instructions, BMI1 instructions, BMI2 instructions, AVX2 instructions, and any future extension which decides to use VEX encoding.

So AVX and VEX are indeed not the same thing, but the hardware has to be capable of decoding VEX instructions to support AVX. The compiler has nothing to do with the hardware's ability to execute AVX.

 

[Nemesis 1]

OK I conceed because I know little about software . My daughter and wife do . But they both have computer science degrees . I on the other sluffed all the way threw school . Here is an interesting blog I found . It interesting .

Intel announces AVX2 (Haswell) ISA extensions
Intel announced yesterday the new AVX2 ISA extensions that should be introduced with Haswell in 2013. We finally get 256bit integer AVX instructions since AVX1 was limited to FP when it comes to 256bit support.There are other additions like support for FMA(256b/128b but FP only),but main one is 256b integer SIMD support.

AVX2 extends Intel AVX by promoting most of the 128-bit SIMD integer instructions
with 256-bit numeric processing capabilities. AVX2 instructions follow the same
programming model as AVX instructions.
In addition, AVX2 provide enhanced functionalities for broadcast/permute operations
on data elements, vector shift instructions with variable-shift count per data
element, and instructions to fetch non-contiguous data elements from memory.
http://software.intel.com/file/36945



Competitive landscape

AMD,on the other hand ,will be supporting their own XOP(128bit) ISA with Bulldozer Ver1 coming out this summer and with 3 new ISA extensions with Bulldozer Enhanced due out in 2012.There is a chance they will upgrade the XOP ISA to 256bit too.As for AMD's AVX2 support ,by the time Haswell arrives ,AMD should be preparing their NextGen Bulldozer core so this is a solid candidate for AVX2 support.

Since AVX1 is presently done in AMD's Bulldozer core via 2 FMACs working together,it shouldn't be that hard to do the same thing with AVX2,only now the MMX/SSE integer portion(each FMAC has 1 MMX/SSE 128bit unit) will be ganged together to execute one 256bit integer instruction.NextGen Bulldozer should have 256bit capable FMACs (each) ,so doing integer/fp 256bit SIMD will be more efficient and faster. AMD should have an upper hand overall since they support the more powerful Fused Multiply Add ISA(FMA4) that will come even in the first Bulldozer version due out this summer.Haswell will support FMA3 so intel will be playing catchup game in this department. Both designs will have to run recompiled software in order to get the most out of their capabilities(be it FMA or AVX).

In the end,here is a short summary of ISA extensions that will be supported by Bulldozer Ver1 core.Source is here.Haswell should support most of these plus AVX2/FMA3.Intel won't support XOP and FMA4

 

[CPUarchitect]

But the Vexprefix is not AVX its code used for recompile.

It's the other way around. To make use of AVX the developer has to recompile his code, using a compiler which can generate VEX encoded instructions.

 

[Nemesis 1]

Why than is the Vexprefix used to do a simple recompile of SSE2. Also why doesn't Intel AVX have support for XOP. I like that Blog its most interesting . AMD supports Vexprefix and Intel doesn't support XOP. Most strange

From wiki . Which was edit in the prefix of Vex today. Below is AMD XOP

AMD has changed the encoding from the original SSE5 specification in order to improve compatibility with Intel's AVX instruction set and the new VEX coding scheme.

All SSE5 instructions that were equivalent or similar to instructions in the AVX and FMA4 instruction sets announced by Intel have been changed to use the coding proposed by Intel. Integer instructions without equivalents in AVX were classified as the XOP extension.[3] The XOP instructions have an opcode byte 8F (hexadecimal), but otherwise almost identical coding scheme as AVX with the 3-byte VEX prefix.



Commentators[4] have seen this as evidence that Intel has not allowed AMD to use any part of the large VEX coding space. AMD has been forced to use different codes in order to avoid using any code combination that Intel might possibly be using in their development pipeline for something else. The XOP coding scheme is as close to the VEX scheme as technically possible without risking that the AMD codes overlap with any future Intel codes. It must be noted that this inference is speculative, since no public information is available about negotiations between the two companies on this issue.

The use of the 8F byte requires that the m-bits (see VEX coding scheme) have a value bigger than or equal to 8 in order to avoid overlap with existing instructions. The C4 byte used in the VEX scheme has no such restriction. This may prevent the use of the m-bits for other purposes in the future in the XOP scheme, but not in the VEX scheme. Another possible problem is that the pp bits have the value 00 in the XOP scheme, while they have the value 01 in the VEX scheme for instructions that have no legacy equivalent. This may complicate the use of the pp bits for other purposes in the future.

A similar compatibility issue is the difference between the FMA3 and FMA4 instruction sets. Intel initially proposed FMA4 in AVX/FMA specification version 3 to supersede the 3-operand FMA proposed by AMD in SSE5. After AMD adopted FMA4, however, Intel canceled FMA4 support and reverted back to FMA3 in the AVX/FMA specification version 5

 

[CPUarchitect]

Why than is the Vexprefix used to do a simple recompile of SSE2.

The majority of SSE instructions can also be VEX encoded. This allows to use non-destructive operands. This requires software developers to recompile their code to use AVX-128. This code will only execute on processors with AVX support, like Sandy Bridge and Bulldozer. And you don't need Intel's compiler for generating AVX-128 instructions.

Also why doesn't Intel AVX have support for XOP.

Because AVX2 will supersede most of XOP. Intel has also never supported 3DNow!, because SSE was superior.

 

[Nemesis 1]

But what than does XOP have in common with the prefix of Vex . Also Why does SSE2 apps that are to be recompiled use a Vexprefix to do an auto recompile . I have basicly been discussing the Vex prefix . NOT AVX or VEX. If I knew were the locked thread was I do some copy pasting that just doesn't fit what your telling me . I sure not going threw the Intel AVX PDF again been there done that.

But XOP is the intel AVX = to prefix of Vex . Thats has been the debate in the locked thread and this thread. SO what does AMD have that is = to VEX prefix . if it isn't XOP.

 

[Dribble]

IMO, for 99% of the users at $100-150 APU market, an SSD and faster Internet speeds will make a much much much much bigger difference than a faster CPU or GPU compared to Core i3 and Llano.

99% of that segment will not be able to understand the difference of CPU performance between Core i3 and Llano in everyday apps (word, internet, video playing etc etc), but they will definitely understand the performance difference with an SSD and a faster Internet connection.

It will take a few more years until more apps will use the GPU for acceleration and until then, Llanos faster iGPU it mostly serves for Gaming (yes i know up to 720p).

And now that i said 720p, 99% of console games run at or less than 720p

An SSD costs a lot more then the difference between a core i3 and Llano, hence it should have a bigger impact.

As for the *fast enough* argument. I don't want a cpu that's just about *fast enough* today, I want one with some legs that will be *fast enough* in 3 years time as that's how long I expect to keep my laptop.

My current laptop must be pretty close to llano in performance (core 2 @ 2.4, geforce 9500GS graphics), I did put a vertex 2 SSD in it a while back. The cpu is still fast enough, but I do notice it's working a lot harder then it used to 3 years ago - the fan is spinning hard and at least one core of the cpu is often maxed out. I often find myself coming to the laptop after wife/family being using it running everyday apps and closing everything down to get performance back just so I can browse the web smoothly (and so fan shuts up). On my core i5 desktop doesn't matter how much crud is left running it's still barely ticking over.

I certainly wouldn't buy a new laptop unless it had a significantly faster cpu.

 

[CPUarchitect]

But what than does XOP have in common with the prefix of Vex .

Here's an overview of all x86 encoding formats to date: http://sandpile.org/x86/opc_enc.htm

Note at the bottom that XOP is completely identical to VEX3, except for the first byte (8Fh instead of C4h).

Also Why does SSE2 apps that are to be recompiled use a Vexprefix to do an auto recompile .

There is no auto recompile. A software developer has to manually recompile his code to make use of AVX. This can be as simple as enabling a compiler flag. So the developers can let code which previously used SSE, use AVX-128 instead with almost no effort. In this sense upgrading to AVX-128 is 'automatic', but it still produces a new executable, which won't run on processors without AVX support (unless it also includes an SSE fallback path). JIT compilation can perform this compilation at run-time, but again this isn't Intel specific at all.

This is in no way different from previous ISA extensions. Developers can choose between various compilers to generate code for SSE1, SSE2, SSE3, SSSE3, SSE4, etc. simply by changing the compiler settings.

I have basicly been discussing the Vex prefix . NOT AVX or VEX.

There not really a single VEX prefix. There's a 2-byte and 3-byte VEX encoding, followed by an opcode byte and possibly other instruction bytes.

The first byte of VEX2 (C5h) overlaps with the LDS instruction, and the first byte of VEX3 (C4h) overlaps with the LES instrutions. The subsequent bytes ensure there's no actual collision. XOP actually maps to a previously unused opcode group (a 1-byte opcode which is combined with the reg field of the mod R/M byte). The reg field falls within the VEX.m-mmmm field though, so XOP encoding adops all other VEX fields.

It's a game of semantics, but XOP and VEX encoding are the same for all practical purposes. Intel called dibs on VEX while AMD owns the XOP opcode space. That doesn't mean they can't implement each other's instructions. They just can't add any new instructions to the other's opcode space. I think that's quite fair. Neither has any significant advantage over the other. Bulldozer will support AVX and several more extensions, while Haswell will trump it with AVX2, most likely followed by AMD adding support for AVX2 as well and potentially some new instructions in the XOP space, etc...

 

[Nemesis 1]

The majority of SSE instructions can also be VEX encoded. This allows to use non-destructive operands. This requires software developers to recompile their code to use AVX-128. This code will only execute on processors with AVX support, like Sandy Bridge and Bulldozer. And you don't need Intel's compiler for generating AVX-128 instructions.

Because AVX2 will supersede most of XOP. Intel has also never supported 3DNow!, because SSE was superior.

OK . I am following ya. But what about AVX -256 Can that use any compiler? As you seem to go to AVX-128?

 

[Nemesis 1]

Likewise the REX prefix has been consolidated into the 3-byte VEX prefix

I do believe this is my hang up . I understand It can make code longer or shorter. Thats were my confusion is with myself . Surely this makes XOP code longer than Vexprefix as the code is inside the vex prefix that replaces the Rex prefix.

Thanks for taking time for walking me threw this .

Now the part that I quoted . That rexprefix inside the vexprefix . Could a person in the industry call that a computational Slice ?

Also If when recompiled into AVX . Isn't it possiable that with XOP because it has to use the rex prefix that existing apps could become longer than 256b ?


Could this be a correct statement for the Rexprefix inside Vex prefix ?

The entry and exit points of the current working thread are marked, and the portion of the thread that would be split off is separated. The new thread is then fed the appropriate input data that it needs to begin its execution.

 

[CPUarchitect]

OK . I am following ya. But what about AVX -256 Can that use any compiler? As you seem to go to AVX-128?

Certainly. Any advanced compiler (like the ones mentioned above) can generate AVX-256 instructions when it encounters an opportunity to use 256-bit vector operations, and the developer has selected to enable it.

The only reason I mentioned AVX-128 first is because each of the 128-bit SSE instructions has an AVX-128 encoded equivalent. So all of the instances for generating SSE instructions "automatically" apply to generating AVX-128 instructions (but require explicit recompilation). Whether the same source code allows AVX-256 instructions to be selected depends on the algorithm. A lot of code is written in array-of-structures style, while AVX-256 is best suited for structure-of-arrays style code. Thus the developer is often required to put some effort into rewriting the code. The gains from using structure-of-arrays style code can be huge though, and AVX2's gather support will make it a lot easier.

AVX-256 instruction encodings differ by only a single bit from AVX-128. So any compiler supporting AVX-128 most definitely also supports AVX-256. It's up to developers to write code which is suitable for 256-bit processing.

 

[CPUarchitect]

I do believe this is my hang up . I understand It can make code longer or shorter. Thats were my confusion is with myself . Surely this makes XOP code longer than Vexprefix as the code is inside the vex prefix that replaces the Rex prefix.

Look closely at the 'byte encodings' chart again: http://sandpile.org/x86/opc_enc.htm

The W, R, X, and B bits in the VEX2, VEX3, and XOP formats correspond to the REX bits with the same names. The ~ in front of them means they're actually inverted (which is part of the trick to avoid collision with LDS and LES instructions which have the same first byte). So VEX2, VEX3, and XOP include REX information. VEX2 only includes REX.R, so often VEX3 is needed when REX extensions are required (when requiring access to the additional registers in x86-64 mode).

XOP always takes 3 bytes, but that's not much of a problem since we're evolving toward using x86-64 all the time, and XOP instructions aren't going to be used as frequently anyhow. Again remember that Bulldozer supports all of AVX, with VEX2 and VEX3 encodings.

 

[Nemesis 1]

Thanks much for your time and effort . Would you comment on this .Now this is during recompile . Lets say in the case of a jit compiler. Could this be a true statement.

The entry and exit points of the current working thread are marked, and the portion of the thread that would be split off is separated. The new thread is then fed the appropriate input data that it needs to begin its execution.

 

[ch33kym0use]

I doubt they get anywhere near 3D discrete graphics card performance if Intel nowhere near extreme graphics is something to use as reference. The only thing they compete on in terms of graphics is 2D performance for desktop and video. They've been behind discrete graphics card for so long it seems obvious that I can't take them seriously for 3D things unless shown adequate proof, such as products for usage and testing that are fast enough and are reliable enough for serious 3D things.

 

[Idontcare]

An SSD costs a lot more then the difference between a core i3 and Llano, hence it should have a bigger impact.

That's the thing right there.

I just spent $500 on my V3 240GB and yet I only spent a mere $315 on the 2600K.

Even just looking at the cooler, H100, it was $120 compared to the CPU it is cooling.

$200 for the ram.

CPU's are cheap. It's gotten silly, not that I'm complaining.