Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!.POSTED!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Re: Green Compiler ? Date: Mon, 24 Dec 2012 05:16:56 +0100 Organization: Compilers Central Lines: 38 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-12-017@comp.compilers> References: <12-12-010@comp.compilers> <12-12-013@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1356326051 39109 64.57.183.58 (24 Dec 2012 05:14:11 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Mon, 24 Dec 2012 05:14:11 +0000 (UTC) Keywords: code, performance Posted-Date: 24 Dec 2012 00:14:11 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:801 Nils M Holm schrieb: > Abid wrote: >> Do we need to change this model and make it >> three dimensional by adding power axis in the search space? > > In principle, I would say that higher execution speed equals more > grenn-ness. Less time spent dissipating heat means less energy > consumed. Not really. You mean more efficient code, I suppose? > So the question actually is the same as ever: how to we make code > run fast? > > - How do we squeeze more meaning into fewer/faster instructions? Okay, but the available machine instructions are limited. In detail on RISC architectures. > - How do we make code so small that it fits in caches? It's not only the code that has to fit into the caches. Instruction reordering and branch prediction are one thing, but the placement of the data (variables) is quite another story. > - How do we organize code execution in such a way that cache > stalls are minimized? (Locality) Such optimization requires compiler hints, so that the compiler can not only arrange the code, but also the data. This requires knowledge about the *frequency* of subroutine use, branches taken, and variables used in these critical pathes. But who should provide such hints? IMO only a profiling tool can provide that information, when a program is run with typical (real life) data. DoDi