- 21 Jan, 2016 9 commits
-
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
- 20 Jan, 2016 8 commits
-
-
Pedro Gonnet authored
-
Pedro Gonnet authored
-
Pedro Gonnet authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
- 19 Jan, 2016 13 commits
-
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Pedro Gonnet authored
-
Pedro Gonnet authored
-
Pedro Gonnet authored
-
Pedro Gonnet authored
-
Pedro Gonnet authored
-
Pedro Gonnet authored
-
Pedro Gonnet authored
change title, it's a bit of a mouthful but more descriptive of what we're actually going to talk about.
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
- 18 Jan, 2016 2 commits
-
-
Matthieu Schaller authored
-
Matthieu Schaller authored
-
- 13 Jan, 2016 3 commits
-
-
Matthieu Schaller authored
Include parallel sort tasks in task dump and add support for MPI dumps Dumps multiple task/thread/rank files for multiple time steps and provides scripting support to process these into graphics for each rank and timestep. Matthieu, reasonably uncontroversial as only small changes to main.c to check. If you want to test use the new `-y 1` flag to dump thread info files and use `process_plot_tasks_MPI` to create the graphics and a web page to view them. See merge request !70
-
Peter W. Draper authored
-
Peter W. Draper authored
-
- 12 Jan, 2016 3 commits
-
-
Peter W. Draper authored
Overlapping tasks This is a back-port of some changes I made to QuickSched: instead of taking the first lockable task with the largest weight, look for a task that maximally overlaps with the previously executed task. This is done to maximize cache re-use, i.e. tasks with similar priorities operating on similar data will be scheduled closer to each other. I was already trying to do this by favouring tasks with the same super-cell as the previous task, but that was a bit of a mess. This should work much better. Peter, can you check this both for correctness and if it doesn't cause a performance regression? I don't really expect a measurable performance gain directly, but this will have a strong effect on some caching that @alepper is currently working on. Cheers! See merge request !75
-
Peter W. Draper authored
conflict in src/scheduler.c.
-
Peter W. Draper authored
init tasks and tasks_ind to make sure they're not freed. Fixes the bungled push to master I did just recently. See merge request !74
-
- 11 Jan, 2016 2 commits
-
-
Pedro Gonnet authored
-
Pedro Gonnet authored
-