1) Muitos aplicativos de software precisarão ser modificados para aproveitar processadores multicore, dividindo tarefas em threads para serem executadas simultaneamente. 2) Há diferentes abordagens para programação multithread como segmentação explícita e métodos dirigidos pelo compilador como OpenMP. 3) Desenvolvedores precisarão testar aplicações multithread para evitar bugs como condições de corrida e otimizar o desempenho aproveitando todos os núcleos da CPU.

1. Multithreaded Tecnologia & Processadores multicore
Preparando-se para CPUs de próxima geração - CRAIG Szydlowski
Muitos aplicativos de software estão prestes a dar uma virada de cabeça para baixo na
transição de CPUs de single para implementações de múltiplos núcleos / Cores. Em novos
projetos, desenvolvedores de software serão encarregado de manter múltiplos núcleos
ocupados para evitar deixar desempenho baixo. Em projetos, você será confrontado com o
desafio de ter aplicações single-threaded funcionando de forma eficiente em múltiplos
núcleos. Programas precisarão servir-se de tópicos de código que podem ser distribuídos em
vários núcleos de forma eficiente. O código rompe uma tarefa em sub-tarefas, software
chamado de "threads", que é executado simultaneamente e de forma independente.
Código de Listagem tem sido a regra em um número de pedidos ha algum tempo, como redes
de área de armazenamento. Utilizando tecnologia Hyperthreading da Intel (a empresa em que
trabalho), aplicações de armazenamento implanta tarefas simultâneas para tirar proveito do
tempo ocioso da CPU, ou recursos subutilizados, como quando os dados são recuperados da
memória. Portanto, as ferramentas e os conhecimentos já estão disponíveis para escrever e
otimizar o código threaded. Sistemas operacionais como o Windows XP, QNX, e algumas
distribuições do kernel Linux foram otimizados para threading e está pronto para suportar os
processadores da próxima geração.
Aplicações embarcadas não são inerentemente threaded e pode exigir algum software de
desenvolvimento para se preparar para CPUs multicore. Neste artigo, eu examino a
motivação dos vendedores da CPU para se deslocar para multicores, as ramificações de
software correspondentes, bem como o impacto sobre os desenvolvedores de sistemas
embarcados.
"Todas essas implementações requerem processamento do código da CPU para utilizar o seu
potencial da computação"
Terminologia arquitetura de CPU
A terminologia para descrever várias encarnações da arquitetura da CPU é complexa.
A Figura 1 descreve o desenvolvimento físico de três interpretações multithread diferentes.
Figura 1 (a) mostra uma configuração dual-processor. Duas CPUs individuais compartilham
um barramento comum do Processador (PSB – Processor Side Bus), que interfaces para um
chipset com um controlador de memória. Cada CPU tem seus próprios recursos para executar
programas. Esses recursos incluem registros de Estado do CPU (CS), de interrupção. A lógica
(IL), e uma unidade de execução (UE), também chamada uma unidade aritmética e lógica
(ALU). Figura 1 (b) mostra a Tecnologia Hyperthreading (HT), que mantém duas linhas em
uma CPU física. Cada thread tem os seus próprios registos dos estados da CPU e interrupção
Lógica, enquanto a Unidade de execução é compartilhada entre os dois segmentos. Isto
significa que a unidade de execução é de tempo compartilhado por ambas as threads
simultaneamente, e a unidade de execução faz continuamente o progresso em ambos os
segmentos. Se uma threaded esteja à espera de uma operação a ser recuperadas da memória,
a unidade de execução continua a executar o outro segmento, resultando em uma CPU
totalmente utilizada. Embora a tecnologia Hyperthreading é implementada em uma única
CPU física, o sistema operacional reconhece dois processadores lógicos e agenda tarefas para
cada processador lógico.

