|optimizing compilers for low power design firstname.lastname@example.org (2014-06-15)|
|Re: optimizing compilers for low power design email@example.com (Kaz Kylheku) (2014-06-15)|
|Re: optimizing compilers for low power design firstname.lastname@example.org (Ivan Godard) (2014-06-15)|
|Re: optimizing compilers for low power design Pidgeot18@verizon.com.invalid (2014-06-15)|
|Re: optimizing compilers for low power design derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2014-06-16)|
|Re: optimizing compilers for low power design email@example.com (Walter Banks) (2014-06-16)|
|Re: optimizing compilers for low power design firstname.lastname@example.org (George Neuner) (2014-06-18)|
|Re: optimizing compilers for low power design email@example.com (2014-06-20)|
|Re: optimizing compilers for low power design firstname.lastname@example.org (glen herrmannsfeldt) (2014-06-20)|
|Re: optimizing compilers for low power design email@example.com (Ivan Godard) (2014-06-20)|
|[2 later articles]|
|Date:||Sun, 15 Jun 2014 18:58:36 -0500|
|Organization:||A noiseless patient Spider|
|Posted-Date:||15 Jun 2014 20:11:43 EDT|
On 6/15/2014 10:43 AM, Kaz Kylheku wrote:
> On 2014-06-15, firstname.lastname@example.org <email@example.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 , "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
Return to the
Search the comp.compilers archives again.