Resenha da Unidade 10 – Graphics Processing Units (GPU)

Artigo de Referência:

Changxin Li; Hongwei Wu; Shifeng Chen; Xiaochao Li; Donghui Guo; , "Efficient implementation for MD5-RC4 encryption using GPU with CUDA," Anti-counterfeiting, Security, and Identification in Communication, 2009. ASID 2009. 3rd International Conference on , vol., no., pp.167-170, 20-22 Aug. 2009
doi: 10.1109/ICASID.2009.5276924. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5276924&isnumber=5276889

 

Neste artigo, os autores procuraram demonstrar as vantagens da arquitetura GPU na execução de algoritmos de criptografia. Essa arquitetura tem conquistado grande relevância nos últimos anos dado, principalmente, o crescimento explosivo no mercado de games. No entanto, com a evolução das GPUs para uma arquitetura de propósito geral, passou-se a utilizá-las em escala para uma grande variedades de aplicações, desde simulações(nas mais diversas áreas de conhecimento), até aplicações no mercado de valores. Para desfrutar do que a arquitetura tem a oferecer, as aplicações precisam, basicamente, atender a um requisito: possibilidade de paralelização!

Coincidência ou não, os algoritmos de criptografia escolhidos pelos autores desfrutam da capacidade de paralelização, principalmente o de criptografia simétrica RC4, que consiste em operações XORs independentes, bit a bit, do texto claro com a chave de criptografia (expandida). Neste caso em particular, pode-se perceber facilmente que tal algoritmo também deve ter uma alta performance em uma CPU x86, haja vista que operações XORs são executadas diretamente como um instrução neste arquitetura, inclusive podendo desfrutar de pipeline. Desta forma, notamos que a característica de ser altamente paralelizável por si só não é suficiente para demonstrar a eficiência da GPU sobre CPU. A escolha de outro algoritmo poderia ter tornado essa diferença ainda mais evidente. Quanto ao MD5, por se tratar de um algoritmo de resumo/hash(não de criptografia), que realiza um conjunto maior de instruções, pode-se perceber melhor as vantagens de GPU sobre uma CPU.

Foi utilizada uma NVIDIA GeForce 9800GTX, contendo 128 GPU Cores e com suporte a plataforma CUDA. A implementação foi relativamente simples, sendo divida nos três estágios a seguir: 1) Os dados e uma chave de entrada são transferidas da CPU para a GPU. Ambos são armazenados na memória global da GPU. 2) O kernel Grid é invocado para processar o problema paralelamente. Como resultado, temos os dados criptografados em RC4 e seu respectivo hash em MD5. 3) Os dados são devolvido para a CPU.

Foi utilizada uma configuração de execução para processamento com 32 blocos, cada um executando 32 threads em paralelo(este é aquele parâmetro kernel <<<32,32>>>), sobre blocos de dados de 32bytes cada. Isso nos dá 32x32 linhas de processamento em paralelo. Com essa configuração eles conseguiram, inicialmente, um throughput de 71MB/s, o que, posteriormente, foi otimizado para 126MB/s). A otimização consistiu em fazer um melhor uso(ou seria o uso adequado?) das memórias internas da GPU. Cada thread no Grid consumiu 256bytes da memória compartilhada da GPU. Dado que cada bloco de Threads na NVIDIA utilizada é de 16384bytes, eles poderiam ter incrementado o número de threads por bloco para até 64 threads. No ensaio final, foram utilizados 256 blocos, cada um com 60 threads cada(ou seja, 15360 objetos rodando em paralelo), permitido um throughput de 217MB/s.

Para comparar os resultados com uma CPU, foi utilizado um AMD Sempron LE-1200, com clock de 2.12Ghz(o clock da NVIDIA é de 1.83Ghz). A velocidade do processamento deste problema está diretamente relacionado com o tamanho dos blocos a serem criptografados(blocos esses que são processados em paralelo). Segundo os autores, o throughput da CPU foi de 70MB/s, contra os 217MB/s da GPU. No entanto, não foi mencionado qualquer detalhe da implementação utilizada na CPU, tal como características de paralelização explicita, linguagem de programação/compilador utilizado e etc. Embora, do ponto de vista de performance, tenha ficado claro as vantagens da arquitetura GPU sobre uma CPU neste estudo de caso, ainda assim a comparação pecou pela impossibilidade de ser reproduzida, uma vez que não foram apresentados os detalhes do experimento.

