Arquitetura Crusoe. 2 Histórico 4

Transcrição

1 Arquitetura Crusoe Carlos Eduardo Andrande e Ricardo Ribeiro dos Santos Instituto de Computação - IC Universidade Estadual de Campinas - UNICAMP Avenida Albert Einstein, 1251 Caixa Postal Campinas, SP - Brasil Sumário 1 Introdução 2 2 Histórico 4 3 Visão Geral da Arquitetura Crusoe Instruções Unidades Funcionais e Pipeline Registradores Software de Code Morphing Técnicas de Software Decodificação e Escalonamento Cache Filtragem e Previsão de Desvios Técnicas de Hardware Exceções e Especulação Alias Hardware Código Auto-Modificável Gerênciamento Energético e Térmico Introdução Gerenciamento de Energia Gerenciamento Térmico Desempenho 16 1

2 7 Conclusões 20 Resumo 1 Introdução A arquitetura Transmeta Crusoe tem despertado, desde o seu lançamento, a atenção da área de arquitetura de computadores em virtude aliar estratégias de software e hardware visando maximizar o desempenho e minimizando o consumo de potência [8]. Ao contrário de outras propostas que geralmente atrelam o lançamento de uma nova versão da arquitetura com a inclusão de novas instruções, a arquitetura Crusoe não apresenta um conjunto de instruções específico ao usuário. De outra forma, o modelo de execução é baseado na tradução dinâmica de instruções x86 para o formato de instruções suportado pelo processador. A motivação para realizar a tradução dinâmica está relacionada com a possibilidade de fornecer suporte de execução a programas desenvolvidos para a arquitetura IntelR x86, através de um hardware com baixo consumo de potência e com desempenho semelhante. No entanto, essa atividade de tradução não é incumbência do hardware embutido no processador Crusoe, e sim de um componente de software denominado Code Morphing (Software de Code Morphing - SCM) que, além de traduzir instruções x86, adota técnicas avançadas de caching na tentativa de minimizar o impacto da atividade de tradução sobre o desempenho do processador. Na realidade, esse é o único software compilado diretamente para a arquitetura Crusoe, uma vez que qualquer outro software deve ser traduzido pelo SCM antes de ser executado pelo hardware. A Figura 1 apresenta uma visão de alto nível da estratégia adotada pela Transmeta. Nessa Figura é possível observar o relacionamento do SCM com o hardware e com os elementos de software do sistema [11]. Uma outra característica marcante nessa arquitetura diz respeito ao agrupamento de instruções. Diferente de arquiteturas convencionais que executam uma instrução por vez, ou mesmo de processadores superescalares que utilizam hardware para executar várias instruções simultaneamente, o SCM constrói instruções VLIW (Very Long Instruction Word) que possibilitam a execução simultânea de até 04 subinstruções x86 desde que as relações de dependências sejam respeitadas. Como é o SCM que trata das dependências, reordenação e emissão de instruções, não há necessidade de unidades funcionais específicas para esse fim no hardware da arquitetura. A arquitetura Transmeta Crusoe está voltada para o mercado de dispositivos móveis como Tablet PCs e Notebooks. Nesse tipo de mercado, reduzir o consumo de energia é um requisito tão importante quanto o próprio desempenho. Assim, a arquitetura Crusoe utiliza uma tecnologia denominada LongRun que monitora constantemente a atividade do hardware com o objetivo de averiguar se a freqüência de clock pode ser reduzida, e 2

3 Figura 1: Relacionamento entre o SCM, processador Crusoe, sistema operacional e aplicações do usuário. conseqüentemente se ganhos no consumo de energia podem ser obtidos, sem prejuízos significativos ao desempenho do processador. Diante do exposto, nota-se que esta arquitetura apresenta diversas características que permitem diferenciá-la precisamente em relação a outras comumente utilizadas. Dessa forma, este trabalho tem o objetivo de apresentar as principais características e tecnologias presentes na arquitetura Transmeta Crusoe. Para tanto, o texto foi organizado da seguinte maneira: A Seção 2 apresenta as origens da arquitetura Crusoe, assim como as principais características dos modelos já lançados no mercado. Uma visão mais detalhada da organização do hardware é apresentada na Seção 3. Nessa Seção, os principais componentes de hardware, suas funções e características são exemplificados através do modelo TM5400 TM. Informações sobre o funcionamento, atividades realizadas e modos de execução do SCM são descritas na Seção 4. Na Seção 5 são apresentados os conceitos e funcionamento da tecnologia LongRun. O desempenho dessa arquitetura é apresentado e discutido na Seção 6. Por fim, na Seção 7 tem-se as conclusões obtidas com o desenvolvimento deste trabalho. 3

