You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: <sla...@li...> - 2003-08-27 18:54:14
|
I like your idea -- it is an attractive way to do a parameter fit to things like 1) thread/no-thread 2) decide average loop size 3) control unrolling 4) etc... The old SISAL compiler did the optimizations statically where it would unroll to some degree (under control of a user option) -- a lot like FORTRAN would. I think we should similarly target large loops (Currently uses a static analysis to guestimate the cost of a loop) and then take advantage of functional programming to do X / | \ L0 L1 L2 \ | / \ | / \ | / Y That is, we pick that big loop. Do a sort of fork/join to try the multiple variants, pick one of the results, and continue. We could use this approach to create a feedback to the compiler for the "money" run. We did something like this to gather dynamic loop runtime costs though the mechanism was clunky (each loop had a unique ID that was carried through compilation and expressed in the statistics gatherer, then the dynamic cost was merged in when we made parallel partitioning decisions. Pat |