Paul A. Clayton (paaronclayton@gmail.com) on 4/28/12 wrote:
---------------------------
>hcl64 (mario.smarq@gmail.com) on 4/28/12 wrote:
>---------------------------
>>Paul A. Clayton (paaronclayton@gmail.com) on 4/20/12 wrote:
>>---------------------------
>[snip]
>>A 6 wide issue processor for x86 is simply a pipe dream...
>>until there will be ways to considerably break the "strong
>>dependency model" of x86 it will be out of reach.
>
>Support for 6 wide execution is not so much physically
>impractical as economically impractical. x86 is not in a
>performance at any cost market, and most of the code run on
>x86 is not high-ILP code.
>

*I got to wonder if its necessary at all*. Perhaps heavy computational tasks can start to use OpenCL and heterogeneous approaches... it seams a trend, even IBM already has cryptographic/compression engines on die of its z196 chips, HPC is starting to use GPGPU pervasively... and results speak loud;

An illustration
https://amdfusion.activeevents.com/scheduler/catalog.do MM-4172 "" Then we used OpenCL to optimize VLC’s scaling filter, which is used to enlarge or shrink the video on the fly during playback. This OpenCL optimization has achieved speedups of up to *10x* on Llano and *18x* on Trinity compared to a competing CPU.""

one got to wonder about this... i bet some here use that piece of OSS (i do)... and when the arguing "ab noxious" is about which is 20 to 30% better, what to think when the arguing could be orders of magnitude... what the future can bring. What role will be left to the CPU ?

>*It is not clear* what you mean by "strong dependency
>model". A quick google found a use of that by you in
>another forum where you seem to refer to memory
>dependency checking. This is not a particularly x86
>issue. (Yes, with only 16 GPRs x86 will have more
>memory activity, but this is not a huge barrier and having
>fewer GPRs helps in renaming and load-op instructions
>communicate single-use temporaries 'registers'.)
>

All over in the work of Mikko Lipasti
http://www.realworldtech.com/forums/index.cfm?action=detail&id=128868&threadid=128602&roomid=2

>OoO can expose some ILP and wide execution can be useful
>at times after a dependency on a long latency operation is
>resolved (wide execution could also be helpful in branch
>misprediction recovery with few checkpoints); but the
>cost-benefit ratio seems to favor more moderate width.
>
>>4 may be already too much (BD is a false 4 wide issue),
>
>The value of 4 wide depends on design budget and design
>goals. For Intel, high single-thread performance is more
>practical (e.g., higher volume allowing higher absolute
>design costs and more binning) and perhaps more important
>than for AMD, and Intel seems committed to SMT (which
>benefits from 'excessive' width).
>

Yes OoO is here to stay, but one has to wonder what is the future of CPU, what it could be like, besides being a control & access processing element for the heterogeneous crowd.

In that light i don't know if a "wide" u-arch is beneficial for branch, more than a narrower one. Also in that light SMT can be as efficiently implemented in a narrower core, cause is not for heavy computations. Also if memory access will be more important "a run-ahead scheme", that is, continue executing speculatively based on predicted and stored values and addresses, after a L1 or L2 miss(cache miss mitigation), seems better than SMT or spMT and so efficiently done at a narrower core also.

**Yes, now Intel and AMD seam to be definitely trailing different approaches:**

Intel will try to beef even more their cores, perhaps even more SMT ways ( 4x per core), complemented with good HTM support...

AMD seems more on a Decoupled approach (decoupled access execute) where the CPU will be more of a control & access processing element for their *co-processores* : FlexFPUs, GNC CU, CCP(cryptographic), Managed code Fabric engines(java/javascript/HSAIL/possible C#), DRAM I/O engines with IOMMU & DirectGMA(DMA from co-processor to co-processor)...
http://news.ncsu.edu/releases/wmszhougpucpu/

I'm not implying about which is better, to me none is better at all things, not even now... but i'm very curious about AMD approach alright, that is why i inquired about fusing on-the-fly 2 Integer macro-ops into one XOP before

http://www.realworldtech.com/forums/index.cfm?action=detail&id=128834&threadid=128602&roomid=2

really curious if even Integer processing can be done in good extent at a co-processor ( FlexFPU *is* a co-processor).

>Width is also somewhat flexible in meaning given the
>potential to fuse operations, and cascaded ALUs could
>further confuse the matter.
>
>[snip]
>BD was clearly targeting higher frequency (like P4) and
>used a relatively small (especially for AMD) Dcache (like
>P4).

Small Dcache... i think someone already answer that, perhaps they were too cocky about their pre-fetch schemes cleverness.