4 2 Histórico A idéia original contida nos processadores da Transmeta foi concebida pela IBM nos anos 90 pelo projeto DAYSY (Dynamically Arclitected Instruction Set from Yorktown). O DAYSY foi construído em cima de uma arquitetura VLIW, que na época, apresentava vantagens significativas sobre arquiteturas superescalares, principalmente referente a custo. A idéia principal do DAYSY era traduzir o código binário de um PowerPC para uma arquitetura VLIW onde seriam executadas intrsuções em paralelo (ver [10]). Mas esse projeto foi descontinuado. Entretando a idéia não foi abandonada, quando a Transmeta efetivamente colocou a tecnologia em funcionamento. Seu marketshare foi baseado em arquitetura x86, o que fez mais aparente que outras implementações, como o TMS320C6x da Texas Intruments. A Transmeta foi fundada em 1995 quanto recrutou um staff altamente competente, do qual o pai do Linux, Linus Torvalds fazia parte. Durante 4 anos, a Transmeta manteve secredo sobre o que vinha desenvolvendo quando, em 1999, revelou seu projeto de um processador de baixo consumo. Em 20 de janeiro de 2000, a Transmeta lançou seu primeiro processador: o TM3120. Este processador foi desenvolvido visando o mercado de dispositivos móveis e executava sobre o sistema operacional Mobile Linux, com 32MB. Foi construído com o processo de 0,22µm, e o tamanho de seu die era de 77 mm 2. Esse tamanho foi possível com a eliminação de 75% dos transistores que eram necessários para um hardware de similar desempenho funcionar. Tinha 96KB de cache nível 1 onde 64KB eram dedicados a instruções e 32KB dedicados a dados, e interface que variava de 66 a 133MHz com memórias SDRAM (a ponte norte faz parte do mesmo die em processadores Crusoe). Seu consumo em operação era de 20mW no nível mais baixo e, em média, 1W o que era 4 vezes menos que os processadores similares. Foi lançado iniciamente nos clocks 333, 366, and 400MHz [9]. Em março do mesmo ano, o TM foi lançado. Voltado ao mercado de dispositivos completos ultra-leves(notebooks), o TM5400 tinha 128KB de cache nível 1, metade para instruções, metade para dados, e mais 256KB de cache nível 2 integrados no die do processador. A interface de memória (ponte norte) acrescentou suporte a memórias DDR. Era esperado que esse chip fosse utilizado em conjunto com Microsoft Windows. Assim como o TM3120, foram reduzidos 75% dos transistores em comparação com um processador de similar desempenho, o que proporcionou um die de 73 mm 2 em um processo de 0.18µm. Consumia em média 1W em aplicações comuns, como aplicações de escritório, e no máximo 2W, como por exemplo aplicações multimídia Foi comercializado em velocidades entre 500 a 700MHz. Uma versão mais recente com alteração no tamanho da cache nível 2 (512KB) é o TM5600 [9]. Em seguida, utilizando a tecnologia de 0,13µm, a Transmeta lançou o TM5500 (128KB de cache L2, freqüência de 667 a 800MHz) e o TM5800 (512KB de cache L2, freqüência de 1 O modelo TM5400 será descrito com mais detalhes na Seção 3 4

5 667MHz a 1GHz) que possuem um controlador de memória de 64 bits SDR e DDR SDRAM, juntamente com um controlador PCI de 32 bits. A vantagem exposta pela Transmeta é que a maior integração entre os controladores facilita a redução do consumo de energia. O tamanho destes processadores é 32,5mm x 25mm. No intuito de reduzir ainda mais o tamanho dos processadores, a Transmeta lançou em 2003 o TM5700 (128KB de cache L2, freqüência de 667MH) e o TM5900 (512KB de cache L2, freqüência de 667MHz a 1GHz), cujo tamanho é de apenas 21mm 2 [5]. Recentemente a Transmeta [4] lançou uma nova geração de seus processadores VLIW chamada Efficeon. Os Efficeon s são baseados em máquinas VLIW de 256 bits o que permite a execução de 8 instruções x86 simultaneamente, contra 4 instruções dos processadores Crusoe. O Efficeon apresenta cache L1 de 128KB para instruções e 64KB para dados, e contém 1MB de cache L2, com suporte a ECC (Error Checking and Correction, correção na paridade de erros na cache). Acrescenta supporte a instruções SSE e SSE2 que auxiliam na execução de programas multimídia além de conter 1MB de cache L2, com suporte a ECC. Outra diferença em relação ao Crusoe, é que a ponte norte integra um controlador de memória DDR-400, suporte a HyperTransport TM, um controlador AGP de 4x e um barramento LPC (Low Pin Count) para acesso a memórias Flash LPC. Além disso, apresentam melhorias no software de Code Morphing e tecnologia LongRun. Além dessas características, o Efficeon possui implementa uma tecnologia denominada AntiVirusNX TM, que trabalha em conjunto com a tecnologia Data Execution Protection (DEP) da Microsoft, prevenindo ataques de estouro de memória por códigos maliciosos. Esse processador é fabricado sob os modelos TM8600, de 1GHz a 1,1GHz de tamanho 29mm 2, TM8620, também de 1GHz a 1,1GHz mas com tamanho de 21mm 2, e TM8800, com clock até 1,6GHz e tamanho 2mm 2. 3 Visão Geral da Arquitetura Crusoe Nesta seção as características da arquitetura Crusoe são apresentadas e discutidas com um nível maior de detalhamento em relação às Seções anteriores. O modelo aqui exemplificado corresponde ao processador TM5400 TM. Embora não seja o modelo mais recente da arquitetura, o TM5400 TM possui os principais recursos presentes em versões mais recentes como o TM5800 TM e TM5900 TM. Além disso, foi o único modelo encontrado na literatura com documentação mais detalhada. A Figura 2 apresenta a organização do processador TM5400 [8]. Em termos de capacidade de memória, a arquitetura possui 128K de memória cache divididos em uma cache de instruções 8-way set associative e uma cache de dados 16-way set associative. Além disso, possui uma cache L2 de dados e instruções de 256K com 4-way set associative. Uma diferença significativa entre o modelo TM5400 TM e versões anteriores da arquite- 5

