Judo x Jypthon

jython é uma implementacao de python usando java. É mais lenta que a implementação em C pq java nao presta pra escrever interpretadores entre outras razoes.

A grande vantagem é que vc pode usar via python todos pacotes do java…

Judo eu desconheco

Eu não imagino por que alguém iria preferir utilizar alguma outra linguagem de script sobre Java que não fosse BeanShell. Realmente recomendo que vc procure um pouco sobre ele.

De qualquer forma, a melhor forma de comparar duas tecnologias é fazer os dois downloads e/ou percorrer o tutorial, quando houver.

Se vc gostar do Judo ou resolver utilizá-lo, conta pra gente!!

[]s

Bom, há uma razão, sim

Por que não usar qualquer linguagem de scripting? Take a look: http://jakarta.apache.org/bsf/

bom
pq alguem pode achar a sintaxe de python, por exemplo, é bem melhor que a de bean shell. ou pq jython é mais rapido que beanshell?
Ou entao pq a linguagem de script usada suporta um dominio especifico de programação;

ou ainda se a linguagem for funcional, e o cara ta afim de desperdicar memoria

Pode ate ser, mas eu ja vi coisas feitas em 2 linhas de Python (que, concordem ou não, tem todas as construções de uma linguagem funcional, talvez exceto continuations, nao me lembro direito :() que levariam paginas de whiles, ifs e terator.next()s pra conseguir em Java… moral da historia: desperdicar memoria as vezes eh mais barato do que desperdicar programador

Tomara que com as novidades da linguagem na versao 1.5 essa diferenca melhore um pouco

quem te disse que uma linguagem funcional desperdiça muita memoria? isso é um mito da decada de 70. Hoje isso é tao verdade quanto oque falavam sobre java 1.1, lento, pesado demais, ruim de usar.
Se voce usar uma linguagem puramente interpretada, como scheme, provavelmente vai ficar lento mesmo, mas te garanto que vai usar menos memoria que 1 programa em java.
Ja se pegar uma linguagem compilavel em codigo nativo, digo compilavel pq normalmente roda em modo misto, como haskell ou clos isso realmente nao vai existir. Ok, a parte OO do clos joga fora tanta memoria quanto java.

escreva um quicksort em java, e outro em ML. compare a velocidade e a memoria alocada pelos 2 (memoriafinal-memoriainicial, claro, sem considerar blueprint da VM).

voce ja viu alguma empresa usando linguagem funcional? mesmo as compiladas, para fazer as recursoes lazy, gastam KILOS de memoria.

Paulo

Sei de varias empresas que usam clos, porem se voce não considerar lisp como linguagem funcional, por não ser uma linguagem funcional ‘pura’, eu dou o assunto por acabado pq não sei de cases grande com empresas usando outras linguagens funcionais.

Primeiro programar AI, expert systems em especial eu diria, em lisp da um show em todos aspectos contra qualquer linguagem imperativa, tanto em elegancia quando em performance.

Não vou ter o link comigo, mas lembro de uma empresa que faz booking de passagens aereas que usa clisp para fazer a busca pela melhor opção de voo, mantendo uma interface com C devido ao fato do gc atrapalhar demais quando tinha muita memoria alocada.

E java nao desperdiça toneladas de memoria atoa? Pq meu programinha em mercury usa menos de 1m de memoria enquando 1 hello world do java usa uns 8m pelo menos? E pq eu nao deveria considerar o footprint da VM, afinal, ela é compulsoria no java.

Ahh, vale lembrar do emacs, editor preferido de 1 metade dos usuarios unix…

Lisp eh usado em IA, como prolog, porque fica mil vezes mais legivel, nao porque eh mais rapido! Eu implementei um planejador heuristico em java que da um pau em qualquer um feito em funcional.

Bastava trocar o GC para as necessdades dele, e fazer com que ele executasse menos ainda que o -server. Outra coisa, lisp tambem tem memory management, se esse clisp tem, eu nao sei, mas se tiver, trocaram 6 por meia duzia.

Conheca as opcoes especiais da VM:

java -Xms1m -Xmx1m -verbose:gc Hello

Sim, o Hello do Java gasta menos de um mega, basta conhecer a VM.

“louds”:

Ahh, vale lembrar do emacs, editor preferido de 1 metade dos usuarios unix…

Os PLUGINzinhos e SCRIPTS sao feitos em lisp. emacs em si eh em c.

É, Louds, essa história de performance ser um contra na adoção de Java já era.

Mas em um ponto que eu acho que vocês tão desprezando que é a melhor razão para se adotar uma linguagem de scripts:

É rapidíssimo de fazer uma tarefa pequena!! E, como um programa feito em PROLOG, é bem legível…

Isso sozinho justifica tudo… : )

[]s

