quarta-feira, 5 de agosto de 2009

A inversa dos estereótipos

Lá vai a moça toda enfeitada, linda e maravilhosa (vulgo gostosa) atravessando a rua, sem fazer nada, apenas atravessando, era Zuleica.
Tá o nome não correspondia a beleza da moça, mas acreditem ela era uma formosura de moça, daquelas de parar o trânsito, uma morena de cabelos cacheados, seios firmes (talvez siliconados, hoje todo mundo põe, não dar para ter certeza), as ancas quase não cabiam na calça, redonda e empinada, olhos cor de mel, e a boca mais perfeita que já vi na vida.
Eis que, do nada, surge Janjão (do caminhão) o moço truculento e sem papas na língua. Chegou, olhou para o lado, suspirou, alisou a barriga e foi logo dizendo.
- Nossa Senhora! Isso lá em casa eu caia matando todo dia e toda hora. Casa, comida e roupa lavada. Topa?
Como Zuleica era moça direita e não aceitava desaforo e homens metidos a engraçadinhos foi logo rebatendo.
- Olha aqui! O Senhor chega com este palavreado chulo, descabido, e em péssima hora.
- Mas, o que te preocupa belezura, vamos ali tomar uma cervejinha e prosear sobre a vida.
- Meu Senhor!
- Senhor tá no céu. Janjão, a seu dispor...
- Janjão, você acha que eu sentaria no bar para prosear com um rapaz que chega, do nada, com uma cantada machista destas.
- Mas o que é isto meu bem.
- Meu bem, não. Meu nome é Zuleica, e não sou seu bem. Sou estudada, tenho diploma de Jornalismo (como se valesse alguma coisa), doutorado em Stanford e nem que você fosse o último homem na face da Terra, iriamos ter alguma coisa.
Neste momento Janjão começou a chorar. Não suportou aquelas palavras duras de Zuleica. Visualizando aquela cena, de um brutamontes chorando, Zuleica se sentiu tocada e pensou com seus botões. - Nossa, um homem sensível, acho que ele não deve ser de todo mal, foi logo tentando reparar o feito. Mudou até o tom de voz (e que linda voz tinha Zuleica)
- Não chora Janjão. Não disse por mal...
Janjão estava aos prantos (vai saber o real motivo do rapaz, talvez ele fosse mesmo sensível), sim, sim, neste momento estava soluçando de tanto chorar.
- Aaaaii, me desculpa moça, não disse por mal.
- Janjão, acalme-se. Enxugue estas lágrimas e vamos até ali tomar aquela cervejinha.
Janjão deu aquela cafungada, enxugou as lágrimas na camisa e lá se foram eles para o bar.

Algumas horinhas se passaram, Janjão e Zuleica descobriram que tinham mais coisas em comum do que imaginavam, seus pais se conheciam de umas férias em Porto de Galinhas, suas irmãs frequentavam a mesma faculdade e Janjão fizera o seu doutorado em Harvard (vai saber o que ele estava fazendo dentro de um caminhão).
Na saída, pareciam amigos de infância, a moça que não era destas, já não tava nem aí pra nada, a mão boba corria solta e dali foram para a casa de Zuleica.

Depois daquele dia não vi mais Zuleica e Janjão, não sei se foram felizes para sempre, se tiveram muitos filhos ou simplesmente uma foda homérica naquela sexta-feira pós-expediente. Caso alguém tenha notícias de Zuleica ou Janjão, favor comunicar.

terça-feira, 16 de junho de 2009

Uma viagem sobre IA (Compilação de esquisitisses)

Nos últimos meses tenho pensado sobre Inteligência Artificial (IA) e em suas aplicações. Tudo começou enquanto assistia aos episódios de "Ghost in the shell", surgiu uma curiosidade tremenda sobre o assunto.
O conceito básico de IA se divide entre a IA fraca e a IA forte. A IA fraca trata-se da resolução de problemas não determinísticos, já a IA forte propõe um computador que seja capaz de raciocinar e resolver problemas e também é classificada como auto-consciente.
Existem várias discussões filosóficas sobre o assunto, muitos delas tratadas em filmes como IA, O homem bicentenário, Eu robô e vários outros, creio que todo mundo já tenha assistido a algum destes filmes.