6 Figura 2: Arquitetura do Processador Crusoe TM5400 TM tura Crusoe diz respeito a presença do hardware de gerenciamento de freqüência/voltagem. A tecnologia LongRun possibilita considerável economia no consumo de energia do processador e será discutida com mais detalhes na Seção 5. A Subseções a seguir discutem mais detalhadamente sobre a organização da arquitetura com relação ao conjunto de instruções, unidades funcionais e pipeline e registradores. 3.1 Instruções Como já apresentado na Seção??, independente do modelo de processador, a execução de instruções nessa arquitetura é baseada em instruções VLIW de 128 bits que agrupam subinstruções de 32 bits. No contexto dessa arquitetura, instruções VLIW são chamadas de moléculas e subinstruções são chamadas de átomos. A medida que um programa do usuário vai sendo executado, o software de Code Morphing traduz as instruções x86 e organiza essas instruções 2 traduzidas em moléculas VLIW de 128 ou 64 bits. Cada molécula 2 Os mnemônicos das instruções não são apresentados nos documentos da arquitetura Crusoe disponibilizados pela Transmeta. 6

7 possui dois ou quatro átomos de 32 bits. Caso o SCM não consiga preencher uma molécula VLIW com átomos válidos, instruções NOP são inseridas nos slots vazios. Através dessa característica, ao mesmo tempo em que possibilita a execução de até 4 instruções simultaneamente, a arquitetura não necessita de unidades funcionais para reordenação de instruções e despacho fora de ordem como acontece com arquiteturas superescalares, uma vez que é responsabilidade do SCM realizar a emissão de instruções válidas (respeitando a dependência) para o hardware. O formato das moléculas VLIW suportadas pela arquitetura são apresentadas na Figura 3. Figura 3: Formato de moléculas VLIW da arquitetura Crusoe Um ponto que deve ser observado é que a indicação do tamanho da molécula (128 ou 64 bits) e o tipo das instruções presentes é fornecido pelos 3 bits mais significativos. Além disso, o bit mais significativo (Cmit) é utilizado para indicar que os valores dos registrados em uso pela instrução devem ser salvos em registradores de cópia. 7

8 3.2 Unidades Funcionais e Pipeline Com relação às unidades funcionais, o modelo TM5400 TM possui 2 ULAs para manipulação de inteiros, uma unidade de load/store, uma unidade de desvio e uma unidade de ponto flutuante. Essas unidades funcionais são utilizadas de acordo com o pipeline em execução que, por sua vez, varia de acordo com o tipo de instrução. Devido a utilização de recursos de software para organizar e escalonar as instruções, a lógica de controle em hardware torna-se mais simples. Assim, o processador Crusoe implementa um pipeline de 7 estágios para instruções que manipulam inteiros e um pipeline de 9 estágios para instruções de ponto-flutuante 3 e multimídia. O fluxo de execução de cada pipeline presente na arquitetura Crusoe é apresentado na Figura 4. Figura 4: Fluxo de execução dos pipelines existentes na arquitetura Crusoe TM5400 Como pode ser observado na Figura 4, todos os pipelines possuem dois estágios destinados a busca dos átomos da molécula VLIW. O estágio de Commit é responsável por atualizar os registradores de cópia com os registradores atualmente em uso caso nenhuma exceção tenha sido gerada. Nesse mesmo estágio, os dados armazenados no gated store buffer (Figura 2) são também atualizados na memória. Os demais estágios possuem nomenclatura e atividades semelhantes aos de algumas arquiteturas RISC.!!!!! ATENÇÃO, NESSE PONTO HÁ UMA REFERÊNCIA PERDIDA. VERIFICAR!!!!!! /cite{patterson1987} No pipeline que trata de instruções de desvio, o primeiro estágio consiste na previsão da tomada ou não do desvio. Essa previsão é decidida tendo como base uma tabela com o histórico dos desvios tomados e não-tomados. O estágio de verificação decide se o caminho 3 Em versões mais recentes, o pipeline de ponto-flutuante possui 10 estágios 8