Resenha da Unidade 9 – Arquiteturas Reconfiguráveis

Artigo de Referência:

A. Azevedo, R. Soares, I. S. Silva, “Implementação da DCT2D em arquiteturas reconfiguráveis utilizando a X4CP32”,Proceedings of Iberchip 02, Havana, Cuba, 2002.

A fim de demonstrar o poder e a flexibilidade das Arquiteturas Reconfiguráveis (AR), os autores do artigo fizeram uso de um cenário um tanto quanto comum hoje em dia, além de favorável para tais arquiteturas: uma aplicação que requer grande fluxo de dados e processamento. Em tempos de mobilidade em alta, o mercado pode aproveitar-se da necessidade por Arquiteturas capazes de realizar um bom trabalho (leia-se performance), consumindo pouca energia e, consequentemente, dissipando menos energia térmica. É ai que entram as ARs, nos permitindo vislumbrarmos a sua importância.

A AR utilizada foi um X4CP32, composto por grãos, células e uma UC. Como sabemos, a reconfigurabilidade da arquitetura é provida pelo grão. Nesta AR, o grão pode assumir dois modos de execução, a saber: modo processador ou bloco de ULA’s. As células, por sua vez, são responsáveis pela computação em si. Cada uma delas é composta por uma ULA, memória interna, uma pilha, um registrador acumulador, lógica de controle interno, 6 portas de comunicação e um canal para roteamento(é, tudo isso em cada uma das células J). Cada célula em um grão está ligada as demais por meio de barramentos dedicados de incríveis 32bits. A comunicação entre grãos distintos pode ser realizada por meio de roteamento ou, se possível, diretamente por barramento! Mas não para por ai. Essa AR é realmente interessante em cada um dos principais aspectos, como comunicação, barramentos, instruções, sincronismo, configuração do grão e etc.

O calculo da transformada discreta do cosseno, utilizado na codificação JPEG, é conhecido por seu alto grau de complexidade. Assim, no referido artigo, foi considerado um bom problema para implementação na AR. O algoritmo utilizado favorece o paralelismo e o uso de pipeline. A implementação ocupou uma área de 4x5 grãos, sendo alguns no modo de execução Processador e outros no modo Bloco de ULA. As constantes foram multiplicadas por 256, de modo a se trabalhar apenas com valores inteiros(truncados, claro). Apesar de o erro médio ter sido de apenas 0.00096265, esse valor já é suficiente para impossibilitar a aplicação da solução em casos mais importantes, como no tratamento de imagens médicas (que é uma grande necessidade na área de processamento de sinais). Embora os autores tenham conseguido reduzir um pouco mais essa taxa de erros(utilizando outros artifícios), ela continua sendo uma taxa de erros e, consequentemente, implicando em uma codificação com perdas.

Cada grão no modo processador possui três células, as quais trabalhando como ULA’s, sendo que 2 grãos foram utilizados para fazerem a parte principal dos cálculos(ou seja, 6ULA’s). Dessa forma, tem-se um dado a cada 10 ciclos(8 de deslocamentos, 1 de entrada e 1 de saída na célula). Desta forma, ao analisar a estrutura da implementação, temos 8 saídas a cada 10 ciclos em um pipeline completo. Isso, em outras palavras, significa que pode-se obter uma matriz 8x8 a cada 80 ciclos(essa matriz é resultante da primeira transformada discreta do cosseno, ou seja, 1D.). Repete-se o mesmo procedimento e, assim, teremos a transformada em 2D.

O FPGA utilizado foi um da família Flex 10KE, da Altera, que possibilitou um clock de 53,08Mhz. O resultado do desenho alcançado permitiu uma taxa de 70,7 imagens monocromáticas(640x480) por segundo. Outra implementação com foco no desempenho alcançou uma taxa de 141,4 imagens por segundo, ou seja, o dobro (também quase o dobro do custo J). Ambos apresentaram uma latência inicial de 160 ciclos. Em comparação com uma ASIC, o ganho foi de 14%, enquanto que o ganho em comparação com uma implementação em software foi de 137%. Levando em conta as características de desempenho e consumo elétrico, os resultados parecem promissores para um mundo mobile. No entanto, também deve-se atender a outros desafios, como o tamanho dos chips, o preço e, naturalmente, a “moda” do mercado.

Resenha da Unidade 8 - Barramentos e interconexão.

Artigos de Referência para a resenha:

Gallo12, R., & Kawakami, H. (2011). SCuP-Secure Cryptographic Microprocessor. Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais. Retrieved from http://www.ppgee.unb.br/sbseg2011/resources/downloads/sbseg/90828.pdf

SILVA, Yamar Aires da. Estudo e proposta de um novo documento de identificação eletrônica (e-ID) para o Brasil. 2007. xx, 147 f. Dissertação (Mestrado em Engenharia Elétrica)-Universidade de Brasília, Brasília, 2007.

Piccolo, Lara Schibelsky Godoy. Arquitetura do Set-top Box para TV Digital Interativa. Instituto de Computação – Unicamp, 2006. Disponível em http://www.ic.unicamp.br/~rodolfo/Cursos/mo401/2s2005/Trabalho/039632-settopbox.pdf

Elevando o nível de proteção...

A Arquitetura de Von Neumann, na qual os nossos dispositivos digitais dotados de processamento se baseiam, não seria tão eficiente nos dias de hoje sem o avanço dos barramentos. Ao pensarmos, em alto nível, em uma CPU executando instruções sobre dados, os quais foram obtidos, ambos, na memória principal, em um determinado instante e por um determinado motivo, pode nos influenciar a crermos que a velocidade da operação dependerá tão somente do clock da CPU, ou, ainda pior, do espaço de armazenamento da nossa memória principal. Mas, na realidade, o gargalo está em um nível mais baixo.

A Unidade de Controle (UC), naturalmente, precisa de um meio para “obter” dados da memória. Além disso, também é necessário um canal de sinalização, informando que o acesso será realizado. Não satisfeito, nosso inseparável amigo também requer outro meio para informar o endereço de memória que contém os dados/instruções necessários. Esses meios são, respectivamente, o Barramento de Dados, Barramento de Controle e o Barramento de Endereço de Memória. Nos processadores Intel, o barramento de dados passou a ter 64bits a sua disposição, um pouco antes que o barramento de memória, que atualmente também conta com 64bits em praticamente todos os novos processadores x86. Mas, qual a relação desses barramentos com “proteção/segurança”?

O Barramento de Dados e o Barramento de Endereço de Memória são, ambos, um canal entre a Memória Principal(MP) e o Registradores de Dados de Memória(RDM) e Registrador de Endereço de Memória(REM). Assim, embora o Barramento de Memória seja unidirecional (apenas a UC aciona a MP, e não o contrário), não ocorre o mesmo com o Barramento de Dados, no qual tanto a UC quanto a MP podem “depositar” dados/instruções. Essa interconexão entre a MP e o Registrador de Dados (ou o Acumulador) é análoga a interconexão entre dois dispositivos em uma Rede de Computadores, na qual fica mais fácil vislumbrarmos a necessidade de um Firewall neste canal.

O firewall é o elemento responsável por analisar o conteúdo dos dados que trafegam em um canal, “fazendo a separação entre o joio e o trigo”. Dessa forma, no contexto dos Barramentos de Interconexão em Chips, os projetistas decidiram que, em certos tipos de chips, era necessário um tipo de firewall no hardware, a fim de evitar que instruções/dados maliciosas possam passar da MP para o RDM(ou outros registrados, a depender da arquitetura) e, com isso, serem executadas pelo processador.

Conforme pode ser visto nas referências desse texto, várias são as abordagens para se conseguir um efeito de Firewall na interconexão de chips. Em smartcards mais antigos, por exemplo, pode ser exigir que a aplicação realize um processo de autenticação antes de poder carregar instruções/dados na MP. Ou seja, o firewall não está, de fato, na interconexão(barramento) entre a MP e o RDM, mas antes da MP. Essa abordagem, de fato, não é a mais segura, uma vez que uma aplicação após autenticada poderá depositar quaisquer tipos de instruções na MP(inclusive maliciosas), as quais, posteriormente, serão carregadas para os Registradores e executadas! Apesar de não ser ideal, é ainda melhor do que no caso de alguns Set-top Box para TVs digitais, que, embora tenham barramentos velozes, que interligam inclusive o controle remoto do usuário diretamente no barramento de dados da CPU(pelo menos é o que disseram o pessoal do artigo), não dispõem de um método para filtrar o conteúdo.

Por outro lado, smartcards mais elaborados, possuem um eficiente Firewall, que recebem o sugestivo nome de Firewall de Hardware (HWF). O HWF age controlando o acesso entre os mestres de barramento e os periféricos (repare que, neste caso, a proteção vai além de apenas a interconexão entre RDM e a MP). Dessa forma, pode-se evitar que qualquer periférico que tenha sido comprometido (como, por exemplo, o teclado de uma urna de votação eletrônica) possa ter acesso aos barramentos de conexão com dados em claro. Com uma aplicação corretamente escrita para essa arquitetura, o voto eletrônico é capturado e criptografado pelo processador. Caso a informação tente passar pelo barramento em claro (sem a criptografia), será impedida pelo HWF. Ao mesmo tempo em que, se um periférico tentar acessar o dado em claro, também poderá ser impedido. Propostas para Documentos de Identificação Eletrônicas (e-ID) seguem a mesma proposta, implemetando um HWF nos níveis mais baixos, a fim de evitar comprometimentos no chip.

Embora essa sofisticação seja incrivelmente funcional, não existem muitos relatos na literatura sobre incidentes de segurança causados pela falta de um HWF na interconexão do chip (pelo menos por enquanto). Ou, em outras palavras, em um nível tão baixo. Algo que as pesquisas não revelaram foi que, de fato, as maiores fraudes quase sempre ocorrem no Mais Alto Nível, literalmente. E isso, infelizmente, está além de qualquer chip(eletrônico). ;)

 

Arquitetura de Computadores - PPGI/UFPB

(Unidade 6)

O ano de 1936 foi, sem dúvida, um marco para a ciência (não só da computação). Um jovem matemático britânico, conhecido como Alan Turing, publicava o primeiro artigo que apresentava ao mundo o seu modelo de máquina universal. Era uma “simples” maquina de computar, composta de um cabeçote capaz de mover-se por uma fita, na qual lia e escrevia informações. Estava pronta a base para, praticamente, toda a computação existente até hoje! De lá para cá, muita coisa mudou, mas quase tudo permaneceu o mesmo (isso mesmo, não é um erro de digitação). Os computadores mais modernos que utilizamos atualmente são basicamente implementações da máquina universal, proposta por Turing em 1936.

A fita dessa máquina, hoje em dia mais conhecida como memória, sempre se manteve como um foco de esforços por parte dos projetistas de hardware, que buscam aperfeiçoar suas capacidades de armazenamento, velocidade e consumo elétrico. Inicialmente usadas em meio magnético, logo as memórias volátil passaram a ser elétricas, eliminando os gargalos mecânicos inconvenientes. Mas, claro, isso apenas não era suficiente J. Logo os computadores passaram a usufruir de vários níveis de memória, as quais variam basicamente em velocidade. As mais velozes, como as memórias cache, naturalmente são mais caras e menos acessíveis. A divisão em níveis teve como objetivo otimizar o acesso aos dados de memória, mas não provocando um grande impacto no custo. Por exemplo, ao invés de construir um computador apenas com memória cache como memória principal, constrói-se uma maquina com uma pequena parcela dessa memória (o que não trará grande impacto no custo), e aplicam-se mecanismos/algoritmos de gerenciamento, os quais buscarão garantir que os dados realmente úteis estejam, na maior parte do tempo, disponíveis na memória cache. Com isso, podemos simular uma memória de tamanho variável, apenas pelo gerenciamento da mesma.

A velocidade de acesso à memória principal não depende exclusivamente da sua própria tecnologia, mas, também, do barramento de dados de memória e do barramento de endereço de memória. Haja vista que a memória cache encontra-se praticamente dentro do processador, neste caso a velocidade dos barramentos não chega a ser um problema, o que, infelizmente, não é o caso das memórias *RAM. No entanto, nos últimos anos, a velocidade dos barramentos externos tem atingido valores mais altos, dando lugar à importância da velocidade interna do circuito de memória. Além disso, tais barramentos dobraram de tamanho, passando a ter 64 linhas (bits), não só no barramento de endereço, mas também no de dados. Com isso, ganhamos memórias muito mais velozes, além de apenas memórias de grande capacidade. É pena que, infelizmente, ainda é comum se ouvir propagandas de computadores com “muita memória” por preços relativamente muito baixos, enquanto outros computadores com “menos memória” (mas com uma tecnologia mais nova e muito mais veloz) por preços mais altos. Assim, o consumidor, mal influenciado, quase sempre termina fechando um belo mal negócio.

