On 31 December 2011 01:21, so <s...@so.so> wrote: > On Sat, 31 Dec 2011 03:12:38 +0200, Iain Buclaw <ibuc...@ubuntu.com> wrote: > >> On 31 December 2011 00:48, so <s...@so.so> wrote: >>> >>> On Fri, 30 Dec 2011 20:48:54 +0200, Walter Bright >>> <newshou...@digitalmars.com> wrote: >>> >>>> On 12/30/2011 7:06 AM, so wrote: >>>>> >>>>> >>>>> I agree @inline (which will probably be an extension) in D should mean >>>>> force-inline. >>>>> Ignoring the impossible-to-inline cases (which in time should get >>>>> better), >>>>> adding @inline is a few minutes of editing. >>>>> It will just bypass the cost function and if it is not possible to >>>>> inline, pop >>>>> error. >>>> >>>> >>>> >>>> >>>> Sure, but I think you'll be very disappointed in that it isn't going to >>>> deliver the goods. >>> >>> >>> >>> dmd_inl -O -inline test.d >>> dmd_inl -O -inline test_inl.d >>> time ./test >>> >>> real 0m4.686s >>> user 0m3.516s >>> sys 0m0.007s >>> time ./test_inl >>> >>> real 0m1.900s >>> user 0m1.503s >>> sys 0m0.007s >>> time ./test >>> >> >> *SNIP* >> >> >>> >>> void main() >>> { >>> for(uint i=0; i<1_000_000_000; ++i) >>> test(); >>> } >> >> >> A better compiler would see that the function 'test' has no side >> effects, and it's return value is unused, so elimates the call to it >> completely as dead code. > > > It is just a dummy function that dmd rejected to inline, send me a better > one (which won't use any libraries) and i'll use it :)
Take a pick of any examples posted on this ML. They are far better fit to use as a test bed. Ideally one that does number crunching and can't be easily folded away. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';