9 tomado pela instrução de desvio está ou não correto. Caso não esteja, a tabela de histórico de saltos deve ser atualizada e os efeitos das instruções que foram incorretamente carregadas na pipeline, em virtude da tomada de decisão errada, devem ser desfeitos. 3.3 Registradores Por fim, deve-se destacar que a arquitetura apresentada na Figura 2 possui 64 registradores de propósito geral com capacidade de 32 bits e 32 registradores de ponto flutuante com capacidade de 80 bits. Alguns dos registradores de propósito geral são usados com a mesma semântica dos registradores x86, conforme exemplificado a seguir [15]: %r63 (%zero): sempre lê 0 quando usado como operando fonte %r59 (%from): endereço de retorno para o qual um procedimento deve retornar %r58 (%link): endereço para o valor de retorno de um procedimento %r47 (%sp): ponteiro atual para a pilha %r0 (%eax): registrador de 32 bits da arquitetura x86 %r1 (%ecx): registrador de 32 bits da arquitetura x86 %r2 (%edx): registrador de 32 bits da arquitetura x86 %r3 (%ebx): registrador de 32 bits da arquitetura x86 Os registradores numerados de r0 até r47 possuem registradores de cópia. Assim, quando uma instrução VLIW possui o bit de commit configurado, o estágio de commit no pipeline realiza a cópia do valor do registrador para o registrador de cópia equivalente. O efeito dessa atividade significa que a instrução executou corretamente e nenhuma exceção foi gerada. O mesmo princípio, também é aplicado para instruções de ponto flutuante em que há 16 registradores de destinados para cópia. Apesar da unidade de ponto flutuante/multimídia possuir capacidade para manipular os mesmos tipos de dados que instruções MMX de processadores Intel, o processador Crusoe não possui registradores de 128 bits utilizados em instruções SSE e não possui suporte para extensões 3DNow da AMD [8]. 4 Software de Code Morphing De forma geral, o software de Code Morphing (SCM) consiste em um sistema de tradução dinâmica em que um programa traduz instruções de uma arquitetura base (x86) para uma arquitetura alvo (VLIW Crusoe). Esse software isola completamente programas x86 do hardware Crusoe e, dessa forma, o conjunto de instruções nativo do processador 9

10 pode ser modificado sem afetar qualquer software x86. Nesse caso, o único programa que necessita ser atualizado para compreender esse novo conjunto de instruções é o próprio SCM. A Figura 4 exibe o relacionamento entre programas x86, software de code morphing e o processador Crusoe [11]. Figura 5: Relacionamento entre o Software de Code Morphing programas x86 e o processador Crusoe. Durante o processo de boot do processador, depois que o controlador DRAM e os controladores da memória cache estão configurados, a imagem do SCM é copiada de uma memória flash ROM interna para o processador, descompactada e copiada para um endereço específico da RAM. A partir de então, o SCM possui o controle sobre a execução de programas no processador. Por questões de segurança, existem duas cópias do SCM em flash ROM. Caso a primeira cópia apresenta alguma falha, a segunda cópia é utilizada. Em termos de fluxo de execução, inicialmente o SCM decodifica e executa instruções x86 sequencialmente, verificando ordem de acessos à memória e geração de falhas e exceções. Ao mesmo tempo, coleta dados a respeito da freqüência de execução de determinada instrução, direção tomada por uma instrução de desvio e operações de I/O mapeadas em memória. Quando o número de execuções de um determinado trecho de código x86 alcança um limite, o endereço onde esse trecho está armazenado é repassado para o o componente de tradução do SCM. Esse componente seleciona uma região que inclui esse endereço e gera 10

11 código nativo (VLIW Crusoe) que corresponde ao código x86 dessa região. Essa tradução é armazenada na memória cache de tradução. A partir dessa atividade, se o fluxo de execução do programa x86 alcançar novamente esse trecho de código que foi traduzido, o SCM executa diretamente o código traduzido e nenhuma atividade de interpretação será necessária. Esse código é mantido na cache de tradução durante a execução do programa ou até que alguma operação possa invalidá-lo [6]. A flexibilidade da abordagem de tradução por software acarreta um preço [11]: o processador deve dedicar alguns ciclos de processamento para o SCM, ciclos esses que um processador convencional poderia usar para executar um programa do usuário. Logo, a tradução por software deve utilizar algumas técnicas e recursos para não prejudicar o desempenho dos programas traduzidos. 4.1 Técnicas de Software As técnicas apresentadas a seguir são implementadas no contexto do SCM e possibilitam minimizar o impacto da atividade de tradução dinâmica sobre o desempenho do programa do usuário Decodificação e Escalonamento Como já discutido, na tentativa de minimizar a sobrecarga na tradução de instruções x86, o SCM avalia a freqüência de execução das instruções e, caso essa freqüência ultrapasse um limite, essas instruções são traduzidas para instruções nativas do hardware. Além disso, esse código traduzido é reescalonado, otimizado e colocado em uma cache de traduções Cache O cache de traduções e o software de code morphing residem em um espaço separado que é inacessível para programas x86. O tamanho desse espaço de memória pode ser configurado em tempo de boot ou o sistema operacional pode definir esse tamanho. Usando uma cache para manter o código nativo e otimizado possibilita executar trechos de código comumente requisitados pelo programa sem nenhuma sobrecarga de tradução e, conseqüentemente, melhorando significativamente o desempenho de execução Filtragem e Previsão de Desvios O software de code morphing possui vários modos para executar códigos baseados em x86. Esses modos variam da interpretação, da tradução simples com geração de código sem otimização, até a geração de código altamente otimizado. Um conjunto de heurísticas determina o modo de execução baseado nas informações atuais de execução do código. De forma geral, o software de tradução adiciona recursos no código do usuário cujo único propósito é coletar a freqüência de execução desse código ou histórico de desvios. Essas 11

12 informações podem ser usadas posteriormente para decidir quando e o que otimizar e traduzir. No caso de instruções de desvio, a decisão prévia de qual caminho deve ser tomado é importante pois possibilita que otimizações possam ser realizadas no caminho escolhido mais freqüentemente. 4.2 Técnicas de Hardware Além das técnicas empregadas diretamente pelo SCM, a arquitetura Crusoe possui componentes de hardware que auxiliam no processo de tradução dinâmica [11] [6]. Esses componentes são principalmente utilizadas para manter a coerência dos dados traduzidos Exceções e Especulação A geração de exceções impõe restrições severas no escalonamento de instruções em virtude de que quando uma instrução causa exceção, algumas instruções devem ser completadas (instruções precedentes) enquanto outras não podem completar (instruções subsequentes). A arquitetura Crusoe procura resolver esse problema através de registradores de trabalho e registradores de cópia. Durante a execução de um átomo, apenas os registradores de trabalho são atualizados. Se o átomo executa e nenhuma exceção é gerada, o estágio de commit copia o conteúdo dos registradores de trabalho alterados pela instrução corrente para os registradores de cópia. De outra forma, se uma exceção é gerada, a ação provocada por todas as moléculas executadas após a exceção é desfeita. O retorno para um estado consistente é possível através da trasnferência do conteúdo dos registradores de cópia para os registradores de trabalho Alias Hardware Quanto mais liberdade o escalonador de instruções tem para preencher as moléculas, melhor é o código gerado. No entanto, nem sempre é possível ter essa liberdade devido às dependências de dados existentes no código. No caso de operações que envolvem dados da memória como load e store é necessário muito cuidado antes de trocar a ordem dessas instruções no escalonamento. A solução empregada pela arquitetura Crusoe para detectar inconsistências quando a ordem de operações da memória são trocadas, consiste na utilização da instrução load-and-protect - ldp, para o caso de loads, e store-under-alias-mask - stam, para stores. A instrução ldp carrega os dados da memória e armazena o endereço e tamanho do dado carregado. A instrução stam verifica se a escrita na memória acontecerá em um endereço que foi utilizado pela instrução ldp. Caso isso ocorra, uma exceção é gerada e o código que disparou a exceção é novamente executado de maneira seqüencial (sem escalonamento). 12

13 4.2.3 Código Auto-Modificável É possível que instruções armazenadas na memória seja sobreescritas, devido ao carregamento de um novo programa ou mesmo através de um código que realiza uma automodificação. Nesse caso, se o trecho de código escrito já foi traduzido, o SCM necessita atualizar a cache de traduções ou simplesmente invalidá-lo. Para ter o conhecimento de quais instruções foram sobreescritas, o sistema de tradução de instruções configura um bit na página armanzena o endereço do código traduzido na unidade de gerenciamento de memória (Memory Management Unit - MMU). Assim, quando uma instrução já traduzida é sobreescrita, o sistema de traduções invalida essa tradução. 5 Gerênciamento Energético e Térmico 5.1 Introdução O processador Crusoe foi concebido com o intuito de alcançar alto desempenho com um baixo consumo de energia. A chave para redução do consumo é o Code Morphing que repõe um conjunto de transistores por software. O Code Morphing é responsável pela tradução de complexas instruções x86 que requerem hardware complexo, portanto caro em termos de dissipaçào energética, por instruções RISC que requerem hardware mais simples e compacto. A principal vantagem da redução do consuno é o prolongamento da vida das baterias, cruscial em dispositivos móveis como laptops e tablet PCs. O menor aquecimento exclui a necessidade de arrefecimento ativo o que diminui o custo, peso e ruído. 5.2 Gerenciamento de Energia O gerenciamento de energia usual nos processadores x86 geralmente segue o padrão ACPI que define um estado ligado(com 100% de atividade) e múltiplos estados desligados, o que remete a variações apenas com ativação e desativação do hardware. Isso pode ser perceptível ao usuário, por exemplo, flicks durante a exibição de um DVD. O Crusoe é compatível com esse padrão, mas diferente do mesmo, utiliza um conjunto de técnicas sofisticadas chamado LongRun TM Power Management, que evita que o usuário perceba a mudnaça de estados e consegue economizar mais energia que os processadores x86 tradicionais. No estado ativo, 90% da dissipação de energia pode ser calculada pela equação: Energia dissipada = (Capacitância freqüência voltagem 2 )/2 O sucesso na economia de está em diminuir os fatores desta equação. 13

14 Quanto a capacitância, o projeto do Crusoe conseguiu repor transistores responsáveis por funções complexas por código mais simples gerado pelo Code Morphing, que utiliza um conjunto menor de transistores. A utilização de VLIWs também evita um controle adicional mais complexo comuns em arquiteturas superescalares como, por exemplo, o Pentium IV. Quanto à freqüencia e à voltagem, o Crusoe modifica ambas dinamicamente, diferente da mudança de estados dos x86 tradicionais. Isto é plausível já que o processador raramente utiliza sua capacidade máxima. Assim em operações mais leves, o Crusoe diminui o clock e a voltagem sem perda de desempenho perceptiva ao usuário. A figura 5.2 mostra o perfil típico de utilização do processador. Figura 6: Perfil típico de utilização de um processador O Crusoe pode mudar a freqüência do clock em inbtervalos de 33 MHz e a voltagem em intervalos de 25mV (dependendo do regulador de voltagem) em uma taxa de 200 vezes por segundo, indo do patamar de 300 MHz e 1,2V até 1 GHz e 1,4V. Na figura 5.2 é mostrado o perfil de consumo do Crusoe. Os algoritmos do LongRun monitoram continuamente a demanda por desempenho ajustando a freqüência e voltagem segundo esta demanda, o que representa uma economia significativa. Por exemplo, em uma aplicação que requer 90% da capacidade de processamento, processadores convencionais economizam em torno de 10% de energia, enquanto o Crusoe com as políticas do LongRun chegam a economizar por volta de 30%. O sistema LongRun tem como principal política a redução dos tradicionais estados de hibernação. Há uma grande perda nos processadores x86 na alternação entre estados de hibernação e estados ativos. As heurísticas do LongRun ao invéz de utilizar as estratégias tradicionais, reduzem a freqüência e voltagem do Crusoe em operações mais simples o que 14

15 Figura 7: Perfil de Consumo do Crusoe aumenta a utilização do processador e evita grandes salvamentos de contexto típicos na transição de um estado ativo para a hibernação. O Crusoe intrega em seu die a ponte norte em uma tentativa de redução no consumo da memória também. Embora as memórias não permitam variação na voltagem, sua freqüência pode ser mudada. No caso das memórias SDR, praticamente não existe piso na freqüência permitindo uma gama de variações até o teto de 100 MHz ou 133 MHz (PC-100 e PC-133, respectivamente). No caso das memórias DDR, o controle é feito pelas mesmas, variando de 80 MHz a 153 MHz. 5.3 Gerenciamento Térmico Outro conceito amplamente pensado e trabalhado nos processadores Crusoe é a eficiente gerência térmica. O gerenciamento térmico em dispositivos móveis cpnsome boa parte da energia com soluções ativas de resfriamento (coolers, ventoinhas). Além disso, essas soluções apresentam ruído, que junto da alta temperatura, representam desconforto ao usuário. Os sistemas baseados no processador Crusoe se beneficiam do LongRun TM Management Thermal Extension que intrega à solução energética, a solução térmica. Assim é possível elimibar o arrefecimento ativo, diminuindo o consumo. A figura 5.3 mostra uma comparação entre desempenho e consumo. Nota-se que um processador x86 convencional gasta 17W contra 6W de um processador Crusoe com o mesmo desempenho. Na realidade, um processador Crusoe executando um software de DVD apresenta o mesmo consumo que um processador convensional no estado de hibernação mais profundo (clock interno e externo parado, sem nenhuma tarefa feita). 15

