Re: duff's device / loop unriolling
- From: mwojcik@xxxxxxxxxxx (Michael Wojcik)
- Date: 20 Aug 2005 18:43:28 GMT
In article <0001HW.BF2BCBB9008348F7F0386550@xxxxxxxxxxxxxxxx>, Randy Howard <randyhoward@xxxxxxxxxxxxxxxxx> writes:
>
> It's suddenly being discussed again, probably as a result of an
> article in DDJ (Doctor Dobb's Journal) about it in the August
> issue. Ralf Holly proposed using it in macro form for generic
> loop unrolling, which probably makes people misunderstand its
> original purpose.
>
> He proposed something like
[Tabs converted to spaces to avoid wrapping.]
> #define DUFF_DEVICE_8(macroCount, macroAction) \
> do { \
> size_t duffcount = (macroCount); \
> size_t dufftimes = (duffcount + 7) >>3u; \
> switch(duffcount & 7) { \
> case 0: do { macroAction; \
> case 7: macroAction; \
> case 6: macroAction; \
> case 5: macroAction; \
> case 4: macroAction; \
> case 3: macroAction; \
> case 2: macroAction; \
> case 1: macroAction; \
> } while (--dufftimes > 0); \
> } \
> } while (0)
>
> Of course, the caller has to know not to call with a 0
> countvalue or it will execute 8 times instead.
Unless I'm missing something, that's easily fixed with a
if (!duffcount) break;
before the switch. (Testing duffcount avoids using macroCount,
which might have side effects, twice, of course.)
A worse problem would be using it with a negative count; hopefully
the compiler would provide a useful diagnostic for the conversion
between a signed value and a size_t when duffcount is initialized,
but that's a QoI issue. (Also, I know far too many C programmers
who routinely ignore such diagnostics, partly because their code is
full of them. I suppose that's a QoP issue.)
> Probably not all that practical in general use, but you might
> find somewhere, (after profiling) where it makes some sense.
Agreed. I have found cases where relatively recent commercial
implementations don't unroll even simple loops where unrolling has a
significant benefit. Of course, if the loop isn't in a performance-
critical path, it doesn't matter anyway.
--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx
We are subdued to what we work in. (E M Forster)
.
- Follow-Ups:
- Re: duff's device / loop unriolling
- From: Tim Rentsch
- Re: duff's device / loop unriolling
- From: Randy Howard
- Re: duff's device / loop unriolling
- References:
- duff's device / loop unriolling
- From: Jan Richter
- Re: duff's device / loop unriolling
- From: Christian Bau
- Re: duff's device / loop unriolling
- From: Randy Howard
- duff's device / loop unriolling
- Prev by Date: Re: multiple file programs in c
- Next by Date: Re: A question on string literals
- Previous by thread: Re: duff's device / loop unriolling
- Next by thread: Re: duff's device / loop unriolling
- Index(es):
Relevant Pages
|