[Rio-pm] Fwd: [SP-pm] Perturbado...

Bruno Buss bruno.buss em gmail.com
Domingo Novembro 25 02:13:49 PST 2007


exit() é uma função do stdlib.h =]

Se quiser programar em C... passe seu codigo pelo gcc com o modificador
'pedantic'... omfg, que coisa chata (mas fui obrigado a usar isso... :P),
ele reclama até dos comentários // que são comentários de C++... enquanto
comentário em C é /* */.
Alem disso... o gcc tem uns 2058 padrões de C ¬¬' ANSI C, ISO C98, ISO C99,
CISSO, CAQUILO.... da para definir tmb... -x=padrao eu acho...

Sobre o void main, int main.... como o breno disse, é recomendável fazer
sempre retornar um número... muitas coisas em unix-like são verificadas
pelos números (código) de retorno do seu programa, para saber se foi tudo ok
ou se não qual foi o erro. Colocando void main(), lixo tende a ser
retornado... logo é boa pratica por int main() e sempre garantir que você
retorne alguma coisa via return ou exit().

On Nov 25, 2007 1:29 AM, breno <breno em rio.pm.org> wrote:

> hehehehehehhehehe acho que se enganou =P
>
> Até onde me lembro o padrão C ANSI não possui a palavra reservada
> "exit", e sim "return". E até onde sei não há qualquer restrição sobre
> qual o tipo de retorno de seu programa (caracterizado pelo tipo da
> função main()), mas é considerado uma boa prática ele retornar um
> valor inteiro indicando sucesso ou falha (e, no caso do último, se
> possível um código de falha comum ao sistema operacional). E o g++


