From leonardo em ruoso.com Fri Jan 2 06:14:24 2015 From: leonardo em ruoso.com (Leonardo Ruoso) Date: Fri, 2 Jan 2015 12:14:24 -0200 Subject: [Cascavel-pm] Perl para sistemas embarcados In-Reply-To: <548B236D.1010005@felipeoliva.eti.br> References: <548AFD60.1060402@felipeoliva.eti.br> <548B236D.1010005@felipeoliva.eti.br> Message-ID: Algo importante de avaliar é o quanto seu footprint vai aumentar com Perl. Eu trabalho com sistemas embarcados que já incluem o interpretador Perl e alguns módulos na própria imagem básica de distribuição e daí não tenho problema em adicionar apenas alguns módulos adicionais. Se seu sistema é baseado em x86_64 já estamos nos 1% de que o Blabos falou, ou seja, já não estamos num microcontrolador e Perl vai ser provavelmente ok, assim como Python provavelmente seria ok também. Se a imagem padrão do teu software é baseada em Debian, saiba que o próprio Debian não funcionaria sem um bom conjunto de módulos Perl instalados. Seus aplicativos, pelo que entendi, vão ser de linha de comando e vão rodar através do cron, correto? No Debian você provavelmente vai encontrar exemplos bastante próximos do que você vai fazer para modificar, extender ou se inspirar, tente usá-los como referência. Em 12 de dezembro de 2014 15:18, Felipe N. Oliva escreveu: > > On 12/12/2014 14:13, Blabos de Blebe wrote: > > Opa, > > O que eu teria a dizer o breno já disse, mas reforçando, tudo depende do > que você tem disponível e do que/quanto está disposto a pagar por isso. > > Em termos de embarcados*, linguagem como Perl, Python, etc não são > indicadas, justamente por ocuparem mais memória e terem uma performance um > pouco menor em geral. > > Ter menos performance aqui significa gastar mais tempo e energia pra > realizar operações equivalentes. Dependendo da aplicação, tempo pode não > ser um problema, mas o consumo extra de bateria sim. > > Normalmente, linguagens de mais alto nível pagam esses recursos em troca > do recurso "tempo do programador", ou seja, possibilitam que o > desenvolvedor crie código num nível muito mais alto de abstração num > ambiente onde ele tem tempo, memória e energia em grande escala. > > Note porém que dependendo de alguns detalhes, como o domínio da > aplicação, se usa XS ou não, etc, pode ser que a aplicação em Perl nem > fique com menos performance, se o gargalo ficar por exemplo na taxa de > transmissão do seu rádio. > > A questão sempre é sobre o que você é obrigado a abrir mão versus o que > você pode ou não abrir mão. > > Para 99% dos casos, Perl não vai ser indicado para embarcados. Se você > estiver trabalhando nos outros 1%, dê mais detalhes, que vai ser > extremamente interessante ajudar. > > *** > > Antigamente tinha isso aqui: > > http://www.foo.be/docs/tpj/issues/vol5_3/tpj0503-0003.html > > Mas creio que foi descontinuado nas versões recentes de Perl. A > referência me fugiu à memória, mas acredito ter lido que foi descontinuado > em algum release note recente. > > *** > > Também existe isso aqui: > > https://metacpan.org/pod/distribution/B-C/perlcompile.pod > > *** > > *: O conceito de embarcados hoje é meio difuso mas normalmente contamos > situações onde os recursos são tão limitados que não há nem sistema > operacional rodando, quanto mais uma linguagem dinâmica disponível. > > []'s > > 2014-12-12 13:53 GMT-02:00 breno : >> >> Oi Felipe, >> >> Parabéns pela primeira mensagem! Tomara que seja a primeira de muitas >> (e não deixe de entrar nos outros grupos também, como Brasil-PM ou as >> regionais de sua escolha - a menos que vc seja de Cascavel, claro :D) >> >> Sobre a sua pergunta, depende de um monte de fatores. Perl, assim como >> todas as linguagens dinâmicas, é feito para poupar seu tempo e preocupação >> em relação a alocação de memória, interrupções, rotinas, etc. Naturalmente, >> isso vem com um preço, em velocidade e em tamanho - tanto em disco quanto >> em memória. >> >> Para mim, se você não está disposto a pagar esse preço, a primeira >> pergunta que você tem que fazer é: Perl é a melhor linguagem para esse >> problema? Ou melhor: linguagens dinâmicas são o melhor tipo de linguagem >> para esse problema? Se a resposta for "não", escreva seu código em C, Lua >> ou mesmo Assembly, e vc certamente conseguirá chegar a um binário muito >> menor. Obviamente, nesse caso o preço a pagar é o tempo de desenvolvimento >> e o cuidado necessário com alocação de espaço, tratamento de erros, >> manipulação de variáveis, etc. >> >> Você diz que o programa em Perl (e o perl em si) ocupam muito espaço >> para uma app embarcada. De quanto estamos falando? Quanto seria bom o >> suficiente? De repente rola de chegar a esse número. De repente não. >> >> Dito isso, se vc realmente quer diminuir o espaço ocupado em disco, há >> algumas coisas que você pode tentar: >> >> * http://perldoc.perl.org/perlembed.html - aqui vc encontra dicas para >> rodar código Perl a partir de um programa em C. Como a compilação inclui só >> as libs necessárias, de repente o resultado fica menor para a app >> embarcada. Obviamente, o resultado pode ser oposto, mas aí vc vai ter que >> testar; >> >> * Você não precisa de documentação para executar código, então pode >> "minificar" os arquivos .pm e .pl na hora de embarcar o código. O espaço em >> memória será o mesmo, mas em disco, será menor; >> >> * Analogamente, se vc tem certeza do que será utilizado e de todas as >> possíveis ramificações do seu código, pode arrancar fora subs que com >> certeza nunca serão chamadas. Eu só faria isso em último caso, e com >> cobertura de 100% em testes de ramificação; >> >> * Você pode também analizar a sua árvore de dependência e ajustá-la >> para usar versões alternativas e menores de determinados módulos. Por >> exemplo, usar código XS em vez de PP, módulos ::Tiny em vez da versão >> completa, Moo em vez de Moose. Em alguns casos você consegue até fazer um >> overhaul no módulo e diminuir as dependências na mão (por exemplo, criar as >> classes diretamente e na mão em vez de usar um framework. >> >> * Existem alternativas que "zipam" o código e descompactam em memória na >> hora de executar. Acho que o PAR faz isso, mas não uso há tanto tempo que >> não sei te dizer; >> >> * Algumas ferramentas como o "strip" ( >> https://en.wikipedia.org/wiki/Strip_%28Unix%29) podem reduzir o tamanho >> do binário final arrancando trechos não utilizados; >> >> * você pode tentar compilar o perl manualmente usando compiladores >> diferentes (por exemplo, clang ou gcc) e flags de compilação diferentes, >> comparar o resultado final e escolher o que ficou menor. As vezes os >> resultados são bem significativos. Aproveite pra ler o script de >> configuração do fonte do perl para desativar coisas que sabe que não vai >> utilizar e que vem ativas por padrão, a diferença no tamanho do binário e >> libs associadas pode ser significativa para o seu problema. >> >> Só não esqueça que cada sugestão acima vem com um preço. Algumas vão >> exigir mais CPU. Outras, mais memória. Outras, mais trabalho na hora de >> fazer deploys. Outras tornam atualizações de módulos externos bem mais >> difíceis. Outras exigem muito mais lógica na hora de estruturar seu >> programa. Outras... acho que vc entendeu :) >> >> Enfim, é isso. Boa sorte! :) >> >> []s >> >> -b >> >> >> 2014-12-12 12:36 GMT-02:00 Felipe N. Oliva : >> >>> Olá senhores, >>> >>> >>> Esta é minha primeira postagem aqui na lista, e peço a paciência de >>> todos em caso de falar alguma bobagem. >>> >>> Estou em meio a um projeto de sistema embarcado onde meu foco é deixar o >>> sistema o menor possível. Meu problema é que o Perl ocupa um espaço >>> relativamente alto (para uma aplicação embarcada). >>> >>> Alguém poderia me dar uma dica de como reduzir o seu tamanho e do Perl >>> em si e seus módulos? >>> >>> Att, >>> Felipe N. Oliva >>> _______________________________________________ >>> Cascavel-pm mailing list >>> Cascavel-pm em pm.org >>> http://mail.pm.org/mailman/listinfo/cascavel-pm >>> >> >> >> _______________________________________________ >> Cascavel-pm mailing list >> Cascavel-pm em pm.org >> http://mail.pm.org/mailman/listinfo/cascavel-pm >> > > > _______________________________________________ > Cascavel-pm mailing listCascavel-pm em pm.orghttp://mail.pm.org/mailman/listinfo/cascavel-pm > > Obrigado pelos retornos. > > Não sou um expert em Perl. Cheguei até o Perl pela facilidade, > documentação e os vários módulos. > > O papel do Perl no meu sistema é automação de processos, como: backup, > checagens e etc; > > A questão do espaço que tenho esbarrado são os modulos, libs, etc... não o > aplicativo em si, exemplo backup.pl > > Se eu estiver viajando podem falar, mas meu mundo perfeito é um deixar o > aplicativo compilado somente com suas dependências. > > Ainda acredito que consigo usa-lo, só me falta conseguir otimizar essa > questão do espaço. > > Talvez também vou utiliza-lo para Interface WEB e Sockets, mas isso ainda > é um "talvez". > > Att, > Felipe N. Oliva > > _______________________________________________ > Cascavel-pm mailing list > Cascavel-pm em pm.org > http://mail.pm.org/mailman/listinfo/cascavel-pm > -- Leonardo Ruoso Journalist, Perl developer and business consultant Media, UFC/2006; Telecom, IFCE/1998 -------------- Próxima Parte ---------- Um anexo em HTML foi limpo... URL: