Estou estudando para fazer um jogo de xadrez com engine (uma pessoa joga contra o computador) e tenho vontade de fazer o jogo inteiro em Python. Como sou novo na linguagem (estou terminando de ler o tutorial do site oficial) tenho receio que a aplicação possa ter problemas de performance, pois os algoritmos que fazem o computador jogar são bastante "pesados". Gostaria de saber a opinião de programadores experientes em Python a respeito desse assunto.
> Estou estudando para fazer um jogo de xadrez com engine (uma pessoa > joga contra o computador) e tenho vontade de fazer o jogo inteiro em > Python. Como sou novo na linguagem (estou terminando de ler o tutorial > do site oficial) tenho receio que a aplicação possa ter problemas de > performance, pois os algoritmos que fazem o computador jogar são > bastante "pesados".
Bom, qual o seu hardware ? DeepBlue ? ;o) Hehehe de fato Python (por enquanto) tem um desempenho em tempo de execução inferior a código nativo. Em compensação o tempo de desenvolvimento em Python é *muito* mais curto e o processo *muito* mais agradável.
> Gostaria de saber a opinião de programadores > experientes em Python a respeito desse assunto.
Eu começaria a escrever em Python e se no futuro vc precisar melhorar o desempenho, pode isolar trechos críticos do algoritmo em módulos externos escritos em C ou C++ (cujo interfaceamento com Python é facilitado por ferramentas e uma API especial).
De: python-bra...@yahoogrupos.com.br [mailto:python-bra...@yahoogrupos.com.br] Em nome de Rodrigo Senra Enviada em: sábado, 31 de março de 2007 13:52 Para: python-bra...@yahoogrupos.com.br Assunto: Re: [python-brasil] Engine de xadrez
On 30Mar 2007, at 10:40 PM, rdavid_cwb wrote:
> Olá pessoal
> Estou estudando para fazer um jogo de xadrez com engine (uma pessoa > joga contra o computador) e tenho vontade de fazer o jogo inteiro em > Python. Como sou novo na linguagem (estou terminando de ler o tutorial > do site oficial) tenho receio que a aplicação possa ter problemas de > performance, pois os algoritmos que fazem o computador jogar são > bastante "pesados".
Bom, qual o seu hardware ? DeepBlue ? ;o) Hehehe de fato Python (por enquanto) tem um desempenho em tempo de execução inferior a código nativo. Em compensação o tempo de desenvolvimento em Python é *muito* mais curto e o processo *muito* mais agradável.
> Gostaria de saber a opinião de programadores > experientes em Python a respeito desse assunto.
Eu começaria a escrever em Python e se no futuro vc precisar melhorar o desempenho, pode isolar trechos críticos do algoritmo em módulos externos escritos em C ou C++ (cujo interfaceamento com Python é facilitado por ferramentas e uma API especial).
> Bom, qual o seu hardware ? DeepBlue ? ;o) > Hehehe de fato Python (por enquanto) tem um desempenho em tempo > de execução inferior a código nativo. Em compensação o tempo de > desenvolvimento em Python é *muito* mais curto e o processo *muito* > mais agradável.
> > Gostaria de saber a opinião de programadores > > experientes em Python a respeito desse assunto.
> Eu começaria a escrever em Python e se no futuro vc precisar > melhorar o desempenho, pode isolar trechos críticos do algoritmo > em módulos externos escritos em C ou C++ (cujo interfaceamento > com Python é facilitado por ferramentas e uma API especial).
> Abração, > Senra
> Rodrigo Senra
Senra, deixa eu perguntar uma coisa. Como Python poderia se tornar mais rápido? Só se for escrito em Assmbly, ou sei-lá. Aliás, aproveitando, se Python foi escrito em C, em que foi escrito C?
Ps.: A velocidade de python para mim não é problema pra minhas pequenas aplicações. Sou devoto. "Time is not a problem until is it is a problem".
> Senra, deixa eu perguntar uma coisa. Como Python poderia se tornar > mais rápido?
Essa pergunta eu vou deixar para o pessoal responder.
>Só se for escrito em Assmbly, ou sei-lá. Aliás, > aproveitando, se Python foi escrito em C, em que foi escrito C?
Bom o CPython foi escrito em C, esse é o Python padrão que utilizamos hoje em dia.
Mas temos o PyPy (Python escrito em Python!), o Stackless Python (variação do CPython), o IronPython (.Net).
Uma coisa que já foi dita aqui na lista é que o IronPython em algumas coisas é bem mais rápido que o CPython.
Ai você vai ficar indignado e peguntar como ? porque ? Pelo menos eu fiquei assim. :)
O CPython é feito pensando em ter um código simples de manter e que seja portável para outras arquiteturas e plataformas.
Já o IronPython foi feito para rodar sobre o .Net, e essa plataforma tem "trocentas" coisas feitas pensando em velocidade.
Por isso no geral o CPython tem poucos bugs, roda em Linux, Unix, Mac, e até no Windows. Ah ia me esquencendo roda no Maemo e no Symbian também.
Isso quer dizer que também roda em arm, x86, ppc e sei lá mais o que.
Depois que formei esse raciocínio, fique muito feliz pelo CPython ser "tão lento", mas sempre é estável mesmo sempre tendo muitas novidades. :)
> Ps.: A velocidade de python para mim não é problema pra minhas > pequenas aplicações. Sou devoto. "Time is not a problem until is it is > a problem".
On 31Mar 2007, at 4:36 PM, Eduardo Willians wrote:
> Senra, deixa eu perguntar uma coisa. Como Python poderia se tornar > mais rápido?
Parte da "lerdeza" do Python advém de sua dinamicidade, muita coisa só é definida em tempo de execução:
- onde estão os objetos (escopo local, global, builtin) - que função vai ser executada - quais os tipos dos parâmetros
> Só se for escrito em Assmbly, ou sei-lá.
Não precisaria ser assembly. Linguagens estaticamente tipadas já possuem técnicas consagradas de otimização:
- sabendo onde está a função eu apenas dou um salto para o offset na posição de memória onde está o código a ser executado - da mesma forma, acessar "objetos" muitas vezes significa pegar um região pré-definida de bytes na memória (conhecendo o offset e tamanho) - conhecendo os tipos dos parâmetros é possível alocar registradores ao invés de empilar os parâmetros na pilha etc etc etc
As linguagens de execução rápida estão próximas do modelo da máquina. Ex.: Assembly, C
As linguagens de desenvolvimento rápido estão próximas do modelo mental do desenvolvedor Ex.: Python, Lisp, Prolog
Esse é o yin/yang do design de linguagens de programação. Existe o projeto Psyco que agregou algumas otimizações para programas em Python. Seu criador, Armin Rigo, agora trabalha no projeto Pypy. O Pypy entre outros objetivos visa a criar VMs otimizadas para execução de código Python.
> Aliás, aproveitando, se Python foi escrito em C,
O Pypy é uma VM Python escrita em ... Python ;o)
> em que foi escrito C?
O ovo ou a galinha certo ? Bom o primeiro compilador C foi escrito em uma linguagem certamente diferente de C (provavelmente Assembly ou BCPL). Mas este conceito não devia causar supresa: - hoje o Linux é desenvolvido em máquinas rodando ... Linux - o projeto (fonte) svn é hospedado em um servidor SVN e por aí vai
> On 31Mar 2007, at 4:36 PM, Eduardo Willians wrote:
> > Senra, deixa eu perguntar uma coisa. Como Python poderia se tornar > > mais rápido?
> Parte da "lerdeza" do Python advém de sua dinamicidade, > muita coisa só é definida em tempo de execução:
> - onde estão os objetos (escopo local, global, builtin) > - que função vai ser executada > - quais os tipos dos parâmetros
> > Só se for escrito em Assmbly, ou sei-lá.
> Não precisaria ser assembly. Linguagens estaticamente tipadas > já possuem técnicas consagradas de otimização:
> - sabendo onde está a função eu apenas dou um salto para > o offset na posição de memória onde está o código a ser > executado > - da mesma forma, acessar "objetos" muitas vezes significa > pegar um região pré-definida de bytes na memória (conhecendo > o offset e tamanho) > - conhecendo os tipos dos parâmetros é possível alocar registradores > ao invés de empilar os parâmetros na pilha > etc etc etc
> As linguagens de execução rápida estão próximas do modelo da máquina. > Ex.: Assembly, C
> As linguagens de desenvolvimento rápido estão próximas do modelo > mental do > desenvolvedor > Ex.: Python, Lisp, Prolog
> Esse é o yin/yang do design de linguagens de programação. > Existe o projeto Psyco que agregou algumas otimizações para > programas em Python. Seu criador, Armin Rigo, agora trabalha > no projeto Pypy. O Pypy entre outros objetivos visa a criar > VMs otimizadas para execução de código Python.
> > Aliás, aproveitando, se Python foi escrito em C,
> O Pypy é uma VM Python escrita em ... Python ;o)
> > em que foi escrito C?
> O ovo ou a galinha certo ? Bom o primeiro compilador C foi escrito > em uma linguagem certamente diferente de C (provavelmente Assembly ou > BCPL). > Mas este conceito não devia causar supresa: > - hoje o Linux é desenvolvido em máquinas rodando ... Linux > - o projeto (fonte) svn é hospedado em um servidor SVN > e por aí vai
C não é escrito em nada, pois C é a linguagem. O que é escrito são os compiladores. E existem muitos compiladores C. O GCC, que é um dos mais importantes, por exemplo, é escrito em -- pasme -- C ! :P
Aliás, Assembly é diretamente equivalente à linguagem de máquina ;)
> Pelo que sei C e escrito em assembly com algumas partes em linguagem de > maquina mesmo.
> Rafael Colucci
> Rodrigo Senra wrote:
> > On 31Mar 2007, at 4:36 PM, Eduardo Willians wrote:
> > > Senra, deixa eu perguntar uma coisa. Como Python poderia se tornar > > > mais rápido?
> > Parte da "lerdeza" do Python advém de sua dinamicidade, > > muita coisa só é definida em tempo de execução:
> > - onde estão os objetos (escopo local, global, builtin) > > - que função vai ser executada > > - quais os tipos dos parâmetros
> > > Só se for escrito em Assmbly, ou sei-lá.
> > Não precisaria ser assembly. Linguagens estaticamente tipadas > > já possuem técnicas consagradas de otimização:
> > - sabendo onde está a função eu apenas dou um salto para > > o offset na posição de memória onde está o código a ser > > executado > > - da mesma forma, acessar "objetos" muitas vezes significa > > pegar um região pré-definida de bytes na memória (conhecendo > > o offset e tamanho) > > - conhecendo os tipos dos parâmetros é possível alocar registradores > > ao invés de empilar os parâmetros na pilha > > etc etc etc
> > As linguagens de execução rápida estão próximas do modelo da máquina. > > Ex.: Assembly, C
> > As linguagens de desenvolvimento rápido estão próximas do modelo > > mental do > > desenvolvedor > > Ex.: Python, Lisp, Prolog
> > Esse é o yin/yang do design de linguagens de programação. > > Existe o projeto Psyco que agregou algumas otimizações para > > programas em Python. Seu criador, Armin Rigo, agora trabalha > > no projeto Pypy. O Pypy entre outros objetivos visa a criar > > VMs otimizadas para execução de código Python.
> > > Aliás, aproveitando, se Python foi escrito em C,
> > O Pypy é uma VM Python escrita em ... Python ;o)
> > > em que foi escrito C?
> > O ovo ou a galinha certo ? Bom o primeiro compilador C foi escrito > > em uma linguagem certamente diferente de C (provavelmente Assembly ou > > BCPL). > > Mas este conceito não devia causar supresa: > > - hoje o Linux é desenvolvido em máquinas rodando ... Linux > > - o projeto (fonte) svn é hospedado em um servidor SVN > > e por aí vai
Voltando ao assunto, recomendo dar uma olhada em TDD, ou Test Driven Development, especialmente no blog do Danilo Sato [1], onde ele começa a implementar o jogo Stratego em Python usando o método TDD. Pode ser de alguma ajuda.
> C não é escrito em nada, pois C é a linguagem. O que é escrito são os > compiladores. E existem muitos compiladores C. > O GCC, que é um dos mais importantes, por exemplo, é escrito em -- pasme > -- C ! :P
> Aliás, Assembly é diretamente equivalente à linguagem de máquina ;)
> Em 31/03/07, Rafael Colucci <rafacolu...@gmail.com> escreveu:
> > Pelo que sei C e escrito em assembly com algumas partes em linguagem > > de > > maquina mesmo.
> > Rafael Colucci
> > Rodrigo Senra wrote:
> > > On 31Mar 2007, at 4:36 PM, Eduardo Willians wrote:
> > > > Senra, deixa eu perguntar uma coisa. Como Python poderia se tornar > > > > mais rápido?
> > > Parte da "lerdeza" do Python advém de sua dinamicidade, > > > muita coisa só é definida em tempo de execução:
> > > - onde estão os objetos (escopo local, global, builtin) > > > - que função vai ser executada > > > - quais os tipos dos parâmetros
> > > > Só se for escrito em Assmbly, ou sei-lá.
> > > Não precisaria ser assembly. Linguagens estaticamente tipadas > > > já possuem técnicas consagradas de otimização:
> > > - sabendo onde está a função eu apenas dou um salto para > > > o offset na posição de memória onde está o código a ser > > > executado > > > - da mesma forma, acessar "objetos" muitas vezes significa > > > pegar um região pré-definida de bytes na memória (conhecendo > > > o offset e tamanho) > > > - conhecendo os tipos dos parâmetros é possível alocar registradores > > > ao invés de empilar os parâmetros na pilha > > > etc etc etc
> > > As linguagens de execução rápida estão próximas do modelo da máquina. > > > Ex.: Assembly, C
> > > As linguagens de desenvolvimento rápido estão próximas do modelo > > > mental do > > > desenvolvedor > > > Ex.: Python, Lisp, Prolog
> > > Esse é o yin/yang do design de linguagens de programação. > > > Existe o projeto Psyco que agregou algumas otimizações para > > > programas em Python. Seu criador, Armin Rigo, agora trabalha > > > no projeto Pypy. O Pypy entre outros objetivos visa a criar > > > VMs otimizadas para execução de código Python.
> > > > Aliás, aproveitando, se Python foi escrito em C,
> > > O Pypy é uma VM Python escrita em ... Python ;o)
> > > > em que foi escrito C?
> > > O ovo ou a galinha certo ? Bom o primeiro compilador C foi escrito > > > em uma linguagem certamente diferente de C (provavelmente Assembly ou > > > BCPL). > > > Mas este conceito não devia causar supresa: > > > - hoje o Linux é desenvolvido em máquinas rodando ... Linux > > > - o projeto (fonte) svn é hospedado em um servidor SVN > > > e por aí vai
> Senra, deixa eu perguntar uma coisa. Como Python poderia se tornar > mais rápido? Só se for escrito em Assmbly, ou sei-lá. Aliás, > aproveitando, se Python foi escrito em C, em que foi escrito C?
> Ps.: A velocidade de python para mim não é problema pra minhas > pequenas aplicações. Sou devoto. "Time is not a problem until is it is > a problem".
> Na paz,
> Eduardo Willians
A pergunta foi pro senra, mas eu vou me candidatar a responde-la, de um jeito mais senra possivel :)
Para se ter tempo de execução menor, que é o que normalmente se fala quando o assunto é performance existem 2 caminhos a se seguir. Um é limitando a dinamicidade da linguagem e usar as mesmas abordagens das linguagens estaticamente tipadas como c, c++, haskell que é de se inferir os tipos e fazer uma compilação do código para código de maquina. O outro é fazendo o que o pessoal do projeto pypy (no qual eu me incluo, pelo menos em espirito) que é de se construir um interpretador melhor, tão melhor a ponto de ter um jit dinamico de python por exemplo. Esse jit dinamico significa gerar durante a execução código de maquina que é especializado para o tipo de dado sendo tratado. Isso teoricamente pode acançar uma performance melhor do que compilação estatica em casos onde os tipos mudam durante o programa, mas são razoavelmente estaticos durante um periodo (relativamente mais curto do que a execução do programa todo), assim conseguindo o que a gente chama de "mais rapido do que C".
Agora o outro ponto da tua pergunta é uma confusão entre o que significa performance. Não faz diferença a linguagem em que um "compilador" foi escrito mas sim a qualidade do código que ele gera. O python hoje gera bytecodes que são rodados numa maquina virtual, essa escrita em C, a qual tem baixa performance. Mesmo escrevendo a maquina virtual em assembly não faria muita diferença em termos de performance, o que precisa mudar é mais profundo é a natureza do código gerado, e provavelmente não fazer interpretação em uma vm como é feita hoje. A idéia é tipo a de implementar um bublesort em C ou em assembly, ambos vão ter performances muito parecidas, enquanto um timsort (o algoritmo de sort que o python usa) seria mais rapido que ambos mesmo em python.
Agora sobre o motor de xadrez, eu vou escrever um motor para um jogo de IA que eu recebi de trabalho final de uma cadeira. A minha idéia vai ser tentar escrever ele todo em RPython e usar o pypy pra compilar ele pra código de maquina... A minha idéia é mais pra aprender sobre as limitações do pypy mas pode ser divertido pra ti também é mais uma dica. A outra é usar o psyco, eu lembro de ler sobre uma engine de xadrez q ficava mais de 20 vezes mais rapida usando ele. No ramo de escrever código C/C++ tu pode usar o pyrex, swig, boost.python pra te ajudar ou até fazer uma lib normal e usar o ctypes para fazer chamadas(cuidado pode não ficar tão bom usando o ctypes do que com os outros). Ou ainda faz a engine e espera que o pypy 1.0 já foi lançado e estamos quase lá pra fazer um python mais rapido!
obs: segura essa senra, agora tu virou um adjetivo :)
Rafael, Os dois principais jogos de xadrez em Python são o Pychess e o glChess, os dois são escritos em pygtk e não perdem em nada em performance com relação a outros jogos em outras linguagens e para hardwares popularmente usados. Só o Pychess tem uma engine própria de xadrez que nas versões inferiores a 0.6 tinha problemas de algoritmos lentos, mas a partir da 0.6 está muita rápida.
On 3/31/07, Leonardo Santagada <santag...@gmail.com> wrote: [...]
> Agora sobre o motor de xadrez, eu vou escrever um motor para um jogo de IA > que eu recebi de trabalho final de uma cadeira. A minha idéia vai ser tentar > escrever ele todo em RPython e usar o pypy pra compilar ele pra código de > maquina... A minha idéia é mais pra aprender sobre as limitações do pypy mas
[...]
Aliás, esse é um assunto muito interessante: usar o tradutor do pypy para traduzir um código em RPython para C, por exemplo. Eu fiz o checkout do pypy justamente para tentar fazer isso, mas acho que me perdi dentro de vários sub-projetos que o pypy possui atualmente.
Você sabe se existe algum tutorial voltado para isso especificamente? Ou, se não houver, já que você está envolvido no pypy e pretende fazer exatamente isso para a sua engine do jogo de IA, que tal escrever um pequeno tutorial sobre como fazer isso?
On 31Mar 2007, at 7:57 PM, Leonardo Santagada wrote:
> A pergunta foi pro senra, mas eu vou me candidatar a responde-la,
Hehehe aqui qualquer pergunta é *sempre* para a Galera ;o)
> de um jeito mais senra possivel :) > obs: segura essa senra, agora tu virou um adjetivo :)
s/senra/Senra/ ;oP
> Agora sobre o motor de xadrez, eu vou escrever um motor para um > jogo de IA > que eu recebi de trabalho final de uma cadeira. A minha idéia vai > ser tentar > escrever ele todo em RPython e usar o pypy pra compilar ele pra > código de > maquina
Muuuuuuito maaaaacho!
> No ramo de escrever código C/C++ tu pode usar o pyrex, > swig, boost.python pra te ajudar ou até fazer uma lib normal e usar > o ctypes > para fazer chamadas(cuidado pode não ficar tão bom usando o ctypes > do que > com os outros).
Tirando o ctypes, eu experimentei essas alternativas e ainda assim achei mais simples e gerenciável escrever C-extensions na mão sem "wrapper-generators".
Não é tão complicado quanto parece e dá muito mais segurança para o desenvolvedor quando algo dá errado. O SWIG é simpático quando vc precisa extender em mais de uma linguagem (além do Python), mas este "use case" é mais raro.
> Ou ainda faz a engine e espera que o pypy 1.0 já foi > lançado e estamos quase lá pra fazer um python mais rapido!
Concordo, para quem puder esperar, é o caminho mais transparente e com melhor potencial de bons resultados. Todavia, eu não prenderia a respiração enquanto espero ;o)
> Aliás, esse é um assunto muito interessante: usar o tradutor do pypy > para traduzir um código em RPython para C, por exemplo. Eu fiz o > checkout do pypy justamente para tentar fazer isso, mas acho que me > perdi dentro de vários sub-projetos que o pypy possui atualmente.
> Você sabe se existe algum tutorial voltado para isso especificamente? > Ou, se não houver, já que você está envolvido no pypy e pretende fazer > exatamente isso para a sua engine do jogo de IA, que tal escrever um > pequeno tutorial sobre como fazer isso?
Cara deve ter algo na documentação, mas o jeito mais simple é ir em pypy/translator/goal e ver o targetjsstandalone.py... dificil ser mais fácil que aquilo. ai tu usa o translator.py no mesmo diretorio pra fazer a tradução, e um arquivo como o targetjsstandalone que é o teu programa. tem também o diretório demo, que usa o translator de forma mais programatica. Vou ver se não tem documentação sobre isso e escrevo algo, mas já aviso que vai se em inglês.
Assembly nao e equivalente a linguagem de maquina ao. Assembly e uma abstracao da linguagem de maquina. Linguagem de maquina e 0 ou 1. Assembly seria algo como mov ax,bx.
> C não é escrito em nada, pois C é a linguagem. O que é escrito são os > compiladores. E existem muitos compiladores C. > O GCC, que é um dos mais importantes, por exemplo, é escrito em -- > pasme -- > C ! :P
> Aliás, Assembly é diretamente equivalente à linguagem de máquina ;)
> Em 31/03/07, Rafael Colucci <rafacolu...@gmail.com > <mailto:rafacolucci%40gmail.com>> escreveu:
> > Pelo que sei C e escrito em assembly com algumas partes em linguagem de > > maquina mesmo.
> > Rafael Colucci
> > Rodrigo Senra wrote:
> > > On 31Mar 2007, at 4:36 PM, Eduardo Willians wrote:
> > > > Senra, deixa eu perguntar uma coisa. Como Python poderia se tornar > > > > mais rápido?
> > > Parte da "lerdeza" do Python advém de sua dinamicidade, > > > muita coisa só é definida em tempo de execução:
> > > - onde estão os objetos (escopo local, global, builtin) > > > - que função vai ser executada > > > - quais os tipos dos parâmetros
> > > > Só se for escrito em Assmbly, ou sei-lá.
> > > Não precisaria ser assembly. Linguagens estaticamente tipadas > > > já possuem técnicas consagradas de otimização:
> > > - sabendo onde está a função eu apenas dou um salto para > > > o offset na posição de memória onde está o código a ser > > > executado > > > - da mesma forma, acessar "objetos" muitas vezes significa > > > pegar um região pré-definida de bytes na memória (conhecendo > > > o offset e tamanho) > > > - conhecendo os tipos dos parâmetros é possível alocar registradores > > > ao invés de empilar os parâmetros na pilha > > > etc etc etc
> > > As linguagens de execução rápida estão próximas do modelo da máquina. > > > Ex.: Assembly, C
> > > As linguagens de desenvolvimento rápido estão próximas do modelo > > > mental do > > > desenvolvedor > > > Ex.: Python, Lisp, Prolog
> > > Esse é o yin/yang do design de linguagens de programação. > > > Existe o projeto Psyco que agregou algumas otimizações para > > > programas em Python. Seu criador, Armin Rigo, agora trabalha > > > no projeto Pypy. O Pypy entre outros objetivos visa a criar > > > VMs otimizadas para execução de código Python.
> > > > Aliás, aproveitando, se Python foi escrito em C,
> > > O Pypy é uma VM Python escrita em ... Python ;o)
> > > > em que foi escrito C?
> > > O ovo ou a galinha certo ? Bom o primeiro compilador C foi escrito > > > em uma linguagem certamente diferente de C (provavelmente Assembly ou > > > BCPL). > > > Mas este conceito não devia causar supresa: > > > - hoje o Linux é desenvolvido em máquinas rodando ... Linux > > > - o projeto (fonte) svn é hospedado em um servidor SVN > > > e por aí vai
On 4/1/07, Rafael Colucci <rafacolu...@gmail.com> wrote:
> Assembly nao e equivalente a linguagem de maquina ao. Assembly e uma > abstracao da linguagem de maquina. Linguagem de maquina e 0 ou 1. > Assembly seria algo como mov ax,bx.
Rafael, o Paul Eipper está certo quando diz que "Assembly é diretamente equivalente à linguagem de máquina".
Existe uma relação de um-para-um entre comandos em linguagem de máquina e comandos em Assembly.
Portanto, não existe nenhuma diferença de performance ou de expressividade entre as duas. Consequentemente, não há nenhum motivo para alguém codificar algo diretamente em linguagem de máquina, a menos que o programador seja masoquista.
> Consequentemente, não há nenhum motivo > para alguém codificar algo diretamente em linguagem de máquina, a > menos que o programador seja masoquista.
Ah, os bons tempos em que se codificava operações em ponto flutuante nos monitores Z80, inspecionando byte a byte e convertendo na mão para checar se o resultado estava correto... Opa, acabei de revelar o quanto eu sou velho. :D
PyAmigos, grato pelas respostas, embora algumas tenham sido divergentes, achei a discussão bastante esclarecedora. Nalon, fiquei abismado, achei que não existisse nada no Brasil antes do FORTRAN. Falando em flashback, lembro-mo quando era menino e meu pai me ensinou um pouco de DBase. Era incrível.
É dito que Assembly é uma pseudo-linguagens que codifica as instruções em 0 e 1 em mnemônicos.
C é dita uma linguagem de médio nível por alguns livros e de alto por outros.. mas médio é interessante, pois é a denominação dada as linguagens de programação que tem acesso direto a Assembly em seu código.
Bem, realmente existe uma equivalência de 1 para 1 de asm para linguagem de máquina.
[ ]'s Brivaldo Jr
Em 01/04/07, Eduardo Willians <edujuri...@gmail.com> escreveu:
> PyAmigos, grato pelas respostas, embora algumas tenham sido > divergentes, achei a discussão bastante esclarecedora. > Nalon, fiquei abismado, achei que não existisse nada no Brasil antes > do FORTRAN. Falando em flashback, lembro-mo quando era menino e meu > pai me ensinou um pouco de DBase. Era incrível.
> Na paz,
> Eduardo Willians
-- Debian Linux em MS, eu apoio esta idéia e você? -- .''`. Debian GNU/Linux : :' : Free Operating System `. `' http://debian.org/ `- DEBIAN-MS
[As partes desta mensagem que não continham texto foram removidas]
Dizer que C é de alto nível é realmente novo para mim. Sempre existe um autor que quer mudar as classificações ao seu próprio entendimento a troco de sei-lá o que. Isso já está bem off-topic...
[As partes desta mensagem que não continham texto foram removidas]
> Bem, realmente existe uma equivalência de 1 para 1 de asm para linguagem > de máquina.
Claro que não, existem comandos em assembly com mais de um encoding possível em código de máquina. Por exemplo, uma coisa boba em x86 como ADD EAX,1 tem três encodings diferentes:
05 01 00 00 00 (usando a forma custom add eax,imm32) 81 38 01 00 00 00 (usando a forma add r32,imm32) 83 38 01 (usando a forma add r32,imm8)
Por isso não dá pra dizer que é 1 pra 1, no máximo 1 pra muitos.
Pra quem faz micro-otimização orientada a tamanho isso faz diferença, por exemplo, quando você está criando demos de 512 bytes. Tem umas coisas realmente muito estranhas no mapeamento do x86, por exemplo, o mínimo de espaço que você precisa pra um MOV EBX,10 é cinco bytes, mas se você fizer PUSH 10 / POP EBX, gasta só três bytes e faz essencialmente a mesma coisa.
---------------------------------------------------------------- Ricardo Bittencourt http://www.mundobizarro.tk ric...@700km.com.br "Save the trees. Eat more woodpeckers" ------ União contra o forward - crie suas proprias piadas ------
> On 31Mar 2007, at 7:57 PM, Leonardo Santagada wrote:
> > A pergunta foi pro senra, mas eu vou me candidatar a responde-la,
> Hehehe aqui qualquer pergunta é *sempre* para a Galera ;o)
> > de um jeito mais senra possivel :) > > obs: segura essa senra, agora tu virou um adjetivo :)
> s/senra/Senra/ ;oP
> > Agora sobre o motor de xadrez, eu vou escrever um motor para um > > jogo de IA > > que eu recebi de trabalho final de uma cadeira. A minha idéia vai > > ser tentar > > escrever ele todo em RPython e usar o pypy pra compilar ele pra > > código de > > maquina
> Muuuuuuito maaaaacho!
> > No ramo de escrever código C/C++ tu pode usar o pyrex, > > swig, boost.python pra te ajudar ou até fazer uma lib normal e usar > > o ctypes > > para fazer chamadas(cuidado pode não ficar tão bom usando o ctypes > > do que > > com os outros).
> Tirando o ctypes, eu experimentei essas alternativas e ainda assim achei > mais simples e gerenciável escrever C-extensions na mão sem > "wrapper-generators".
> Não é tão complicado quanto parece e dá muito mais segurança para o > desenvolvedor quando algo dá errado. O SWIG é simpático quando vc > precisa > extender em mais de uma linguagem (além do Python), mas este "use > case" é > mais raro.
> > Ou ainda faz a engine e espera que o pypy 1.0 já foi > > lançado e estamos quase lá pra fazer um python mais rapido!
> Concordo, para quem puder esperar, é o caminho mais transparente e > com melhor potencial de bons resultados. Todavia, eu não prenderia > a respiração enquanto espero ;o)
> Dizer que C é de alto nível é realmente novo para mim.
Concordo em parte. É o lance da teoria da relatividade, como estávamos falando de linguagem demáquina e assembly pode se dizer que C é *alto nível em relação* a essas alternativas. Não em termos absolutos, ou sequer comparado com Python ou Lisp ou Prolog, etc.
> Isso já está bem off-topic...
Eu não sou moderador desta lista, mas acho que quando o papo varia um pouco do tema Python mais ainda está relacionado a programação não custa deixar rolar um pouco.
>> Dizer que C é de alto nível é realmente novo para mim. >Concordo em parte. É o lance da teoria da relatividade, >como estávamos falando de linguagem demáquina e assembly >pode se dizer que C é *alto nível em relação* a essas alternativas. >Não em termos absolutos, ou sequer comparado com Python ou >Lisp ou Prolog, etc.
que eu lembre C era alto nivel por ter funções e variaveis e não ter acesso direto aos registradores ou algo assim. seguindo essa linha python é uma VHLL very high level language.
On 4/3/07, Leonardo Santagada <santag...@gmail.com> wrote:
> >> Dizer que C é de alto nível é realmente novo para mim.
> >Concordo em parte. É o lance da teoria da relatividade, > >como estávamos falando de linguagem demáquina e assembly > >pode se dizer que C é *alto nível em relação* a essas alternativas. > >Não em termos absolutos, ou sequer comparado com Python ou > >Lisp ou Prolog, etc.
> que eu lembre C era alto nivel por ter funções e variaveis e não ter acesso > direto aos registradores ou algo assim. > seguindo essa linha python é uma VHLL very high level language.
Já vi gente quase saindo no tapa em lista de discussão para decidir se C é de médio nível de abstração ou alto nível. Nâo dá para decidir este tipo de coisa em um sentido absoluto. Você pode comparar linguagens e até dizer que uma está "mais ou menos" em mais alto nível de abstração que outra, mas não dá para fazer isto em um sentido amplo para todas as linguagens.
Aliás, até entre duas linguagens a definição é artificial. O que é mais abstrato: Python, com toda sua dinamicidade, ou Java, com seu poderoso sistema de definição de interfaces? Mesmo que você diga que uma linguagem é "mais alto nível" que outra (ou ainda melhor, que uma linguagem é "mais ou menos mais alto nível" que outra) ainda poderá haver pontos onde a linguagem "desprivilegiada" poderá ser mais abstrata que a a linguagem "vencedora". Afinal, como decidir quem é mais alto nível, C ou Forth? ;)
EMHO não há muito sentido em falar sobre nível de linguagens, mas nível de abstrações que uma linguagem possui. O nível de abstração de list comprehentions, closures ou classes é altíssimo quando comparado com loops while, que já é mais abstrato que gotos, por exemplo. Note que estou falando da funcionalidade, não da linguagem. Mesmo certas funcionalidades opostas podem estar em níveis de abstração próximos. Compare a tipagem dinâmica em Python com a tipagem estática de Java e de Haskell. É meio difícil definir quem é "mais alto nível", né?
No final das contas, há de se considerar também a função da linguagem. Você já mexeu com sed? sed é, de fato, uma liguagem de programação surpreendente, com poucas mas poderosas abstrações para processar texto, que, porém, só possui gotos condicionais bem no nível de um "jump if zero" de Assembly. Mesmo Visual Basic (ou seu parente que prefiro, Gambas), PHP 3 etc são linguagens de altíssimo nível de abstração para construção de interfaces, mas com poucas ferramentas de abstração para lógica de negócio. SQL é uma linguagem extremamente abstrata para processar consultas em banco de dados, XSLT é poderosíssima para processar texto etc. etc. mas são linguagens cujo nível de abstração para outras tarefas é simplesmente muito baixo.
Resumindo: falar de "nível" de linguagem não é uma boa idéia. Ok, se você e os outros interlocutores concordam que linguagem A é mais alto nível que linguagem B então uma conversa é possível, mas apenas porque todos sabem os termos da discussão. Nâo quero dizer que Python é "mais alto nível" que C, nem que esta afirmação não possa ser feita. Quero dizer que esta afirmação, solta aqui, é cogniscível para todos - mas tentar criar uma regra universal para definir quem é mais "alto nível" é um trabalho desnecessário e até indesejável. Python é "mais alto nível" que C, eu entendo esta frase;ambíguo é quem fala que "C é médio nível" ou "Python é de altíssimo nível". Eu posso até concordar com as afirmações, mas que são complicadas quando postas neste sentido absoluta, são ;)
|
