Comments (7)
Here's a take on implementing this in ScaLAPACK, so far just the BLACS library. If this seems like a good direction, can @weslleyspereira or someone do the other directories? Or I can, but may not have time immediately. I use this myself and have seen several people burned by make -j
failing, so it seems useful to fix.
https://github.com/mgates3/scalapack/tree/non-recursive-make
mgates3@d51c709?diff=split
from scalapack.
Upon further inspection, make -j lib
is still buggy, probably because of this:
$ cat SRC/Makefile
[...]
single: $(SLASRC) $(SCLAUX) $(ALLAUX)
$(ARCH) $(ARCHFLAGS) ../$(SCALAPACKLIB) $(SLASRC) $(SCLAUX) \
$(ALLAUX)
$(RANLIB) ../$(SCALAPACKLIB)
complex: $(CLASRC) $(SCLAUX) $(ALLAUX)
$(ARCH) $(ARCHFLAGS) ../$(SCALAPACKLIB) $(CLASRC) $(SCLAUX) \
$(ALLAUX)
$(RANLIB) ../$(SCALAPACKLIB)
double: $(DLASRC) $(DZLAUX) $(ALLAUX)
$(ARCH) $(ARCHFLAGS) ../$(SCALAPACKLIB) $(DLASRC) $(DZLAUX) \
$(ALLAUX)
$(RANLIB) ../$(SCALAPACKLIB)
complex16: $(ZLASRC) $(DZLAUX) $(ALLAUX)
$(ARCH) $(ARCHFLAGS) ../$(SCALAPACKLIB) $(ZLASRC) $(DZLAUX) \
$(ALLAUX)
$(RANLIB) ../$(SCALAPACKLIB)
[...]
The target files are being overwritten by the different rules, and one may end up with errors such as:
/usr/bin/ar: ../libscalapack.a: error reading blacs_grid_.oo: file truncated
/usr/bin/ar: ../libscalapack.a: error reading free_handle_.o: file truncated
from scalapack.
Just FYI, one functioning approach (at least that's what's being done when building ScaLAPACK in PETSc) is available in this commit: https://bitbucket.org/petsc/pkg-scalapack/commits/bf5290f5d002fe43a6fc59f83730ff5141860380. But I don't know if you'd be willing to merge that in @langou?
from scalapack.
Hi @prj-. I agree, there is a problem there. Thanks for taking your time to explain this!
I am sorry but I am not sure I understood your suggestion for the use of https://bitbucket.org/petsc/pkg-scalapack/commits/bf5290f5d002fe43a6fc59f83730ff5141860380. Are you suggesting we call $(ARCH) $(ARCHFLAGS) $(SCALAPACKLIB) ...
only once for all precisions? Or is it something else?
Using a single call of $(ARCH) $(ARCHFLAGS) $(SCALAPACKLIB) ...
is a good way to go in my opinion. That is also working on LAPACK (https://github.com/Reference-LAPACK/lapack/blob/a7c0392a190998f550cbf064f711b9575c8410cf/SRC/Makefile)
ALLOBJ = $(SLASRC) $(DLASRC) $(DSLASRC) $(CLASRC) $(ZLASRC) $(ZCLASRC) \
$(SCLAUX) $(DZLAUX) $(ALLAUX)
ifdef USEXBLAS
ALLXOBJ = $(SXLASRC) $(DXLASRC) $(CXLASRC) $(ZXLASRC)
endif
ifdef BUILD_DEPRECATED
DEPRECATED = $(DEPRECSRC)
endif
.PHONY: all
all: $(LAPACKLIB)
LAPACKLIB_DEPS := $(ALLOBJ)
ifdef USEXBLAS
LAPACKLIB_DEPS += $(ALLXOBJ)
endif
ifdef BUILD_DEPRECATED
LAPACKLIB_DEPS += $(DEPRECATED)
endif
$(LAPACKLIB): $(LAPACKLIB_DEPS)
$(AR) $(ARFLAGS) $@ $^
$(RANLIB) $@
With this kind of approach, I think we would still be able to build for a single precision type.
from scalapack.
Are you suggesting we call
$(ARCH) $ (ARCHFLAGS) $(SCALAPACKLIB) ... only once for all precisions? Or is it something else?
I'm now realizing that the trick there is indeed to have a single rule for all precisions, which may not be acceptable to you.
With this kind of approach, I think we would still be able to build for a single precision type.
Right, I think this file https://bitbucket.org/petsc/pkg-scalapack/src/bf5290f5d002fe43a6fc59f83730ff5141860380/Makefile.objs could be parsed to split objects among the different precisions. (not sure whether this is really needed) Then, the Makefile
would match the one of LAPACK indeed.
from scalapack.
Using a single ar cr
is the right thing to do, rather than multiple ar cr
updating the same file. In terms of correctness and speed, I advocate moving to a non-recursive Makefile, where the top-level Makefile can see the whole dependency DAG. See "Recursive Make Considered Harmful". A non-recursive Makefile could be either a single Makefile for the entire project (SLATE uses this approach), or a top-level Makefile that includes Makefiles for each sub-directory (MAGMA uses this approach), which has the same logical effect. With this non-recursive structure, linking a shared library (.so
) is easy, too.
Here's an example non-recursive Makefile structure. I'm sure there are many more subtleties in ScaLAPACK's Makefiles.
There are ways to write it such that running make
in, say, the BLACS directory compiles only the BLACS, but I suspect this is overkill for ScaLAPACK.
The use of make single double complex complex16
seems inherently problematic for parallelism. It defines 4 targets that all write via ar cr
to the same library. Better would be to define 4 variables that select the appropriate files to go into $(lib_obj). E.g., from the example repo:
single ?= 1
...
ifeq ($(single),1)
lib_obj += $(dir1_s_obj)
endif
from scalapack.
Thanks for the complete answers, @mgates3 !! I also don't know if I have time to work on it now, but I will keep your solution in my radar.
from scalapack.
Related Issues (20)
- MPI not linked during build? HOT 9
- Adopt a conservative ABI / SOVERSION policy HOT 1
- xshseqr and xdhseqr fail with FPE if run in parallel HOT 4
- build errors on GCC 10 (gfortran) HOT 2
- Wrong lwmin in pdstedc HOT 1
- Compiling With mpich ERROR undefined reference to `MPI_Type_free' HOT 1
- Input parameters checks in p?potri don't work. HOT 1
- Compilation issue - missing function definitions? HOT 8
- Instaled library maintains RUNPATH HOT 2
- MpiInt is wrong and should be removed HOT 3
- Wrong description of punmrq, punmlq functions
- use CMAKE_INSTALL_LIBDIR to allow for library installation in multiarch contexts HOT 1
- p*trrfs not listed in SRC/Makefile or SRC/CMakeLists.txt HOT 1
- Wrong pdlapiv or pdlapv2 output in ScaLAPACK HOT 2
- 2.2.1 release HOT 1
- Argument mismatches
- Build fails with strict-aliasing violations.
- CMake issues for building scalapack with VS2022 in windows
- Build failed due to implicit declaration HOT 1
- Wrong output for `igebs2d`, `igebr2d` (matrix broadcast) in ScaLAPACK
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from scalapack.