16 Figura 8: Comparação entre desempenho e consumo do Crusoe e processadores x86 típicos 6 Desempenho Em geral, os dados sobre o desempenho do Crusoe são escassos, muitas vezes referidos a alguns artigos de revistas não-técnicas ( [13,14] ) e relatórios técnicos da própria Transmeta ( [2, 3, 12] ). O maior problema da avaliação de desempenho, segundo alega a Transmeta, é que as ferramentas utilizadas para benchmarking existentes no mercado são construídas para a medição do pico de desempenho das máquinas, situação muitas vezes, não atingida na utilização normal, principalmente em dispositivos móveis. Um verdadeiro benchmark de dispositivos móveis deve levar em conta o desempenho alcançado e o consumo de energia em situações de carga de trabalho reais (workloads) [12]. Geralmente, as ferramentas utilizadas para o benchmarking são sintéticas, ou seja, tentam simular as condições de uso do dispositivo. O problema é que muitas vezes estas ferramentas não o fazem satisfatoriamente, principalmente no que consta da utilização de dispositivos de entrada e saída e utilização real pelo usuário. Considera-se dois tipos de workloads: demanda fixa, onde a necessidade de desempenho em um determinado período de tempo é relativamente constante, como por exemplo, a reprodução de um DVD; demana variável, onde a necessidade de desempenho é determinada por vários fatores como tempo de resposta do usuário, tempo de resposta de dispositivos de entrada e saída, entre outros. Claramente, a situação mais comum é de demanda variável, como por exemplo uma aplicação de escritório onde geralmente a demanda é baixa quando 16

17 sob controle do usuário e alta em algum tipo de processamento independente. Assim, algumas métricas podem ser utilizadas: Taxa de Conclusão de Workload(Throughput): O throughtput é uma taxa clássica utilizada para medir o pico de desempenho ao nível de aplicação. Dada por: Throughtput = Workload Tempo gasto para conclusão A taxa é dada em unidades de workload por hora. É uma métrica importante na análise de cargas de trabalho com demanda variada e processos com intensa troca de informações entre memória e processador. Eficiência energética: É a eficiência na conclusão de um workload concluído de um sistema. Descreve a enegia consumida e pode ser definida como: Eficiência Energética = Workload concluído Energia consumida para conclusão A eficiência é medida em unidades de workload por Watts-hora. Eficiência do throughtput: É a relação de consumo de energia no pico de desempenho. Medida em unidades de workload por hora por Watts-hora. Dada por: Eficiência do throughtput = Throughtput Energia consumida para conclusão Esta medida é uma das mais importantes em dispositivos móveis já que mede o consumo na realidade, levando em conta as variações na demanda de processamento. A Transmeta realizou um benchmarking comparativo entre 3 sistemas utilizando Microsft Windows 98 SE R, Office 2000 R, Internet Explorer R, um reprodutor de MP3 e um reprodutor de DVDs. As máquinas testadas foram: 1. Pentium III de um fabricante de notebooks OEM, 64M PC-100 SDRAM, 0, 18µ, cache L2 integrada, núcleo Coppermine de 500MHz utilizando 1,54V, chipset 440BX, gerenciamento de energia ACPI setado para máxima economia de energia; 2. TM5400 em uma plataforma TM FTM 4, 64M PC-133 SDRAM, 266MHz/1,225V a 533MHz/1,6V, gerenciamento de energia ACPI setado para máxima economia de energia, LongRun TM habilitado 5; 4 Não foram encontradas referências sobre esta plataforma 17

