Hi Minh, that looks perfect. Thanks for the hard work!
If we end up with too much data horizontally, we can just omit the ram and #cores, as these are not relevant for MPIR. One slight issue is that we need to stop the processes running on skynet before tuning, as tuning is critically dependent on the machines not being heavily loaded. It can take up to 0.5 hours for the processes to actually stop once you put the flags in /tmp. Also, we'll end up with the same architectures (from MPIR's point of view) multiple times. The tuning values only need to be changed once per architecture. However, it might be interesting to take an average of tuning values where there is more than one machine with the same arch. Bill. On 12 May 2010 18:48, Minh Nguyen <[email protected]> wrote: > Hi Bill, > > On Thu, May 13, 2010 at 3:32 AM, Bill Hart <[email protected]> > wrote: >> Can we add another column to the wiki page for the build and tune results: >> >> Can we show the architecture as printed by config.guess, e.g. k8 or >> nehalem or core2 or penryn, etc. > > I have added a set of tables for revision 2927, with the above table > headers. Please check it out and tell me whether or not the new > columns are what you wanted. > > -- > Regards > Minh Van Nguyen > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
