As I understand, when you create tasks, they can get allocated to different cores/threads, but what exactly is the difference between creating a task and spawning a thread for example, with std::thread?

I think the programmer needs to allocate the work to each spawned thread. When you create tasks, you are only telling the compiler that the chunk of the code can be executed independently.

Are tasks mapped to threads via some sort of 'task pool' where anytime a thread finishes it's current task it checks the pool for a new one? Or are they allocated to particular threads at the start?

So if I have more tasks than hardware threads, do we have a 1-1 mapping of hardware threads to tasks? Or do the threads behave like consumers of some task queue? Does ISPC combine task and SIMD at the same time? In programming assignments tasks seem to get more speedup than we would expect from multithreading alone.

From my understanding, @kcoran, tasks are just a way of abstracting work that needs to get done, and we can create more tasks than threads. If there are tasks remaining, threads can pick up tasks when they are done working with their current one. This is why we see gains in Mandelbrot runtime when creating more than 8 ISPC tasks; some tasks had unequal amounts of work.

@legoat, I'd like to follow up to see if the course staff or other students can expound upon the difference between std::threads and ISPC tasks in that there must be some under-the-hood monitoring to make possible an efficiency gain in the Mandelbrot Assignment 1 task example where there are intermediate computations enabling even faster performance that what a thread offers (i.e. another execution context ready to go).