Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
May 08, 2004 Static loops | ||||
---|---|---|---|---|
| ||||
What about static loops. These would be loops that would be guaranteed to be unrolled (or at least checked/optimised at compile-time). If the compiler can't work out all the specifications at compile time then it would be a compile-time error.
form:
static for (int n=0; n<6; n++)
{
...
}
void func(int size)
{
static for (int n=0; n<size; n++) //Compile time error - "Variable size cannot be determined at compile-time, for a static loop"
{
}
}
The compiler wouldn't necessarily unroll the for-loop. It would just be checked to make sure it can. One use would be for compile-time property deduction that has been discussed recently. Another reason would be to make sure that a particular loop can be optimised.
C/C++ has an unroll pragma. I think this would simply be a stronger (slightly different) version of that.
--
-Anderson: http://badmama.com.au/~anderson/
|
May 08, 2004 Re: Static loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to J Anderson | unrolled loops arent neccessarily faster on todays higly complex pc architectures. I bet a modern pentium would probably cache instructions that were repeatedly executed - so unroll loops would actually be slower. In article <c7hjcc$2hph$1@digitaldaemon.com>, J Anderson says... > >What about static loops. These would be loops that would be guaranteed to be unrolled (or at least checked/optimised at compile-time). If the compiler can't work out all the specifications at compile time then it would be a compile-time error. > >form: >static for (int n=0; n<6; n++) >{ > ... >} > > >void func(int size) >{ > static for (int n=0; n<size; n++) //Compile time error - "Variable >size cannot be determined at compile-time, for a static loop" > { > > } > >} > > >The compiler wouldn't necessarily unroll the for-loop. It would just be checked to make sure it can. One use would be for compile-time property deduction that has been discussed recently. Another reason would be to make sure that a particular loop can be optimised. > >C/C++ has an unroll pragma. I think this would simply be a stronger (slightly different) version of that. > >-- >-Anderson: http://badmama.com.au/~anderson/ |
May 08, 2004 Re: Static loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to imr1984 | imr1984 wrote: >unrolled loops arent neccessarily faster on todays higly complex pc >architectures. I bet a modern pentium would probably cache instructions that >were repeatedly executed - so unroll loops would actually be slower. > > > I'm not necessarily taking about unrolling loops. It's just that loops that can be unrolled can be optimised in other ways at compile time. It would be nice to know that a look remains static. -- -Anderson: http://badmama.com.au/~anderson/ |
May 08, 2004 Re: Static loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to J Anderson | In article <c7hjcc$2hph$1@digitaldaemon.com>, J Anderson says... > >What about static loops. These would be loops that would be guaranteed to be unrolled (or at least checked/optimised at compile-time). If the compiler can't work out all the specifications at compile time then it would be a compile-time error. > >form: >static for (int n=0; n<6; n++) >{ > ... >} I would prefer that the compiler implementation figure out what is best for the target architecture. The less "hints" I have to give to the compiler the better for portability, etc. Let the best compiler writers win. |
May 08, 2004 Re: Static loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mark T | Mark T wrote: >In article <c7hjcc$2hph$1@digitaldaemon.com>, J Anderson says... > > >>What about static loops. These would be loops that would be guaranteed to be unrolled (or at least checked/optimised at compile-time). If the compiler can't work out all the specifications at compile time then it would be a compile-time error. >> >>form: >>static for (int n=0; n<6; n++) >>{ >> ... >>} >> >> > >I would prefer that the compiler implementation figure out what is best for the >target architecture. The less "hints" I have to give to the compiler the better >for portability, etc. Let the best compiler writers win. > > Right probably a bad idea. The reason I brought this up was because Kevin Bealer was bring up a whole new for-loop construct, for an idea I liked (iterating over properties at compile-time). I don't think a new for-loop would be a good idea but if people can't agree that a general for-loop is good enough, I think something in-between would be good. -- -Anderson: http://badmama.com.au/~anderson/ |
Copyright © 1999-2021 by the D Language Foundation