Há aqueles que pregam que a inteligência precisa de meios biológicos para ser considerada inteligência como a nossa, e outros que pregam o contrário. (Opinião, cada um tema a sua).
Pensando um pouco sobre isto cheguei ao seguinte:

A inteligência/conciência nada mais é do que uma análise lógica que damos a certos fatos com base em nossas experiências e conhecimentos adquiridos ao longo de nossa existência. Podemos, assim, ter visões distintas sobre um mesmo assunto, vista por pessoas diferentes e até mesmo por uma mesma, em tempos distintos, já que a experiência adquirida pode influênciar na lógica com que analisamos/interpretamos um fato. A consciência é a essência do ser é ela que define a sua individualidade, semela seriamos uma casca sem sentido.
A base "biológica" nada mais é do que o meio para a reprodução desta essência, se a reprodução desta essência se der através de outros meios (artificiais), permitindo que os seres se desenvolvam como nós, poderiam então eles nos julgar como máquinas.

Nosso organismo se assemelha muito às maquinas e vice versa. Nosso material genético é o programa responsável por definir a nossa programação, cada célula de nosso corpo carrega parte deste código e se torna um programa que executa funções limitadas e específicas. Estes programa, agrupados, podem dar origem a tecidos mais complexos e que em conjunto poderão formar órgãos, programas mais complexos para desempenhas uma gama maior de funcionalidades e estes por sua vez, formam sistemas mais complexos (respiratório, circulatório, etc.) que em conjunto e integrados formam o ser, fruto desta programação.

Iniciei minha pesquisa sobre algumas linguagens utilizadas em IA e encontrei o LISP uma coisa que achei interessante foi a possibilidade de um programa receber como entrada um outro programa o que o torna muito flexível e com uma infinidade de opções (em teoria pelo menos).

Um assunto muito interessante que anda rondando a minha mente doentia nos últimos meses.

domingo, 8 de março de 2009

Consumo de energia e otimização de código

Consumo de energia e otimização de código


Tenho ouvido falar muito sobre eficiência energética, taxa de carbono, custo de refrigeração de data centers. Isto me deixou intrigado e comecei a pensar em como a construção de aplicativos (componentes, sistemas, etc.) pode ajudar na otimização e economia de energia. Claro que este é um assunto muito vasto e poderão ser tomadas decisões distintas, dependendo de cada projeto. Teve um sistema a que tivemos acesso, e que possuía grandes problemas de performance e consequente consumo de energia. Este projeto era desenvolvido utilizando banco de dados SQL Server 2000/2005 e Visual Basic 6.0., com base nisto as soluções mostradas foram baseadas nesta aplicação e servirá apenas como um modelo para exemplificação.


Princípios para economia de energia

  • Minimizar a quantidade de dados armazenados: dado utiliza energia já que dados armazenados em aplicações de banco de dados ou sistema de arquivos necessitam de operações em disco para serem armazenadas. Então, reduzindo a quantidade de dados armazenados podemos reduzir a quantidade de energia utilizada por uma aplicação, por reduzir a quantidade de dados na infraestrutura de armazenamento.” (FRANCIS e RICHARDSON, p. 11, 2009).

  • O princípio, ainda mais importante do que o primeiro, seria “desenvolver e codificar aplicações eficientes: No passado os desenvolvedores eram forçados a codificar cuidadosamente porque os computadores eram muito lentos e códigos ineficientes faziam a aplicação inutilizável. A lei de Moore nos deu computadores poderosos com recursos de hardware com taxas mais velozes do que poderíamos consumir, resultando em aplicações que aparentemente executam corretamente e melhores do que jamais pudemos imaginar, mesmo o código sendo gastador de recursos e ineficiente. Códigos ineficientes necessitam de grandes ciclos de CPU para serem consumidos, o que consome mais energia.” (FRANCIS e RICHARDSON, p. 11, 2009).


Quanto mais o “processador estiver carregado, maior será o consumo de energia” (FRANCIS e RICHARDSON, p. 11, 2009), send assim a eficiência energética pode ser obtida através da seguinte equação:


eficiência = throughput / watt


Quando maior a quantidade de dados processados em um determinado tempo e menor o consumo de energia, maior será a eficiência energética do servidor.