Mesmo, oque voce anda usando pra executar suas comparações? Eu experimentei usar compiladores como o MLton, que produzem as vezes resultados melhores que de programas escritos em C com compiladores tradicionais. A questão é vc saber usar a linguagem, poder olhar a versão não linkada e ver oque e pq não gerou codigo eficiente. Linguagens funcionais te permitem gerar codigo pessimisado tanto quanto java ou pior.

clist é o lisp moderno, common lisp, a versao ratificada pela iso, ou foi pela ansi?, eles usavam C pq o clisp deles nao permitia usar shm de forma otimizada, entao eles usaram a interface com C para usar blocos grandes, alguns poucos Gb se me recordo bem, de shm de forma eficiente. Isso pq o GC não coletava referencias em memoria fora da area dele, entao eles poderiam ter zilhoes de objetos em memoria sem degradar a performance do GC.

acabei de fazer 1 teste bem simples no linux:

java
ctrl-z
ps aux | grep java

e eu vejo a VM usando 7364kb de memoria, memoria MESMO, pq de virtual passa dos 20mb…
ahh, java -version diz 1.4.1_02, é a versão da sun por sinal.
Entao me diga que a jvm da sun pra linux é uma grande piada ou me mostre como seu programa pode usar menos memoria que a VM sem executar nada?

Enquanto isso um programinha compilado em caml usa 100kb de memoria e realmente faz algo.

Sem ser hipocrita, minha contra-prova so mostra o custo do runtime do java, que é gigantesco, não vou nem comentar do warm-up time, porem o uso de memoria descontanto esse custo fixo não muda muito em relação a ocalm por exemplo, é a velha historia de usar um Vector com Byte’s e byte[] pra armazenar 1.000.000 de bytes.

“Paulo Silveira”:

Os PLUGINzinhos e SCRIPTS sao feitos em lisp. emacs em si eh em c.

Eu não tou falando que java é lento. Na minha opinião, java oferece a melhor relação performance/produtividade.

“louds”:

e eu vejo a VM usando 7364kb de memoria, memoria MESMO, pq de virtual passa dos 20mb…
ahh, java -version diz 1.4.1_02, é a versão da sun por sinal.
Entao me diga que a jvm da sun pra linux é uma grande piada ou me mostre como seu programa pode usar menos memoria que a VM sem executar nada?

Faca o seguinte: java -X
Procura por ai, que, por default, o java prepara um heap de quase 8 megas, se voce nao especificar. Entao quando voce digita java, ele aloca 8 megas, se voce nao especificar menos.

Dessa maneira meu programa gasta menos memoria, ja que eu pedi ao java para usar menos mem de cara, e que gastasse no maximo 1 mega, senao ele daria OutOfMemoryError.

Novamente, leia a documentacao antes de falar que meu programa em java nao consegue gastar menos que 7364kb de memoria. Mesmo a JVM do linux consegue.

Outra coisa, que PS eh esse que voce tem, que o AUX fala a quantidade de memoria que cada processo tem?

alias, fui fazer o benchmarking com o mlton
peguei o mergesort do ullman:

fun merge(nil,M) = M
        |   merge(L,nil) = L
        | merge(L as x::xs, M as y::ys) =
                if (x:int) < y then x::merge(xs,M)
                else
                  y::merge(L,ys);

        fun split(nil) = (nil,nil)
        |   split([a]) = ([a],nil)
        |   split(a::b::cs) =
                let
                        val (M,N) = split(cs)
                in
                        (a::M, b::N)
                end;


        fun mergeSort(nil) = nil
        |   mergeSort([a]) = [a]
        |   mergeSort(L) =
                let
                        val (M,N) = split(L);
                        val M = mergeSort(M);
                        val N = mergeSort(N);
                in
                        merge(M,N)
        end;

olha que bacana. fiz o merge com 5 numeros, compilei e rodou perfeito o binario do mlton

mergeSort
([2,4,3,6,8]);

ai pensei, vou testar com mais de 50 numeros, soh para ver se ja da para sentir um pouquinho

mergeSort
([2,4,3,6,8,34,55,33234,234,235,34,34,23,345,456,456,234,234,23234,
234,235,34,34,23,345,456,456,234,234,234234,234,235,34,34,23,345,
456,456,234,234,234,234,235,34,34,23,345,456,456,234,234,2234,234,
235,34,34,23,345,456,456,234,234,23,76,564,987,678,65,23,4,22,65,
234,43,2345,43,4564,7,234,5642,2456,234,234,235,34,34,23,345,
456,456,234,234,234234,234,235,34,34,23,345,456,456,234,
234,234]);

(quebrei linha para nao zoar a pagina do forum)
e adivinhem:

$ ./merge 
Segmentation fault (core dumped)

Hahhaha. Louds, o Collections.sort aguenta arrays com mais de 50 itens sim…

