I assume that since you have comments enabled, you don't mind them :-). I'd be interested to hear your thoughts here. I don't like persistent threads for a few reasons:
1. It doesn't seem very scalable. If there are 1000 tasks, then each thread has to evaluate 1000 if statements to see what task to evaluate after dequeue(according to my understanding). 2. It is totally ignorant of SIMD architecture (again according to my understanding). 2 threads can dequeue 2 totally different tasks (leading to branch divergence). 3. The turnaround time between 2 work-groups in the non-PT case (one scheduled and one waiting for resources) seems fundamentally lower than the turnaround time between processing work and then dequeueing new work off a task queue in system memory. 4. It seems like a very manual process in current machines/languages (the programmer is required to manage tasks queues/load balance). Though I guess this is not really fundamental to the idea.
I assume that since you have comments enabled, you don't mind them :-). I'd be interested to hear your thoughts here. I don't like persistent threads for a few reasons:
ReplyDelete1. It doesn't seem very scalable. If there are 1000 tasks, then each thread has to evaluate 1000 if statements to see what task to evaluate after dequeue(according to my understanding).
2. It is totally ignorant of SIMD architecture (again according to my understanding). 2 threads can dequeue 2 totally different tasks (leading to branch divergence).
3. The turnaround time between 2 work-groups in the non-PT case (one scheduled and one waiting for resources) seems fundamentally lower than the turnaround time between processing work and then dequeueing new work off a task queue in system memory.
4. It seems like a very manual process in current machines/languages (the programmer is required to manage tasks queues/load balance). Though I guess this is not really fundamental to the idea.
Totally agree. When my framework is released, I will have addressed some of these issues (all except the first).
ReplyDelete