---------------------

Terminando de arrumar as referências ainda... minha internet deu problema ;\

 

 

(Resenha do Artigo:

FÁVERO, AL: “Suporte a Multiprocessadores Simétricos (SMP) em kernel Linux”, Universidade Federal do Rio Gande do Sul.)

Referências:

Open Source Development Labs, Inc., Linux Process Scheduler Improvements in Version

2.6.0, Disponível em http://developer.osdl.org/craiger/hackbench/. Acesso em abril 2004.

Rick Lindsley, What's New in the 2.6 Scheduler, Disponível em

http://www.linuxjournal.com/article.php?sid=7178 . Acesso em abril 2004.

Enkh Tumenbayar, Linux SMP HOWTO. Disponível em

http://www.tldp.org/HOWTO/SMP-HOWTO.html. Acesso em abril 2004.

Hank Dietz, Linux Parallel Processing HOWTO, Disponível em

http://www.tldp.org/HOWTO/Parallel-Processing-HOWTO.html. Acesso em abril 2004.

Intel Corporation, MultiProcessor Specification,Version 1.4 May 1997.

Arquitetura de Computadores - PPGI/UFPB

Unidade 5

Desde meados de 2002, quando a Intel lançou a série dos incríveis processadores Pentium 4, os quais chegavam a atingir clocks na faixa dos 3,8Ghz, os seus engenheiros e projetistas começaram a levar a sério os problemas decorrentes do aquecimento destas pequenas pastas de silício. Já era passada a hora de migrar de paradigma. Assim, finalmente, foram empenhados esforços nos Multiprocessadores Simétricos, os famosos SMPs, no sentido de tornar-lhes, de fato, a nova tecnologia dominante.

Os SMPs são, em linhas gerais, arquiteturas onde grupos de processadores, independentes, podem trabalhar conjuntamente. De fato, essa foi uma solução realmente plausível. Levando em conta que o Sistema Operacional realize um escalonamento de forma eficiente, pode-se ter dois núcleos de 1,5Ghz funcionando como um único núcleo de 3Ghz, mas eliminando uma série de problemas que se teria com este, como aquecimento e, diga-se de passagem, custo ($D)! Nesta arquitetura, tem-se núcleos realmente independentes, cada um com sua própria Unidade de Controle, ULA, registradores e cache. Como já era de se esperar, eles compartilham a mesma memória principal e, consequentemente, o mesmo barramento de memória, além da entrada/saída. Este gargalo, que chega a ser uma desvantagem no que diz respeito ao desempenho, passa a ser uma grande vantagem no quesito de simplicidade no modelo de programação (justamente ao contrário dos MPPs). Isto é, desde que os implementadores do Sistema Operacional, mais especificamente dos algoritmos de escalonamento de processos, tenham feito as suas atividades de casa (isso, eles tinham tempo para fazer coisas legais :D)

De inicio, os Sistemas Operacionais (SOs) não cumpriam muito bem o seu papel de gerenciamento dos multiprocessadores, o que culminava em certo desperdício desses recursos. Mas, ainda assim, graças a esse trabalho dos SOs, os programadores de aplicações puderam, simplesmente, desfrutar dos SMPs de forma transparente (obviamente, usando processos multithreads!). Com isso, ganha-se: desempenho, disponibilidade (haja vista que a falha em um core não afetará os demais), crescimento incremental, entre outras vantagens.

Mas, nem tudo são rosas. Enquanto, em teoria, uma arquitetura SMP possa escalar para até 256 processadores simétricos, o mecanismo de escalonamento presente no GNU\Linux “só” suporta até 64 destes (considerando o Kernel v2.6). Embora até pouco tempo esse número fosse bastante suficiente, atualmente, com a explosão da virtualização & cloud computing, já se é relativamente comum data centers com arquiteturas SMPs com até 128 multicores. A boa (ou será má?) notícia, é que este limite de 64 trata-se de software. Mas não é software de user space, estamos falando do nosso amigo mais velho, o Kernel. Um cara que só “conversa”, digamos, com os “mais chegados”.

