Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end From: Peter Dassow Newsgroups: comp.compilers Subject: Re: Green Compiler ? Date: Wed, 26 Dec 2012 19:31:53 +0100 Organization: Arcor Lines: 29 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-12-022@comp.compilers> References: <12-12-010@comp.compilers> <12-12-012@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1356662002 3613 64.57.183.58 (28 Dec 2012 02:33:22 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Fri, 28 Dec 2012 02:33:22 +0000 (UTC) Keywords: performance, optimize Posted-Date: 27 Dec 2012 21:33:22 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:806 On 23.12.2012 09:18, glen herrmannsfeldt wrote: > Abid wrote: > >> It seems that the Power Wall is becoming a major issue, especially for High >> Performance Computing. Current compilers work has two dimensional model, i.e., >> all the optimization phases are targeted either towards reducing execution >> time or code size. My question is: Do we need to change this model and make it >> three dimensional by adding power axis in the search space? If yes, then we >> have to revisit all the phases and adjust them or come up with new cost >> models for these phases. > > It should be energy, not power. You can always reduce the power by > doing the calculation slower. Energy is power times time (more > generally, the integral of E(t)dt). Efficiency is NOT equal to power consumption. You can do calculations (e.g. divide something) in more than one way, means by using the "fastest" operations, or by using the "best" algorithm, means using the most efficient opcodes (that is NOT using the fastest operations, e.g. shifting/rotating bits), e.g. using a DIVIDE opcode instead which can probably cost more clock cycles. That does not mean just to make it slow, you should still choose the most efficient way (means doing something with fewer opcodes, regardless of how many clock cycles are used for per opcode). But I'm not sure this kind of optimization would save a significant percentage compared to an clock cycle optimized binary. Regards Peter