BRPI0611318A2 - melhoramentos em arquitetura de monitoramento de desempenho para análise baseada em percurso crìtico - Google Patents

Abstract

MELHORAMENTOS EM ARQUITETURA DE MONITORAMENTO DE DESEMPENHO PARA ANáLISE BASEADA EM PERCURSO CRìTICO. A presente invencao refere-se a um método e aparelho para monitorar o desempenho de uma micro arquitetura e sintonizar a micro arquitetura com base no desempenho monitorado. O desempenho é monitorado através de simulacao, raciocínio analítico, medicao de descarte de retirada, tempo de execucao total, e outros métodos para determinar os custos de evento por instância. Com base nos custos de evento por instância, a micro arquitetura e/ou o software de execucao é sintonizado para melhorar o desempenho.

Description

Relatório Descritivo da Patente de Invenção para "MELHORA-MENTOS EM ARQUITETURA DE MONITORAMENTO DE DESEMPENHOPARA ANÁLISE BASEADA EM PERCURSO CRÍTICO".

CAMPO DA INVENÇÃO

A presente invenção refere-se ao campo de sistemas de compu-tador, e especificamente ao monitoramento de desempenho e sintonia demicroarquiteturas.

ANTECEDENTES DA INVENÇÃO

A análise de desempenho é o princípio para caracterizar, depu-rar, e sintonizar um projeto microarquitetural, encontrar e reparar os gargalosde desempenho em hardware e software, assim como localizar os proble-mas de desempenho evitáveis. Conforme a indústria de computadores pro-gride, a capacidade de analisar o desempenho de uma microarquitetura efazer mudanças na microarquitetura com base naquela análise torna-se maiscomplexa e importante.

Além de prover a melhor plataforma possível, o melhor desem-penho é freqüentemente conseguido pela sintonia do aplicativo para operaro seu melhor nesta plataforma. Existe um investimento significativo na identi-ficação dos gargalos de desempenho, descobrir como evitá-los através deuma melhor geração de código, e confirmar os aperfeiçoamentos de desem-penho. Os monitores de desempenho são um elemento chave nesta análise.O monitoramento de desempenho provê um maior volume de dados de de-sempenho do que as simulações pré-silício, e tem sido utilizado para ajustaros projetos microarquiteturais para aperfeiçoar o desempenho em áreas taiscomo a transferência de armazenamento. Sabendo apenas quão freqüente-mente um problema de desempenho surge e quanto ganho seria obtido doaperfeiçoamento daquela parte da microarquitetura é essencial na motivaçãode mudanças do silício.

No passado, o monitoramento de desempenho de máquinas deexecução seriais era relativamente direto, já que rastrear os gargalos de de-sempenho seriais é muito mais fácil do que detectar as limitações de de-sempenho durante uma execução paralela, fora de ordem. Uma análise dedesempenho típica decompõe o CPI (clocks por instrução) da carga de tra-balho em componentes individuais como segue: 1) contar os eventos de de-sempenho em hardware, 2) estimar a contribuição relativa de cada eventopara o percurso crítico do programa, e 3) combinar os componentes indivi-duais que contribuem para os gargalos de desempenho da carga de trabalhoem uma avaria total. A estimativa de custos por instância para uma únicacausa microarquitetural é difícil para uma máquina altamente especulativa,fora de ordem, onde existe um paralelismo superescalar e encadeado paracobrir uma fração significativa de muitos custos de parada. Até o momento,métodos ad hoc tem sido utilizados para estimar o impacto por instância deeventos, e a precisão e variação destas estimativas eram freqüentementedesconhecidas.

Por exemplo, a figura 1 ilustra um exemplo das instruções debusca, execução e retirada de instruções 101-107 em uma máquina de pro-blema único. A instrução 102 tem uma má predição de ramificação 110, oque retarda a busca de instrução 103 e descarta a retirada da instrução 103significativamente após a instrução 102. A instrução 104 tem uma perda decache de primeiro nível 120 o que descarta adicionalmente a retirada da ins-trução 105. Mas o descarte de retirada da instrução 104 é tolhido pela perdade cache de segundo nível 130 da instrução 105, o que tem uma latência tãolonga que a má predição de ramificação 135 na instrução 106 não tem ne-nhum impacto sobre o seu tempo de retirada. Como enumerado pela figura1, existem complexidades intrincadas na medição de descarte de retirada,mesmo em uma máquina de problema único, para não dizer o monitoramen-to de desempenho compreensivo em um processado que é capaz de umaexecução paralela altamente especulativa fora de ordem.

BREVE DESCRIÇÃO DOS DESENHOS

A presente invenção está ilustrada por meio de exemplo e nãopretende ser limitada pelas figuras dos desenhos acompanhantes.

A figura 1 ilustra uma modalidade de busca, execução e retiradapara uma pluralidade de operações em uma máquina de problema único.

a figura 2 ilustra uma modalidade de um processador que incluium primeiro módulo de monitoramento de desempenho e um segundo mó-dulo de sintonia microarquitetural.

a figura 3 ilustra uma modalidade específica da figura 2.

a figura 4 ilustra uma modalidade de um processador que incluium módulo para recompilar estaticamente ou dinamicamente o software.

a figura 5 ilustra uma modalidade de um sistema que inclui pro-cessador que tem um módulo para monitorar o desempenho e sintonizar amicroarquitetura do processador.

a figura 6a ilustra uma modalidade de um fluxograma para moni-torar o desempenho e sintonizar um microprocessador com base no desem-penho.

a figura 6b ilustra uma modalidade específica da figura 6a.

a figura 6c ilustra outra modalidade para monitorar o desempe-nho e sintonizar um microprocessador.

a figura 7 ilustra uma modalidade para medir o descarte de reti-rada quando da ocorrência de um evento específico.

DESCRIÇÃO DETALHADA

Na descrição seguinte, numerosos detalhes específicos estãoapresentados tais como arquiteturas específicas, características dentro des-tas arquiteturas, mecanismo de sintonia, e configurações de sistema de mo-do a prover uma compreensão completa da presente invenção. Ficará apa-rente, no entanto, para alguém versado na técnica que estes detalhes espe-cíficos não precisam ser empregados para praticar a presente invenção. Emoutros casos, componentes ou métodos bem-conhecidos, tais como os pro-jetos de lógica, os compiladores de software, as técnicas de reconfiguraçãode software, e as técnicas de descaracterização de processador bem-conhecidos, não foram descritos em detalhes de modo a evitar um obscure-cimento desnecessário da presente invenção.

MONITORAMENTO DE DESEMPENHO

A figura 2 ilustra uma modalidade de um processador 205 quetem um módulo de monitoramento de desempenho 210 e um módulo de sin-tonia 215. O processador 205 pode ser qualquer elemento para executar umcódigo e/ou operar sobre dados. Como um exemplo específico, o processa-dor 205 é capaz de execução paralela. Em outra modalidade, o processador205 é capaz de uma execução fora de ordem. O processador 205 pode tam-bém implementar uma predicação de ramificação e uma execução especula-tiva, assim como outras unidades e métodos de processamento conhecidos.

Outras unidades de processamento ilustradas no processador250 incluem: um subsistema de memória 220, uma interface 225, uma má-quina fora de ordem 230, e unidades de execução 235. Cada um destesmódulos, unidades, ou blocos funcionais pode prover a funcionalidade acimamencionada para o processador 205. Em uma modalidade, o subsistema dememória inclui um cache de nível mais alto e uma interface de barramentopara interfacear com os dispositivos externos, a interface 225 inclui uma ló-gica de especulação e uma lógica de busca, a máquina fora de ordem 230inclui uma lógica de programação para reordenar as instruções, e unidadesde execução 235 incluem unidades de ponto flutuante e de execução de in-teiros que executam em serial e em paralelo.

