0

I found the following quotation from another answer (Performance difference for multi-thread and multi-process):

Next, you can have CPUs with "hyperthreading", which can run (at least) two threads on a core very rapidly -- but, not processes (since the "hyperthreaded" threads cannot be using distinct address spaces) -- yet another case in which threads can win performance-wise.

Is this accurate? The two threads of a virtual core (hyperthreading) cannot be running different OS processes?

On a hyperthreaded machine, if I have a program architecture that uses "worker" processes that a "supervisor" process communicates with using sockets, would I be likely to see a performance increase by moving those worker processes into the supervisor process as threads (leaving the sockets and everything else the same)?

Harris M Snyder
  • 274
  • 1
  • 8

1 Answers1

1

First part of the question can be answered quickly, you can test it on your system if its the same.

On my old windows system with an intel CPU I can from the task manager set the affinity of different programs (or processes) to on each of the 2 HT of a core, seeing that they will actually both run there.

On the second question with Workers and Supervisors you could get a small performance gain (at least on Linux) by having them in the same process. This is because when you make a task switch you also make set the Page Table (intel CR3-register), and the code looks something like this during task switch:

if (newProcess != oldProcess)
  CR3 = new page table

Setting CR3 effectively invalidates the TLB as the page tables differ. The consequence is that the CPU must perform a page table walk to find the correct translations. On a 64-bit cpu a page walk will typical take 5 memory walks costing anything from 5*TLB 2 access (each ~3 cycles) to 5 * memory access (each ~300 cycles).

Surt
  • 15,501
  • 3
  • 23
  • 39