Mercurial > hg > octave-nkf
changeset 4680:493ff0643644
[project @ 2003-12-17 21:18:18 by jwe]
author | jwe |
---|---|
date | Wed, 17 Dec 2003 21:18:18 +0000 |
parents | c0302db81b75 |
children | bb9515a3527d |
files | README.Cray scripts/control/system/sysupdate.m |
diffstat | 2 files changed, 152 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
new file mode 100644 --- /dev/null +++ b/README.Cray @@ -0,0 +1,152 @@ +It should now be possible to compile and link Octave on the Cray SV1 +and perhaps other similar Cray systems using the following procedure. +It even runs and seems to work, at least for the few small things I +tried. + + * Run + + configure \ + F77=ftn FFLAGS="-dp -O0" \ + CC=cc CFLAGS=-O0 CXX=CC \ + CXXFLAGS="-O0 -h new_for_init -h nomessage=76" \ + --without-blas --without-lapack --disable-readline + + The last to arguments tell Octave to use the reference blas and + lapack implmentation in Fortran and to not require the readline + library. If you have the readline library, you can omit the last + option. You can also try to use a vendor library for LAPACK and + BLAS, but how are those compiled? You will need a version of the + library that is compiled for 64-bit double precision values, but + that uses the D and Z names (I'm not sure that this is the case + with the Cray librararies). + + I'm using -O0 in an effort to speed up compilation. If you want + an optimized version and have time to wait for the build to + complete, then use whatever -On option you like. + + * Edit the generated Makeconf file and make sure that you have + + FFLAGS = -dp -O0 + CFLAGS = -O0 + CXXFLAGS = -O0 -h new_for_init -h nomessage=76 + FPICFLAG = + CPICFLAG = + CXXPICFLAG = + + The first three should be handled automatically by the configure + arguments, but the others are not (yet). + + * Edit liboctave/data-conv.h and force the definitions of + TWO_BYTE_INT and FOUR_BYTE_INT to be int. These will have to be + fixed correctly later, but this fix will allow Octave to compile + and even run, though some things like saving and loading data with + some binary file formats will be broken. Suggestions for a good + way to fix this are welcome. + + * If building from CVS, you will need to have gperf installed, or + you can generate src/oct-gperf.h on some other machine and copy to + the src subdirectory in the Cray build tree. + + * If you don't have TeX installed on your SV1, then edit the + generated octMakefile and remove doc from the SUBDIRS variable so + you won't try to run make in the doc subdirectory. Otherwise, it + will fail because you don't have TeX installed (and why would + you?). This is only a problem when building from CVS or if you + build from a distribution and configure with something other than + --prefix=/usr/local. + + * Run + + gmake -k omit_deps=true + + and it should run all the way to creating an octave executable + (see below for why omit_deps=true is needed). + + +REMAINING PROBLEMS +------------------ + + * I tried to get dependency generation to work, but it seems there is + a bug in the C++ compiler because it keeps crashing with errors like + this: + + making pathsearch.d from pathsearch.cc + CC-1353 CC: INTERNAL File = CColVector.cc, Line = 38 + + #include "oct-cmplx.h" + ^ + + CC-2202 CC: ERROR + "/opt/ctl/CC_sv1/CC_sv1/lib/ccom" (pid 69504) was terminated + due to receipt of signal 06: Abort (core dumped). + + when I try to use the -M option. Dependency generation is + relatively slow, so maybe it would be worth trying to speed it up + by using a simpler tool. We are currently using the compilers to + build lists of dependencies that include system header files, but + maybe it would be good enough if we only listed the header files + that are included with the Octave sources. In that case, we could + probably write a simple script that could do the job and that + could run much faster than the compiler. + + * IEEE Inf and NaN (and Octave's NA value, which is a particular NaN + value) are all currently set to DBL_MAX since the SV1 doesn't + support IEEE floating point numbers. Will this be true of future + machines from Cray? I don't think it is possible to have a fully + functional version of Octave (or Matlab) on a system without IEEE + numbers. + + * TWO_BYTE_INT and FOUR_BYTE_INT types, mostly used in load-save.cc. + This can probably be solved by using arrays of char values and + some masking, but it will probably be a bit tricky. The problem + is that various binary data file formats are specified using + integer values of specific sizes, so we need to be able to read + and write integer values in 16 and 32 bit formats. + + * The code in liboctave/mach-info.cc that determines the floating + point format used by the system assumes that a double is exactly + twice as wide as an int. This should be fixed, since the Cray has + + sizeof (char) == 1 + sizeof (short) == 8 + sizeof (int) == 8 + sizeof (long) == 8 + sizeof (double) == 8 + + For now, I forced the floating point format based on an #ifdef CRAY. + + * Build a working readline library. Probably not too hard but I + didn't think it was worth the effort yet. I can't run Octave + interactively on the SV1 I have access to anyway, so command line + editing doesn't matter much. + + * Build the FFTW library for better fft performance. Without this, + we still have fft and ifft functions using FFTPACK. + + * Build the HDF5 library to support loading and saving of HDF + files. This is not necessary unless you need to access Octave + data files that have been stored in the HDF file format. + + * Link with fast BLAS and LAPACK libraries for better performance. + There is a Cray library, but I'm not sure whether we can use it + directly. Does DGEMM in the Cray BLAS library use double + precision, or is it compiled with the equivalent of -dp? If it + uses double precision (i.e., 128-bit floating point values) then + it will take some work to make this functional for Octave, since + Octave uses the D and Z names and we would presumably need the S + and C names instead. + + * Shared libraries. Apparently this is not supported on the SV1, so + dynamically linked functions (.oct files) will not work on this + system. + + * There are a few warnings when compiling glob/glob.c that should + probably be fixed. + + +John W. Eaton +jwe@bevo.che.wisc.edu +University of Wisconsin-Madison +Chemical & Biological Engineering Department + +Wed Dec 17 15:17:29 2003