2. Figura 1.: Três tecnologias multithread
A CPU dual-core é mostrado na Figura 1 (c). Cada núcleo contém os seus próprios meios
de processamento semelhantes dedicados a um CPU particular, exceto para o Processador
Side Bus, o que pode ser compartilhado entre os dois núcleos.
Todas estas implementações de CPU requerem código para empregar plenamente o potencial
de computação. No futuro, o modelo dual-core CPU será estendida para quad-core, com
quatro núcleos em uma única peça de silício.
Por que a mudança para Dual-Core?
Cada vez maior velocidade de clock está criando um problema de dissipação de energia para
fabricantes de semicondutores. As velocidades de relógio mais rápidos normalmente exigem
transistores adicionais e tensões de entrada mais altas, resultando em maior consumo de
energia.
As mais recentes tecnologias de semicondutores apoiam mais e mais transistores. A
desvantagem é que cada transistor tem vazamentos de uma pequena quantidade de corrente,
a soma dos quais é problemática. Em vez de empurrar fichas para correr mais rápido, os
projetistas da CPU estão adicionando recursos, como mais núcleos e mais cache para
proporcionar um desempenho comparável, ou melhor, com menor poder. Transistores
adicionais estão sendo aproveitados para criar capacidade mais diversificada, como a
tecnologia de virtualização e/ou os recursos de segurança em oposição a condução para
velocidades de clock mais altas. Estas diversas capacidades em última análise, trazer mais
desempenho para aplicações embarcadas dentro de um orçamento de energia mais baixo.
CPUs dual-core, por exemplo, pode ser cronometrado em velocidades mais lentas e é
fornecido com uma voltagem mais baixa para produzir maior desempenho por watt.
Paralelismo e seu impacto Software
A implementação de processador multicore terá um impacto significativo sobre aplicações
embarcadas. Para tirar proveito de CPUs multicore, programas exigem algum nível de
migração para um modelo de software de threaded e exigem validação periódica e ajuste de
desempenho. Há kernel ou sistema threads gerenciados pelo sistema operacional e threads
do usuário mantidos por programadores. Aqui eu me concentro em threads do usuário.
Você deve escolher um modelo de programação de rosca que se adapte o paralelismo inerente
à aplicação. Quando há uma série de tarefas independentes que são executados em
paralelamente, a aplicação é adequada para a decomposição funcional. Segmentação
explícita é geralmente melhor para a decomposição funcional. Quando existe um grande
conjunto de dados independente que deve ser processada através da mesma operação, a
aplicação é adaptada para a decomposição de dados. Métodos dirigido pelo compilador, tais
como OpenMP (http://www.openmp.org/), são projetados para expressar o paralelismo de
dados. O exemplo a seguir descreve segmentação explícita e métodos compilador dirigido de
forma mais detalhada.

3. Para explorar CPUs multicore, você identifica o paralelismo dentro de seus programas e criar
threads para executar várias tarefas simultaneamente. O sistema de visão-inspeção da Figura
2 ilustra o conceito de enfiar no que diz respeito ao paralelismo funcional e de dados. Você
também deve decidir sobre a qual segmento modelos de implementar - segmentação explícita
ou driver-compilador.
O sistema de visão-inspeção na Figura 2 mede o tamanho e a colocação de cabos em um
pacote de semicondutores. O sistema executa várias tarefas de funções simultâneas, como
interface a um ser humano, que controla uma correia transportadora, a captação de imagens
dos condutores, o processamento de imagens, e detecção de defeitos e a transferência de
dados para uma rede de área de armazenamento. Estas tarefas representam paralelismo
funcional porque eles correm ao mesmo tempo, executar como segmentos individuais, e são
relativamente independentes. Essas tarefas são assíncronas para o outro, o que significa que
não iniciam e terminam ao mesmo tempo.
A vantagem de colocar essas tarefas funcionais é que a aplicação de inspeção não travar
quando outras tarefas ou funções são executadas, de modo que o operador da máquina, por
exemplo, experimenta uma aplicação mais ágil.
O processamento das imagens de pacotes semicondutores é bem adequado para o paralelismo
de dados, porque o mesmo algoritmo é executado em um grande número de elementos de
dados. Neste caso, o algoritmo de detecção de defeitos processa conjuntos de pixels de
acordo com looping e aplicação da mesma operação de inspeção para conjuntos
independentes de pixels. Cada conjunto de pixels é processado por seu próprio segmento.
Para qualquer paralelismo funcional ou dados, você pode escrever instruções de threads
explicitas de um sistema operacional para executar essas tarefas concorrentemente. Um
thread é intencionalmente explicito. Usando instruções codificadas de thread, tais como
bibliotecas Ptthreads ou APIs Win32. Você é responsável para criar threads manualmente,
independente de funções que são mapeados para o thread. Como a alocação de memória e a
criação também deve ser criada por você.
Embora, threads explícitos ser poderoso e de uso geral sua complexidade pode fazer um
compiler-directed para uma alternativa mais atraente. Um exemplo de compiler-directed
threading é Open-MP, que é um de padrão de indústria de um conjunto de diretivas de
compiladores. Em Open-MP, você usa programas para descrever paralelismo para o
compilador; por exemplo.
#pragma omp parallel for private (pixelX,pixelY)
for (pixelX=0; pixelX< imageHeigth; pixelX++)
[for( pixelY=0;pixelY < imageWidth;pixelY++)
{newImage [pixelX,pixelY]=ProcessPixel (pixelX,pixelY,image);}
O programa omp diz que esta é uma oportunidade para Open MP paralelismo. O parallel,
palavra-chave, informa o compilador para criar threads. A palavra-chave serve para informa
para as iterações do compilador do próximo loop for, será dividido entre aqueles threads.
A clausula privada de listas variáveis que precisam ser mantidas em sigilo para cada thread,

4. para evitar condições de corrida e corrupção de dados. O compilador cria o thread isolado
como na Figura 3. Observe o thread afastado, são todas criadas e retiradas ao mesmo tempo,
que se assemelha aos dentes de um garfo. Tem um relacionamento explicito entre pai-filho
que não é necessário com threads libraries. Isto é chamado de ‘’Fork Join’’ modelo e é um
requisitocaracterístico para OpenMP paralelism. OpenMP progmas são menos geral do que
threaded libraries, mas eles são menos complexos porque o compilador cria o paralelismo
fundamental de código para multiplicar threads. OpenMP é suportado por vários
compiladores permitindo que o threaded crie um código para ser transportado, enquanto que
threaded libraries tipicamente tem fidelidade para especificar sistemas operacionais.
Paralelism de bug
Se os threads São criados explicitamente, pela diretiva de compilador, ou por qualquer outro
método, eles precisam ser testados para garantir que não existem condições de disputas. Com
uma condição de corrida, você equivocadamente assumiu uma ordem de execução particular,
mas isso não é garantido. Em aplicação incorporado, os processos muitas vezes são
assíncronos, um bug comum que pode significa que está dormente durante os testes de
validação e permite que o código trabalhe quase o tempo todo. Uma condição de corrida pode
ser causada por um conflito de armazenamento. Dois threads poderiam ser a substituição de
um local de memória particular ou um thread pode presumir outro thread. Concluindo os seus
trabalhos em uma determinada variável, que conduz à utilização de dados corrompidos.
O acesso aos dados comuns deve ser sincronizado para evitar perda de dados. Sincronizando
para poder ser implementado com uma palavra de estado simples para indicar o estado dos
dados chamados ‘' semáforo ''. Uma assume o controle dos dados, por escrito '' 0 '' para a
palavra de estado, enquanto escrevendo '' 1 '' para o controle de versões de palavras de status,
permitindo que outro possa acessar a variável. Como aplicações embarcadas são muitas vezes
acionados por interrupções, pode ser útil para implementar uma sequência de leitura-
modificação-gravação protegida para garantir umas operações em uma variável desde de que
não sejam perturbados por outro processo, como uma rotina de interrupção de serviço.
Existem ferramentas sofisticadas disponíveis para testar as condições de corrida. O
verificador da Intel (http://www.intel.com/ids/) é um depurador de runtime automatizado que
verifica a existência de conflitos de armazenamento e olha para os lugares onde threads pode
bloquear ou excluir. Ele identifica locais de memória que são acessados por um thread,
seguido por um acesso desprotegido por outro thread, o que expõe o programa de corrupção
de dados. O Thread verificador é uma ferramenta de análise dinâmica e, portanto, é um
conjunto de dados independentes. Como tal, se o conjunto de dados não exercer determinados
fluxos de programa, a ferramenta não é capaz de verificar que parte do código. Para
aplicações embarcadas, é importante criar um conjunto de dados para que simule os
processos assíncronos relevantes. Encontrar as condições de corrida pode ser muito difícil e
demorado. Threads Checker pode facilmente encontrar estes conflitos, mesmo quando o
conflito é gerado por instâncias de código em diferentes pilhas de chamadas e muitos
milhares de linhas de intervalo.
Afinando performance
Uma vez que o código foi testado e verificado para ser executado corretamente, o

5. desempenho de otimização pode começar. Os desempenhos da otimização devem ser
limitados para o caminho de execução critica.
Para maximizar o desempenho de CPUs com vários núcleos, muitas vezes é necessário
assegurar que a carga de trabalho é equilibrada entre os núcleos. Desequilíbrio de carga vai
limitar paralelo de forma ineficiente e escalabilidade porque algum recurso do processador
será ocioso.
A sincronização também pode limitar o desempenho criando gargalos e sobrecarga. Embora
a sincronização de dados ajude na integridade da garantia, ele serializa o fluxo do programa.
A sincronização requer algum thread esperar por outro thread antes de o fluxo de programa
possa prosseguir, resultando em recursos de processador ociosos.
Para auxiliar o ajuste de desempenho, segue o Profiler Thread Intel
http://www.intel.com/ids/) permite que você verifique o equilíbrio de carga, contenção de
bloqueio, os gargalos de sincronização e sobrecarga paralelo. Esta ferramenta pode detalhar
para código fonte para criar thread por OpenMP ou thread libraries. O profiler identifica o
caminho crítico no programa e indica a utilização do processador por thread. Você pode ver
o thread no caminho crítico, bem como o tempo gasto em cada thread na CPU.
Impacto das CPUs Multicore em sistemas embarcados
Hardware e Software são desenvolvedores de sistemas embarcados que serão impactados
pela mudança para CPUs multicore. Felizmente, o designer de tabuleiro vai encontrar CPUs
multicore, aliviar os problemas térmicos de processadores de alto desempenho de hoje,
oferecendo performance comparável.
Os programadores de software podem precisar de se adaptar a novos modelos de
programação que incluem threaded. Embora a criação, verificação e volta threads
podeinicialmente ser árdua, que irá fornecer-lhe mais controle sobre os recursos da CPU e,
possivelmente, reduzir latências do programa.
Esse sistema de tempo real em desenvolvimento pode particionar trabalho entre múltiplos
núcleos e atribuir prioridades a fim de obter as tarefas críticas concluídas mais rapidamente.
Os desenvolvedores de software que não conseguem se preparar para a transição das CPUs
multicore pode tanto ser escondidos em CPUs mais velhas ou problemas de desempenho
risco de código otimizado.
Muitas ferramentas estão disponíveis para ajudar a transição para o código thread. Por meio
de recursos de vários segmentos, tais como Hyper-Threading, muitos desenvolvedores já têm
experiência com ferramentas especializadas e modelos de programação. Neste contexto, o
código de desenvolvimento irá fornecer um retorno imediato quando esses aplicativos são
executados em dual-core CPUs.
Multicore também levantou a questão de licenciamento de software e os custos associados
que os clientes têm de pagar.

6. Alguns fornecedores de software têm considerado a cobrança de taxas de licença em uma
base per-core, cobrando mais para os sistemas de dupla ou multicore. Contra essa maré, a
Microsoft anunciou que o software será licenciado em uma base pacote por processador.
O trabalho de base está sendo colocada para a transição para processadores multicore em
2005.
Ferramentas estão disponíveis para ajudá-lo a desenvolver um código eficiente e confiável
threaded. Aplicação incorporado deve planejar sua mudança para threaded Modelos de
programação para utilizar plenamente a perfomance de CPUs multicore próxima geração.
** Craig é um engenheiro da Divisão de Infra-estrutura do processador da Intel. Ele pode ser
contatado em craig.p.szydlowski@intel.com