O módulo 210 e o módulo 215 podem ser implementados emhardware, software, firmware, ou qualquer sua combinação. Comumente, oslimites de módulo variam e funções são implementadas juntas, assim comoseparadamente em diferentes modalidades. Em um exemplo, o monitora-mento de desempenho e a sintonia são implementados em um único módu-lo. Na modalidade apresentada na figura 2, o módulo 210 e o módulo 215estão separadamente mostrados; no entanto, o módulo 210 e o módulo 215podem ser executados em software pelas outras unidades 220-235 ilustradas.

O módulo 210 é para monitorar o desempenho do processador205. Em uma modalidade, o monitoramento de desempenho é feito pela de-terminação e/ou derivação de custos de eventos por instância para um per-curso crítico. Um percurso crítico inclui qualquer percurso ou seqüência deocorrências, tarefas, e/ou eventos que contribuiriam para o tempo que levapara completar uma operação, instrução, grupo de instruções, ou um pro-grama se a latência de qualquer tal ocorrência, tarefa ou evento tivesse queser aumentada. Graficamente1 um percurso crítico pode algumas vezes serreferido como um percurso através de um gráfico de dados, controle, e de-pendências de recursos em um programa que opera em uma máquina espe-cífica para o qual prolongamento de qualquer arco neste gráfico de depen-dência levaria a um aumento na latência de execução deste programa.

Portanto, a contribuição por instância de um even-to/característica para um percurso crítico e, em outras palavras, a contribui-ção de eventos, tais como uma perda de cache de segundo nível, ou umacaracterística microarquitetural, tal como uma unidade de predição de ramifi-cação, à latência experimentada no completamento de uma tarefa um pro-grama. De fato, a contribuição de um evento ou característica pode variarsignificativamente através de domínios de aplicativos. Conseqüentemente, ocusto/contribuição do evento ou da característica microarquitetural pode serdeterminado para um aplicativo de nível de usuário específico, tal como umsistema de operação. O módulo 215 será discutido em mais detalhes comreferência à figura 3.

Um evento inclui qualquer operação, ocorrência, ou ação em umprocessador que introduz uma latência. Uns poucos exemplos de eventoscomuns em um microprocessador incluem: uma perda de cache de baixonível, uma perda de cache secundária, uma perda de cache de alto nível, umacesso de cache, um snoop de cache, uma má predição de ramificação,uma busca da memória, um bloqueio na retirada, uma pré-busca de hardwa-re, um armazenamento de interface, uma divisão de cache, um problema detransferência de armazenamento, uma parada de recurso, uma memóriatemporária, uma decodificação de instrução, uma tradução de endereço, umacesso a um armazenamento de tradução, uma execução de operando deinteiro, uma execução de operando de ponto flutuante, uma renomeação deum registro, uma programação de uma instrução, uma leitura de registro, euma escrita de registro.

Uma característica microarquitetural inclui uma lógica, uma uni-dade funcional, um recurso, ou outra característica associada com um even-to acima mencionado. Exemplos de características microarquiteturais inclu-em: um cache, um cache de instrução, um cache de dados, uma rede alvode ramificação, uma tabela de memória virtual, um arquivo de registro, umatabela de tradução, um armazenamento de consulta, uma unidade de predi-ção de ramificação, um pré-buscador de hardware, uma unidade de execu-ção, uma máquina fora de ordem, uma unidade de alocador, uma lógica derenomeação de registro, uma unidade de interface de barramento, uma uni-dade de busca, uma unidade de decodificação, um registro de estado arqui-tetural, uma unidade de execução, uma unidade de execução de ponto flutu-ante, uma unidade de execução de inteiros, um ALU, e outras característicascomum de um microprocessador.

CLOCKS POR INSTRUÇÃO

Um dos indicadores primários de desempenho é o clocks porinstrução (CPI). O CPI pode ser dividido em diversos componentes, de modoque uma indicação da fração de ciclos que pode ser atribuída a cada um dediversos fatores/eventos possa ser determinada. Estes fatores, como acimaapresentado, podem incluir eventos, tais como uma latência introduzida porcaches faltantes e indo para DRAM, penalidades de má predição de ramifi-cação, retardos de encadeamento incorridos por mecanismos na retirada,isto é para bloqueios, e assim por diante. Outros exemplos de fatores inclu-em as características microarquiteturais que estão associadas com os even-tos, tais como um cache que é perdido, uma perda em uma rede alvo de ra-mificação utilizada para predicação de ramificação, a utilização de interfacesde barramento para ir para DRAM, e a utilização de máquinas de estado pa-ra implementar os bloqueios.

Tipicamente, a contribuição relativa de um fator é determinadapela multiplicação do número de ocorrências do fator por seu efeito em ci-clos, então dividindo pelo número total de ciclos. Apesar de uma tal divisãopoder ser precisamente apresentada para uma máquina escalar, não enca-deada, não especulativa, é difícil fornecer uma contagem de ciclos precisapara uma máquina superescalar, encadeada, fora de ordem, e altamenteespeculativa. Freqüentemente existe um paralelismo suficiente em cargas detrabalho que podem ser exploradas por uma tal máquina para ocultar pelomenos uma porção da parada fazendo um trabalho útil. Como um resultado,o impacto local desta parada pode fazer uma contribuição muito menor parao percurso crítico total do programa do que o custo por instância teórico.

Surpreendentemente, a parada local pode até ter um impacto positivo sobreo tempo de execução total do programa, se este retardo local levar a umamelhor programação total.

ANALISANDO AS CONTRIBUIÇÕES/CUSTOS POR INSTÂNCIA

Os custos de evento por instância, isto é uma contribuição deevento ou de características microarquiteturais para um percurso crítico, po-dem ser determinados em muitos diferentes modos, que incluem: (1) estima-tivas analíticas; (2) contagens de duração de monitores de desempenho; (3)descartes de retirada como medidos por monitores de desempenho dehardware e por simuladores; e (4) mudanças no tempo de execução totaldevido a mudanças no número de eventos como medidos por micropadrõesde desempenho, simulações, e descaracterizações de silício.

ESTIMATIVAS ANALÍTICAS

Em uma primeira modalidade, um custo por instância, isto é umacontribuição de uma característica, é determinado teoricamente. A contribui-ção teórica pode incluir um conhecimento de operação empírico de uma ca-racterística ou uma ocorrência de um evento, assim como uma simulação deuma arquitetura. Isto é freqüentemente derivado de uma compreensão damicroarquitetura, e tipicamente, focaliza no estágio de execução, ao invés dena retirada. A forma mais simples de estimativas analíticas caracteriza umcusto de parada local, independentemente de como estas paradas podemser cobertas através do paralelismo disponível da execução de outras ope-rações (estágios de execução ou instruções) em paralelo.

CONTAGENS DE DURAÇÃO

Em outra modalidade, um monitor de desempenho determinauma contribuição de uma característica através de contagem de duração.

Alguns eventos de monitor de desempenho são definidos para contar cadaciclo que alguma coisa de interesse está acontecendo. Isto gera uma conta-gem de duração ao invés de uma contagem de instâncias. Duas tais conta-gens são os ciclos que uma máquina de estado está ativa, por exemplo ummanipulador de page walk, uma máquina de estado de bloqueio, e ciclos queexistem uma ou mais entradas em uma fila, por exemplo, a fila de barramen-to de faltas de cache destacadas. Estes exemplos medem o tempo em umestágio de execução, e não necessariamente medem um descarte de retira-da, a menos que a execução seja na retirada, o que é o caso para a máqui-na de estado de bloqueio. Esta forma de caracterização é utilizável no cam-po de avaliação de custos específicos de padrão de desempenho.

DESCARTES DE RETIRADA

Os descartes de retirada são úteis na determinação da contribui-ção de eventos e características em uma escala local, assim como extrapo-lando esta medição para uma escala global. Um descarte de retirada ocorrequando uma operação não se afasta em um momento esperado ou duranteum ciclo esperado. Por exemplo, para um par de instruções seqüencial (oumicrooperações), se a segunda instrução não se afasta logo que possívelapós a primeira (normalmente no mesmo ciclo, ou se os recursos de retiradasão restritos, no próximo ciclo), então a retirada é considerada ser descarta-da. O descarte de retirada provê uma medição de retrovisão, "regional" (aoinvés de puramente local) de contribuição para o percurso crítico. É de retro-visão no sentido em que o descarte de retirada está consciente da sobrepo-sição de todas as operações as quais foram afastadas antes de algum pontono tempo. Se duas operações com um custo de parada local de 50 come-çam separadas por um ciclo, o descarte de retirada para a segunda é nomáximo um, ao invés de 50.

