>> > +/* This function adjusts the unroll factor based on >> > + the hardware capabilities. */ > > I like this patch. > Just a quick question: what hardware characteristics would prefer a > bigger unroll factor—a wider decoder or a larger OoO window?
A larger OoO window allows a core to "unroll more in hardware" so wouldn't typically be factored into that decision. Same with decoding. Usually, the decoder is far ahead anyway. Of course there can be contrived examples where you're actually icache bound or decoder bound but those are IMHO exceptions and getting rid of loop overhead isn't a large factor. One typical case where unrolling helps expose ILP is a loop like for (int i = 0; i < n; i++) a += b[i]; that gets transformed into for (int i = 0; i < n; i += 2) a1 += b[i + 0]; a2 += b[i + 1]; ... So a factor 2x here would correspond to two vector units. With small loop unrolling, things are a bit different and in my experience small loops tend to hit edge cases more frequently. Also, loop overhead is more significant in a small loop, compare and branch alone might make up 1/3 or 1/2 of the loop. -- Regards Robin
