From: Dave (dfisher_at_pophost.com)
Date: 2002-03-01 13:34:02
On Fri, 01 Mar 2002 02:40:42 -0600, Doug Sutherland wrote:
>Hi Dave,
>
>> I have spent this evening trying to resolve the display
>> disparity between Jim-P's binary version and mine
>
>What is the display disparity? Did you try adjusting the
>brightness, this is key, as outlined in Jim's tutorial.
>When I first tried BWView all I saw was darkness, with
>just a bit of grey here and there. From the tutorial:
I have tried all the brightness settings, from b0..b9. The image which is
dislayed is clearly different from the image that is presented when using his
original binary. I sent some screen shots up to my server a few days ago, but
have deleted them. I am now on my way out the door for the day, but will send
some more back up later if nothing else clarifies concerning this issue.
>> I also have both gcc 2.95 and 3.0 installed on my system
>
>Youch.
I know; sometimes I live dangerously. :-)
>According to Jim's instructions, when you build FFTW ...
>
> ./configure --enable-float --enable-i386-hacks
>
> This is required because I use the 32-bit floating
> point version of the library, rather than the
> default 64-bit one.
Now, that I missed. I did enable the i386 hacks during the compilation, but
let the build default to double percision floats. Well, you might have just
targeted the issue. Enabling the hacks did not change the display I was
seeing, which makes sense since they only effect the performance of the
calculations, but leave the correctness of the calculations the same. I wish I
had time this morning to test the theory!
>
>Dave, see this section of the FFTW FAQ:
>http://www.fftw.org/doc/fftw_6.html
>
> By default, FFTW is compiled for double-precision
> transforms. To work in single precision rather than
Yep, and I let it default to that. :-(
>A note for Jim: there is apparently a way to install FFTW
>for BOTH single and double precision on the same machine,
>as long as you don't use both in the SAME program.
I saw that last night, also. I am curious... why would we want both single and
double floating point percision? Are there speed trade-offs? Calculation
accuracies?
> of our own hacks when --enable-i386-hacks is used. The fftw_test
> program outputs speed measurements that you can use to see if
> these hacks are beneficial.
>
>Dave, did you try running the FFTW tests? After installation
>just do make check ...
No, I did not. I will do a couple of test compilations both with gcc 2.95 and
gcc 3.0. I'll post the results later.
>> So... now the favor from both of you. I have uploaded two
>> binaries to my web site (these are Linux-only, folks). Could
>> you run these on your systems and see if your results match
>> the original binary that you, Jim, included in your release?
>
>The binaries will only work if we are on same major kernel
>revision and same glibc version. Jim's binary would not
>run on my system because I'm using Glibc 2.1.3 and Jim is
>using Glibc 2.2. So what kernel and Glibc version are you
>using, and what version of the compiler?
That's why I was able to use Jim's binary then. My kernel is 2.2.19 and Glibc
is 2.2.
>> So I recompiled FFTW so that it created the sharable libraries,
>> and compiled a new BWView binary (bwview-dave-shared-fftw).
>> Notice the size difference.
>
>Good stuff, we should be working on shared libraries.
Note, though, that while a wonderful thing, they can also be difficult if not
managed well. This is a good example of what we are experiencing now, in terms
in incompatibility. It becomes a real issue if a client has one program based
on one set of shared libraries (let's say that the program is not as well
maintained and as up-to-date), and another package that is based on a newer
set. It is not easy to get them to coexist. It can be done using
LD_LIBRARY_PATH, but there are issues surrounding the use of that. I wish I
had more time, but you are probably familiar with all of this.
>> If bwview-dave-shared-fftw works, but bwview-dave-static-fftw
>> does not, then we have identified FFTW as the problem.
>
>I still don't understand what the disparity is. I will try
>your binaries but I'm guessing they will screech to a halt
>due to incompatibilites in libraries.
I'm sorry, I really can't send those screen shots now, or even test the your
feedback concerning the recompilation using single percision floats. The
latter sounds the more likely fix. Thanks, Doug!
Dave.
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST