This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
glibc conditioning
- To: libc-alpha at sources dot redhat dot com
- Subject: glibc conditioning
- From: Jinsong Zhao <zhaojs at cadence dot com>
- Date: Mon, 27 Aug 2001 14:28:30 -0700 (PDT)
- CC: stevew at srware dot com, aj at suse dot de
Andreas Jaeger <aj@suse.de> directed me to report the problem to this
mailing list. I work at Cadence Design Systems. For those people who
don't know us, Cadence is the largest Electronic Design Automation
software vendor, and our tools are used by almost every IC designers.
Lately I ported some codes to Linux (redhat 7.0), hoping to run codes
faster on a cheaper platform. Formal releases of our tools run on
Sun/HP/IBM workstations. Though the code runs much faster on Linux,
the problem is that ... results are entirely different from those we
have on workstations. I found the problem reported in
http://www.srware.com/linux_numerics.txt
is the most relevant. In my case, in gdb I can see that two variables
a and b, both double, are the same up to 16 digits, yet if(a==b) fails
on Linux while on Solaris (compiled under gcc) it succeeds. Then I
would have different sorted order of some data structure. Then it's no
surprise the results are different. The problem is that we use a lot
of legacy codes and debugging those codes is extremely difficult.
What I hope is that Linux community can help to enhance the glibc so
that the "conditioning" can be implemented. Ideally we hope the
floating point results on Linux are the same as those in Solaris. By
the way, I tested some simple codes on FreeBSD, and seems their
results are consistent with Solaris. Is it possible to borrow some
ideas from there?
I was originally a big proponent of porting EDA tools to Linux, 3
years ago. Now we start to see some demand for Linux mainly for Intel
performance. But, please understand that if the conditioning of
floating point operation is not there, there lies this huge hopeless
obstacle for us to make the transition to Linux. Worse yet, this time
the resistance is not from management, the resistance will come from
engineers. Fixing these types of problems is exactly the support we
expect to get from the vendor of any platform which we support.
Thanks for your attention.
Jinsong