Apple Silicon support?

[jacobwilliams]

Is support for Apple Silicon processors planned or possible?

Currently, I get this error if I try to compile on an Apple M1 system:

checking build system type... Invalid configuration `arm64-apple-darwin20.0.0': machine `arm64-apple' not recognized
configure: error: /bin/sh ../build-aux/config.sub arm64-apple-darwin20.0.0 failed

[sthibaul]

You probably just need to re-./autogen.sh with an autoconf that supports it? StarPU itself is very arch-independent, by using gcc atomics & such.

[jacobwilliams]

Thanks! I know next to nothing about these gnu tools.

That got me further. I'll tinker with it some more. I guess now it's complaining about not having MKL (which doesn't exist for Apple Silicon). I guess there's probably a way to link with a different BLAS/Lapack?

[sthibaul]

now it's complaining about not having MKL

That shouldn't be a problem, starpu itself doesn't need a blas library. Do you actually get an error message?

[jacobwilliams]

Looks like it's trying to link with the x86 MKL:

...
ld: warning: directory not found for option '-L/opt/intel/oneapi/mkl/2022.0.0/lib/intel64'
ld: warning: ignoring file /opt/intel/oneapi/mkl/2022.0.0/lib/libmkl_intel_lp64.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /opt/intel/oneapi/mkl/2022.0.0/lib/libmkl_sequential.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /opt/intel/oneapi/mkl/2022.0.0/lib/libmkl_core.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
1 warning generated.
  CC       heat/dw_factolu_grain.o
1 warning generated.
  CC       heat/dw_sparse_cg.o
Undefined symbols for architecture arm64:
  "_dasum_", referenced from:
      _STARPU_DASUM in blas.o
  "_daxpy_", referenced from:
      _STARPU_DAXPY in blas.o
  "_ddot_", referenced from:
      _STARPU_DDOT in blas.o
  "_dgemm_", referenced from:
      _STARPU_DGEMM in blas.o
  "_dgemv_", referenced from:
      _STARPU_DGEMV in blas.o
  "_dger_", referenced from:
      _STARPU_DGER in blas.o
  "_dpotrf_", referenced from:
      _STARPU_DPOTRF in blas.o
...
ld: symbol(s) not found for architecture arm64
clang-16: error: linker command failed with exit code 1 (use -v to see invocation)

When I add --enable-blas-lib=none to the ../configure call I get:

...
checking for FFTW... checking for FFTWF... checking for FFTWL... checking for HWLOC... configure: error: libhwloc or pkg-config was not found on your system. If the target machine is hyperthreaded the performance may be impacted a lot.  It is strongly recommended to install libhwloc and pkg-config. However, if you really want to use StarPU without enabling libhwloc, please restart configure by specifying the option '--without-hwloc'.

I have hwloc installed via conda. How do I tell it where that is located?

If I add --without-hwloc, I get

...
icc: warning #10193: -vec is default; use -x and -ax to configure vectorization
ld: warning: ignoring file basic_examples/vector_scal_opencl.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64
ld: warning: ignoring file basic_examples/vector_scal_cpu.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64
ld: warning: ignoring file ../src/.libs/libstarpu-1.4.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
ld: warning: ignoring file basic_examples/vector_scal.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64
ld: warning: ignoring file /Users/jwilliam/git/qr_mumps_build/env/lib/libc++.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
  CCLD     filters/fndim_to_vector
  CCLD     filters/fndim_to_matrix
  CCLD     filters/fndim_to_variable
Undefined symbols for architecture x86_64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
make[3]: *** [basic_examples/vector_scal] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1

No idea why it's trying to build x86_64 code.

Update after I pasted all this in I noticed the icc. So it's using the intel icc compiler (which is x86_64). I'll try to prevent it from doing that...

[sthibaul]

I have hwloc installed via conda. How do I tell it where that is located?

If libhwloc is installed in a standard location, no option is required, it will be detected automatically, otherwise --with-hwloc= should be used to specify its location.

Another (standard) way is to set the PKG_CONFIG_PATH environment variable to the lib/pkgconfig directory.

[jacobwilliams]

I just can't quite get this working.

Here's my script. I gave up on conda and now just trying to use homebrew:

#!/bin/bash

# now: before running this, install homebrew and:
#
#  brew install libtool
#  brew install wget
#  brew install autoconf
#  brew install automake
#  brew install gcc
#  brew install pkg-config
#  brew install hwloc

set -e

STARPUVERSION=1.4.1
STARPUDIR=$PWD/starpu
STARPUINSTALLDIR=$STARPUDIR/install

rm -rf $STARPUDIR
rm -rf $INSTALLDIR

# try from brew:
export CXX=/opt/homebrew/bin/g++-13
export CPP=/opt/homebrew/bin/cpp-13
export CC=/opt/homebrew/bin/gcc-13
export FC=/opt/homebrew/bin/gfortran-13
export F77=/opt/homebrew/bin/gfortran-13
export AR=/usr/bin/ar
export RANLIB=/usr/bin/ranlib
export NM=/usr/bin/nm
export AS=/usr/bin/as

# build StarPU
mkdir $STARPUDIR
cd $STARPUDIR
STARPUINSTALLDIR=$PWD/install
wget https://files.inria.fr/starpu/starpu-$STARPUVERSION/starpu-${STARPUVERSION}.tar.gz
tar xf starpu-${STARPUVERSION}.tar.gz
cd starpu-${STARPUVERSION}
./autogen.sh
mkdir build
cd build
../configure --prefix=$STARPUINSTALLDIR --disable-build-tests --disable-build-doc --enable-blas-lib=none

make -j 4
make install

The result is that it starts to compile. I do get a million warnings like this:

<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
  CC       sched_ctx/sched_ctx_remove.o
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
  CC       sched_ctx/sched_ctx_delete.o
  CC       sched_ctx/two_cpu_contexts.o
  CC       sched_ctx/dummy_sched_with_ctx.o
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition

But in the end it errors out with this:

<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
f951: Warning: Nonexistent include directory '/Library/Python/3.9/include' [-Wmissing-include-dirs]
<command-line>:6:0:

Warning: "_FORTIFY_SOURCE" redefined
<command-line>:5:0:

note: this is the location of the previous definition
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
../../examples/cpp/add_vectors_cpp11.cpp:22:10: fatal error: cassert: No such file or directory
   22 | #include <cassert>
      |          ^~~~~~~~~
compilation terminated.
make[3]: *** [cpp/add_vectors_cpp11.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1

[sthibaul]

Your c++ compiler doesn't have the standard <cassert> header? You can try to replace that with <assert.h>

[jacobwilliams]

update: I've gotten it to compile. The main problem was the presence of the icc 32 bit C compiler in my path. Somehow that was messing things up. Once I got rid of that and updated the script a bit it seems to compile.

Still trying to figure out if it's actually working.

I'll post the updated script here for reference once I verify that it's working.