This diagram was really cool for me because in previous classes, I'd worked under the assumption that multiple threads make things happen at the same time (but really, it's having multiple ALUs that does that). Threads only hide the amount of time it takes to get cached information, and it will only appear that multiple threads make things happen at the same time IF utilization is good (meaning when all the other threads are inactive, there is one thread that is executing its instructions ideally)
adamsiwiec
@lee I also find this very interesting because you can simply hide the fact that latency even exists by constantly switching stalled loads between threads. I am not sure if I follow you when you say "it will only appear multiple threads make things happen at the same time". What I got from this illustration was that there can only ever be one thread executing instructions at any given time, therefore multiple threads aren't doing more but are just being more efficient with the time they are on the ALU. That's where utilization becomes the big word rather than spreading the load across multiple threads.
This diagram was really cool for me because in previous classes, I'd worked under the assumption that multiple threads make things happen at the same time (but really, it's having multiple ALUs that does that). Threads only hide the amount of time it takes to get cached information, and it will only appear that multiple threads make things happen at the same time IF utilization is good (meaning when all the other threads are inactive, there is one thread that is executing its instructions ideally)