uso procps, q vem em 10 entre 10 distros de linux
o teste foi feito no shell da sourceforge, la eles usam redhat valhalla (7.3).
ps aux vai te mostra 2 informacoes referentes ao uso de memoria do teu processo:
vsz -> tamanho da memoria virtual do processo (data + heap + stack), so nao inclui o tamanho das page tables e da struct proc
rss -> resident set size: numero de paginas faulted pelo processo, num pc sao blocos de 4k, ou seja toda memoria que o kernel precisou realmente alocar pro processo.

bom
segui sua sugestao e usei java -Xms, mas primeiro li a documentacao e la diz que o heap minimo tem 1 mega, resolvi entao repetir meu teste, dessa vez num gentoo, java 1.4.1_02 denovo. usei dessa vez foi java -Xms1m -Xmx1m
Mudou, o VZS diminuiu um pouco, o RSS continuou acima dos 7 mega.

Ok, resolvi testar com 1 programa bem simples:

public class a
{
   public static void main(String[] s) throws Exception
   {
       Thread.sleep(1000000);
   }
}

usei javac -g:none -O

resultado:
java a
RSS de 9196 kbytes e 9 threads criadas!!
vamos melhoras?
java -Xmx1m -Xss96k a
RSS de 9180
hmmm
java -Xmx1m -Xss96k -Xint a
RSS de 8112

tentei de tudo, -Xrs diminuiu em 1 o numero de threads…

Ou seja, a nao ser que eu esteja fazendo algum muito errado, java usa pelo menos 7m de memoria so de runtime (8 - 1 de heap), nao vou nem comentar o quao isso piora numa maquina 64 bits.

Quanto ao seu teste com o MLton, qual versao vc usou so por curiosidade? Pq eu nunca tive problemas com ele…

mlton-20030312-1.i386, ultima versao do dia 12 do 3, estavel.

parece q o runtime/vm sempre usa 7 sim, soh podemos mexer no heap, claro.

vou pegar o clisp entao para fazer um benchzinho. mas me parece q ele eh praticamente procedural… eh muito C mesmo. bem, nem tanto. e vi q eh menos conhecida que ML… eu ja tava achando que estava super por fora

hmm
Paulo, aqui funcionou perfeitamente usando exatamente a mesma versao que voce, o mesmo codigo, provavelmente eh a versao de algum componente do teu linux gcc, binututils, etc…

clisp eh o dialeto de lisp mais usado, pq depois dos zilhoes de dialetos de LISP criados nas decadas de 70-80, clisp foi criado como padrao iso pra acabar com a zona, ja clos eh a versao OO do clisp.

A mim clisp nao lembra nada C, afinal tem que usar notacao prefixada (- n 1).

Isso tudo se resume a minha decepcao com java em nao poder fazer coisas como o seguinte:

void func(float *a, float *b, int i)
{
        switch(i & 4) {
                do {
        case 0: *a++ += *b++; --i;
        case 1: *a++ += *b++; --i;
        case 2: *a++ += *b++; --i;
        case 3: *a++ += *b++; --i;
                } while(i);
        }
}

hehehehehe
quem entende logo de cara oque isso faz?

“louds”:

void func(float *a, float *b, int i) { switch(i & 4) { do { case 0: *a++ += *b++; --i; case 1: *a++ += *b++; --i; case 2: *a++ += *b++; --i; case 3: *a++ += *b++; --i; } while(i); } }

Esse codigo
:arrow: tem Magic Numbers
:arrow: um CPD iria gritar facil
:arrow: abusa de pre/pos incremento numa mesma linha

Tudo isso torna o codigo soh possivel de entender com teste de mesa… claro que quem escreveu isso ai nao tinha o menor interesse de que outra pessoa entendesse… esse cara ai escrevendo algo parecido em java seria processado

Nao sei o q faz, parece que ele soma em A a progressao aritimetica simples de razao 1, alem de somar I vezes b em a. Soh de ver um do/while no MEIO do switch (repare que ele esta FORA dos cases) me da ansia.

diga o que faz, que te dou uma solucao quase tao curta, 100 mil vezes mais legivel e elegante.

Sem contar que esse codigo parece que faz a mesma coisa que:

void func(float *a, float *b, int i)
{
                do {
                       *a++ += *b++;
                } while(--i);
        }
}

bom, esse codigo deveria fazer loop-unrolling manual, porem nao vai funcionar pq a ordem dos cases ta errada, em vez de 0…3 deveria ser 3…0

eh
deu pra perceber, tanto que ele poderia ser escrito em uma linha, como eu escrevi la em cima…
nunca imaginei que alguem fosse tosco o suficiente para fazer o unrolling na mao, hhahaha.

Mais curioso ainda é como o teu sig serviu direitinho nesse contexto, paulo

Esse código é de 1987, naquela época o overhead de c++ era ainda considerado grande e o compiladores eram 1 piada perto de hoje, ninguem cogitava criar compiladores que fizessem WPO (Whole Program Optimization) pq seria proibitivo, hoje da pra fazer isso em projetos como o kernel do linux ou o XFree86 em maquina domesticas.

A solução foi ate elegante, pq a outra alternativa seria usar assembly inline.