> pode compilar código C. Aliás, apesar de todos os meus argumentos vc
> pode sempre dar exatamente essa cartada, que é a de que o C é um
> subgrupo do C++ (não, isso ficou muito feio, assim K&R vão me caçar
> até a morte... melhor dizer que o C++ engloba o C e adiciona um monte
> de gambiarras extras), entao qq código C é de fato um código C++. Mas
> isso é programação C++ com sotaque de C, não é C++ "de verdade" :-)
>
> Voltando ao que interessa, sobre o seu "Range iterator outside integer
> range", olha lá, pode ser a sua resposta para a lentidão! Seu perl
> pode ter sido compilado com inteiros pequenos, então após um certo
> número ele tenta se virar com pontos flutuantes (2.14e30, etc) e/ou
> outros recursos mágicos, ou mesmo travar (o q seria um bug digno de
> alerta). Tente algo como:
>
>      perl -e    ' $a = sprintf "%u", ~0; print $a . $/ '
>
> para ver o limite de inteiros sem sinal no perl em seu sistema. Aqui
> deu 4294967295, que é o dobro do valor buscado (e consequentemente o
> maior inteiro com sinal).
>
> "perldoc perlnumber" pode te dar mais informações caso também esteja
> com insônia ;-)
>
> []s
>
> -b
>
>
> ---------- Forwarded message ----------
> From: Blabos de Blebe <blabos em gmail.com>
> Date: Nov 25, 2007 1:38 AM
> Subject: Re: [SP-pm] Perturbado...
> To: saopaulo-pm em mail.pm.org
>
>
> P.S.2: o int de int main, o return 0 e o fato de eu ter usado o g++,
> no meu ponto de vista torna isso c++. Em C, acho que seria
> void main(int argc, char** argv ){ alguma coisa; exit(0); } + gcc.
>
> Me corrija se me enganei.
>
> Mas este comentário é inútil também, e só a título de curiosidade mesmo.
> Na verdade nesse contexto não acho que faça muita diferença.
>
> E buááá, eu fui testar com foreach e deu "Range iterator outside integer
> range"
> Ah, deixa pra lá.....
>
>
> Valeu Breno pela sua atenção :)
>
>
>
>
> On Nov 25, 2007 1:28 AM, Blabos de Blebe <blabos em gmail.com> wrote:
> > Estou aliviado, deve ser loucura da minha máquina.
> > Eu esperava resultado semelhantes aos seus mesmo.
> >
> > De qualquer forma eu tava sem o que fazer mesmo e sei que
> > isso não vale pra medir nada. Só fiquei espantado com o
> > resultado bizarro da minha máquina, e por isso resolvi consultar
> > a lista.
> >
> > Obrigado
> >
> > P.S.: O programa é inútil assumido....... :)
> >
> >
> > On Nov 25, 2007 1:03 AM, breno <breno em rio.pm.org> wrote:
> > > Hmmm... aqui eu tive resultados diferentes para C (note, seu código é
> > > em C e não em C++) e Perl. Aproveitei então para testar algumas
> > > variações em ambos:
> > >
> > > -----------------8<----------------
> > > $ time ./loop.c.bin [usando for(), código igual ao seu]
> > >
> > > real    0m10.651s
> > > user    0m9.545s
> > > sys     0m0.104s
> > >
> > > [usando while(i++<2147483647); teve resultado na mesma ordem de
> grandeza]
> > >
> > > *******************************************
> > > $ time ./loop.pl [usando while(), código igual ao seu]
> > >
> > > real    0m51.960s
> > > user    0m47.555s
> > > sys     0m0.272s
> > >
> > > [for ($i=0;$i<2147483647; $i++) {} teve resultado na mesma ordem de
> grandeza]
> > >
> > > *******************************************
> > > $ time ./loop.2.pl [usando foreach (0..2147483647) {}]
> > >
> > > real    0m33.862s
> > > user    0m29.034s
> > > sys     0m0.176s
> > >
> > > [for (0..2147483647) {} teve resultado na mesma ordem de grandeza]
> > > -----------------8<----------------
> > >
> > > A evidente vantagem do código em C cai para aproximadamente 20
> > > segundos (ou 40, no pior caso). Sinceramente não sei o que pode ter
> > > acontecido em sua máquina, realmente é estranho e não faz o menor
> > > sentido. No caso geral (que imagino ser mais próximo dos meus
> > > resultados, ou será que o errado sou eu?!), o que acontece ao meu ver
> > > é que esse programa é extremamente inútil e Perl foi feito para
> > > programas úteis, e o overhead que vemos está relacionado às diferentes
> > > tarefas que o perl está fazendo por debaixo dos panos, como
> > > atribuições à variáveis de contexto e otimizações para facilitar a sua
> > > vida e que vc simplesmente não está aproveitando pq tudo o q o seu
> > > programa faz é incrementar um inteiro até o maior valor suportado por
> > > uma máquina com 32 bits.
> > >
> > > Esse tipo de overhead é o preço que vc paga por usar uma linguagem "Do
> > > What I Mean" (Perl) em vez de uma linguagem "Do As I Say" (C/C++), e
> > > francamente acho que saimos dessa troca com um baita lucro. O problema
> > > é que programas-placebo como esse sempre vão ser quase sempre mais
> > > rápidos em linguagens DAIS, pq o Perl (que é DWIM) vai perder tempo
> > > tentando entender o que diabos vc quer com isso :-P
> > >
> > > []s
> > >
> > > -b
> > >
> > >
> > >
> > > On Nov 24, 2007 9:38 PM, Blabos de Blebe <blabos em gmail.com> wrote:
> > > > Boa noite,
> > > >
> > > > Tava sem nada pra fazer, então fiquei alternando entre "O Livro" e
> um
> > > > livro de assembly x86.
> > > > Aí bateu aquela curiosidade mórbida de fazer algo tosco...
> > > >
> > > > resolvi fazer em assembly, Perl e C++ um programa idiota que
> entrasse
> > > > num loop grande,
> > > > e medir quem era mais rápido com o programa time, no linux.
> > > >
> > > > Eis os códigos fontes:
> > > >
> > > > Em Assembly
> > > > <code>
> > > > #PURPOSE: This program count from 0 to a big number
> > > > # only to make a benchmark
> > > >
> > > > #VARIABLES: the registers have the following uses
> > > > # %edi - Count variable.
> > > > # %ebx - The maximum number of iterations.
> > > >
> > > > .section .data
> > > >
> > > > max_numb:
> > > >     .long 2147483647
> > > >
> > > > .section .text
> > > >
> > > > .globl _start
> > > > _start:
> > > >
> > > > movl $0, %edi
> > > > movl max_numb , %ebx
> > > >
> > > > init_loop:
> > > >     incl %edi
> > > >     cmpl %edi, %ebx
> > > > jg init_loop
> > > >
> > > >
> > > >
> > > >
> > > > movl $0, %ebx
> > > > movl $1, %eax
> > > > int $0x80
> > > >
> > > > </code>
> > > >
> > > >
> > > > Em C++
> > > > <code>
> > > > int main( int argc , char** argv )
> > > > {
> > > >     for( long i = 0 ; i < 2147483647 ; i++ );;
> > > >     return 0;
> > > > }
> > > >
> > > > </code>
> > > >
> > > >
> > > > Em Perl
> > > > <code>
> > > > #!/usr/bin/perl
> > > >
> > > > my $i = 0;
> > > > while($i++ < 2147483647){}
> > > >
> > > > </code>
> > > >
> > > > Eu esperava que o programa em assembly fosse terminar primero que os
> > > > outros, e que
> > > > o loop em Perl fosse brigar com o C++ pelo segundo lugar, pois meus
> > > > testes tocos,
> > > > com outros códigos vinham caminhando nesse sentido. Por várias
> vezes,
> > > > Perl foi mais
> > > > rápida que C++, e em outras, um pouco mais lenta.
> > > >
> > > > Para minha surpresa não foi o que aconteceu. Eu repeti isso umas 3
> > > > vezes e o resultado
> > > > foi semelhante. Segue a saída do time:
> > > >
> > > > <code>
> > > > user em machine:~/docs/asm/code/cap-03$ time ./loop.pl
> > > >
> > > > real    9m21.105s
> > > > user    7m49.761s
> > > > sys     0m2.888s
> > > > user em machine:~/docs/asm/code/cap-03$ time ./loopc
> > > >
> > > > real    0m4.180s
> > > > user    0m3.984s
> > > > sys     0m0.040s
> > > > user em machine:~/docs/asm/code/cap-03$ time ./loop
> > > >
> > > > real    0m1.551s
> > > > user    0m1.484s
> > > > sys     0m0.004s
> > > > user em machine:~/docs/asm/code/cap-03$
> > > > </code>
> > > >
> > > > Putz, enquanto os programas em C++ e Assembly demoraram poucos
> segundos,
> > > > o programa em perl demorou quase 10 MINUTOS!!!!
> > > > Naturalmente cheguei a conclusão que fiz alguma cagada, ignorando
> algo
> > > > importante
> > > > que deve estar na documentação (a qual estou ainda lendo), mas não
> > > > descobri o que.
> > > > Estou levemente desconfiado que é algo bobo que eu deixei escapar,
> mas o que?
> > > >
> > > > Não to querendo levantar nenhuma questão sobre performance ou
> comparação de
> > > > linguagens, só achei curioso códigos tão parecidos executarem em
> tempos tão
> > > > diferentes, embora também, uma coisa não tenha nada a ver com a
> outra.
> > > >
> > > > Gostaria de saber a opinião de vcs a respeito
> > > >
> > > > Obrigado
> > > > _______________________________________________
> > > > SaoPaulo-pm mailing list
> > > > SaoPaulo-pm em pm.org
> > > > http://mail.pm.org/mailman/listinfo/saopaulo-pm
> > > >
> > > _______________________________________________
> > > SaoPaulo-pm mailing list
> > > SaoPaulo-pm em pm.org
> > > http://mail.pm.org/mailman/listinfo/saopaulo-pm
> > >
> >
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>



-- 
Bruno C. Buss

DCC - UFRJ - www.dcc.ufrj.br
Membro do GRIS - UFRJ - www.gris.dcc.ufrj.br
Analista de Segurança - Clavis Segurança da Informação - www.clavis.com.br

"The universe doesn't care what you believe. The wonderful thing about
science is that it doesn't ask for your faith, it just asks for your eyes."
— xkcd.com

"There is a ton of evidence both in computing and outside of it which shows
that poor security can be very much worse than no security at all. In
particular stuff which makes users think they are secure but is worthless is
very dangerous indeed." — Alan Cox

"You know, you really are supposed to understand the code you are
modifying..." — Al Viro
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/rio-pm/attachments/20071125/dd817edb/attachment-0001.html 


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