[Rio-pm] Fwd: [SP-pm] Perturbado...
Blabos de Blebe
blabos em gmail.com
Domingo Novembro 25 02:43:03 PST 2007
Breno, quanto a C/C++, vc tem razão mesmo, e desculpe por tocar em C
numa lista de perl, mas pelo nível das respostas só mostra que por aqui
o pessoal conhece bastante de muita coisa :)
Só lembrando, meu post não tem pretensão de ser útil, só curioso.
Agora vai o mais esquisito ainda:
perl -e ' $a = sprintf "%u", ~0; print $a . $/ '
retorna 4294967295 na minha máquina......
?????????????????????????????????????????????
P.S.: Ah, vcs dois ainda tão devendo aquela palhinha depois da
palestra como prometido...
On Nov 25, 2007 8:13 AM, Bruno Buss <bruno.buss em gmail.com> wrote:
> 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
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
Mais detalhes sobre a lista de discussão Rio-pm