____ _ | __ )| | ___ __ _ | _ \| |/ _ \ / _` | | |_) | | (_) | (_| | |____/|_|\___/ \__, | |___/
_ _ _/_| |__ ___ _ __| |_ _ _/_ / _ \ '_ \ / _ \ '__| | | | |/ _ \ __/ |_) | __/ | | | |_| | __/ \___|_.__/ \___|_| |_|\__,_|\___|

[2025-09-24][Daily]

Comparing the impact of the image size on starpu scheduling

vite ./28x28x3-images-scheduling-result.trace
vite ./512x512x3-images-scheduling-result.trace
# For wayland users
env -u WAYLAND_DISPLAY vite ./28x28x3-images-scheduling-result.trace
env -u WAYLAND_DISPLAY vite .5512x512x3-images-scheduling-result.trace

Parallelization of DAHL tasks, fully read for each cpu, showing they
are 99% of time sleeping — Scheduling of DAHL tasks on a dataset with 28x28x3 images.

When using 28x28x3 images the tasks are very small which make it way hard for starpu to schedule tasks on multiple cpu. We even notice a lot of overhead and scheduling on the traces. I knew that it was probably linked to the task size but wanted to improve more my parallelizion before trying this.

Better parallelization, we see more green, which indicates actual
work being done — Scheduling of DAHL tasks on a dataset with 512x512x3 images.

So we notice that 512x512 images lead to way better scheduling, e.g. tasks a executed (almost) continously and are spread on every cpus. We still notice some sleep time in red, this is caused by the gather functions (block_sum_z_axis, tensor_sum_t_axis...) that reduces the batch results in order to update weights and biases. this could probably be fixed by using built-in starpu reduce capabilities, because right now I simply looping through the datas and summing "by hand" at the end of each "layer batch".

This is a pretty interesting result because it showcases the limitations of using a TGCS. Of course, using bigger dataset that requires more computation will make DAHL shine because it will parallelize well. Nevetherless, we should probably investigate more about the task granularity: it could be really interesting to have ways to "cut" or "gather" tasks together depending on the size of the input data. Maybe for the 28x28 images we should do data parallelism? and simply pack the tasks together into a big "per batch task".

So we have many ideas to try, however they will be limited by the code.

< Previous post | Next post >