[Cascavel-pm] Perl para sistemas embarcados
Felipe N. Oliva
felipe em felipeoliva.eti.br
Sexta Dezembro 12 09:18:37 PST 2014
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 <breno em rio.pm.org
> <mailto:breno em rio.pm.org>>:
>
> 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
> <felipe em felipeoliva.eti.br <mailto:felipe em felipeoliva.eti.br>>:
>
> 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 <mailto:Cascavel-pm em pm.org>
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
>
>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org <mailto: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
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
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20141212/65e18cf6/attachment-0001.html>
Mais detalhes sobre a lista de discussão Cascavel-pm