Resultados 1 a 4 de 4
  1. #1
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,573

    VPS "core dedicado" em processadores Intel com Hyperthreading habilitado

    Tenho observado um aumento de ofertas de VPS que oferecem explicitamente "cores" dedicados por preços que não cobririam sequer o custo do equipamento.

    Note-se que não estou falando de vCPUs ou frequências "garantidas" mas de alocação "exclusiva".

    Esse tipo de recurso será cada vez mais necessário com o crescimento do uso de containers e de aplicações que fazem uso intensivo de CPU ou requerem processamento em "tempo real". O modelo de negócios da maioria dos provedores de VPS não suporta esse tipo de processamento intensivo, usualmente limitando no contrato o nivel de utilização, claramente ou não. IMO não vejo como overselling ou má prática um provedor alocar centenas de VPS em um servidor fisico apropriado à carga média estimada para o perfil de consumidores que atende. O mesmo não posso dizer daqueles que cinicamente alegam que por estarem usando virtualização X ou Y não praticam overselling, uma dupla burrice e duplamente falso quando contabilizam processadores lógicos como se fisicos fossem.

    Pelos motivos acima, a proposta de VPS com cores dedicados tem o seu mercado. Porém, as ofertas de "cores" não entregam o prometido se o provedor estiver vendendo threads de processadores Intel anunciando-as como cores, o que parece ser prática generalizada -- que não fica restrito à famosa questão ignorância ou má fé. Se, por um lado, manuais técnicos de hipervisores alertam para esse uso indevido, por outro, "todo mundo faz isso" é a justificativa padrão. Entende-se. Se um provedor popular de "cores dedicados" entregar cores se colocará em posição desfavorável em preço aos que entregam threads à quem de fato não precisa de cores e procura esse tipo de oferta para se proteger de eventuais suspensões por "abuso" ou processamento irregular.

    Dito isso, existem outros aspectos que passam despercebidos mas podem fazer muita diferença. Por exemplo, o desempenho adicional (speedup) de core com Intel Hyperthreading habilitado sabidamente depende das aplicações mas também depende da geração do processador. Esse é um aspecto raramente comentado e virtualmente jamais testado. A Intel tem sucessivamente ampliado a capacidade de multiprocessamento dos cores adicionando unidades especializadas, ou seja, comparações utilizando aplicações "single thread" não capturam integralmente diferenças de desempenho entre microarquiteturas porque não contabilizam o speedup decorrente de avanços da tecnologia Intel HyperThreading.

    A Intel fornece manuais parrudos detalhados sobre a tecnologia e uma série de artigos que pretendem explicá-la mas IMO existem dissociações entre as abstrações e a implementação real. Por exemplo, é amplamente utilizado o conceito de "pipeline" para explicar a operação do core mas não é como funciona realmente. E dos comentários mais instigantes (fantástico) que encontrei, não existiria estrutura dedicada no core para processar 2 threads -- alegadamente seria possivel processar simultaneamente "n" threads e 2 seria o número "ideal" ... ou escolhido. Alegadamente a implementação faria uso de pools e tags. Os manuais não confirmam e não negam.

    A seguir vou postar algumas figuras que talvez possam ajudar a compreensão da tecnologia Hyperthreading e implementações, algumas extraidas do manual https://www.intel.com/content/dam/ww...ion-manual.pdf

    Uma boa descrição das etapas do pipeline pode ser encontrada aqui:
    PDF (12p) https://www.cs.sfu.ca/~fedorova/Teac...-threading.pdf








    Última edição por 5ms; 02-06-2017 às 10:27.

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,573

    Haswell microarchitecture










  3. #3
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,573

    Skylake microarchitecture








  4. #4
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,573

    Resumo

    At a high level, the easiest way to think about Intel's HyperThreading implementations is that the threads have their own registers(*), but share everything else -- particularly all of the processor's functional units and all levels of the processor's cache hierarchy.

    Modern processors employ a technique called pipelining to increase instruction throughput. In a pipeline, various dedicated pieces of hardware on the processor each perform particular functions needed to process an instruction, on different instructions at the same time. For example, while one part of the pipeline is executing instruction A, another part will be fetching instruction B, and another part might be committing (writing results to memory) instruction C. This allows the processor to be working on multiple instructions at once, and helps smooth out waits for data and other long-running operations.

    The pipeline isn't really a physical structure created on the chip - but it is encoded into the way the chip processes instructions. Specialized hardware and queues are set up all along the pipeline to keep things moving in the right direction. The number of stages and implementation specifics of a pipeline may change from one CPU model to another. The layout of the pipeline - number of stages, the specific layout of each stage, etc, is one of the main features we are referring to with each new named microarchitecture.

    The Front-End of the Pipeline

    The initial part of the pipeline is usually responsible for providing a stream of work for the back-end to operate on. For Intel x86-based processors specifically, the front-end is "in-order" while most of the back-end is not. This means that, at the beginning of the pipeline, instructions are processed in the same order as they are found in the program being run. Also on Intel x86 processors, the front-end is working on instructions, where as the back-end is working on micro-operations. Intel x86 processors use a CISC architecture, which means that within the pipeline, assembly instructions are broken down into smaller pieces, which we call micro-operations, or uops. It is the front-end's job to do this breakdown - called "decoding" the instructions.

    So for x86-based processors, the front-end does two main things - fetch instructions (from where program binaries are stored in memory or the caching system), and decode them into micro-operations. As part of the fetching process, the front-end must also predict the targets of branch instructions (if-type statements) when they are encountered, so that it knows where to grab the next instruction from. All sorts of specialized logic and hardware work together to do these functions - a branch predictor, a specialized micro-operation cache, particular decoders for both simple and complex instructions, and more. All these bits of hardware contribute toward the front-end's main goal of supplying work - in the form of micro-operations - to the back-end.

    The Out-of-Order Engine

    The back-end of the pipeline is responsible for executing the micro-operations the front-end generates. In order to make the best use of its resources, the back-end uses it's own bookkeeping system to keep track of each micro-operation, the pieces of data it requires, and its execution status. Then it executes the micro-operations in any order - according to when a micro-operations has all its data ready and when the execution resources are available. The bookkeeping and scheduling of micro-operations is fairly complex, and requires many dedicated queuing structures. It is when some of these queuing structures are full that the back-end cannot accept new micro-operations from the front-end - a situation referred to as "back-end bound pipeline slots".

    The execution resources that the back-end is keeping track of are called execution units. Each microarchitecture might have a slightly different layout and number of execution units available. These are the pieces of logic on the processor that perform specific functions, such as adding, dividing, logical shifting, loading from memory, etc. Once micro-operations have finished using the execution units and have all data loaded or stored, they are "retired" - meaning that they have finished their time in the pipeline. These uops are never explicitly converted back into instructions. An instruction is considered "retired" when all of its uops have retired, but this is really an abstraction of what happens - the back-end of the pipeline is dealing with uops only.



    (*) The architecture state consists of registers including the general-purpose registers, the control registers, the advanced programmable interrupt controller registers as well as some machine state registers. Logical processors share most resources on the physical processor: caches, execution units, branch predictors, control logic and buses.

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens
  •