(Resenha do Artigo:

FÁVERO, AL: “Suporte a Multiprocessadores Simétricos (SMP) em kernel Linux”, Universidade Federal do Rio Gande do Sul.)

Referências:

Open Source Development Labs, Inc., Linux Process Scheduler Improvements in Version

2.6.0, Disponível em http://developer.osdl.org/craiger/hackbench/.

Rick Lindsley, What's New in the 2.6 Scheduler, Disponível em

http://www.linuxjournal.com/article.php?sid=7178 .

Enkh Tumenbayar, Linux SMP HOWTO. Disponível em

http://www.tldp.org/HOWTO/SMP-HOWTO.html.

Hank Dietz, Linux Parallel Processing HOWTO, Disponível em

http://www.tldp.org/HOWTO/Parallel-Processing-HOWTO.html.

Intel Corporation, MultiProcessor Specification,Version 1.4 May 1997.

Em épocas de Cloud Computing, onde o homem, com toda a sua astúcia, bolou um novo nome para um paradigma antigo, a virtualização passou a ocupar uma posição privilegiada neste cenário. Como sempre, a busca é por fazer mais, com menos (leia-se: otimizar os lucros $$). Mas qual seria a relação entre a Cloud Computing e a Virtualização? E estas, por sua vez, com os Processadores Modernos e, ainda, todos estes com a redução de custos?

Tudo começou na década de 69, quando finalmente o homem conseguiu implementar a tão esperada multitarefa no Sistema Operacional Unix(antes disso, em 61, já se tinha feito em um outro SO). Com isso, foi possível usufruir do escalonamento de tarefas e, finalmente, causar a impressão de paralelismo. Muitas tarefas poderiam ser executadas em paralelo! Algum tempo depois, vieram novas tecnologias de hardware, visando melhorar esse suporte multitarefa já suportado pelo SO, tais como pipeline, superpipeline, execução especulativa, vários níveis de cache(apelação) e outros mais. A Intel apelou e lançou o Hyper-Threading, tecnologia que cria novos processadores virtuais, usufruindo de um único processador físico. O interessante desta tecnologia é que cada processador virtual possui o seu próprio conjunto de registrados e controlador de interrupção(também virtuais, claro)! Isso mesmo, um processador Virtual, com os seus respectivos registradores!

Os anos passaram e novas tecnologias surgiram, algumas foram modificadas, outras aprimoradas e outras apenas mudaram de nome (e de preço). Com a possibilidade de executar maquinas virtuais em um único hardware, cada qual com seu próprio processador virtual, e a garantia de isolamento(inicialmente via software), o mercado ficou “quente”. Surgiram, então, os processadores com conjuntos específicos de instruções para a virtualização, os famosos Intel-VT e AMD-V. Com eles, as maquinas virtuais podem comunicar-se com o hardware utilizando esse conjunto de instruções especiais, em detrimento de uma espessa camada de software que era utilizada anteriormente (na chamada virtualização total).

Este cenário turbinou o mercado de TI! Muitas empresas pelo mundo passaram a vender o produto dos seus sonhos: um produto Virtual! A infraestrutura de TI passou a ser vendida como um modelo “pague pelo uso”. Os clientes pagam pelo uso de uma maquina virtual, com processadores virtuais e memória virtual. A Intel e AMD, por sua vez, vendem ainda mais os seus “novos” processadores, que, na verdade, não são tão novos assim(a Intel, por exemplo, já tinha tecnologia VT desde o Pentium 4, só que com outro nome). Todo esse mercado chama-se Cloud Computing. Um modelo de negocio que, do ponto de vista tecnológico, nada tem de novo. =)

 

Referências:
Hardware virtualization trends: http://www.usenix.org/events/vee06/full_papers/vandoorn-keynote.pdf
Intel VT: http://www.intel.com/technology/virtualization/
Virtualização cada vez mais fascinante e séria: http://blogs.forumpcs.com.br/flavio_xando/2006/04/24/virtualizacao-cada-vez-mais-fascinante-e-seria-parte-1/
Como funciona a tecnologia de virtualização da Intel: http://www.clubedohardware.com.br/artigos/Como-Funciona-a-Tecnologia-de-Virtualizacao-da-Intel/1144/1
Tecnologia Hyper-Threading: http://www.clubedohardware.com.br/artigos/163