Related articles |
---|
Static analysis of code for "flop counting"? fouts@orville (1987-04-17) |
Re: Static analysis of code for "flop counting"? allegra!utzoo!henry (1987-04-22) |
Re: Static analysis of code for "flop counting"? think!ames!ucbcad!ucbvax!decwrl!mips!sjc (1987-04-23) |
Re: Static analysis of code for "flop counting"? harvard!seismo!watmath!orchid!atbowler (Alan T. Bowler [SDG]) (1987-04-26) |
Re: Static analysis of code for "flop counting"? eugene@ames-pioneer.arpa (Eugene Miya N.) (1987-05-06) |
Re: Static analysis of code for "flop counting"? eugene@ames-pioneer.arpa (Eugene Miya N.) (1987-05-06) |
Re: Static analysis of code for "flop counting"? allegra!utzoo!henry (1987-05-13) |
Date: | Wed, 13 May 87 04:11:20 EDT |
From: | allegra!utzoo!henry |
References: | <1299@ames.UUCP>, <565@ima.UUCP> |
> >[You can run your assembler through a preprocessor that puts counting code
> > before each float operations.]
> >This gets you fast, accurate counts without compiler cooperation.
>
> Bullshit.
>
> It's very intrusive (typically around 10%). This is enough to totally
> wreck measurement on all and worse: synchronization on parallel codes...
Easy on the "bullshit", Eugene. The original article wasn't *asking*
about timings, or about synchronization of parallel codes: it wanted
instruction counts. This technique will give you accurate instruction
counts without cooperation from the compiler or the hardware. And it is
decidedly fast compared to the alternatives, like interpreting the code.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
[Eugene's and Henry's points both being well taken, I'm closing this
discussion unless there are new ideas about instruction counting. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.