Implementations for solving least-squares. Master-worker implementations including asynchronous versions.
These were run on the Cori cluster using an interactive session. You could also use sbatch with an appropriate slurm script. Get an interactive session with
salloc -C gpu -N 1 --ntasks 20 -t 180 --cpus-per-task 1 -A m3898
Note that there is no GPU. This is cpu-only code. 20 is the number of CPUs and tasks.
There are three files you may run: centralizedPS.py, syncCentralPS.py and parallelGD.py. In addition, you need to randomly generate an instance of data using makeRandomLS.py. To run, use
srun python syncCentralPS.py
or
srun python centralizedPS.py
or
srun python parallelGD.py
An entire experiment can be run using ./runExperiment.sh.
There are command line arguments to choose the random delay amounts.
You need to ensure that the size of the matrix generated will be correct for the number of processes. If you set ntasks=n, there will be 1 master, n-2 workers, and 1 monitor. The monitor simply computes the function values for comparing performance of the different methods. So if you set ntasks=20, there will be 18 workers, 1 master, and 1 monitor. You need to ensure that the number of rows m in the matrix generated using makeRandomLS.py is a multiple of 18. You also need to set the variables m and d manually in centralizedPS.py (or whatever algo you are running) are correct (i.e. same as the actual data generated by makeRandomLS.py).
- centralizedPS.py: Async Master-worker implementation of projective splitting.
- syncCentralPS.py: Synchronous master-worker projective splitting
- parallelGD.py: synchronous accelerated GD using master-worker topology.
- singleProcPS.py: single threaded implementation to compare results with.
- Implement a differential encoding version of async PS
- Implement proximal-version of PS
- Implement baseline federated averaging