Are both threads on a physical CPU treated equally?
Sim. Não há preferência na alocação dos recursos de execução do núcleo para um thread ou outro. (O que é um "recurso de execução"? Veja o artigo que eu relacionei abaixo. Mas exemplos são coisas como os registros arquitetônicos (IP, SP, EAX, etc.), as "unidades de execução" que implementam operações específicas como aritmética, etc. / p>
As we know, hyper threading on intel CPUs is a system in which each physical core is presented as 2 virtual cores to the OS.
Na verdade, ele é apresentado apenas como duas coisas que parecem ser OS-para-ser-núcleos ou dois "processadores lógicos", como o Windows os chama. (Apesar do que o Ramhound alegou). Se você tem o HT desativado, então cada núcleo tem apenas um LP, então a mesma terminologia é usada.
Se você tiver um sistema operacional não compatível com HT, seu núcleo com HT ativado será parecido com dois núcleos e será enumerado e usado dessa maneira pelo sistema operacional. Na verdade, este foi o caso no Windows 2000, que não tinha conhecimento de qualquer HT.
These 2 virtual cores give the processor the ability to context switch between 2 execution units (threads @ virtual cores) on events that are unknown to the OS (page faults, other cpu-internal events) that would normally make the CPU waste cycles waiting on other IO events.
Isso não é realmente como funciona (e as falhas de página, eu adicionaria, são mais conhecidas do sistema operacional! Talvez você esteja pensando em latência de acesso à memória). O processador habilitado para HT não faz nada como uma alternância de contexto no nível do sistema operacional entre threads. Lembre-se, um núcleo HT realmente enumera dois processadores (lógicos) diferentes, cada um com seu próprio conjunto de registros arquitetônicos, etc. Em um comutador de contexto de encadeamento, o conteúdo desses registros é copiado para a memória (no objeto de encadeamento) e os registros são carregado a partir do contexto salvo de algum outro segmento. Isso não acontece no HT, porque os registros (e muitos outros recursos) são duplicados pelos dois LPs. Assim, o estado de cada LP é mantido continuamente dentro da CPU.
Mas há outros recursos que não são duplicados. O HT permite que o firmware do processador use recursos de execução, recursos que seriam desperdiçados se apenas um LP estivesse em execução, para suportar as atividades de um segundo LP. Aqui está uma descrição muito boa: link
By default, an OS does not need to take hyper-threading into account. All cores will eventually do the work, only difference being that now not all visible/virtual cores may process at the same speed. Work scheduled for 2 threads on the same physical core (VCPU0+1 -> CPU 0) will not be as fast as work scheduled on 2 different cores (VCPU0+2 -> CPU 0 + 1).
Tudo correto. O Windows 2000 não tinha conhecimento do HT, mas quando foi executado em um único núcleo de CPU com HT habilitado, ele "viu" dois processadores e os usou. (Devido à ordem de enumeração com o firmware inicial para tais plataformas, se você estivesse executando uma edição do Win2K que suportava apenas dois processadores, infelizmente usaria dois LPs dentro de um dos pacotes de CPU! Este foi posteriormente corrigido com um firmware ("BIOS ") atualização que mudou a ordem da aparência dos LPs nas tabelas ACPI.)
From what I've researched, 'hyper-threading' aware OSs will go as far as to try and schedule work per physical cores before doubling up on scheduling on 'virtual cores'.
O Windows certamente funciona. Eles tentam usar apenas um LP por núcleo. Por exemplo, ao procurar um LP ocioso para executar um thread recém-Ready, o agendador do Windows primeiro tenta encontrar um LPs ocioso em um núcleo onde ambos LPs estão ociosos.
I usually see this as the 'even' VCPU getting scheduled first (fill VCPU 0+2 before 1+3). Are both the 'even' and 'odd' thread equal?
Bem, eles são iguais, pois não há preconceito interno dentro do núcleo para um LP sobre o outro. Pode ser que, por acaso, o trabalho seja feito mais rápido do que o outro, porque o encadeamento em execução em um precisa de menos recursos de execução do que o outro.
Na verdade, é algo de uma deficiência de HT, a propósito, que a CPU habilitada para HT não implemente qualquer conceito de prioridade entre os dois LPs. Digamos que você tenha dois encadeamentos vinculados à computação, que são de prioridade diferente para o sistema operacional. Pelas regras do sistema operacional, se você tivesse apenas um processador lógico, o thread de maior prioridade receberia praticamente todo o tempo da CPU. Mas, suponha que temos dois LPs livres que estão no mesmo núcleo. O firmware central tentará executá-los aproximadamente igualmente, mesmo que não seja realmente o que o sistema operacional deseja. (Pelo menos, a última vez que eu olhei para esses detalhes, este foi o caso.)
(theres not actually a 'hyper thread' virtual CPU). In other words, is there not a primary/secondary 'thread' for a physical CPU?
Correto. Não há. By the way, CPUs e núcleos de CPU não "têm segmentos". Um processador lógico pode executar um encadeamento. Quanto mais LPs você tiver, mais threads podem ser "computados" ao mesmo tempo.
If i schedule work on just VCPU 1, will it perform the same as if i just scheduled on VCPU 0?
Sim.
Assuming that, if equal work is scheduled on both, will it take roughly twice as long for both threads to complete?
Bem, não. O ponto principal do HT é que um núcleo normalmente tem mais recursos de execução disponíveis do que qualquer outro thread pode usar. Ao apresentar o núcleo como dois LPs, dois threads podem ser executados "ao mesmo tempo" e ter menos recursos de execução em ociosidade. Com a maioria das threads você pode esperar que seus dois threads sejam concluídos em algo entre 1,4x a 1,7x o tempo que apenas um deles teria recebido.
Um caso extremo seria se um dos encadeamentos estivesse realizando quase toda a aritmética inteira, e o outro quase todo o trabalho de ponto flutuante. Ainda assim, é improvável que você obtivesse o mesmo desempenho como se os dois encadeamentos estivessem sendo executados em dois núcleos diferentes, devido a problemas compartilhados de cache L3 e largura de banda de memória. Mas se ambas as threads não estão fazendo muito trabalho intensivo de memória, você pode chegar bem perto.