A medição real de descarte de retirada pode variar dependendode quando o descarte é medido. Em uma instância, a medição é de uma o-corrência de um evento. Em outra modalidade, o descarte é de quando ainstrução ou a operação deveria ter sido afastada. Em ainda outra modalida-de, o descarte de retirada é medido simplesmente pela contagem do númerode ocorrências de descartes de retirada, como abaixo discutido com referên-cia ao descarte de retirada de operações seqüenciais. Existem vários modosde medir/derivar uma contribuição por instância através de descarte de reti-rada. Para ilustrar, dois métodos de descarte de retirada, operações se-qüenciais e identificação, estão abaixo discutidos.

Ambos os mecanismos permitem ao usuário criar um histogramada distribuição de descartes de retirada, operando repetidamente com dife-rentes valores de limite. O descarte de retirada de operações seqüenciaispermite a criação de um perfil de retardos de retirada para todas as opera-ções no programa. Além disso, a identificação de descartes de retirada per-mite a criação de perfis de distribuição de retardo para eventos individu-ais/específicos, tais como a contribuição individual de más predições de ra-mificação.

Descarte de Retirada de Operações Seqüenciais, isto é, qualifi-cação de retirada lenta.

Para este mecanismo instâncias de operações seqüenciais sãocontadas onde o retardo entre a retirada de operações consecutivas, ou mi-crooperações, é maior do que um limite especificado pelo usuário. Conse-qüentemente, o descarte para as operações consecutivas é medido e o nú-mero de descartes com uma latência acima de um limite predefinido é relatado.

Em uma modalidade, a qualificação de retirada lenta é medidautilizando um contador de uso específico, o qual conta os ciclos nos quais asinstruções de uma cadeia não estão sendo afastadas. O contador é iniciali-zado para um valor definido pelo usuário logo que uma primeira operação seafasta. Se o contador estoura negativamente ou positivamente, dependendodo projeto, para uma segunda instrução específica, esta segunda instrução éconsiderada ter uma retirada lenta, isto é um descarte de retirada.

Como um exemplo de um projeto que utiliza um contador re-gressivo, se um usuário deseja contar quantas retiradas de instruções sãodescartadas ao longo de 25 ciclos, então o contador é ajustado para um va-lor predefinido de 25. Se este estourar negativamente, a retirada de umasegunda instrução é considerada descartada. Em uma implementação decontador crescente o valor definido pelo usuário pode ser inicializado ou em0 ou em um número negativo. Por exemplo, o contador é inicializado para 0e conta até um valor limite de 25. Se o contador estourar então existe umdescarte de retirada. Em uma alternativa, o contador crescente pode ser ini-cializado para -25 e contar até 0, o que simplifica a comparação lógicaquando determinando um estouro de contador.

Identificação de Descarte de Retirada, isto é Perfilamento deDescarte de Retirada

Muito similar à qualificação de retirada lenta, a identificação dedescarte de retirada qualifica as instruções ou a operação as quais tem des-cartes de retirada acima de algum limite. No entanto, neste mecanismo, aqualificação de retirada lenta é apenas uma de muitas outras qualificaçõessobre a instrução ou operação de interesse. Outras qualificações podem in-cluir os eventos específicos que ocorreram para aquela instrução ou opera-ção, tal como uma perda de cache de segundo nível. Estas qualificações sãologicamente combinadas, e a instrução ou operação é contada se esta aten-der ao critério de qualificação especificado. Note que os qualificado-res/eventos podem ser logicamente operados ou combinados, o que podeser definível pelo usuário em registros de estado de máquina especificados.

Em outra modalidade, uma operação é identificada com base naexclusão de um evento ou eventos específicos. Como acima apresentadouma execução paralela pode mascarar o efeito real de um evento específico.Como um exemplo específico, uma perda de um cache de terceiro nível po-de tolher o efeito de uma perda para o cache de segundo nível. Para isolar oefeito de uma perda para um cache de segundo nível, uma operação especí-fica pode ser identificada, se esta resultar em uma perda para o cache desegundo nível e não perder o cache de terceiro nível. Em outras palavras, amedição de operações que resultam em perdas de cache de terceiro nívelsão excluídas da medição. Portanto, esta identificação inclui selecionar umaoperação quando de uma ocorrência de um evento específico e a não ocor-rência de pelo menos um segundo evento.

Observando brevemente a figura 7, uma modalidade para mediro descarte de retirada utilizando um mecanismo de identificação está ilustra-da. No fluxo 705, uma operação é identificada, quando da ocorrência de umevento específico e/ou a exclusão de um evento específico. A operação de-ve ser executada em um processador capaz de uma execução paralela. Noentanto, o processador pode também ser capaz de uma execução serial,uma execução especulativa, e uma execução fora de ordem.