18 3. TM3120 em uma plataforma TM WTM 5, 64M PC-133 SDRAM, gerenciamento de energia ACPI setado para máxima economia de energia. Os dados apresentados nas tabelas 1, 2 e 3 foram coletados pela própria Transmeta [2] utilizando a terminologia: LOS - Workload do carregamento do sistema operacional; WDI - Workload do desktop inativo do Windows; O2K - Workload do Office 2000 R ; WEB - Workload do navegador Web; MP3 - Workload de um areprodução de MP3; DVD - Workload de um areprodução de DVD. Tabela 1: Throughtput de softwares comuns em um desktop Pentium TM5400 TM3120 TM5400/Pentium TM3120/Pentium LOS 60,0 55,2 50,7 0,92 0,84 WDI 60,0 60,0 60,0 1,00 1,00 O2K 60,0 48,0 44,9 0,80 0,75 WEB 60,0 60,0 59,3 1,00 0,99 MP3 60,0 60,0 60,0 1,00 1,00 DVD 60,0 60,0 60,0 1,00 1,00 Tabela 2: Eficiência energética de softwares comuns em um desktop Pentium TM5400 TM3120 TM5400/Pentium TM3120/Pentium LOS 5,85 20,0 15,0 3,42 2,56 WDI 11,90 75,5 51,8 6,34 4,35 O2K 8,45 24,0 16,4 2,84 1,94 WEB 9,84 40,3 27,1 4,10 2,75 MP3 11,00 52,0 34,5 4,73 3,14 DVD 8,85 27,6 20,9 3,12 2,36 Pelos dados fornecidos podemos observar que o throughtput é praticamente igual para os processadores apresentados ocorrendo uma pequena na carga do sistema operacional e utilização do Office. Talvez essa correlação pode ser dada pois o Office utiliza várias funções 5 Não foram encontradas referências sobre esta plataforma 18

19 Tabela 3: Eficiência do throughtput de softwares comuns em um desktop Pentium TM5400 TM3120 TM5400/Pentium TM3120/Pentium LOS ,17 WDI ,33 O2K ,45 WEB ,72 MP ,13 DVD ,35 do Windows. Quanto a eficiência energética, o Crusoe, em suas duas versões, apresenta desempenho bem superior ao processador Pentium, em fatores de até 6, principalmente em momentos de inatividade da máquina. Mesmo com a utilização mais intensa da CPU como reprodução de MP3 e DVD o Crusoe responde com um fator de 3, ou seja, sua eficiência é aproximadamente 3 vezes melhor que o Pentium. Por fim temos a eficiência energética dos processadores Crusoe, levando-se em conta o throughtput apresenta fatores na média de 3 vezes a eficiência do Pentium. Entretanto, esses dados não condizem com dados de ferramentas de benchmarking comercias como o Winstone TM 99 e o BatteryMark TM 99 da ZD Labs. A Transmeta alega que estas ferramentas não conseguem reproduzir a realidade de utilização das máquinas, assim não pode avaliar corretamente o impacto das tecnologias utilizadas para gerenciamento de energia e carga de trabalho [3]. Entretanto, algumas publicações tem comparado os processadores com essa ferramenta. Um artigo da revista PC Magazine [14] compara algumas máquinas do mercado utilizando o Winstone TM 2003 e o BatteryMark TM A figura 6 mostra essa comparação. Figura 9: Comparação entre algumas máquinas do mercado. Podemos ver que o Crusoe deixa a desejar em se tratando deste benchmark, principalmente no quesito energia onde deveria ser o melhor. Mas devemos nos atentar que neste caso também é levado em conta a arquitetura e tecnologia do restante da máquina, não 19

20 só o do processador, o que pode distorcer os dados. O artigo [14] afirma que a máquina é decididamente a mais diferentes das máquinas testadas, o que pode justificar a afirmativa anterior. Já no artigo [13], o Crusoe é inserido em um Tablet PC e apresenta bons resultados principalmente na economia de energia, alcançando uma marca de 3 horas e 20 minutos no BatteryMark. 7 Conclusões Referências [1] Elizabeth Connor. Transmeta introduces Crusoe Visitado em 05/11/2004. [2] Transmeta Corporation. Crusoe TM Processor Benchmark Report. Technical report, Transmeta Corporation, [3] Transmeta Corporation. Crusoe TM Processor Systems and ZD Labs Winstone TM 99 and BatteryMark TM 3.0 Benchmarks. Technical report, Transmeta Corporation, [4] Transmeta Corporation. Efficeon Processor. em 05/11/2004, [5] Transmeta Corporation. Crusoe Processor Visitado em 05/11/2004. [6] James C. Dehnert, Brian K. Grant, John P. Banning, Richard Johson, Thomas Kistler, Alexander Klaiber, and Jim Mattson. The transmeta code morphing software: Using speculation, recovery, and adaptive retranslation to address real-life challenges. In Proceedings of the First Annual IEEE/ACM International Symposium on Code Generation and Optimization, [7] Marc Fleischmann. Longrun TM Power Management. Technical report, Transmeta Corporation, [8] Tom R. Halfhill. Transmeta Breaks x86 Low-Power Barrier. Microprocessor Report, [9] Rob Hughes. Transmeta s Crusoe Microprocessor Visitado em 05/11/