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: Newsgroups: comp.compilers Subject: Re: optimizing compilers for low power design Date: Sun, 15 Jun 2014 18:58:36 -0500 Organization: A noiseless patient Spider Lines: 53 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-06-007@comp.compilers> References: <14-06-003@comp.compilers> <14-06-004@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: miucha.iecc.com 1402877504 98461 2001:470:1f07:1126:0:676f:7373:6970 (16 Jun 2014 00:11:44 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Mon, 16 Jun 2014 00:11:44 +0000 (UTC) Keywords: optimize, architecture Posted-Date: 15 Jun 2014 20:11:43 EDT 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:1262 On 6/15/2014 10:43 AM, Kaz Kylheku wrote: > On 2014-06-15, idatarm@gmail.com wrote: >> Abstract: We describe an algorithm for optimizing compilers for low >> power design. The algorithm can be applied to almost any c compiler >> and in particular we target gcc compiler. The algorithm works by >> modifying optimization table lookup of gcc. This works in theory. We > > Instructions do not have a fixed power cost which can be measured by > repeating a long run of that instruction and then dividing. > It depends on their operands, and the complex state of the CPU (what > other instructions are in the pipeline before and after, caching, etc). > This approach might work on a very old processor, on which every instruction > had a predictable instruction count. I see it as plausible that different functional units can take usefully different power to compute (i.e., using x86 SSE instructions versus the x87 instruction set, or using vectorized versus non-vectorized instructions). Even then, though, I consider it only an a priori plausible event--you'd need to provide experimental evidence that it actually occurs in practice before continuing. > Percentages do not add. Were that the only serious error of this paper. The percentages themselves seem to be literally conjured out of thin air. > Your paper's reference [1], "A Guide to LaTeX" is inappropriate to your > topic and suggests that you're trying to inflate your reference section. If > you're going to do this this, bury the questionable reference in the > middle of the list; do not begin the list with one. The other 4 references are equally irrelevant. Two of them are self-citations of earlier work on what appears to be waveform pattern generation for electrical circuits and the other two may be culled from the references of those problems. In contrast, a typical PL paper would contain a page of references or more. > You have a typographical problem. The grammatical mistakes in the paper reached the threshold of "actively distracting" for me. Curious, I decided to see what other papers might be found, given that the URL contains a papers folder. ... Unfortunately, this appears to be the most logically cohesive paper of the lot. The more I read, the more I got the feeling that the author is very much outside of his capabilities in this line of work. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth