search

JeffersonLab / qphix-codegen

Code Generator for the QPhiX library, Wilson Fermions
http://jeffersonlab.github.io/qphix-codegen/
1 stars 4 forks source link

Make -j is not inherited properly #12

Closed martin-ueding closed 7 years ago

martin-ueding commented 7 years ago

When one calls make -j, it will start a job server and then other make processes can inherit this and coordinate the number of processes running. By explicitly giving the option -j on the sub make, this behavior seems to be suppressed.

bjoo commented 7 years ago

Hi Martin, My problem here was that on my linux systems at least, if I did not give a -j option, sub makes would run with only 1 thread. NB: This was not true on my mac, but only on my linux nodes. This is why I gave the recursive_jN (qphix) or target_jN (qphix_codegen) CMake option, so I could make sub-builds build with that value of -j It seems clunky to me. What is the best way? to give -j but no value?

Best, B

On Jun 21, 2017, at 1:44 PM, Martin Ueding notifications@github.com wrote:

When one calls make -j, it will start a job server and then other make processes can inherit this and coordinate the number of processes running. By explicitly giving the option -j on the sub make, this behavior seems to be suppressed.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Dr Balint Joo High Performance Computational Scientist Jefferson Lab 12000 Jefferson Ave, Suite 3, MS 12B2, Room F217, Newport News, VA 23606, USA Tel: +1-757-269-5339, Fax: +1-757-269-5427 email: bjoo@jlab.org

martin-ueding commented 7 years ago

I am not sure. Just giving -j is not a good idea, that will spawn an unlimited amount of processes. There are around 500 compilation units each needing 300 MB of RAM. This is something that I can look into at some point, I just wanted to file an issue such that it does not get lost. The recursive_jN works fine for the moment, so let's just keep using that for now.

bjoo commented 7 years ago

Annoyingly, this is another feature of the fact that we have a sub "cmake; make” It seems the top level make environment is not passed down (inluding jobserver details). Incidentally I have no idea of how the jobserver is meant to work in actuality. This is somewhere I think where we can spend a lot of time digging, with maybe not so fruitful results. I agree to stick with the recursive_jN unless anyone suggests better.

Best, B

On Jun 21, 2017, at 1:51 PM, Martin Ueding notifications@github.com wrote:

I am not sure. Just giving -j is not a good idea, that will spawn an unlimited amount of processes. There are around 500 compilation units each needing 300 MB of RAM. This is something that I can look into at some point, I just wanted to file an issue such that it does not get lost. The recursive_jN works fine for the moment, so let's just keep using that for now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

Dr Balint Joo High Performance Computational Scientist Jefferson Lab 12000 Jefferson Ave, Suite 3, MS 12B2, Room F217, Newport News, VA 23606, USA Tel: +1-757-269-5339, Fax: +1-757-269-5427 email: bjoo@jlab.org

martin-ueding commented 7 years ago

The sub-make has to be invoked with cd subdir && $(MAKE) in the Makefile in order to get the job server stuff right. I assume that it passes a path to some UNIX socket for the communication. If you just call cd subdir && make, then the job server will not work correctly. Since our Makefiles are generated by CMake, that is another matter.

Even worse, nobody guarantees that we are using make. I prefer ninja to build my stuff because it handles output of multiple processes better. So I sometimes pass -G ninja to cmake. This should be passed along as well.

I might dig into that when I want to do some productive procrastination.