Question 1: to assign two threads to the four execution contexts, should we assign them to different cores so that each thread can take advantage of 8 ALUs (8-wide SIMD instruction)?

Question 2: would the additional pthread be stored in cache?

Typo: Do you mean "up to 4 instructions per clock" for the processor, in the second point?

Question 1: I agree with @suninhouse. I would assign each thread to a different core (one thread per core) just so each thread can have the SIMD and scalar exec units to itself.

Question 2: @suninhouse, not sure what you mean. But I think the additional pthread would be managed by the kernel (thread context would be in memory) and be scheduled (then context is loaded to registers) once the kernel preempts one of the four executing threads.

I agree with @bmo that it should be up to 4 instructions per clock.

Question 1: I agree that both threads should be assigned to different cores, but my reasoning is that while on different cores, both threads can run in parallel. If they were on the same core but in different execution contexts, only one of them can run at a time.

Question 2: I think that if we have 5 threads, the OS must intervene. What I would do is first assign 4 threads to each EC on the chip. Then, I think that every time that there is a syscall, the OS swaps off the process that is doing the syscall, and puts the 5th process in its place in the EC. Additionally, each core should have a timer that would cause an interrupt after a certain amount of time, to prevent processes from running too long. Of course, the OS could also keep track of estimates of how many clock cycles each thread has executed, to try to distribute them as fairly as possible.