[Rio-pm] Res: Perl melhor que C para OpenGL (?!)

Ricardo Filipo ricardo_filipo em yahoo.com.br
Terça Abril 17 14:36:35 PDT 2007


Oi, Marco.
A coisa pode estar criando imagens em tempo real, como gráficos, ícones ou vídeos, para apresentação na web. :)

----- Mensagem original ----
De: Marco A P D'Andrade <mdacwb em gmail.com>
Para: Perl Mongers Rio de Janeiro <rio-pm em pm.org>
Enviadas: Terça-feira, 17 de Abril de 2007 18:15:11
Assunto: Re: [Rio-pm] Perl melhor que C para OpenGL (?!)

Breno,

Achei muito interessante suas informações, mas fiquei confuso com uma coisa ...

Você entendeu a vantagem de usar OpenGL com mod_perl ?? Me parece um
tanto contrastante ...

Sds,
Marco Antonio

Em 16/04/07, breno<breno em rio.pm.org> escreveu:
>
>
> Desenvolvedores de soluções Desktop costumam partir do princípio que
> linguagens compiladas funcionam sempre mais rápido que as interpretadas
> (como Perl).Ainda que muitos desenvolvedores de serviços online já estejam
> acostumados com mecanismos que carregam interpretadores como mod_perl e
> ISAPI e cujo desempenho se aproxima bastante daquelas em C/C++, são poucos
> os desenvolvedores 3D que pensam em Perl quando o objetivo é performance.
> Bom, eles deveriam!
>
> GPUs (Graphics Processing Units) são microprocessadores especializados em
> processamento de gráficos disponíveis em todas as placas de vídeo modernas,
> e estão a cada dia tirando a carga das CPUs para o tratamento de números. O
> processamento moderno de GPGPU (General Purpose GPUs) se aproxima de
> programas em C e carrega grandes vetores de dados dentro da GPU, onde o
> processamento acontece independentemente da CPU. Como resultado, a
> contribuição de programas atados à CPU diminui, e a diferença entre Perl e C
> se tornam insignificantes em termo de performance GPU.
>
> A mais nova versão do módulo POGL (Perl OpenGL), disponível em
> http://graphcomp.com/opengl/ e diretamente via CPAN, adicionou suporte ao
> GPGPU. O autor colocou ainda uma série de benchmarks entre C e Perl,
> demonstrando não haver qualquer diferença estatística de performance entre
> implementações em C e em Perl, e apresentando inclusive casos em que a
> performance em Perl é melhor do que em C para operações OpenGL!
>
> De um modo geral, C foi melhor que Perl em operações Vertex/Fragment Shader,
> enquanto Perl foi melhor em operações de Objetos Frame Buffer. Essa
> similaridade é explicada por diversos fatores, dentre eles a alta quantidade
> de operações realizadas pela GPU; o fato do POGL ser um módulo C compilado;
> e que operações não-GPU são mínimas. Ainda assim, esse é de fato o ambiente
> típico de operações de processamento e renderização de imagens. E é aí que
> entram as vantagens do Perl, seja na portabilidade, facilidade e agilidade
> de desenvolvimento, diversos módulos de imagens para carregar texturas em
> vetores de dados GPGPU, ser essencialmente mais rápido do que Java (em
> especial sob mod_perl/ISAPI), ou pelo simples fato de não haver suporte a
> FBO (Frame Buffer Objects) em Java, Python ou Ruby até a data de hoje. E os
> resultados mais favoráveis ao Perl foram obtidos onde? No Windows Vista!
>
> Com Perl, desenvolvedores OpenGL/GPU de Desktops podem prototipar seus
> códigos rapidamente em Perl e depois portar (caso necessário) para C/C++
> mais tarde. É fácil perceber também as vantagens em escrever o código em uma
> janela e executar na outra sem qualquer IDE ou compilação, permitindo
> experimentações em tempo real com novos algoritmos, modelos e efeitos
> especiais.
>
> --
> Notícia adaptada, original por Shlomi Fish, Bob Free, Mike Friedman e Brian
> D Foy em www.perl.com
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
_______________________________________________
Rio-pm mailing list
Rio-pm em pm.org
http://mail.pm.org/mailman/listinfo/rio-pm






__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/rio-pm/attachments/20070417/92b8a7ec/attachment.html 


Mais detalhes sobre a lista de discussão Rio-pm