? (0xe2.0x9a.0x9b@gmail.com) on 8/16/09 wrote:
---------------------------
>Euronymous (euronymous@realworldtech.com) on 8/15/09 wrote:
>---------------------------
>>Those IPC figures are from the ASPLOS paper by David Wall, on the Limits of Instruction-Level
>>Parallelism. Also available as a DEC WRL research report:
>>http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-93-6.pdf
>>
>>Euronymous
>
>So, the theoretical limit of instruction-level parallelism is nowhere 2000. Figure 18 on page 21:
>- gcc: ILP=60
>- compress: ILP=25
>
>I wonder whether there exists a report approaching [the problem of how to speed
>up program execution] from a completely different angle: how much computation in
>a program (gcc, compress, etc) is redundant.
>
>In other words, when talking about ILP it is in my opinion absolutely crucial to
>have at least a faint idea about how many instructions are redundant (read: how
>many of the executed instructions are pointless). See, the amount of ILP by itself
>does *not* convey objective knowledge about parallelism in a program. For example,
>I could easily modify GCC by incorporating a physics simulation greatly contributing
>to ILP but having no real effect on the results produced by GCC.
>
>The results published in the report silently assume that real-world programs such
>as 'gcc', 'compress', etc have been well optimized over their lifetime, so the amount
>of redundancy is "relatively low". So, the question is: is there a scientific article
>which challenges such an assumption? If so, how does removing redundant computation affect ILP?

Of course this report is also based on perfect execution of *EXISTING* code, ie: code that was never written to take advantage of such an (impossible) cpu - to counter your point that it would be easy to artificially increase the apparent ILP, I would suggest that it would also be possible (I make no comment on the ease) given enough resource to write the programs differently to usefully consume more ILP - compilers and especially execution analysis are quite poor at creating suitable algorithms.

A good example is SSE code, which is written to take advantage directly of a (small amount) of explicit ILP in effect - which should give a higher 'reading' than older (and usually simpler) non SSE codes (I am talking about quite specific highly SSE optimised code here, such as video codecs and audio processors, for example).

There is a strange new world out there in high-ILP codes, and we are only just starting to dabble in it. Like explicit vectors is can work great for some applications, and not at all for others.