In case more granularity is required , then we need more configure options for each case. Perhaps this is better achieved by just letting tune have these options and it can adjust the threshold to exclude/include any particular algorithm.Any embedded cpu would almost certainly not use default value even if only for memory constraints.
On Tuesday 27 September 2011 22:18:46 Jason wrote: > Yeah , perhaps then the name should change to --enable-small-footprint and > also disable subquadratic gcd and other "large" algorithms > > On Tuesday 27 September 2011 21:57:57 Bill Hart wrote: > > I believe this is done mainly on embedded devices, e.g. ARM devices > > with small memory. > > > > On 27 September 2011 21:19, Jason <ja...@njkfrudils.plus.com> wrote: > > > Hi > > > > > > I'm consdiering removing the above option , in almost all cases(I > > > think) the main effect will be to reduce the executible size only , as > > > if it is never used in execution then the fft code won't pollute the > > > proccessor caches. > > > > > > What do you think? > > > > > > Thanks > > > Jason > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "mpir-devel" group. To post to this group, send email to > > > mpir-devel@googlegroups.com. To unsubscribe from this group, send email > > > to mpir-devel+unsubscr...@googlegroups.com. For more options, visit > > > this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
