As far as I can tell, when I comment out the offending lines of code in CheckerTexture the floating point assist faults stop but the performance doesn't really improve, so I guess this particular case isn't really an issue. And James is right about the unaligned accesses, it's from openGL.
Thiago
Solomon Boulos wrote:
if i remember correctly, fisher is running a decently old version of Redhat AS (I think version 3 or so, since the kernel is a 2.4 based kernel from SGI). The actual result of uname -a is as follows:
Linux fisher.sci.utah.edu 2.4.21-sgi230rp03111013_10029 #1 SMP Mon Nov 10 13:25:42 PST 2003 ia64 unknown
On May 16, 2005, at 12:17 PM, Rocky Rhodes wrote:
I don't see these messages on any of the Altix machines I've run manta on
here, so unfortunately I don't think these are at the heart of the
performance problems.
I've also been using the intel compilers, currently the 8.1.030 version,
although I've tried the beta version of the 9.0 compilers with no
performance improvement. I'm about to give gcc a try with the compiler
flags Steve mentioned, as I'm having no luck getting icc to generate decent
code with the loops I've been looking at, like those in Phong::shade (). I
tried it earlier with just "-O2" or something similar and got dreadful
results.
What version of the OS is running on fisher? ("uname -a", for instance)
Rocky
-----Original Message-----
From: owner-manta@sci.utah.edu [mailto:owner-manta@sci.utah.edu] On Behalf
Of Solomon Boulos
Sent: Sunday, May 15, 2005 12:59 PM
To: Thiago Ize
Cc: James Bigler; manta@sci.utah.edu
Subject: Re: [MANTA] unaligned access problem on fisher
I recommend using -ffast-math as part of your compiler flags and
seeing if it goes away ( the fast math versions of the libraries,
will change a few modes for floating point, so if it does happen to
be denormalized numbers this would go away ). If it doesn't go away,
it might be due to things like the reciprocal square root calls, etc
that the compiler might have chosen, but that at run time the
floating point unit realizes won't be able to give an accurate answer
( see Intel Documentation here: http://www.intel.com/design/itanium/
downloads/24541501.pdf ).
To figure out how many of these floating point software assist
exceptions are happening (since like you said the log is throttled),
this guy seems to know how:
http://www.gelato.unsw.edu.au/linux-ia64/0411/11772.html
pfmon is available on fisher, so somebody (not me) should follow the
instructions and see if this is a problem for manta.
Solomon
On May 15, 2005, at 3:05 PM, Thiago Ize wrote:
Every single time I run manta on fisher I get this. Try it
yourself. Connect to fisher, type dmesg and make a note of what the
last thing is so you know what messages you'll be adding to the
list (I already put a ton on there), then just run manta with all
the default options for a couple seconds. Quit, and run dmesg.
I should point out that these messages are throttled so that only 4
or 5 are logged every second. So we could potentially be having
thousands or millions of these happening every second...
Thiago
James Bigler wrote:
Ok, not much we can do about openGL. Incidently, I don't get
those messages when I connect to fisher from my home computer...
Different X server, perhaps?
There is another software trap I noticed though. If you run manta
and then look in dmesg, you'll see it's getting:
manta(13450): floating-point assist fault at ip
4000000000018181, isr 0000020000000008
errors on fisher.
I tried passing -ftz when compilling, but I still get these
messages which means either I did something wrong, it's not
denormalized numbers, or it's in some outside library. Any idea
on these? I read that each software trap costs abouts 1000 instr...
I haven't seen this one before. Can you reproduce it?
James
James Bigler wrote:
This happens with OpenGL. It doesn't affect anything that I can
tell in using the port for over 2 years. Just disregard it.
James
Thiago Ize wrote:
When I run manta on fisher I get the following message:
manta(11958): unaligned access to 0x200000000155c05c,
ip=0x200000000097f0f0
I'm guessing this is causing a performance hit...
I have ccmake using ipcp and icc to compile the code, but
aside from that I believe I'm using the default settings for
everything else. Any ideas why this might be happening?
Thiago
Archive powered by MHonArc 2.6.16.