Re: config/xconfig problems (was Re: [Math-atlas-devel] Any advice on IRIX dynamic linking?)
Brought to you by:
rwhaley,
tonyc040457
From: <rw...@cs...> - 2004-12-02 22:33:47
|
Allen, >Sigh... unfortunately, pretty much all of them are needed, as far as I can >tell (it's possible that I could get along without the -LNO:opt=1 part - it >should be defaulting to doing the loop nest optimization). For instance, >telling the compiler that the platform is IP30 does _not_ indicate whether >the processor is r10000 or r12000 (and config.c currently makes some >assumptions in regard to IP## telling the processor that are incorrect, BTW, >at least with regard to setting cache sizes et al) and optimal scheduling >differs. As another instance, -O3 does change things with how accurate >(and/or IEEE compliant) the math is, and some of these changes are >undesirable when repeated FP operations with consequent cumulative roundoff >are likely. OK, I haven't scoped an SGI box in a couple of years, other than to make sure it still installs on old machines. I don't have access to any SGI machines these days, and I must admit I kind of lost interest in the platform once they made the astoundingly stupid announcement they were killing off their own successful platform in favor of the unproven IA64. I'm pretty sure I thought that the IPXX ID was unique; I'm alarmed to see that it doesn't seem to mean much. What, precisely, does it mean? The flags ATLAS uses where carefully chosen 5 years ago or so, and they achieved the best performance then. I have no idea these days, and I was not aware of any IEEE violations . . . >Incidentally, speaking of flags, is loop nest optimization desirable for >MCC/MMFLAGS or not? I had thought at first not - ATLAS is doing testing of >various degrees of unrolling itself - but have been noticing some >code comments that seemed to indicate otherwise. Like I said, back in the day, I tried pretty much all flags, and those gave the best performance. >Also speaking of loop nest optimization, I note in tune/sysinfo/masearch.c: > >that tune/sysinfo/masearch.c notes that: >This would seem to be solvable by compiling muladd.c without loop nest >optimization. I shudder to think about adding yet a third compilation >variant, MCC/MMFLAGS without loop nest optimization vs MCC/MMFLAGS with loop >nest optimization, but this would probably be helpful... and it does occur >to me that as well as adaptive code generation and trying out different >prewritten code sections, it would probably be helpful for ATLAS's install >to do a check of "should this be compiled with CC/CFLAGS vs MCC/MMFLAGS (vs >?)". The existing mechanism for replacing MCC/MMFLAGS in the usergemm et al >compilations is going in this direction to some degree, but currently lacks >a facility for "use part of the existing MCC/MMFLAGS" - admittedly, string >manipulation is a headache in C... This probe has been crippled for years due to compiler bugs (primarily, one which hung gcc). I might be able to uncripple it, but I'm not sure. In the old days, I tried a bunch of manual unrollings . . . >It's the reverse in most cases that I've seen for IRIX. (The problem you may >be thinking of is that the various ATLAS makefiles often assume that one >does not need quote marks around the compiler name; I've fixed this.) Hmm . . . OK. I kind of liked having flags in flags most of the time . . . I was indeed speaking of the atlas makefiles. >for IRIX, to see whether a program can be complied & linked by a gcc in the >user's path. The test program itself is also useful (either with cc or gcc) >as a more portable way of telling the number of processors, at least if the >sysconf function is working. (Speaking of sysconf, would it be useful for >ATL_mvpagesize in tune/blas/gemv/emit_head.c to be set to >ATL_DivBySize([system memory page size]) instead of always being >ATL_DivBySize(4096)? On 64-bit IRIX systems, the default page size is 16384, >and one can actually use even larger pages if the kernel and program >(-bigp_on) are set up for them - something that I might try doing on the >system here with the largest memory/nproc ratio.) I'm not sure this is used anymore . . . >Did you get my message regarding suggestions on where you could check >on available professorships? We were having mail problems around then, so >I'm not sure if it ever got out of here. Got it, thanks! Clint |