Decisões e procedimentos

Otimizar sistemas em produção, sempre trazem grandes problemas e insatisfações dos clientes com relação a instabilidades no aplicativo. Visando minimizar estes problemas foram tomadas decisões que impactassem o mínimo possível no projeto, porém estas alterações deveriam gerar ganhos perceptíveis de performance, principalmente por parte dos clientes.

Com os princípios propostos, em um primeiro momento, foi realizado um mapeamento dos dados para que fossem realizadas otimizações nas bases de dados, primeiramente com a redução da quantidade de dados armazenada. É muito comum que sejam construídas tabelas com campos do tipo “int” onde poderia haver um dado do tipo “smallint”, ou dados do tipo “smallint” onde poderia haver um dado do tipo “tinyint”. Também é comum serem utilizados campos do tipo “varchar(n)” onde poderia existir um campo com valor numérico (numeric, int, smallint, tinyint), abro um parêntese para a conversão de campos “varchar” para um correspondente numérico, pois nestes casos é necessário uma análise precisa do código para evitar sérios problemas na aplicação. A otimização dos tipos do banco de dados também impactará significativamente na performance do banco de dados, já que chaves/índices/registros menores serão encontrados mais rapidamente e consumirão menos ciclos de CPU, e poderão ser encontrados mais rapidamente.

A otimização do código é um pouco mais complicada e inicialmente foram necessárias pesquisas para analisar o ambiente em que as aplicações era executada e a tecnologia empregada na sua fabricação, antes de iniciarmos as alterações. Uma coisa que, talvez não saibam, é que o Visual Basic 6.0 utiliza uma máquina virtual para a execução do aplicativo, como grande parte das linguagens que utilizam alocação dinâmica de memória, e um grande gargalo destas aplicações são a desalocação de memória (“garbage collector”), e neste caso é sempre bom ler a documentação e seguir as recomendações do fabricante. Um outro ponto a ser analisado é o tamanho total da aplicação, em alguns casos poderão ser construídos componentes “ActiveX” agrupando as funções em comum, para a redução do tamanho total do executável em memória, já que quando ocorrer a necessidade da utilização de certas funções (externas a aplicação), o sistema fará a alocação do objeto na memória e estes recursos poderão ser liberados quando não forem mais necessários.

O manual do MSDN faz as seguintes recomendações para otimização de código, utilizando Visual Basic 6.

  • Evite utilizar variáveis do tipo “variant”.

  • Dê preferência para utilizar variáveis do tipo “integer” e “long”.

  • Coloque os valores das propriedades mais utilizadas em uma variável.

  • Substitua chamada de procedimentos por códigos “inline”.

  • Utilize constantes sempre que possível.

  • Passe argumentos com “ByVal” ao invés de “ByRef”.

  • Utilize argumentos opcionais tipados.

  • Tire vantagens das “collections”.


Como muitos destes itens podem parecer meio vagos, mais informações sobre cada um dos itens listados pode ser obtido diretamente do site do MSDN, no endereço: http://msdn.microsoft.com/en-us/library/aa263511(VS.60).aspx#


Com estas informações em mãos, as otimizações do código foram realizadas utilizando a seguinte regra de prioridade:

  1. Funções genéricas, aquelas utilizadas por grande parte da aplicação.

  2. Módulos e funções mais utilizados pelos usuários.

  3. Módulos críticos, aqueles em que a empresa fica parada caso não funcionem (merecem atenção especial).


Ainda tinhamos algumas dúvidas com relação à alocação de memória, com relação as variáveis, por parte do VB6, neste foram construídos dois protótipos para exemplificar como a aplicação se comportava quanto a alocação de memória. Para isto foram criados dois executáveis, um deles fazia a alocação de um vetor do tipo “Long” com 1 posição e o outro utilizava um vetor com 52256000 posições (definido aleatoriamente), os valores eram apenas alocados na memória, não eram manipulados em nenhum momento, a seguir uma imagem para exemplificar o tamanho das duas aplicações.





Após a confirmação da alocação de memória, passamos a um problema sério, variáveis que eram declaradas no código e em nenhum momento eram utilizadas na aplicação, gerando um desperdício de memória e um consequente aumento no consumo de energia. Este é um processo que demandaria muito tempo para analisar todo o código, neste caso a decisão tomada, foi a construção de um aplicativo para fazer a leitura de toda a aplicação e validar as variáveis que estavam sendo utilizadas e aquelas que não eram utilizadas, como este procedimento é muito perigoso, o aplicativo apenas gerava um log indicando onde as variáveis se encontravam, arquivo e linha, permitindo que o programador a localizasse rapidamente e fizesse a correção (manualmente).

A construção deste aplicativo nos roubou uma madrugada e um dia de trabalho, não ficou otimizado, mas permitiu que realizássemos as correções rapidamente. Isto também possibilitou a descoberta de algumas falhas no código, ainda não reclamadas ou ocorridas nos clientes. Também foram realizadas algumas otimizações no banco de dados, mas não entrarei em mais detalhes, pois fogem ao escopo deste artigo.


Conclusão

Ao final das iterações, pode-se perceber uma melhora significativa na qualidade do aplicativo e na otimização da aplicação, os usuários puderam perceber uma melhora significativa na sua execução, também pudemos perceber que a utilização de boas práticas e uma codificação otimizada sempre podem evitar falhas na aplicação, além de facilitar o entendimento do código pelos membros da equipe, apesar da demostração de otimização em aplicações cliente/servidor, aplicativos que serão executados apenas no servidor merecem uma atenção especial, pois a maior parte, senão todo, o processamento do aplicativo será centralizado nele, o que poderá gerar a necessidade de um consumo extra de energia com a alocação física de mais servidores ou processadores, do que o necessário, caso a aplicação fosse construída preocupando-se com a eficiência energética.


Referências:

FRANCIS, Kevin e RICHARDSON, Peter. Green Maturity Model for Virtualization. Green Computing.

Microsoft Journal, Estados Unidos, n. 18, p. 11, 2009.


MICROSOFT. Visual Basic Concepts. Optimizing Code. Disponível na internet. http://msdn.microsoft.com/en-us/library/aa263511(VS.60).aspx# . 2009.


terça-feira, 24 de fevereiro de 2009

Uma breve consideração sobre "Browsers"

A Web mudou muito desde o seu surgimento, recursos, como os mecanismos javascript, possibilitaram que aplicações web "tomassem ares" de aplicações “desktop”.

Ultimamente tenho visto uma nova leva de browsers surgindo, como novos recursos de segurança, compiladores JIT para código javascript, gerenciamento de tabs, etc.

Achei o novo browser produzido belo Google (Chrome) fantástico, ainda, como todo novo aplicativo, um pouco instável e com falhas, mas implementou recursos muito interessantes e possibilitou novas discussões a respeito dos novos browsers. O que mais me chamou a atenção foi a execução de cada tab como um novo processo, claro que isto implica em um consumo maior de memória, mas evita que problemas em uma tab influenciem no funcionamento de todas as outras, além de permitir uma melhor execução em processadores multinucleares (dual, quad, etc.). Como os aplicativos do google são muito simples e leves cada tab consome pouquíssima memória.


Para o teste acima foi aberto o Firefox 3.0.6 e acessada a página do Terra (www.terra.com.br) , o mesmo foi realizado com o Chrome (utilizando uma única tab). Notem que foram criados três processos para o Chrome e apenas um para o Firefox, porém a soma de todos os processos do Chrome ainda é menor do que a memória total consumida pelo Firefox (Sei do GoogleUpdate, porém ele é executado ao entrar no SO, sendo assim ele gera impacto na execução de ambos os browsers, logo será desconsiderado).

Chome (KB)

Firefox (KB)

~88.848

~89.448

Mas eis a pergunta que não quer calar, porque a execução de três processos para uma única tab?! O Chrome utiliza um processo para gerenciar as tabs, outro processo é a própria tab com o processador de Javascript, CSS, HTML, etc. e o outro é responsável pela execução do plugin do Flash (que é utilizado na página do Terra para mostrar as propagandas). Em processadores multinucleares a eficiência do Chrome seria muito maior do que a do Firefox, já que os processos poderiam ser executados em núcleos distintos, diferente do Firefox que sobrecarregaria um único núcleo, podendo levar mais ciclos de CPU para realizar a mesma tarefa do Chrome.

A Microsoft soltou um documento com o conceito de OS Browsers (princípios de um S.O. para a construção de Web Browsers) a publicação prevê a construção do Gazelle Web Browser, que possui, como características básicas, um Browser Kernel que utiliza IPC para a comunicação entre as tab (outros processos), sendo que esta comunicação deve, obrigatoriamente, passar pelo Kernel Browser, permitindo a centralização da segurança em um único local, e somente o Kernel Browser teria acesso as funções nativas do sistema operacional. O documento aborda, principalmente, questões de segurança no desenvolvimento do Browser e faz considerações muito interessantes. O modelo de segurança utilizado pelo Gazelle, prevê a unificação do tratamento SOP (same origin policy, ) para todos os recursos do browser. Os processos são protegidos uns dos outros separando os recursos dentro de “hardware-isolated protection domain”. Qualquer compartilhamento entre os processos deverá ser explicitado utilizando o IPC, sempre mediado pelo Kernel Browser. (Não entrarei em muitos detalhes, devido a extensão do documento, mas quem tiver curiosidade, recomendo a leitura.)

Pode ser que este seja apenas um documento acadêmico que aponta um “punhado” de coisas que nunca serão implementadas, mas considero pertinentes as considerações, claro que segurança e performance são inversamente proporcionais, talvez o consumo de CPU seja absurdo, talvez uma implementação para mais alguns anos a frente, talvez um sistema operacional enxuto com um tremendo Browser que executará todos os nossos aplicativos online (nas nuvens).

O pessoal do Mozilla Labs tem uma série de conceitos e discussões sobre um novo Browser que indicam este tipo de direção para os aplicativos, com alto nível de interatividade, compartilhamento de informações, comunicação, organização e agrupamento de informações acessadas, compartilhamento de históricos entre os usuários (os vídeos da série dão uma boa noção sobre as idéias do pessoal, recomendo que assistam).

Com isto pode-se perceber que as aplicações Web vieram para ficar e a cada dia tomam proporções nunca antes imaginadas. Uma tremenda fonte para inovações.


domingo, 25 de janeiro de 2009

Querido diário...

Belo Horizonte, 2020...

A tecnologia avançou e aquele monte de "parafernalha" dos filmes de Hollywood se tornaram realidade, ainda não existem carros voadores, na verdade eles até tentaram, mas estava dando muita confusão e como o espaço aéreo já andava meio confuso resolveram engavetar o projeto.
Nas próximas férias pretendo comprar uma passagem para a Lua, é a sensação do momento, um amigo meu foi até lá e disse que é muito divertido, e os habitantes são bem legais. Você se lembra quando eles começaram a escavar por lá (na Lua)?! Encontraram um monte de formigas gigantes e inteligentes debaixo da terra. Eles já vinham nos visitar, um dia eles erraram a rota e caíram em Varginha, saiu até no noticiário. - Viu! Os habitantes da Lua também erram, e diziam que errar é humano. Humpf!
Também ocorreram algumas revoluções, nunca me esquecerei daquele 15 de fevereiro de 2015, onde a tecnologia passou a trabalhar como nossa aliada e deixamos de ser escravos dela, voltamos a nossa convivência em sociedade, tudo era festa, a todo o momento reuníamos os amigos em casa para uma boa conversa e um bom bate-papo, isto refletiu até mesmo na arquitetura, as casas de hoje são grandes e as salas espaçosas, fica melhor para reunir o pessoal, dançar, beber, contar piadas, registrar momentos. Qualquer boa notícia é motivo para comemoração e tudo isto foi uma maravilha, as pessoas estavam tão felizes com as suas vidas que a satisfação com o trabalho e o bem estar alheio permitiu a nossa rápida evolução.
Me lembro da assinatura do tratado de livre acesso Minas-Lua que dava a todo extraterrestre da Lua livre acesso ao território mineiro, a primeira vez que topei com um me assustei um pouco, mas hoje tenho grandes amigos por lá também. Ainda não tive a oportunidade de conhecer, só estou esperando sair as minhas férias para embarcar, enquanto isto fico por aqui com a cabeça no mundo da Lua.