From hgk at ll.mit.edu Mon Oct 1 19:40:32 2007 From: hgk at ll.mit.edu (Hahn Kim) Date: Mon, 1 Oct 2007 15:40:32 -0400 Subject: VSIPL++ and OpenMPI Message-ID: Hi, I know you support LAM/MPI and MPICH/MPICH2, but do you support OpenMPI? I've seen OpenMPI referenced in some of the patches sent to this mailing list, but your Quickstart documentation doesn't have any reference to it. Thanks. Hahn -- Hahn Kim MIT Lincoln Laboratory Phone: (781) 981-0940 244 Wood Street, S2-252 Fax: (781) 981-5255 Lexington, MA 02420 E-mail: hgk at ll.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgk at ll.mit.edu Mon Oct 1 19:45:44 2007 From: hgk at ll.mit.edu (Hahn Kim) Date: Mon, 1 Oct 2007 15:45:44 -0400 Subject: Indexing information Message-ID: <5947A521-31E3-404B-AFEF-ABA04E0E6ADE@ll.mit.edu> Hello, Another question: is there a way to grab lower-level index information beyond functions like global_from_local_index or Domains, e.g. something closer to PITFALLS? I'm guessing any information like that is probably implementation-specific and not addressed in the VSIPL++ spec, right? Thanks. Hahn -- Hahn Kim MIT Lincoln Laboratory Phone: (781) 981-0940 244 Wood Street, S2-252 Fax: (781) 981-5255 Lexington, MA 02420 E-mail: hgk at ll.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at codesourcery.com Mon Oct 1 19:48:33 2007 From: stefan at codesourcery.com (Stefan Seefeld) Date: Mon, 01 Oct 2007 15:48:33 -0400 Subject: [vsipl++] VSIPL++ and OpenMPI In-Reply-To: References: Message-ID: <47014F11.8020801@codesourcery.com> Hahn Kim wrote: > Hi, > > I know you support LAM/MPI and MPICH/MPICH2, but do you support > OpenMPI? I've seen OpenMPI referenced in some of the patches sent to > this mailing list, but your Quickstart documentation doesn't have any > reference to it. Thanks. Yes, we do support open-mpi (use --enable-mpi=openmpi to trigger it). I believe this has been added after the last official release (1.3), which may explain why the online docs do not reflect this feature yet. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Mon Oct 1 20:17:50 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Mon, 01 Oct 2007 16:17:50 -0400 Subject: [vsipl++] Indexing information In-Reply-To: <5947A521-31E3-404B-AFEF-ABA04E0E6ADE@ll.mit.edu> References: <5947A521-31E3-404B-AFEF-ABA04E0E6ADE@ll.mit.edu> Message-ID: <470155EE.6030209@codesourcery.com> Hahn Kim wrote: > Hello, > > Another question: is there a way to grab lower-level index information > beyond functions like global_from_local_index or Domains, e.g. something > closer to PITFALLS? I'm guessing any information like that is probably > implementation-specific and not addressed in the VSIPL++ spec, right? > Thanks. Hahn, I'm afraid not. Is there particular information that you had in mind? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From hgk at ll.mit.edu Mon Oct 1 21:40:43 2007 From: hgk at ll.mit.edu (Hahn Kim) Date: Mon, 1 Oct 2007 17:40:43 -0400 Subject: [vsipl++] Indexing information In-Reply-To: <470155EE.6030209@codesourcery.com> References: <5947A521-31E3-404B-AFEF-ABA04E0E6ADE@ll.mit.edu> <470155EE.6030209@codesourcery.com> Message-ID: <9813DF52-D7C4-4BCC-9197-52FC396B9B1B@ll.mit.edu> I was basically hoping to get PITFALLS-like information so I could do extra index partitioning computations on my own, but I think I can do it by extracting that information from global_from_local_index and Domains, then constructing my own PITFALLS-like structure. It'll be a bit inefficient, but should suffice for our needs. Even if I could reach down and grab that information from with VSIPL+ +, I want to make sure my stuff is implementation-agnostic, so using the VSIPL++ API is probably the best route. But I figured I'd ask anyway. :) Hahn On Oct 1, 2007, at 4:17 PM, Jules Bergmann wrote: > Hahn Kim wrote: >> Hello, >> Another question: is there a way to grab lower-level index >> information beyond functions like global_from_local_index or >> Domains, e.g. something closer to PITFALLS? I'm guessing any >> information like that is probably implementation-specific and not >> addressed in the VSIPL++ spec, right? Thanks. > > Hahn, I'm afraid not. Is there particular information that you > had in mind? -- Jules > > > -- > Jules Bergmann > CodeSourcery > jules at codesourcery.com > (650) 331-3385 x705 > -- Hahn Kim MIT Lincoln Laboratory Phone: (781) 981-0940 244 Wood Street, S2-252 Fax: (781) 981-5255 Lexington, MA 02420 E-mail: hgk at ll.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgk at ll.mit.edu Mon Oct 1 21:41:02 2007 From: hgk at ll.mit.edu (Hahn Kim) Date: Mon, 1 Oct 2007 17:41:02 -0400 Subject: [vsipl++] VSIPL++ and OpenMPI In-Reply-To: <47014F11.8020801@codesourcery.com> References: <47014F11.8020801@codesourcery.com> Message-ID: <2D9C7515-F1B6-4DDC-9142-2CDAFD422585@ll.mit.edu> Thanks! On Oct 1, 2007, at 3:48 PM, Stefan Seefeld wrote: > Hahn Kim wrote: >> Hi, >> >> I know you support LAM/MPI and MPICH/MPICH2, but do you support >> OpenMPI? I've seen OpenMPI referenced in some of the patches sent to >> this mailing list, but your Quickstart documentation doesn't have any >> reference to it. Thanks. > > Yes, we do support open-mpi (use --enable-mpi=openmpi to trigger it). > I believe this has been added after the last official release (1.3), > which may explain why the online docs do not reflect this feature yet. > > Thanks, > Stefan > > -- > Stefan Seefeld > CodeSourcery > stefan at codesourcery.com > (650) 331-3385 x718 > -- Hahn Kim MIT Lincoln Laboratory Phone: (781) 981-0940 244 Wood Street, S2-252 Fax: (781) 981-5255 Lexington, MA 02420 E-mail: hgk at ll.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgk at ll.mit.edu Thu Oct 4 20:13:14 2007 From: hgk at ll.mit.edu (Hahn Kim) Date: Thu, 4 Oct 2007 16:13:14 -0400 Subject: Compiling VSIPL++ on Cell PPE Message-ID: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> Hello, I'm trying to build VSIPL++ 1.3 for the Cell PPE on a Playstation 3 (I know about the Cell version of VSIPL++ but I just want to use the release version for various reasons). I specify that I want to use Mercury SAL and even disable ATLAS, but configure is still trying to configuration ATLAS. I'm including the configure command (excluding some path information) and its output. Can you tell me why it's trying to configure ATLAS when I try to disable it? Any information is appreciated. Thanks! > ./configure --prefix=/sourceryvsipl++-1.3- mpich2-1.0.6-sal --with-mpi-prefix=/ mpich2-1.0.6 CXXFLAGS="-O2 -DMPICH_IGNORE_CXX_SEEK" --with-sal- include=/opt/MultiCorePlus/include --with-sal-lib=/opt/MultiCorePlus/ lib --enable-fft=sal --disable-builtin-atlas checking build system type... powerpc64-unknown-linux-gnu checking host system type... powerpc64-unknown-linux-gnu checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... f95 checking whether we are using the GNU Fortran 77 compiler... yes checking whether f95 accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for short... yes checking size of short... 2 checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking for long long... yes checking size of long long... 8 checking for FORTRAN float return type... float. checking for bugs in g++ and its runtime... no bugs found checking for compatible std::complex types.... yes checking for std::abs(float), std::abs(double), and std::abs(long double).... yes checking if complex supported.... yes checking whether exp10 is declared... yes checking whether exp10f is declared... yes checking whether exp10l is declared... yes checking for acosh... yes checking for hypotf... yes checking whether hypotf is declared... yes checking for malloc.h... yes checking for posix_memalign... yes checking for memalign... yes checking whether posix_memalign is declared... yes checking whether memalign is declared... yes checking for png.h... yes checking for mpi.h... yes checking whether MPICH_NAME is declared... yes checking for MPI build instructions... found checking for sal.h... yes checking for library containing vaddx... -lcsal checking for std::complex-compatible SAL-types.... yes checking for g2c none... not found checking for g2c lopt... not found libg2c not found. with_lapack: probe Searching for LAPACK packages: atlas generic1 generic2 builtin checking for LAPACK/ATLAS library... skipping (g2c needed but not found) checking for LAPACK/Generic library (w/o blas)... not found checking for LAPACK/Generic library (w/blas)... not found checking for built-in ATLAS/C-LAPACK library... found =============================================================== ATLAS: CC gcc ATLAS: F77 f95 ATLAS: CFLAGS -g -O2 checking build system type... powerpc64-unknown-linux-gnu checking host system type... powerpc64-unknown-linux-gnu checking for powerpc64-unknown-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for machine type... linux arch ppc unknown checking for asm style... GAS_LINUX_PPC checking for AltiVec ISA... SUCCESS FOUND. ARCH: Linux_unknownAltiVec checking for L2 cache size... L2 Cache size: 0 checking C compiler family... GCC checking mach/compiler specific flags... none checking for architectural defaults (CONFIG/ARCHS/ unknownAltiVec.tgz)... DIR ../.././vendor/atlas/CONFIG/ARCHS/ unknownAltiVec.tgz configure: error: NOT FOUND. =============================================================== configure: error: built-in ATLAS configure FAILED. -- Hahn Kim MIT Lincoln Laboratory Phone: (781) 981-0940 244 Wood Street, S2-252 Fax: (781) 981-5255 Lexington, MA 02420 E-mail: hgk at ll.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From don at codesourcery.com Thu Oct 4 20:27:07 2007 From: don at codesourcery.com (Don McCoy) Date: Thu, 04 Oct 2007 14:27:07 -0600 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> Message-ID: <47054C9B.6080906@codesourcery.com> Hahn Kim wrote: > > Can you tell me why it's trying to configure ATLAS when I try to > disable it? Any information is appreciated. Thanks! > > > ./configure > --prefix=/sourceryvsipl++-1.3-mpich2-1.0.6-sal > --with-mpi-prefix=/mpich2-1.0.6 CXXFLAGS="-O2 > -DMPICH_IGNORE_CXX_SEEK" --with-sal-include=/opt/MultiCorePlus/include > --with-sal-lib=/opt/MultiCorePlus/lib --enable-fft=sal > --disable-builtin-atlas I find this somewhat confusing myself and usually have to look it up each time. I looked in a current tree, but I believe this is true for 1.3 also: use --with-lapack=no or --with-lapack=simple-builtin for a lapack that doesn't need atlas. Please let me know if this doesn't work. Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 From jules at codesourcery.com Fri Oct 5 14:31:51 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 05 Oct 2007 10:31:51 -0400 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <47054C9B.6080906@codesourcery.com> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> Message-ID: <47064AD7.8090202@codesourcery.com> Don McCoy wrote: > Hahn Kim wrote: >> >> Can you tell me why it's trying to configure ATLAS when I try to >> disable it? Any information is appreciated. Thanks! >> >> > ./configure >> --prefix=/sourceryvsipl++-1.3-mpich2-1.0.6-sal >> --with-mpi-prefix=/mpich2-1.0.6 CXXFLAGS="-O2 >> -DMPICH_IGNORE_CXX_SEEK" --with-sal-include=/opt/MultiCorePlus/include >> --with-sal-lib=/opt/MultiCorePlus/lib --enable-fft=sal >> --disable-builtin-atlas > I find this somewhat confusing myself and usually have to look it up > each time. I looked in a current tree, but I believe this is true for > 1.3 also: use --with-lapack=no or --with-lapack=simple-builtin for a > lapack that doesn't need atlas. FWIW, this looks like a quickstart documentation bug. It mentions --disable-builtin-atlas, but does not mention --with-lapack=no. configure --help appears to get it right. Don, can you fix the quickstart? thanks, -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From hgk at ll.mit.edu Tue Oct 9 15:31:00 2007 From: hgk at ll.mit.edu (Hahn Kim) Date: Tue, 9 Oct 2007 11:31:00 -0400 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <47064AD7.8090202@codesourcery.com> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> Message-ID: <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> Thanks for the feedback, configure now completes without error, but now I'm encountering problems with make. When I add --with-lapack=no, configure completes: > ./configure --prefix=/sourceryvsipl++-1.3- mpich2-1.0.6-sal --with-mpi-prefix=/ mpich2-1.0.6 CXXFLAGS="-O2 -DMPICH_IGNORE_CXX_SEEK" --with-sal- include=/opt/MultiCorePlus/include --with-sal-lib=/opt/MultiCorePlus/ lib --enable-fft=sal --disable-builtin-atlas --with-lapack=no When I run make, I get the following error: ... g++ -c -I src -I ./src -I/data/PVTOL/vendor/ppc64/ Linux-2.6.22-0.ydl.rc4/mpich2-1.0.6/include -DVSIP_IMPL_MPI_H_TYPE=1 - I/data/PVTOL/vendor/ppc64/Linux-2.6.22-0.ydl.rc4/mpich2-1.0.6/ include -O2 -DMPICH_IGNORE_CXX_SEEK -I/data/PVTOL/ vendor/ppc64/Linux-2.6.22-0.ydl.rc4/mpich2-1.0.6/include - DVSIP_IMPL_PAR_SERVICE=1 -I/opt/MultiCorePlus/include - DVSIP_IMPL_HAVE_SAL=1 -DVSIP_IMPL_SAL_FFT=1 - DVSIP_IMPL_FFT_USE_FLOAT=1 -DVSIP_IMPL_FFT_USE_DOUBLE=1 - DVSIP_IMPL_FFT_USE_LONG_DOUBLE=1 -DVSIP_IMPL_PROVIDE_FFT_FLOAT=1 - DVSIP_IMPL_PROVIDE_FFT_DOUBLE=1 -DVSIP_IMPL_PROVIDE_FFT_LONG_DOUBLE=0 -O2 -DMPICH_IGNORE_CXX_SEEK -I./src -o src/vsip/initfin.o src/vsip/ initfin.cpp src/vsip/opt/sal/elementwise.hpp: In function ?void vsip::impl::sal::vconv(const vsip::impl::sal::Sal_vector&, const vsip::impl::sal::Sal_vector&, vsip::length_type)?: src/vsip/opt/sal/elementwise.hpp:249: error: invalid conversion from ?char* const? to ?signed char*? src/vsip/opt/sal/elementwise.hpp:249: error: initializing argument 3 of ?void vconvert_f32_s8x(float*, int, signed char*, int, float*, float*, int, int, int)? src/vsip/opt/sal/elementwise.hpp: In function ?void vsip::impl::sal::vconv(const vsip::impl::sal::Sal_vector&, const vsip::impl::sal::Sal_vector&, vsip::length_type)?: src/vsip/opt/sal/elementwise.hpp:256: error: invalid conversion from ?char* const? to ?signed char*? src/vsip/opt/sal/elementwise.hpp:256: error: initializing argument 1 of ?void vconvert_s8_f32x(signed char*, int, float*, int, float*, float*, int, int, int)? make: *** [src/vsip/initfin.o] Error 1 If I disable everything, then VSIPL++ builds to completion and I'm able to build and run example1: ./configure --prefix=/data/PVTOL/vendor/ppc64/Linux-2.6.22-0.ydl.rc4/ sourceryvsipl++-1.3-mpich2-1.0.6-nolapack --with-mpi-prefix=/data/ PVTOL/vendor/ppc64/Linux-2.6.22-0.ydl.rc4/mpich2-1.0.6 CXXFLAGS="-O2 - DMPICH_IGNORE_CXX_SEEK" --disable-builtin-atlas --with-lapack=no This is good for now, it will let us use VSIPL++ in a functional manner. Later, it would be nice to be able to compile an optimized version linked to SAL. Any help is appreciated. Hahn On Oct 5, 2007, at 10:31 AM, Jules Bergmann wrote: > Don McCoy wrote: >> Hahn Kim wrote: >>> >>> Can you tell me why it's trying to configure ATLAS when I try to >>> disable it? Any information is appreciated. Thanks! >>> >>> > ./configure --prefix=/sourceryvsipl+ >>> +-1.3-mpich2-1.0.6-sal --with-mpi-prefix=/ >>> mpich2-1.0.6 CXXFLAGS="-O2 -DMPICH_IGNORE_CXX_SEEK" --with-sal- >>> include=/opt/MultiCorePlus/include --with-sal-lib=/opt/ >>> MultiCorePlus/lib --enable-fft=sal --disable-builtin-atlas >> I find this somewhat confusing myself and usually have to look it >> up each time. I looked in a current tree, but I believe this is >> true for 1.3 also: use --with-lapack=no or --with-lapack=simple- >> builtin for a lapack that doesn't need atlas. > > FWIW, this looks like a quickstart documentation bug. It mentions > --disable-builtin-atlas, but does not mention --with-lapack=no. > > configure --help appears to get it right. > > Don, can you fix the quickstart? > > thanks, > -- Jules > > > -- > Jules Bergmann > CodeSourcery > jules at codesourcery.com > (650) 331-3385 x705 > -- Hahn Kim MIT Lincoln Laboratory Phone: (781) 981-0940 244 Wood Street, S2-252 Fax: (781) 981-5255 Lexington, MA 02420 E-mail: hgk at ll.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules at codesourcery.com Tue Oct 9 15:45:30 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 09 Oct 2007 11:45:30 -0400 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> Message-ID: <470BA21A.4090800@codesourcery.com> Hahn Kim wrote: > Thanks for the feedback, configure now completes without error, but now > I'm encountering problems with make. Hahn, What version of GCC are you using (g++ -v)? Also, this is with VSIPL++ 1.3 (or 1.3.1)? thanks, -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From don at codesourcery.com Tue Oct 9 16:11:41 2007 From: don at codesourcery.com (Don McCoy) Date: Tue, 09 Oct 2007 10:11:41 -0600 Subject: [patch] Re: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <47064AD7.8090202@codesourcery.com> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> Message-ID: <470BA83D.3040807@codesourcery.com> The attached patch fixes the quickstart guide. Jules Bergmann wrote: > Don McCoy wrote: >> Hahn Kim wrote: >>> >>> Can you tell me why it's trying to configure ATLAS when I try to >>> disable it? Any information is appreciated. Thanks! >>> >>> > ./configure >>> --prefix=/sourceryvsipl++-1.3-mpich2-1.0.6-sal >>> --with-mpi-prefix=/mpich2-1.0.6 CXXFLAGS="-O2 >>> -DMPICH_IGNORE_CXX_SEEK" >>> --with-sal-include=/opt/MultiCorePlus/include >>> --with-sal-lib=/opt/MultiCorePlus/lib --enable-fft=sal >>> --disable-builtin-atlas >> I find this somewhat confusing myself and usually have to look it up >> each time. I looked in a current tree, but I believe this is true >> for 1.3 also: use --with-lapack=no or --with-lapack=simple-builtin >> for a lapack that doesn't need atlas. > > FWIW, this looks like a quickstart documentation bug. It mentions > --disable-builtin-atlas, but does not mention --with-lapack=no. > > configure --help appears to get it right. > > Don, can you fix the quickstart? > > thanks, > -- Jules > > -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: qs.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: qs.diff URL: From jules at codesourcery.com Tue Oct 9 16:18:59 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 09 Oct 2007 12:18:59 -0400 Subject: [vsipl++] [patch] Re: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <470BA83D.3040807@codesourcery.com> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> <470BA83D.3040807@codesourcery.com> Message-ID: <470BA9F3.9060504@codesourcery.com> Don McCoy wrote: > The attached patch fixes the quickstart guide. Don, thanks, this looks good, please apply. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Tue Oct 9 16:30:38 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 09 Oct 2007 12:30:38 -0400 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> Message-ID: <470BACAE.80502@codesourcery.com> Hahn, As far as I can tell, it looks like Mercury changed their API. According to the latest SAL documentation, https://customers.mc.com/self_solve/docs/doc_files/SAL_Reference.pdf vconvert_s8_f32x takes a 'char*' first argument: void vconvert_s8_f32x( char *A, /* input vector */ int i, /* address stride for A */ float *C, /* output vector */ int k, /* address stride for C */ float *scale, /* pointer to scale value (NULL=1.0) */ float *bias /* pointer to bias value (NULL=0.0) */ int n, /* element count */ int rfflag, /* reserved */ int eflag ); /* ESAL flag */ This is consistent with our experience using SAL. However, from your error message, > src/vsip/opt/sal/elementwise.hpp:256: error: invalid conversion from > ?char* const? to ?signed char*? > src/vsip/opt/sal/elementwise.hpp:256: error: initializing argument 1 > of ?void vconvert_s8_f32x(signed char*, int, float*, int, float*, > float*, int, int, int)? > make: *** [src/vsip/initfin.o] Error 1 it now appears SAL expects a 'signed char*'. You might look at sal.h to confirm this change. If so, you might also let Mercury know, since they probably didn't mean to break application compatibility like this. We can of course work around this in VSIPL++. The easiest way for us to fix this by sending you an updated snapshot. However, if it is more convenient for you, we can also send you a patch against 1.3 or 1.3.1. Let me know which you would prefer. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From stefan at codesourcery.com Tue Oct 9 17:47:45 2007 From: stefan at codesourcery.com (Stefan Seefeld) Date: Tue, 09 Oct 2007 13:47:45 -0400 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <470BACAE.80502@codesourcery.com> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> <470BACAE.80502@codesourcery.com> Message-ID: <470BBEC1.7070404@codesourcery.com> The attached patch lets configure check the signature of vconvert_s8_f32x, and uses the result when delegating to that function. Tested with manual modifications made to a local CSAL installation. OK to apply ? Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: From hgk at ll.mit.edu Tue Oct 9 17:57:06 2007 From: hgk at ll.mit.edu (Hahn Kim) Date: Tue, 9 Oct 2007 13:57:06 -0400 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <470BACAE.80502@codesourcery.com> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> <470BACAE.80502@codesourcery.com> Message-ID: <461D16A3-DD76-4446-A34B-F26A8E0C169D@ll.mit.edu> Hi Jules, We took a look at the PS3 sal.h over here and compared it to our Mercury CTES sal.h and it appears you are correct; SAL's API has been updated to explicitly require "signed char *" instead of "char *". According to the comments in the file, this was changed on June 15, 2007. It also appears that this change pops up in a bunch of places. I'm sending along the entire sal.h for your reference. I'm guessing the build of SAL we have for our PS3 is an advance copy. If we could get a snapshot, that would be great. We'll also notify Mercury that we encountered this problem, as you suggested. Thanks! Hahn ? On Oct 9, 2007, at 12:30 PM, Jules Bergmann wrote: > Hahn, > > As far as I can tell, it looks like Mercury changed their API. > According to the latest SAL documentation, > > https://customers.mc.com/self_solve/docs/doc_files/SAL_Reference.pdf > > vconvert_s8_f32x takes a 'char*' first argument: > > void vconvert_s8_f32x( > char *A, /* input vector */ > int i, /* address stride for A */ > float *C, /* output vector */ > int k, /* address stride for C */ > float *scale, /* pointer to scale value (NULL=1.0) */ > float *bias /* pointer to bias value (NULL=0.0) */ > int n, /* element count */ > int rfflag, /* reserved */ > int eflag ); /* ESAL flag */ > > This is consistent with our experience using SAL. > > However, from your error message, > >> src/vsip/opt/sal/elementwise.hpp:256: error: invalid conversion >> from ?char* const? to ?signed char*? >> src/vsip/opt/sal/elementwise.hpp:256: error: initializing >> argument 1 of ?void vconvert_s8_f32x(signed char*, int, float*, >> int, float*, float*, int, int, int)? >> make: *** [src/vsip/initfin.o] Error 1 > > it now appears SAL expects a 'signed char*'. You might look at > sal.h to confirm this change. If so, you might also let Mercury > know, since they probably didn't mean to break application > compatibility like this. > > We can of course work around this in VSIPL++. The easiest way for > us to fix this by sending you an updated snapshot. However, if it > is more convenient for you, we can also send you a patch against > 1.3 or 1.3.1. Let me know which you would prefer. > > -- Jules > > -- > Jules Bergmann > CodeSourcery > jules at codesourcery.com > (650) 331-3385 x705 > -- Hahn Kim MIT Lincoln Laboratory Phone: (781) 981-0940 244 Wood Street, S2-252 Fax: (781) 981-5255 Lexington, MA 02420 E-mail: hgk at ll.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sal.h Type: application/octet-stream Size: 250076 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at codesourcery.com Tue Oct 9 20:53:51 2007 From: stefan at codesourcery.com (Stefan Seefeld) Date: Tue, 09 Oct 2007 16:53:51 -0400 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <461D16A3-DD76-4446-A34B-F26A8E0C169D@ll.mit.edu> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> <470BACAE.80502@codesourcery.com> <461D16A3-DD76-4446-A34B-F26A8E0C169D@ll.mit.edu> Message-ID: <470BEA5F.9010707@codesourcery.com> Hahn, thanks for the attached header. I ported the original patch over to the 1.3 branch, and adjusted it further to make it work with that header (there was one other signature change in need of adjustment). Can you try this patch ? Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: From hgk at ll.mit.edu Wed Oct 10 03:42:59 2007 From: hgk at ll.mit.edu (Hahn Kim) Date: Tue, 9 Oct 2007 23:42:59 -0400 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <470BEA5F.9010707@codesourcery.com> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> <470BACAE.80502@codesourcery.com> <461D16A3-DD76-4446-A34B-F26A8E0C169D Message-ID: <45BE45DB-EF98-439D-A6CD-F4BFE6AA3A05@ll.mit.edu> Thanks for doing this so quickly. I apologize, but I've never used the patch command before and am having trouble with it. Assuming the diff file is called salpatch.diff, I'm using the following command: patch -b < salpatch.diff and am getting the following error: patching file ChangeLog Hunk #1 succeeded at 1 with fuzz 1. patching file configure.ac Hunk #1 succeeded at 1345 with fuzz 2 (offset -91 lines). can't find file to patch at input line 60 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- | | if test "$enable_sal_fft" != "no"; then |Index: src/vsip/opt/sal/elementwise.hpp |=================================================================== |--- src/vsip/opt/sal/elementwise.hpp (revision 184420) |+++ src/vsip/opt/sal/elementwise.hpp (working copy) -------------------------- File to patch: Sorry for the noob question, can you help me out? Thanks. Hahn On Oct 9, 2007, at 4:53 PM, Stefan Seefeld wrote: > Hahn, > > thanks for the attached header. I ported the original patch over to > the > 1.3 branch, and adjusted it further to make it work with that header > (there was one other signature change in need of adjustment). > > Can you try this patch ? > > Thanks, > Stefan > > -- > Stefan Seefeld > CodeSourcery > stefan at codesourcery.com > (650) 331-3385 x718 > Index: ChangeLog > =================================================================== > --- ChangeLog (revision 184420) > +++ ChangeLog (working copy) > @@ -1,3 +1,8 @@ > +2007-10-09 Stefan Seefeld > + > + * configure.ac: Test whether SAL uses signed char types > explicitely. > + * src/vsip/opt/sal/elementwise.hpp: Adjust. > + > 2007-05-09 Jules Bergmann > > * src/vsip/opt/simd/simd.hpp: Fix faux-complex trait to work > Index: configure.ac > =================================================================== > --- configure.ac (revision 184420) > +++ configure.ac (working copy) > @@ -1436,12 +1436,37 @@ > CPPFLAGS=$save_CPPFLAGS > LDFLAGS=$save_LDFLAGS > else > + # Check specific SAL signatures > + > + AC_MSG_CHECKING([for vconvert_s8_f32x signature.]) > + AC_COMPILE_IFELSE([ > +#include > + > +int main(int, char **) > +{ > + signed char *input; > + float *output; > + vconvert_s8_f32x(input, 1, output, 1, 0, 0, 1, 0, 0); > +} > +], > +[ > + vconvert_s8_f32x_is_signed=1 > + AC_MSG_RESULT([signed char *]) > +], > +[ > + vconvert_s8_f32x_is_signed=0 > + AC_MSG_RESULT([char *]) > +]) > + > AC_SUBST(VSIP_IMPL_HAVE_SAL, 1) > if test "$neutral_acconfig" = 'y'; then > CPPFLAGS="$CPPFLAGS -DVSIP_IMPL_HAVE_SAL=1" > + CPPFLAGS="$CPPFLAGS -DVSIP_IMPL_SAL_USES_SIGNED= > $vconvert_s8_f32x_is_signed" > else > AC_DEFINE_UNQUOTED(VSIP_IMPL_HAVE_SAL, 1, > [Define to set whether or not to use Mercury's SAL library.]) > + AC_DEFINE_UNQUOTED(VSIP_IMPL_SAL_USES_SIGNED, > $vconvert_s8_f32x_is_signed, > + [Define if Mercury's SAL uses signed char *.]) > fi > > if test "$enable_sal_fft" != "no"; then > Index: src/vsip/opt/sal/elementwise.hpp > =================================================================== > --- src/vsip/opt/sal/elementwise.hpp (revision 184420) > +++ src/vsip/opt/sal/elementwise.hpp (working copy) > @@ -246,14 +246,22 @@ > > VSIP_IMPL_SAL_VCONV(vconv, float, long, vconvert_f32_s32x); > VSIP_IMPL_SAL_VCONV(vconv, float, short, vconvert_f32_s16x); > +#if VSIP_IMPL_SAL_USES_SIGNED == 1 > +VSIP_IMPL_SAL_VCONV(vconv, float, signed char, vconvert_f32_s8x); > +#else > VSIP_IMPL_SAL_VCONV(vconv, float, char, vconvert_f32_s8x); > +#endif > VSIP_IMPL_SAL_VCONV(vconv, float, unsigned long, vconvert_f32_u32x); > VSIP_IMPL_SAL_VCONV(vconv, float, unsigned short, vconvert_f32_u16x); > VSIP_IMPL_SAL_VCONV(vconv, float, unsigned char, vconvert_f32_u8x); > > VSIP_IMPL_SAL_VCONV(vconv, long, float, vconvert_s32_f32x); > VSIP_IMPL_SAL_VCONV(vconv, short, float, vconvert_s16_f32x); > +#if VSIP_IMPL_SAL_USES_SIGNED == 1 > +VSIP_IMPL_SAL_VCONV(vconv, signed char, float, vconvert_s8_f32x); > +#else > VSIP_IMPL_SAL_VCONV(vconv, char, float, vconvert_s8_f32x); > +#endif > VSIP_IMPL_SAL_VCONV(vconv, unsigned long, float, vconvert_u32_f32x); > VSIP_IMPL_SAL_VCONV(vconv, unsigned short, float, vconvert_u16_f32x); > VSIP_IMPL_SAL_VCONV(vconv, unsigned char, float, vconvert_u8_f32x); -- Hahn Kim MIT Lincoln Laboratory Phone: (781) 981-0940 244 Wood Street, S2-252 Fax: (781) 981-5255 Lexington, MA 02420 E-mail: hgk at ll.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From don at codesourcery.com Wed Oct 10 04:48:43 2007 From: don at codesourcery.com (Don McCoy) Date: Tue, 09 Oct 2007 22:48:43 -0600 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <45BE45DB-EF98-439D-A6CD-F4BFE6AA3A05@ll.mit.edu> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> <470BACAE.80502@codesourcery.com> <461D16A3-DD76-4446-A34B-F26A8E0C169D <45BE45DB-EF98-439D-A6CD-F4BFE6AA3A05@ll.mit.edu> Message-ID: <470C59AB.3070104@codesourcery.com> Hahn Kim wrote: > Thanks for doing this so quickly. I apologize, but I've never used > the patch command before and am having trouble with it. Assuming the > diff file is called salpatch.diff, I'm using the following command: > Hopefully Stefan or someone can pinpoint any problems if this doesn't work, but this is the recipe that I use. I tried this against the 1.3.1 release, so if you are using 1.3, the number of lines offset may vary. Note this is done from within the top-level directory containing 'src': $ patch -p0 < ../salpatch.diff patching file ChangeLog Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej patching file configure.ac Hunk #1 succeeded at 1379 (offset -57 lines). patching file src/vsip/opt/sal/elementwise.hpp The change log failure is no big deal of course, but the other two files succeeded so all should be well. Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 From hgk at ll.mit.edu Wed Oct 10 14:24:30 2007 From: hgk at ll.mit.edu (Hahn Kim) Date: Wed, 10 Oct 2007 10:24:30 -0400 Subject: [vsipl++] Compiling VSIPL++ on Cell PPE In-Reply-To: <470C59AB.3070104@codesourcery.com> References: <9AC9F828-B800-4F5C-A191-C886A1CFBE18@ll.mit.edu> <47054C9B.6080906@codesourcery.com> <47064AD7.8090202@codesourcery.com> <4034FED0-24E6-4707-A131-9DB59CEBCA13@ll.mit.edu> <470BACAE.80502@codesourcery.com> <461D16A3-DD76-4446-A34B-F26A8E0C169D Message-ID: <5AA64206-B5C2-42CA-852A-5F6B5D4C96E2@ll.mit.edu> Hi all, Looks like it worked, both the patch command and make completed. Thanks for the quick turnaround and all of your help! Hahn On Oct 10, 2007, at 12:48 AM, Don McCoy wrote: > Hahn Kim wrote: >> Thanks for doing this so quickly. I apologize, but I've never >> used the patch command before and am having trouble with it. >> Assuming the diff file is called salpatch.diff, I'm using the >> following command: >> > Hopefully Stefan or someone can pinpoint any problems if this > doesn't work, but this is the recipe that I use. I tried this > against the 1.3.1 release, so if you are using 1.3, the number of > lines offset may vary. > > Note this is done from within the top-level directory containing > 'src': > > $ patch -p0 < ../salpatch.diff > patching file ChangeLog > Hunk #1 FAILED at 1. > 1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej > patching file configure.ac > Hunk #1 succeeded at 1379 (offset -57 lines). > patching file src/vsip/opt/sal/elementwise.hpp > > > The change log failure is no big deal of course, but the other two > files succeeded so all should be well. > > Regards, > > -- > Don McCoy > don (at) CodeSourcery > (888) 776-0262 / (650) 331-3385, x712 > -- Hahn Kim MIT Lincoln Laboratory Phone: (781) 981-0940 244 Wood Street, S2-252 Fax: (781) 981-5255 Lexington, MA 02420 E-mail: hgk at ll.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From eschnetz at harris.com Wed Oct 10 16:58:16 2007 From: eschnetz at harris.com (Schnetzer, Everett) Date: Wed, 10 Oct 2007 12:58:16 -0400 Subject: [vsipl++] Compile problems with reference implementation and gnu 3.4.5 In-Reply-To: <46E5A073.8040305@codesourcery.com> References: <46E1D155.8040209@codesourcery.com> <46E5A073.8040305@codesourcery.com> Message-ID: Stefan Seefeld wrote: > As I can't reproduce this with my (Linux-based) version of GCC 3.4.5, and > since this looks like a C++ frontend issue, rather than a platform-specific > problem, I'm tempted to believe that the cause is related to your writing > your own Makefile for tests/ref-impl/. The problem was in the Makefile, in that it did not have the following compile def's: -DVSIP_IMPL_PAR_SERVICE=0 -DVSIP_IMPL_HAVE_CVSIP=1 -DVSIP_IMPL_CVSIP_HAVE_FLOAT=1 -DVSIP_IMPL_CVSIP_HAVE_DOUBLE=1 -DVSIP_IMPL_CVSIP_FFT=1 -DVSIP_IMPL_FFT_USE_FLOAT=1 -DVSIP_IMPL_FFT_USE_DOUBLE=1 -DVSIP_IMPL_FFT_USE_LONG_DOUBLE=1 -DVSIP_IMPL_PROVIDE_FFT_FLOAT=1 -DVSIP_IMPL_PROVIDE_FFT_DOUBLE=1 -DVSIP_IMPL_PROVIDE_FFT_LONG_DOUBLE=0 They were in the GNUmakefile produced by the configuration script. I would have expected these to be in acconfig.hpp. For our port to MinGW, I manually put them in acconfig.hpp so application Makefiles/build scripts don't have to define them. Another problem was discovered if we include windows.h before the vsipl++ include files. This file is part of the MinGW distribution and is the main header for the Win32 API. Some other file that windows.h includes confuses some of the vsipl++ template instantiations. I didn't track down who the culprit was, but defining WIN32_LEAN_AND_MEAN is a work-around. Otherwise an application has to make sure all relevant vsipl++ .hpp files are brought in before windows.h. That seems to be it, though. The reference implementation tests now work in our MinGW environment. Thanks, Everett Schnetzer Software Engineer, Harris GCSD eschnetz at harris.com 321-727-6607 From stefan at codesourcery.com Wed Oct 10 17:10:50 2007 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 10 Oct 2007 13:10:50 -0400 Subject: [vsipl++] Compile problems with reference implementation and gnu 3.4.5 In-Reply-To: References: <46E1D155.8040209@codesourcery.com> <46E5A073.8040305@codesourcery.com> Message-ID: <470D079A.209@codesourcery.com> Everett, Schnetzer, Everett wrote: > The problem was in the Makefile, in that it did not have the following > compile def's: [...] > They were in the GNUmakefile produced by the configuration script. I > would have expected these to be in acconfig.hpp. For our port to MinGW, > I manually put them in acconfig.hpp so application Makefiles/build > scripts don't have to define them. Right. By default these macros are put into the build system, but you can tell configure to store them in acconfig.hpp by using the --disable-shared-acconfig option. (Sharing in this context refers to building multiple build variants out of a single development environment (and thus, set of VSIPL++ header files). > Another problem was discovered if we include windows.h before the > vsipl++ include files. This file is part of the MinGW distribution and > is the main header for the Win32 API. Some other file that windows.h > includes confuses some of the vsipl++ template instantiations. I didn't > track down who the culprit was, but defining WIN32_LEAN_AND_MEAN is a > work-around. Otherwise an application has to make sure all relevant > vsipl++ .hpp files are brought in before windows.h. > > That seems to be it, though. The reference implementation tests now work > in our MinGW environment. Great, thanks for letting us know ! Regards, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From prakashnm07 at gmail.com Thu Oct 11 06:23:00 2007 From: prakashnm07 at gmail.com (prakash narayanan) Date: Thu, 11 Oct 2007 11:53:00 +0530 Subject: FFT Segmentation Fault Message-ID: Hi Everyone, I am new to VSIPL & VSIPL++. I recently installed the following on me link 64 bit AMD machine (dual core). VSIPL tvcpp0p86 VSIPL++ sourceryvsipl++-1.3 I have compiled and installed VSIPL++ using the following configuration command ................... ./configure --with-fft=none --disable-mpi --enable-sse --enable-sse2 --disable-mpi --prefix=/usr/local host=IA64 --enable-cpu-mhz=2000 --enable-cvsip After this a simple example program for FFT is taken and compiled. When I am running the program a Segmentation fault occurs in the following line. Fft fft_forward(Domain<1>(fftLen), static_cast(1.0)); before this variables and vectors are declared as follows. // variables int numSamples = (32 * 1024); int fftLen = (numSamples/2); int invFftLen = (numSamples/2); // vectors Vector signal(fftLen); Vector Result(invFftLen); if numSamples = 16 of less the program runs.......... Instead of Fft() if I use Fftm() it works with matrices of size more than 32K also. I am attaching below the entire program. Can anyone suggest how to go about? Thanks in advance...... Regards PNM #include #include #include #include #include #include #include #include #include namespace vsip { typedef vsip_scalar_d scalar_d; typedef std::complex cscalar_d; } using namespace std; using namespace vsip; typedef cscalar_f complex_type; typedef cscalar_d dbl_complx; typedef scalar_f real_type; int main() { // variables int numSamples = (32 * 1024); int fftLen = (numSamples/2); int invFftLen = (numSamples/2); // vectors Vector signal(fftLen); Vector Result(invFftLen); std::cout << "Initialising FFT forward" << endl; // set up forward fft Fft fft_forward(Domain<1>(fftLen), static_cast(1.0)); std::cout << "Initialising FFT inverse" << endl; // set up inverse fft Fft fft_inverse((Domain<1>(invFftLen)), static_cast(1.0 /invFftLen)); std::cout << "Calling FFT forward" << endl; // take forward fft fft_forward(signal); std::cout << "Calling FFT inverse" << endl; // take inverse fft fft_inverse(signal, Result); std::cout << "Finished sucessfully" << endl; return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at codesourcery.com Thu Oct 11 16:25:45 2007 From: stefan at codesourcery.com (Stefan Seefeld) Date: Thu, 11 Oct 2007 12:25:45 -0400 Subject: [vsipl++] FFT Segmentation Fault In-Reply-To: References: Message-ID: <470E4E89.8020808@codesourcery.com> prakash narayanan wrote: > Hi Everyone, > > I am new to VSIPL & VSIPL++. I recently installed the following on me > link 64 bit AMD machine (dual core). > VSIPL tvcpp0p86 > VSIPL++ sourceryvsipl++-1.3 > > > I have compiled and installed VSIPL++ using the following configuration > command ................... > ./configure --with-fft=none --disable-mpi --enable-sse --enable-sse2 > --disable-mpi --prefix=/usr/local host=IA64 --enable-cpu-mhz=2000 > --enable-cvsip > > > > After this a simple example program for FFT is taken and compiled. The way to configure what FFT backends to use with VSIPL++, please use the --enable-fft option. (The option accepts a comma-separated list of backends.) However, I'm not quite sure what you are trying to accomplish, as you seem to want to disable FFT (you use "--with-fft=none"), yet you then try to compile and run an FFT applet. Typically, if no FFT backends are available, any code using vsip::Fft objects will result in a compile-time error. (A way not to compile any FFT backend in, yet prevent compile-time errors, is to use the dummy "no_fft" backend, i.e., --enable-fft=no_fft. Regards, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From stefan at codesourcery.com Wed Oct 17 15:52:11 2007 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 17 Oct 2007 11:52:11 -0400 Subject: patch: varia Message-ID: <47162FAB.3070100@codesourcery.com> The attached patch fixes a number of issues: * It incorporates the CBE SDK FFT backend into our FFT-handling harness, by supporting the --enable-fft=cbe_sdk option. * It conditionalize more png-dependent examples on the availability of libpng, thus preventing errors if the library isn't available. * It fixes a typo in the tutorial, and adds some support for further documentation enhancements (notably the reference manual). OK to apply to trunk and sdk 2.1 branch ? Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: From jules at codesourcery.com Wed Oct 17 15:56:04 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 17 Oct 2007 11:56:04 -0400 Subject: [vsipl++] patch: varia In-Reply-To: <47162FAB.3070100@codesourcery.com> References: <47162FAB.3070100@codesourcery.com> Message-ID: <47163094.7090909@codesourcery.com> Stefan Seefeld wrote: > The attached patch fixes a number of issues: > > * It incorporates the CBE SDK FFT backend into our FFT-handling harness, > by supporting the --enable-fft=cbe_sdk option. > > * It conditionalize more png-dependent examples on the availability of > libpng, thus preventing errors if the library isn't available. > > * It fixes a typo in the tutorial, and adds some support for further > documentation enhancements (notably the reference manual). > > OK to apply to trunk and sdk 2.1 branch ? > > Thanks, > Stefan > > Stefan, Looks good. Can you add some logic to have --enable-fft=cbe_sdk check that --enable-cbe-sdk has been given? Otherwise, please check it in. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From howes at ll.mit.edu Thu Oct 18 16:57:48 2007 From: howes at ll.mit.edu (Brad Howes) Date: Thu, 18 Oct 2007 12:57:48 -0400 Subject: 1.3 Configuration Issues on OpenSUSE 10.2 Message-ID: <17549466-83C0-4C5D-A195-14873B2C5999@ll.mit.edu> On a box running OpenSUSE 10.2, I had some problems configuring vsipl+ + 1.3 to use the blas and lapack libraries present on the system. In the 'configure' script, the code that checks for g2c is somewhat broken, missing double-quotes around some variable expansions, and I could not get the test cases to run unless I linked in -lgfortran by manually adding it to the proper action line in the 'configure' file. After those minor changes, I was able to properly configure using -- with-lapack=generic. I can post a diff if desired. As an aside, does anyone have any information on how stock blas/ lapack installs perform compared to the vsipl++ builtin version? Thanks! Brad -- Brad Howes Group 42 MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules at codesourcery.com Fri Oct 19 19:48:31 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 19 Oct 2007 15:48:31 -0400 Subject: [vsipl++] 1.3 Configuration Issues on OpenSUSE 10.2 In-Reply-To: <17549466-83C0-4C5D-A195-14873B2C5999@ll.mit.edu> References: <17549466-83C0-4C5D-A195-14873B2C5999@ll.mit.edu> Message-ID: <47190A0F.1020203@codesourcery.com> Brad, Sourcery VSIPL++ incorporates ATLAS version 3.7.11, which is a bit dated (circa 2005). How that compares to a stock blas/lapack library will depend quite a bit on what "stock" is: * Comparing against a "stock" ATLAS, it will depend on your architectures. For architectures not supported in 3.7.11 (with a predefined config file), a newer version of ATLAS will probably do much better. You can configure VSIPL++ to use a pre-existing ATLAS. * Comparing against a vendor lapack/blas, such as Intel's MKL, IBM's ESSL, or AMD's ACML, my suspicion is the vendor libraries will do better. Again, you can configure VSIPL++ to use these libraries if you have them. * Comparing against the reference implementation of lapack/blas from netlib.org, the builtin ATLAS will win hands down! I'm sorry that you encountered problems trying to build VSIPL++ for OpenSUSE. However, it sounds like you were able to work around them. Would you mind contributing your patch for inclusion in future versions of VSIPL++? I'm not sure what version of ATLAS OpenSUSE ships with, but if it is more recent than 3.7.11, it may be worth installing and using. Let me know if you have any questions configuring VSIPL++ to use an external ATLAS. thanks, -- Jules Brad Howes wrote: > On a box running OpenSUSE 10.2, I had some problems configuring vsipl++ > 1.3 to use the blas and lapack libraries present on the system. In the > 'configure' script, the code that checks for g2c is somewhat broken, > missing double-quotes around some variable expansions, and I could not > get the test cases to run unless I linked in -lgfortran by manually > adding it to the proper action line in the 'configure' file. After those > minor changes, I was able to properly configure using > --with-lapack=generic. I can post a diff if desired. > > As an aside, does anyone have any information on how stock blas/lapack > installs perform compared to the vsipl++ builtin version? > > Thanks! > > Brad > > -- > Brad Howes > Group 42 > MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 > Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 > > > > -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From don at codesourcery.com Thu Oct 25 19:02:00 2007 From: don at codesourcery.com (Don McCoy) Date: Thu, 25 Oct 2007 13:02:00 -0600 Subject: [patch] fix for profiling long processes Message-ID: <4720E828.2000907@codesourcery.com> When profiling over a long period of time, the raw timestamps observed in the profiler output have the potential to be truncated, leading to inaccurate results. The error is only in how the profiler output is managed, not in the profile timer itself, which handles rollovers in the time source correctly. The profiler output function was affected because it uses the 'ticks()' profile timer function to obtain the raw timestamps to place in the log, which were being truncated to 32-bits. Ok to apply? -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pt.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pt.diff URL: From jules at codesourcery.com Thu Oct 25 19:28:37 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 25 Oct 2007 15:28:37 -0400 Subject: [vsipl++] [patch] fix for profiling long processes In-Reply-To: <4720E828.2000907@codesourcery.com> References: <4720E828.2000907@codesourcery.com> Message-ID: <4720EE65.6010903@codesourcery.com> Don McCoy wrote: > When profiling over a long period of time, the raw timestamps observed > in the profiler output have the potential to be truncated, leading to > inaccurate results. > > The error is only in how the profiler output is managed, not in the > profile timer itself, which handles rollovers in the time source > correctly. The profiler output function was affected because it uses > the 'ticks()' profile timer function to obtain the raw timestamps to > place in the log, which were being truncated to 32-bits. > > Ok to apply? Don, Hurray! This seems a plausible explanation for the weird roll up (sum less than the parts) of time values. One quick suggestion: can you create a 'tick_type' typedef that is unsigned long long. That will help us remember not to use a 32-bit type again. Otherwise this looks good, please apply. thanks, -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Tue Oct 30 19:58:39 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 30 Oct 2007 15:58:39 -0400 Subject: [patch]: Fix tests/tutorial/matlab_iter_example.cpp Message-ID: <47278CEF.4020402@codesourcery.com> Adds a test_write function to create the sample.mat file necessary for the read tests. There is a race between this and the other tutorial/matlab test if they're run in parallel. Fortunately, the release testing is serial (sigh). Patch applied. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mie.diff URL: From jules at codesourcery.com Wed Oct 31 13:54:12 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 31 Oct 2007 09:54:12 -0400 Subject: [patch] Matlab IO Message-ID: <47288904.6010705@codesourcery.com> This patch - Cleans up parts of the matlab IO interface. In particular, - fixes endian issues with the iterator interface, - fixes confusion about writing version, - adds informative exceptions on failures - adds comments on file format - minor renaming for coding standards compliance - Extends the matlab_bin_file test to also read pre-canned .mat files in little- and big-endian format. - Adds a lsmat utility to list contents of a matlab file through the iterator interface. Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: matlab.diff URL: From stefan at codesourcery.com Wed Oct 31 14:23:50 2007 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 31 Oct 2007 10:23:50 -0400 Subject: [vsipl++] [patch] Matlab IO In-Reply-To: <47288904.6010705@codesourcery.com> References: <47288904.6010705@codesourcery.com> Message-ID: <47288FF6.9040508@codesourcery.com> Jules Bergmann wrote: > This patch > > - Cleans up parts of the matlab IO interface. In particular, > - fixes endian issues with the iterator interface, > - fixes confusion about writing version, > - adds informative exceptions on failures > - adds comments on file format > - minor renaming for coding standards compliance This looks good. > - Extends the matlab_bin_file test to also read pre-canned .mat > files in little- and big-endian format. Our QMTest database does have support for tests involving input. Some FFT tests are doing this already: The test consists in running an executable (which has been compiled by means of a 'resource'), passing it a particular file as argument. I wonder whethere we could simply do the same here, e.g. 'matlab/bin_file.cpp' would name a resource, while 'matlab/X.mat' and 'matlab/Y.mat' would name tests. (For QMTest to detect this, we'd simply have to follow the same layout as the FFT tests, i.e. have a 'matlab_bin_file' directory, containing a source file, as well as a 'data' subdirectory with the input (.mat) files. The source file automagically maps to a 'CompiledResource', while the data/*.mat files map to 'ExecutableTests' that run the previously compiled resource, passing the input file as argument... (And, as with the FFT tests, we could encode into the input file names how they are to be processed by the executable, e.g. 'le' and 'be' to tell the applet about endianness. > - Adds a lsmat utility to list contents of a matlab file through > the iterator interface. Wonderful ! > Ok to apply? Please take the above merely as a suggestion. If you would rather keep the current layout, I'd suggest to base the computation of the input filenames on the __FILE__ macro, rather than generating the directory name via configure. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Wed Oct 31 15:35:21 2007 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 31 Oct 2007 11:35:21 -0400 Subject: [vsipl++] [patch] Matlab IO In-Reply-To: <47288FF6.9040508@codesourcery.com> References: <47288904.6010705@codesourcery.com> <47288FF6.9040508@codesourcery.com> Message-ID: <4728A0B9.20504@codesourcery.com> > >> - Extends the matlab_bin_file test to also read pre-canned .mat >> files in little- and big-endian format. > > Our QMTest database does have support for tests involving input. Some > FFT tests are doing this already: The test consists in running an > executable (which has been compiled by means of a 'resource'), passing > it a particular file as argument. I wonder whethere we could simply do > the same here, e.g. 'matlab/bin_file.cpp' would name a resource, while > 'matlab/X.mat' and 'matlab/Y.mat' would name tests. (For QMTest to > detect this, we'd simply have to follow the same layout as the FFT > tests, i.e. have a 'matlab_bin_file' directory, containing a source > file, as well as a 'data' subdirectory with the input (.mat) files. > The source file automagically maps to a 'CompiledResource', while the > data/*.mat files map to 'ExecutableTests' that run the previously > compiled resource, passing the input file as argument... > > (And, as with the FFT tests, we could encode into the input file names > how they are to be processed by the executable, e.g. 'le' and 'be' to > tell the applet about endianness. > Please take the above merely as a suggestion. If you would rather keep > the current layout, I'd suggest to base the computation of the input > filenames on the __FILE__ macro, rather than generating the directory > name via configure. Thanks for the feedback. I like the suggestion (and implemented it :). It avoids hard coding the directory path at configure. Patch applied as attached. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: matlab2.diff URL: