[Cascavel-pm] Perl para sistemas embarcados

Sexta Janeiro 2 06:14:24 PST 2015

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 <felipe em felipeoliva.eti.br>
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 <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>:
>>
>>> 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: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20150102/00eb83c9/attachment-0001.html>