O evento específico pode ser qualquer evento em um micropro-cessador como acima discutido. Em uma modalidade, o evento é uma amos-tragem baseada em evento precisa (PEBS) no evento de retirada. EmPEBS, uma operação (microoperação ou instrução) é marcada (identificada)como tendo experimentado um evento de interesse, tal como uma perda decache. Conforme esta operação se retira, a lógica de retirada nota que estaestá identificada e executa ações especiais. O endereço da instrução e oestado arquitetural tal como os identificadores e os registros arquiteturaissão salvos em um armazenamento de memória. Neste caso, a latência deretirada é gravada juntamente com as outras informações. A execução deprograma pode continuar seguindo estas ações especiais até que o armaze-namento de memória no qual tais informações são gravadas fique (quase)cheio. Quando este fica cheio (ou acima de uma marca d'água especificadapelo usuário), uma interrupção de monitoramento de desempenho é causa-da, sinalizando que o usuário deveria ler o armazenamento de memória. Asações executadas quando de uma PEBS podem ser gerenciadas ou poruma máquina de estado finito no hardware, através de uma instrução emmicrocódigo, ou uma sua combinação.

Uns poucos exemplos específicos de um evento que resulta emidentificação de uma operação incluem: uma perda de cache, um acesso decache, um snoop de cache, uma má predição de ramificação, um bloqueioquando da retirada, uma pré-busca de hardware, uma carga, um armazena-mento, uma memória temporária, e um acesso a um armazenamento de tra-dução. A identificação inclui selecionar uma operação para medição. Noteque estes eventos podem também ser destinados para exclusão, já que aoperação pode não ser identificada se um destes eventos também ocorrerem conjunto com o evento específico como acima discutido.

Após identificar ou selecionar uma operação, no fluxo 710, umdescarte de retirada para a operação é determinado. Como acima mencio-nado, a determinação de um descarte de retirada pode ser a medição realdo retardo na retirada, assim como simplesmente contar a operação comouma retirada retardada devido ao evento específico.

Na modalidade onde a medição real do descarte de retirada é oobjetivo, o módulo de limite em um contador, tal como o contador utilizadopara a qualificação de retirada lenta, é ajustado para 0, de modo que o valorfinal quando da retirada é um número positivo igual ao descarte de retirada.Em um caso, o primeiro contador é inicializado e o descarte de retirada édeterminado com base na inicialização do primeiro contador e na utilizaçãode um registro de armazenamento. Nesta caso, o estado do primeiro conta-dor é copiado para outro registro de estado de máquina. Quando da retirada,o registro de armazenamento é congelado e não é atualizado. Assim o regis-tro de armazenamento fica estável até que o software o lê.

Note que a medição do descarte foi referida em referência à me-dição e à retirada. No entanto, o descarte pode ser medido em outros pontosde estrangulamento em ordem em uma máquina fora de ordem, tais comoas operações de buscar, de decodificar, de emitir, de alocação de memóriaem um armazenamento de ordenação de memória, e as operações de visibi-lidade global de memória.

TEMPO DE EXECUÇÃO TOTAL

Os custos de parada local podem ser parcialmente ou totalmentecobertos por outro trabalho o qual é feito em paralelo. Os descartes de reti-rada que capturam o retardo regional podem também ser parcialmente outotalmente cobertos por trabalho, ou outras paradas, que ainda estão ocor-rendo no momento no qual o descarte de retirada é medido. Um modo noqual o descarte de retirada é coberto está ilustrado na figura 1, como acimadiscutido. A medição de contribuição final que uma dada parada de opera-ção faz ao percurso crítico de um programa é a mudança na latência de e-xecução que ocorre devido àquela causa de parada.

Uma indicação da contribuição incrementai média ao percursocrítico global é medir a execução inteira de um programa ou rastreio longo,isto é um monitoramento de execução de rastreio longo. Esta proposta cobreas contribuições ao percurso crítico que ocorre em qualquer lugar no enca-deamento, e leva em conta o fato de que os retardos locais podem ser co-bertos por outro paralelismo. A contribuição incrementai é derivada pela mu-dança do número de instâncias de um evento, o que muda o tempo de exe-cução, e computando a mudança no tempo de execução dividido pela mu-dança no número de eventos. Por exemplo, se o aumento do tamanho decache diminui o número de perdas de cache de 100 para 90, e diminui otempo de execução de 2000 para 1600, então a contribuição incrementai é(2000 - 1600)/(100 - 90) = 40 ciclos por perda.

A implementação desta técnica pode ser feita em uma pluralida-de de modos. Primeiro, duas versões de um micropadrão de desempenhopodem ser construídas, uma com eventos e a outra sem. Segundo, umaconfiguração de simulador pode ser mudada para introduzir ou eliminar e-ventos. A simulação é operada para um ou mais programas em ambas asconfigurações, e tanto o número de eventos quanto o tempo de execuçãototal são gravados para cada caso. Finalmente, alguns produtos suportamdescaracterizações de silício, tais como o encolhimento do tamanho de umarede alvo de ramificação ou a mudança das políticas. Isto pode ser feito paraafetar as taxas de predição de ramificação, por exemplo.

Como acima mencionado, a determinação de uma contribuiçãode uma características microarquitetural, isto é um custo de evento, pode serfeita através de (1) estimativas analíticas; (2) contagens de duração de moni-tores de desempenho; (3) descartes de retirada como medidos por monito-res de desempenho de hardware e por simuladores; e (4) tempo de execu-ção total como medido por micropadrões de desempenho, simulações, edescaracterizações de silício. No entanto, o monitoramento de desempenhoe a determinação de contribuição para um percurso crítico não estão limita-dos a uma implementação ortogonal de um dos métodos acima menciona-dos, mas ao contrário qualquer combinação pode ser utilizada para analisara contribuição de um evento de uma característica de silício para o percursocrítico.UM EXEMPLO DE CUSTO POR INSTÂNCIA PARA EVENTOS ESPECÍFICOS

Para avaliar o custo por instância dos vários eventos, as técni-cas descritas na seção de análise de contribuições por instância foram em-pregadas. Existem, é claro, numerosos contribuidores para a divisão de CPIcompreensiva de um rastreio. Quatro contribuidores significativos foram es-colhidos para demonstrar a eficiência de cada técnica descrita. Para cadaevento, no entanto, não é sempre possível ou conveniente utilizar todas astécnicas. Por exemplo, as contagens de duração de monitoramento de de-sempenho podem não estar disponíveis para o evento sob consideração. Domesmo modo, perturbar a execução pelo ajuste de um tamanho ou políticano simulador pode não afetar o número de ocorrências de um evento oumudar o tempo de operação em um rastreio específico. A Tabela 1 mostra oresumo dos custos estimados para cada uma destas quatro causas com ba-se na perturbação de execução simulada, e provê uma indicação de variân-cia no impacto que está baseada em resultados de simulação totais.

<table>table see original document page 15</column></row><table>

Tabela 1: Custos por instância empíricos

MÁS PREDIÇÕES DE RAMIFICAÇÃO

As más predições de ramificação são uma causa comum de de-saceleração de aplicativos. Estas forçam a reinicialização de encadeamentode processador e jogam fora o trabalho especulativo. Os preditores de rami-ficação tornaram-se cada vez mais precisos ao longo do tempo. Apesar detudo, com encadeamentos mais profundos e mais largos, as más prediçõespodem causar uma considerável perda de oportunidade para completar otrabalho útil.

table>table see original document page 16</column></row><table>

Tabela 2: má predição de ramificação por custo de evento de instância

A medição analítica de custo de má predição de ramificação é onúmero de ciclos de retardo (31) de onde uma má predição de ramificação énormalmente detectada, na execução, para trás onde as instruções sãonormalmente buscadas, do cache de rastreio. A perspectiva analítica mede oretardo real incorrido na interface da máquina. Este retardo pode ser aumen-tado se não existir nenhum retardo na avaliação da condição de ramificação,ou devido à contenção de recursos, ou devido a uma dependência de dadosnão resolvida, especialmente se a dependência for em uma carga que sofreuuma perda de cache. É por três razões que o retardo de descarte de retiradapode estar nos trinta até os quarenta, como visto nos micropadrões de de-sempenho, nos descartes de retirada de HW, e nos descartes de retiradasimulados. Três valores estão mostrados para os descartes de retirada deHW na Tabela 2. O micropadrão de desempenho aqui utilizado tinha umcorpo de laço com uma ramificação condicional e nenhuma referência dememória. 28% mais ramificações tinha um retardo de 36 do que em 35,27%mais ramificações tinham um retardo de 40 versus 39, e 43% mais ramifica-ções tinham um retardo de 41 versus 40 ciclos. Os micropadrões de desem-penho correspondia proximamente ao modelo analítico já que estes contémpouco trabalho paralelo e não requerem uma limpeza complexa.

No entanto, como mostrado na figura 1, onde a instrução 106tem uma má predição de ramificação, um retardo na interface pode não ternenhum impacto se existiu um descarte de retirada anterior na traseira damáquina. Também, uma perda de cache posterior pode afogar a contribui-ção da ramificação para o percurso crítico com um retardo muito maior. Estaé uma razão porque a contribuição média para o percurso crítico total é mui-to mais baixa do que o descarte de retirada. A contribuição total simuladapara o percurso crítico foi derivada da desabilitação do preditor de ramifica-ção indireta, de modo que este pode somente predizer o último alvo. Maisainda, em aplicações reais, o código fora de percurso pode freqüentementeexecutar pré-buscas de dados úteis e consultas de DTLB o que diminui oimpacto das más predições. Finalmente, a sobreposição do processamentode uma má predição com o processamento de uma segunda pode reduzir acontribuição média para o percurso crítico total.

Desta discussão, fica claro que a contribuição média real para opercurso crítico pode ser altamente dependente do contexto, e os descartesde retirada podem superestimar o custo por instância. Um fator de escala-gem, tal como ~ 70% pode ser aplicado nos descartes de retirada medidosem HW para derivar o custo por instância mediano. Note que este custo deevento pode ser altamente dependente da microarquitetura específica emesmo da implementação dentro da mesma família microarquitetural.

PERDA DE CACHE DE PRIMEIRO NÍVEL (L1)

As perdas de cache de primeiro nível são uma ocorrência co-mum. Os processadores fora de ordem são projetados para encontrar umtrabalho independente no fluxo de instruções para manter o processadorocupado enquanto fornecendo a perda para o cache de segundo nível. Co-mo um resultado, somente uma pequena fração do custo de perda de L1local (por exemplo descarte de retirada) contribui para o percurso crítico total.

<table>table see original document page 17</column></row><table>

Tabela 3: Perda de cache de primeiro nível por custo de evento de instância

O modelo analítico aqui descreve o excesso da perda de L1 a-cima do custo de carregar para utilizar normal. O micropadrão de desempe-nho para este evento consiste em um laço de perseguição de ponteiro o qualencontra uma distribuição uniforme de excessos de 18 ciclos. Um fator deescalagem de ~ 50% pode ser aplicado no descarte de retirada de hardwarepara todos os eventos de perda de L1 para chegar ao custo por instânciamédio.

PERDA DE CACHE DE SEGUNDO NÍVEL (L2)

As perdas de cache de segundo nível podem ser enviadas paraum cache de nível mais alto ou para um controlador de memória/DRAM. Osprocessadores fora de ordem são projetados para encontrar as perdas decache de L2 independentes para encadear o processamento destas longastransações.

<table>table see original document page 18</column></row><table>

Tabela 4: Perda de cache de segundo nível por custo de evento de instância

A medida analítica de perdas de cache é de 306 clocks com a-certos de página de DRAM de fluxo contínuo. Isto é computado de umaDRAM de 90 ns com um FSB de 800 MHz em um processador de 3,4 GHz.O micropadrão de desenvolvimento, o qual consiste em um simples códigode perseguição de ponteiro, correlaciona bem com o modelo analítico. Estenúcleo foi projetado para acertar no DTLB mas não realiza nenhum benefíciodo pré-buscador de hardware. Assim existe pouco trabalho paralelo parafazer que pudesse esconder parte da latência, e pouco trabalho independen-te para fazer que impedisse que cada carga fosse prontamente enviada paraa DRAM. Os descartes de retirada e as execuções simuladas todos resultamem um custo por instância que é menor do que o valor analítico. De fato, asexecuções simuladas mostram uma ampla variância no custo por instânciaatravés dos rastreios, tanto mais curta quanto mais longa do que o valoranalítico. Claramente, existe o benefício de acessos de DRAM sobrepostosna extremidade de latência curta do espectro. As latências por instânciamais longas podem ocorrer em diversos modos, incluindo as limitações deprofundidade de fila de solicitação de memória de processador e perdas delargura de banda de barramento.

O pré-buscador de hardware desempenha um papel muito im-portante nesta latência. Apesar de apropriadamente controlado em acelera-ção, este tem a capacidade de inserir numerosas solicitações no sistema dememória por meio disto aumentando a latência de cargas de demanda sub-seqüentes. Na outra extremidade do espectro, o pré-buscador algumas ve-zes começa a pré-buscar tarde demais para evitar a perda de uma cargamais recente, mas cedo o bastante para ter feito com que os dados estives-sem a caminho da DRAM no momento da carga mais recente. Isto resultaem custos de perda efetiva por instância mais curtos. Em geral, o custo porinstância mediano é muito similar à medição de descarte de retirada de HW.

A variação de custo varia significativamente através dos domí-nios de aplicativo, como acima sugerido. Portanto, potencialmente tendo ummecanismo no campo para medir o custo para um dado aplicativo pode serextremamente útil na determinação de contribuição de características espe-cíficas. À luz desta variação, uma microarquitetura pode ser sintonizada emuma base por aplicativo.

SINTONIZANDO A MICROARQUITETURA

A microarquitetura pode ser sintonizada tal como durante a me-dição de descarte de retirada e a medição de tempo de execução total paradeterminar o custo de evento por instância. No entanto, a microarquiteturapode também ser sintonizada em resposta ao custo de evento por instância.

A sintonia de uma característica microarquitetural ou de uma microarquitetu-ra inclui mudar o tamanho, habilitar ou desabilitar a lógica, uma característi-ca, e/ou uma unidade dentro da microarquitetura, assim como mudando aspolíticas dentro da microarquitetura.

Em uma modalidade, a sintonia é feita com base em uma contri-buição, isto é uma contribuição por instância, de uma característica microar-quitetural. Como um primeiro exemplo, o tamanho da característica é altera-do, a característica é habilitada, a característica é desabilitada, ou as políti-cas associadas com a característica são alteradas com base em qual açãoreduz a latência em um percurso crítico. Como outro exemplo, outras consi-derações tais como a energia podem ser utilizadas para sintonizar a micro-arquitetura. Neste exemplo, pode ser determinado que desabilitar a caracte-rística aumenta a latência por uma quantidade significativa. No entanto, combase na determinação de que o benefício de desempenho da característicaé significativo e que a desabilitação da característica economizaria uma e-nergia significativa, a característica é sintonizada, por exemplo desabilitada.

Como um exemplo empírico,foi notado nas arquiteturas anterio-res que em diversas macro cargas de trabalho um número significativo deconflitos de serrilha foi notado. Um destes exemplos onde os conflitos deserrilha ocorreram foi entre múltiplas cadeias acessando as mesmas linhasde cache.

Uma cadeia de software é pelo menos uma parte de um progra-ma que é operável para ser executado independentemente de outra cadeia.

Alguns microprocessadores até suportam um multiencadeamento em hard-ware, onde o processador tem pelo menos uma pluralidade de conjuntoscompletos e independentes de registros de estado de arquitetura para pro-gramar independentemente a execução de múltiplas cadeias de software.

No entanto, estas cadeias de hardware compartilham alguns recursos, taiscomo os caches. Anteriormente, os acessos à mesma linha no cache pormúltiplas cadeias resultavam no deslocamento da linha de cache e a redu-ção de localidade. Portanto, o endereço de partida de memória de dadospara as cadeias, era ajustado para diferentes valores para evitar o desloca-mento de linhas em cache entre as cadeias.

Observando a figura 3, uma modalidade específica do módulo215 no processador 205 está ilustrada. O módulo 215 é para sintonizar umacaracterística microarquitetural para um aplicativo de nível de usuário, combase em pelo menos a contribuição da característica microarquitetural para opercurso crítico.

Um exemplo muito específico deste tipo de sintonia inclui, moni-torar o desempenho de um pré-buscador de hardware durante os aplicativos,ou fases de um aplicativo tal como o coletamento de lixo. O coletamento delixo é operado com o pré-buscador de hardware habilitado, então desabilita-do, e é descoberto que em algumas instâncias o coletamento de lixo executamelhor sem o pré-buscador de hardware. Conseqüentemente, a microarqui-tetura pode ser sintonizada e o pré-buscador de hardware desabilitadoquando da execução de um aplicativo de coletamento de lixo.

Outros exemplos de mudança de políticas com base em análisede desempenho incluem a agressividade de pré-busca, a alocação relativade recursos para diferentes cadeias em uma máquina de encadeamento si-multâneo, page walks especulativos, atualizações especulativas para TLBs1e a seleção entre os mecanismos preditivos para ramificações e dependên-cias de memória.

A figura 3 ilustra as características microarquiteturais: o subsis-tema de memória 220, o cache 350, a interface 225, a predição de ramifica-ção 355, o buscador 360, as unidades de execução 235, o cache 350, asunidades de execução 355, a máquina fora de ordem 230 e a retirada 365.Outros Exemplos de características microarquiteturais incluem: um cache,um cache de instrução, um cache de dados, uma rede alvo de ramificação,uma tabela de memória virtual, um arquivo de registro, uma tabela de tradu-ção, um armazenamento de consulta, uma unidade de predição de ramifica-ção, um preditor de ramificação indireta, um pré-buscador de hardware, umaunidade de execução, uma máquina fora de ordem, uma unidade de aloca-dor, uma lógica de renomeação de registro, uma unidade de interface debarramento, uma unidade de busca, uma unidade de decodificação, um re-gistro de estado arquitetural, uma unidade de execução, uma unidade deexecução de ponto flutuante, uma unidade de execução de inteiros, um ALU,e outras características comum de um microprocessador.

Como acima mencionado, a sintonia de uma característica mi-croarquitetural pode incluir habilitar ou desabilitar a característica microarqui-tetural. Como no exemplo com o pré-buscador de hardware acima, o pré-buscador pode ser desabilitado se a contribuição for determinada ser melho-rada, isto é melhor, quando a característica é desabilitada durante progra-mas de software específicos.

Um modo de determinar a contribuição de uma característicamicroarquitetural para o percurso crítico para um aplicativo de nível de usuá-rio é executar o aplicativo de nível de usuário com a característica microar-quitetural habilitada. Então, executar o aplicativo de nível de usuário com acaracterística microarquitetural desabilitada. Finalmente, a contribuição dacaracterística microarquitetural para o percurso crítico para o aplicativo denível de usuário é determinada com base na comparação da execução doaplicativo de nível de usuário com a característica habilitada com a execuçãodo aplicativo de nível de usuário com a característica desabilitada. Simples-mente, medindo o tempo de execução total cada vez que o aplicativo de ní-vel de usuário é executada, é determinado qual tempo de execução total émelhor; o tempo total com a característica habilitada ou desabilitada.

Como um exemplo especifico o módulo 215 inclui o registro dedescaracterização 305. O registro de descaracterização 305 inclui uma plu-ralidade de campos, tais como os campos 310-335. Os campos podem serbits individuais, ou cada campo pode ter uma pluralidade de bits. Além disso,cada campo é operável para sintonizar uma característica microarquitetural.

Em outras palavras, o campo está associado com uma característica micro-arquitetural, como o campo 310 está com a predição de ramificação 355, ocampo 315 está com o buscador 360, o campo 320 está com o cache 350, ocampo 325 está com a lógica de retirada 365, o campo 330 está com as uni-dades de execução 355, e o campo 335 está com o cache 350. Quando umdos campos, tal como o campo 310, é ajustado, este desabilita a predição deramificação 355.

Outro módulo, tal como um programa de software, associadocom o módulo 215, incorporado no módulo 215, ou parte do módulo 215 po-de ajustar um campo, tal como o campo 310, se a contribuição de desempe-nho da característica para o percurso crítico, quando desabilitada, é melho-rada como acima discutido. Como acima notado, o módulo 215 pode ser umhardware, um software ou uma sua combinação, assim como associado comum módulo parcialmente sobreposto 210. Por exemplo, como parte da fun-cionalidade do módulo 210, para determinar uma contribuição da prediçãode ramificação 355 durante a execução de um programa de nível de usuário,o registro 305, ilustrado no módulo 215, pode ser utilizado para sintonizar oudesabilitar as características do processador 205, tal como a predição deramificação 355.

Em outra modalidade, a descaracterização, isto é a sintonia, in-clui mudar o tamanho, ou fisicamente ou virtualmente, de uma característica.Na alternativa ao exemplo acima, se a contribuição da predição de ramifica-ção 355 mostrasse melhorar a execução de um aplicativo de nível de usuá-rio, então o tamanho da predição de ramificação 355 pode ser aumenta-do/diminuído conseqüentemente através do campo 310. O exemplo abaixoilustra a capacidade de sintonizar o processador para descobrir a contribui-ção de uma característica ou evento, tal como uma perda de cache, pelasintonia do tamanho de caches.

SOFTWARE DE SINTONIA

Observando a figura 4 uma modalidade de um software de de-sempenho de monitoramento e de sintonia de processador está ilustrado. Oprocessador 405, similarmente ao processador 205 mostrado nas figuras 2 e3, pode ter qualquer lógica conhecida associada com um processador. Co-mo ilustrado, o processador 405 inclui unidades/características: um subsis-tema de memória 420, uma interface 425, uma máquina fora de ordem 430,e unidades de execução 435. Dentro de cada um destes blocos funcionaisnumerosas outras características microarquiteturais podem existir, tal comoum cache de segundo nível 421, uma unidade de busca/decodificação 427,uma predição de ramificação 426, uma retirada 431, um cache de primeironível 436, e unidades de execução 437.

Como acima, o módulo 410 determina um custo de evento porinstância em um percurso crítico para execução de um programa de softwa-re. Exemplos de derivação de um custo de evento por instância acima inclu-em as contagens de duração, a medição de descarte de retirada, e a medi-ção de execução de rastreio longo. Note mais uma vez, que o módulo 410 eo módulo 415 podem ter limites borrados, já que sua funcionalidade, hardwa-re, software, ou uma combinação de hardware e software podem sobrepor.

Em contraste com a figura 3, onde o módulo 415 sintonizava amicroarquitetura interfaceando com as características, o módulo 415 devesintonizar um programa de software com base no custo de evento por ins-tância no percurso crítico. O módulo 415 pode incluir qualquer hardware,software, ou combinação para compilar e/ou interpretar um código para exe-cutar no processador 405. Em uma modalidade, o módulo 415 recompila ocódigo que é executado em uma operação subseqüente do programa parautilizar as características microarquiteturais acima mencionadas mais oumenos freqüentemente se comparado com o código originalmente compiladobaseado em um custo de evento por instância determinado. Em outra moda-lidade, o módulo 415 compila o código diferentemente para o restante damesma operação do programa, isto é, uma compilação dinâmica ou recom-pilação é utilizada para aperfeiçoar o tempo de execução em uma carga detrabalho e uma plataforma específicas.

Como acima apresentado, além de ser capaz de sintonizar amicroarquitetura, um melhor desempenho pode ser conseguido sintonizandoo aplicativo para operar o seu melhor naquela plataforma. O software de sin-tonia inclui um código de otimização. Um exemplo de sintonizar um aplicati-vo é a recompilação do programa de software. Sintonizar o software podetambém incluir otimizar um software/código para bloquear estruturas de da-dos para caberem dentro de caches, retransmitir o código para aproveitar-sede condições de predição de ramificação padrão que não requerem a utiliza-ção de recursos de tabela de preditor de ramificação, emitir um código emdiferentes endereços de instrução de modo a evitar certas serrilhas e condi-ções de conflito que podem levar a problemas com o gerenciamento de loca-lidade em estruturas de predição de ramificação e de busca de código, re-transmitir dados em uma memória dinamicamente alocada ou na pilha (queinclui o alinhamento de pilha) para evitar as penalidades incorridas pela ex-tensão de uma linha de cache, e ajustar a granularidade e o alinhamento deacessos de modo a evitar os problemas de transferência de armazenamento.

Como um exemplo específico de software de sintonia, o software450 é executado com/no processador 405. O módulo 410 determina um cus-to de evento por instância, tal como o custo de má predição de uma ramifi-cação na lógica de predição de ramificação 426. Com base nesta análise, omódulo 415 retransmite o software 450 para o software 460, o qual é omesmo aplicativo de nível de usuário retransmitido para executar diferente-mente no processador 405. Neste exemplo, o software 460 é retransmitidopara melhor aproveitar-se das condições de predição de ramificação padrão.

Portanto, o software 460 é recompilado para utilizar a predição de ramifica-ção 426 diferentemente. Outros exemplos podem incluir executar as instru-ções em código para desabilitar a lógica de predição de ramificação 426 emudar as sugestões de software utilizadas pela lógica de predição de ramifi-cação 426.

UM SISTEMA PARA MONITORAMENTO DE DESEMPENHO

Referindo a seguir à figura 5, um sistema para utilizar o monito-ramento de desempenho está ilustrado. O processador 505 está acopladono hub de controlador 550 e o hub de controlador 550 está acoplado namemória 560. O hub de controlador 550 pode ser um hub de controlador dememória ou outra porção de um dispositivo de conjunto de chip. Em algunscasos, o hub de controlador 550 tem um controlador de vídeo integrado, talcomo o controlador de vídeo 555. No entanto, o controlador de vídeo 555pode também estar em um dispositivo gráfico acoplado no hub de controla-dor 550. Note que outros componentes, interconexões, dispositivos, e circui-tos podem estar presentes em cada um dos dispositivos mostrados.

O processador 505 inclui o módulo 510. O módulo 510 é paradeterminar uma contribuição de evento por instância durante a execução deum programa de software, sintonizar uma configuração arquitetural de mi-croprocessador 505 com base na contribuição de evento por instância, ar-mazenar a configuração arquitetural, e ressintonizar a configuração arquite-tural com base na configuração arquitetural armazenada, quando da execu-ção subseqüente do programa de software.

Como um exemplo específico, o módulo 510, que utiliza o módu-lo de contribuição 511, determina uma contribuição de evento durante a exe-cução de um programa de software, tal como um sistema de operação. Ou-tros exemplos de programas de software incluem um aplicativo de convida-do, um aplicativo de sistema de operação, um padrão de desempenho, ummicropadrão de desempenho, um operador, e um aplicativo incorporado.

Para este exemplo, assumindo que uma contribuição de evento, tal comouma falta para um cache de primeiro nível 536 não afetou a execução signi-ficativamente, o cache 536 pode ser reduzido em tamanho para economizarenergia sem afetar o tempo de execução no percurso crítico. Portanto, omódulo de sintonia 512 sintoniza a arquitetura do processador 505 pela re-dução do cache de primeiro nível 536 em tamanho. A sintonia pode ser feita,como acima mencionado, com um registro que tem campos associados comas diferentes características no processador 505. Onde um registro é utiliza-do, o armazenamento da configuração arquitetural inclui armazenar os valo-res de registro no armazenamento 513, o qual é simplesmente outro registroou dispositivo de memória, tal como a memória 560. Quando da subseqüen-te execução do programa de software, a etapa de monitoramento de desem-penho não precisa ser repetida, e a configuração previamente armazenadapode ser carregada. Conseqüentemente, a arquitetura é ressintonizada parao programa de software com base na configuração armazenada.

UM MÉTODO PARA MONITORAMENTO DE DESEMPENHO

A figura 6a ilustra uma modalidade de um fluxograma para moni-torar o desempenho e sintonizar um microprocessador. No fluxo 605 umprimeiro programa de software é executado utilizando um microprocessador.

Em uma modalidade, o microprocessador é capaz de uma execução parale-la fora de ordem. A seguir, no fluxo 610, um custo de evento para um per-curso crítico associado com a execução do primeiro programa de software édeterminado.

Observando a figura 6b1 exemplos de determinação de um custode evento e de sintonia do microprocessador são ilustrado. Um custo de e-vento pode ser determinado por análise analítica, contagens de duração,como mostrado no fluxo 611, descartes de retirada, como no fluxo 612, e/outempo de execução total, como mostrado no fluxo 613. Note que qualquercombinação destes métodos pode ser utilizada para determinar o custo deum evento.

Uns poucos exemplos de eventos comuns em um microproces-sador incluem: uma perda de cache de baixo nível, uma perda de cache se-cundária, uma perda de cache de alto nível, um acesso de cache, um snoopde cache, uma má predição de ramificação, uma busca da memória, um blo-queio na retirada, uma pré-busca de hardware, uma carga, um armazena-mento, uma memória temporária, uma decodificação de instrução, uma tra-dução de endereço, um acesso a um armazenamento de tradução, uma e-xecução de operando de inteiro, uma execução de operando de ponto flutu-ante, uma renomeação de um registro, uma programação de uma instrução,uma leitura de registro, e uma escrita de registro.

Retornando à figura 6a, no fluxo 615, o microprocessador é sin-tonizado com base no custo de evento para o percurso crítico associadocom a execução do primeiro programa de software. A sintonia inclui qualquermudança na microarquitetura para melhorar o desempenho e/ou o tempo deexecução. Referindo de volta à figura 6b, um exemplo de sintonia inclui habi-litar ou desabilitar uma característica microarquitetural, como no fluxo 617.Uns poucos exemplos ilustrativos de características incluem, um cache, umatabela de tradução, um armazenamento de consulta de tradução (TLB), umaunidade de predição de ramificação, um pré-buscador de hardware, umaunidade de execução e uma máquina fora de ordem. Outro exemplo incluimudar o tamanho ou a freqüência de utilização de uma característica micro-arquitetural, tal como no fluxo 616. Em ainda outra modalidade, a sintonia domicroprocessador inclui sintonizar/compilar o programa de software a serexecutado para utilizar o processador diferentemente, tal como não utilizan-do um pré-buscador de hardware.

Até o momento, o monitoramento de desempenho e a sintoniaforam discutidos com referência a um único programa de software para des-crever o monitoramento de desempenho. No entanto, o monitoramento dedesempenho e a sintonia podem ser implementados com qualquer númerode aplicativos a serem executados em um processador. A figura 6c ilustrauma modalidade de um diagrama de fluxo para perfilar/sintonizar uma arqui-tetura para um segundo programa e quando carregando o primeiro aplicativonovamente, o microprocessador é ressintonizado.Os fluxos 605-615 são os mesmos como mostrados na figura 6a.

No fluxo 620 a primeira configuração que representa a sintonia do micropro-cessador associado com o primeiro programa de software é armazenada.

Um custo de evento para o percurso crítico associado com a execução deum segundo programa de software é determinado no fluxo 625. No fluxo630, o microprocessador é sintonizado com base no custo de evento para opercurso crítico associado com a execução do segundo programa de softwa-re. Finalmente, o microprocessador é ressintonizado com base na primeiraconfiguração armazenada quando da subseqüente execução do primeiroprograma de software no fluxo 635.

Como pode ser visto acima um microprocessador é dinamica-mente sintonizado com base no desempenho de aplicativos individuais. Co-mo certas características em um processador são diferentemente utilizadas,e o custo de eventos, tal como uma perda de cache, varia significativamentede aplicativo para aplicativo, a microarquitetura e/ou os aplicativos de soft-ware estes próprios podem ser sintonizados para executarem mais eficien-temente e rapidamente. O custo de eventos e as contribuições de caracterís-ticas são medidos através de qualquer combinação de métodos analíticos,simulação, medição de descartes de retirada, e tempo de execução total pa-ra assegurar que o desempenho correto está sendo monitorado, especial-mente para as máquinas de execução paralelas.

Na especificação acima, a invenção foi descrita com referênciaàs suas modalidades exemplares específicas. Ficará, no entanto, evidenteque várias modificações e mudanças podem ser feitas nas mesmas semafastar-se do espírito mais amplo e do escopo da invenção como apresenta-dos nas reivindicações anexas. A especificação e os desenhos devem, con-seqüentemente, ser considerados em um sentido ilustrativo ao invés de umsentido restritivo.

Claims (33)

1. Método que compreende:executar um primeiro programa de software utilizando um micro-processador;determinar um custo de evento para um percurso crítico associ-ado com a execução do primeiro programa de software; esintonizar o microprocessador com base no custo de evento pa-ra o percurso crítico associado com a execução do primeiro programa desoftware.

2. Método de acordo com a reivindicação 1, em que o micropro-cessador é capaz de uma execução paralela fora de ordem.

3. Método de acordo com a reivindicação 1, em que sintonizar omicroprocessador compreende mudar o tamanho de uma característica mi-croarquitetural, a característica microarquitetural sendo selecionada de umgrupo que consiste em um cache de instrução, um cache de dados, umarede alvo de ramificação, uma tabela de memória virtual e um arquivo deregistro.

4. Método de acordo com a reivindicação 1, em que sintonizar omicroprocessador compreende desabilitar uma característica microarquitetu-ral, a característica microarquitetural sendo selecionada de um grupo queconsiste em um cache, uma tabela de tradução um armazenamento de con-sulta, uma unidade de predição de ramificação, um pré-buscador de hardwa-re, e uma unidade de execução.

5. Método de acordo com a reivindicação 1, ainda compreendendo:armazenar uma primeira configuração que representa a sintoniado microprocessador associada com o primeiro programa de software;determinar um custo de evento para o percurso crítico associadocom a execução de um segundo programa de software;sintonizar o microprocessador com base no custo de evento pa-ra o percurso crítico associado com a execução do segundo programa desoftware; eressintonizar o microprocessador com base na primeira configu-ração armazenada, quando de uma execução subseqüente do primeiro pro-grama de software.

6. Método de acordo com a reivindicação 5, em que cada um doprimeiro e do segundo programas de software é selecionado do grupo queconsiste em um aplicativo de convidado, um sistema de operação, um apli-cativo de sistema de operação, um aplicativo de padrão de desempenho, umoperador, e um aplicativo incorporado.

7. Método de acordo com a reivindicação 1, em que a determi-nação de um custo de evento para um percurso crítico compreende executaruma contagem de duração.

8. Método de acordo com a reivindicação 7, em que a execuçãode uma contagem de duração compreende contar os ciclos em que umamáquina de estado no microprocessador está ativa, em que a máquina deestado é selecionada do grupo que consiste em um manipulador de pagewalk, uma máquina de estado de bloqueio, e uma fila de barramento de per-das de cache destacadas.

9. Método de acordo com a reivindicação 1, em que a determi-nação de um evento para um percurso crítico compreende medir os descar-tes de retirada de operações.

10. Método de acordo com a reivindicação 9, em que a mediçãode descartes de retirada de operações compreende medir um retardo naretirada de um par de operações seqüencial.

11. Método de acordo com a reivindicação 9, em que a mediçãode descartes de retirada de operações compreende medir um retardo deretirada para uma operação que tinha um evento específico.

12. Método de acordo com a reivindicação 11, em que o eventoé selecionado de um grupo que consiste em uma perda de cache de baixonível, uma perda de cache secundária, uma perda de cache de alto nível, umacesso de cache, um snoop de cache, uma má predição de ramificação,uma busca da memória, um bloqueio na retirada, uma pré-busca de hardwa-re, uma carga, um armazenamento, uma memória temporária, uma decodifi-cação de instrução, uma tradução de endereço, um acesso a um armaze-namento de tradução, uma execução de operando de inteiro, uma execuçãode operando de ponto flutuante, uma renomeação de um registro, uma pro-gramação de uma instrução, uma leitura de registro, uma escrita de registro.

13. Método que compreende:identificar uma operação quando da ocorrência de um eventoespecífico, a operação a ser executada em um processador capaz de umaexecução paralela; edeterminar um descarte de retirada para a operação.

14. Método de acordo com a reivindicação 13, em que a identifi-cação de uma operação compreende selecionar a operação, quando da o-corrência do evento específico, para amostragem.

15. Método de acordo com a reivindicação 13, em que a identifi-cação de uma operação compreende selecionar a operação, quando da o-corrência do evento específico e uma não ocorrência de um segundo evento,para amostragem.

16. Método de acordo com a reivindicação 14, em que o eventoespecífico é selecionado de um grupo que consiste em um perda de cache,um acesso de cache, um snoop de cache, uma má predição de ramificação,um bloqueio na retirada, uma pré-busca de hardware, uma carga, um arma-zenamento, uma memória temporária, e um acesso de armazenamento detradução.

17. Método de acordo com a reivindicação 14, em que o eventoespecífico é um evento preciso com base em uma amostragem de evento naretirada.

18. Método de acordo com a reivindicação 14, em que a deter-minação de um retardo de descarte de retirada para o operação compreen-de:inicializar um primeiro contador, quando da seleção da operaçãopara amostragem;determinar o descarte de retirada com base na inicialização doprimeiro contador e na utilização de um registro de armazenamento.

19. Método de acordo com a reivindicação 18, em que a iniciali-zação do primeiro contador inclui ajustar o primeiro contador para um valordefinido pelo usuário, e em que a utilização de um registro de armazena-mento inclui quando da medida do descarte de retirada com o primeiro con-tador, copiar um estado do primeiro contador no registro de armazenamentopara ser lido para determinar o descarte de retirada.

20. Aparelho que compreende:um microprocessador que inclui:um primeiro módulo para determinar uma contribuição de umacaracterística microarquitetural para um aplicativo de nível de usuário; eum segundo módulo para sintonizar a característica microarqui-tetural com base pelo menos na contribuição da característica microarquite-tural, quando o aplicativo de nível de usuário deve ser executado.

21. Aparelho de acordo com a reivindicação 20, em que deter-minar uma contribuição de uma característica microarquitetural para um apli-cativo de nível de usuário compreende:executar o aplicativo de nível de usuário com a característicamicroarquitetural habilitada;executar o aplicativo de nível de usuário com a característicamicroarquitetural desabilitada; edeterminar a contribuição da característica microarquitetural parao aplicativo de nível de usuário com base na comparação da execução doaplicativo de nível de usuário com a característica habilitada com a execuçãodo aplicativo de nível de usuário com a característica desabilitada.

22. Aparelho de acordo com a reivindicação 20, em que sintoni-zar a característica microarquitetural compreende: mudar o tamanho da ca-racterística microarquitetural, a característica microarquitetural sendo sele-cionada de um grupo que consiste em um cache de instrução, um cache dedados, uma rede alvo de ramificação, uma tabela de memória virtual, e umarquivo de registro.

23. Aparelho de acordo com a reivindicação 20, em que sintoni-zar a característica microarquitetural compreende desabilitar a característicamicroarquitetural, a característica microarquitetural sendo selecionada de umgrupo que consiste em um cache de instrução, um cache da dados, umatabela de tradução, um armazenamento de consulta, uma unidade de predi-ção de ramificação, um pré-buscador de hardware, e uma unidade de execução.

24. Aparelho de acordo com a reivindicação 20, em que sintoni-zar a característica microarquitetural está adicionalmente baseado em umaquantidade de energia consumida pela característica microarquitetural.

25. Aparelho de acordo com a reivindicação 23, em que o se-gundo módulo compreende:um registro que tem um campo associado com a característicamicroarquitetural, em que o campo, quando ajustado, é para desabilitar acaracterística microarquitetural;um módulo para ajustar o campo no registro associado com acaracterística microarquitetural, se a contribuição de desempenho da carac-terística, quando desabilitada, for melhorada.

26. Aparelho que compreende:um microprocessador que inclui,um módulo para determinar um custo de evento por instânciapara execução de um programa de software; eum módulo para sintonizar o programa de software com base nocusto de evento por instância.

27. Aparelho de acordo com a reivindicação 26, em que deter-minar um custo de evento por instância compreende derivar o custo de e-vento por instância através de uma técnica de monitoramento de desempe-nho selecionada do grupo que consiste em contagem de duração, mediçãode descarte de retirada, e monitoramento de execução de rastreio longo.

28. Aparelho de acordo com a reivindicação 26, em que a sinto-nia do programa de software é selecionada de um grupo que consiste emrecompilar o programa de software, otimizar o programa de software, otimi-zar o programa de software para bloquear as estruturas de dados para caberdentro de um cache, retransmitir o programa de software para aproveitar-sede uma condição de predição de ramificação padrão, emitir um código emum diferente endereço de instrução, retransmitir dados em uma memóriadinamicamente alocada, e ajustar a granularidade e o alinhamento de acessos.

29. Sistema que compreende:um hub de controlador acoplado em uma memória e em um con-trolador de vídeo;um microprocessador que inclui um módulo para,determinar uma contribuição de evento por instância durante aexecução de um programa de software;sintonizar uma configuração arquitetural do microprocessadorcom base na contribuição de evento por instância;armazenar a configuração arquitetural; eressintonizar a configuração arquitetura com base na configura-ção arquitetural armazenada, quando da execução subseqüente do progra-ma de software.

30. Sistema de acordo com a reivindicação 29, em que o micro-processador é capaz de uma execução paralela fora de ordem.

31. Sistema de acordo com a reivindicação 29, em que a confi-guração arquitetural está armazenada em um registro no microprocessador.

32. Sistema de acordo com a reivindicação 29, em que a deter-minação de uma contribuição de evento por instância durante a execução deum programa de software compreende:medir uma pluralidade de descartes de retirada para uma plura-Iidade de ocorrências de evento específicas, ederivar a contribuição de evento por instância para o evento es-pecífico com base na pluralidade de descartes de retirada e no número deocorrências de evento específicas.

33. Sistema de acordo com a reivindicação 29, em que a deter-minação de uma contribuição de evento por instância durante a execução deum programa de software compreende:executar o programa de software uma pluralidade de vezes, emque cada vez que o software é executado:o número de vezes que um evento específico ocorre é mudado,eo desempenho de um percurso crítico no microprocessador émonitorado;derivar a contribuição de evento por instância do evento especí-fico com base na comparação da mudança em desempenho do percursocrítico com a mudança no número de vezes que o evento específico ocorre.