Arquivo Discussoes de Programacao e Tecnologia Desculpem a pergunta aparentemente tola, mas estou lendo um artigo sobre exploits e vi uma recomendação de uso de linguagem de baixo nível, daí me veio a dúvida, java é uma linguagem de baixo nível como é o caso do C???
PS: estou lendo http://www.linuxsecurity.com.br/article.php?sid=8844
Amigo,
Creio que não, pois Java é completamente Orientada a Objetos (coisas de alto nivel).
Alem disso a linguagem Java tem que ser interpretada pela JVM, tornando-se Bytecodes. Bytecodes sim representa baixo nível. Acredito que quando falam em linguagem de baixo nível, as pessoas se referem à Assembly, C ou Cobol.
Até +!
Não, Java é alto nível.
Rodar em multiplataformas e não permitir manipulação da memória são só alguns dos exemplos que a tornam alto nível.
O C também não é uma linguagem de baixo nível. Alguns dizem que é de médio nível, ou alto nível.
Linguagens de baixo nível geralmente tem menos estrutura, e são muito ligadas ao hardware.
opa! como assim, ViniGodoy, sempre ouvi falarem que C é uma linguagem de baixo nível, claro que não como assembly, mas sempre falaram em C como baixo nível… agora fiquei confuso :S
Talvez se comparado com Java, ela seja de mais baixo nível.
Numa linguagem de baixo nível, você normalmente é obrigado a conhecer a arquitetura do hardware para poder desenvolver. Isso inclui registradores, organização da memória, interrupções, pilha de execução, etc. Você pode programar em baixo nível em C, pois ele tem integração com assembly, mas a linguagem C em si abstrai tudo isso para você. Logo, ela deixa de ser de baixo nível.
De baixo nível mesmo, inclui-se apenas o assembly, seja programando diretamente, ou com algum compilador que facilite boa parte de sua vida (como o Turbo Assembler).
O C é chamado de médio nível pq, apesar da linguagem abstrair para você praticamente tudo sobre a máquina, ela ainda tem preocupações de baixo nível. Entre elas:
Quem te falou isso?
Wiki:
Explicação da UFRGS:
http://www6.ufrgs.br/engcart/PDASR/linguagens.html
Por ser uma linguagem de médio nível, o algoritmo em C torna-se mais complexo do que o mesmo algoritmo feito no PHP (alto nível), por exemplo. Em compensação, o programador possui um número de recursos muito maior e pode controlar com mais segurança as operações que necessita processar. (…)C é frequentemente chamada de linguagem de médio nível porque combina elementos de linguagens de alto nível com a funcionalidade da linguagem assembly (baixo nível). Nessa categoria, o C permite a manipulação de bits, bytes e endereços - os elementos básicos com os quais o computador funciona.
A wiki americana já deixa claro que muitas vezes refere-se como C sendo de baixo nível, pois o termo pode ser usado de forma relativa, e ela pode ser comparada com linguagens de mais alto nível, como o java:
Entretanto, sou partidário de enquadrar o C como médio nível, pois se você olhar bem, é possível programar em C sem qualquer conhecimento do hardware (ou com muito pouco conhecimento), prática que tem se tornado cada vez mais comum hoje em dia.
ok, vini. Obrigado pelos links e pela resposta…
Agora, vou fazer uma pergunta que vai fugir um pouco até do tópico…
Meu objetivo ao entrar na área nunca foi o de ganhar dinheiro e tal, sempre quis me tornar um Hacker (pelo amor de Deus, hacker aí entra como uma pessoa que possui grandes conhecimentos e os utiliza da melhor forma, não confundam com cracker), então no meu caso devo continuar estudando Java ou seria mais indicado estudar uma linguagem de médio nível como C e/ou mesmo o assembly de baixo nível?
ok, vini. Obrigado pelos links e pela resposta…
Agora, vou fazer uma pergunta que vai fugir um pouco até do tópico…
Meu objetivo ao entrar na área nunca foi o de ganhar dinheiro e tal, sempre quis me tornar um Hacker (pelo amor de Deus, hacker aí entra como uma pessoa que possui grandes conhecimentos e os utiliza da melhor forma, não confundam com cracker), então no meu caso devo continuar estudando Java ou seria mais indicado estudar uma linguagem de médio nível como C e/ou mesmo o assembly de baixo nível?
Depende do que você vai programar. Dependendo do que for, você faz até com shell script. Arquivos maliciosos como vírus, por exemplo, geralmente são escritos em C ou Assembly, inclusive, há um site sobre isso, e que disponibiliza códigos do gênero em tais linguagens. Só não acho coerente posta-lo aqui. Exploits, como você já deve ter notado, geralmente são escritos em linguagens interpretadas como Perl, Python, Ruby e etc, mas também há muitos exploits em C, e até mesmo em Java. Portanto, há varias formas de se fazer uma coisa, o que você deve fazer é escolher a maneira mais fácil.
O fato de a maioria dos vírus de computador serem escritos em assembly é porque o resultado final é muito insignificante falando de peso. Menos de 1kb.
O assembly é uma linguagem de montagem, já não é mais uma linguagem de alto nível(quando escrevemos na linguagem que o homem entende). São mnemônicos que representam registradores e instruções a serem executadas pelo processador.
Existe um ditado que Geek que diz, “Teclado de Programador de verdade só tem 3 teclas: “0, 1 e ENTER”.”
Isso quer dizer que está abaixo do assembly.
A uns 8 anos atrás conheçi o JAVA como uma linguagem pouco eficiente em termos de processamento por ser interpretada e não compilada.
Entretanto nas publicações mais recentes é informado que isso está mudando.
É verdade ? Até que ponto ?
+++
Ha uns 8 anos atrás conheçi o JAVA como uma linguagem pouco eficiente em termos de processamento por ser interpretada e não compilada.
Entretanto nas publicações mais recentes é informado que isso está mudando. É verdade ? Até que ponto ?
Em primeiro lugar, porque é um erro comparar o Java com uma linguagem interpretada, tal como Javascript. Isso porque o Java usa uma abordagem mista. Você compila o programa num .class, e esse .class é um código otimizado, sem que seja necessário qualquer validação sintática e semântica, e já com a parte lexica pronta. Em resumo, basta que a VM execute o que está ali, sem grandes interpretações. É mais próximo de um assembly, o que reduz consideravelmente o esforço de execução.
Segundo, porque desde o Java 1.2, boa parte do código que está efetivamente rodando na máquina é compilado para plataforma nativa, através da Hotspot compilation. Como a VM sabe exatamente em que máquina está rodando e que comportamento o assembly tem, seu compilador pode ainda incluir otimizações específicas, coisa que uma aplicação simplesmente compilada não pode fazer. Alguns exemplos são usar conjuntos de instruções otimizados para um processador, dar preferência para DirectX ou OpenGL na hora do desenho ou ainda remover sincronização caso a aplicação não dispare mais de uma thread.
Finalmente, é bom lembrar que o gababage collector tem um papel fundamental em aumentar muito a performance da linguagem, uma vez que provê uma solução muito elegante para a gerência de memória. Não é à toa que uma aplicação Java, por padrão, chega a ser mais rápida que uma aplicação escrita em C ou C++, a menos que a equipe nessas linguagens seja extremamente cuidadosa, e dedicada ao ponto de escrever seus próprios memory managers.
Dê uma lida nos artigos técnicos do Goetz, que explicam bem várias das características do java.
Sobre lendas a respeito da linguagem:
http://www-106.ibm.com/developerworks/java/library/j-jtp04223.html
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html
http://www-106.ibm.com/developerworks/java/library/j-jtp1029.html
http://www.ibm.com/developerworks/java/library/j-threads1.html
Sobre o funcionamento e performance do garbage collector:
http://www-106.ibm.com/developerworks/java/library/j-jtp10283/
http://www-106.ibm.com/developerworks/java/library/j-jtp11253/
http://www-106.ibm.com/developerworks/library/j-jtp12214/
Sobre otimizações em sincronizações introduzidas na Mustang:
Ele também escreveu algumas dicas sobre como melhorar a performance do código, muitas não aplicadas só a Java:
Pessoal,
Sempre percebi que o Java possui melhor desempenho em GNU\Linux do que no Windows. Tanto para desenvolver quando para executar, a diferença é notável! Algum motivo específico para isso?
Até +
Pessoal,Sempre percebi que o Java possui melhor desempenho em GNU\Linux do que no Windows. Tanto para desenvolver quando para executar, a diferença é notável! Algum motivo específico para isso?
Até +
Não diretamente, já que o aplicativo Java roda encima de uma máquina virtual, a JVM. O Linux trata seus processos melhor que os sistemas da MS, pelo menos é o que notei nesses 7 anos de uso do sistema Linux. Isso não só com aplicativos em Java, note que ocorre com qualquer aplicativo.
Opa!!! pegando o gancho, já que falaram de SO, na minha busca pelo conhecimento também li que um hacker deve dominar um SO, estou no Ubuntu, vcs indicam outro SO? e o que exatamente devo estudar do SO?
O Ubuntu é uma distribuição Linux. Existem outras distribuições com foco em segurança, tais como: PHLAK, BackTrack, e etc. Mas você pode instalar as mesmas ferramentas em seu Ubuntu e usa-lo para realizar testes de segurança. Por outro lado, existem distribuições menos flexíveis, que vão te forçar a aprender de fato, à usar este sistema, e ter controle sobre tudo que há nele. O Gentoo é um exemplo de distribuição “difícil”. Em compensação, além de você saber tudo que está nele, ele ainda possui uma velocidade incomparável. Com relação à estudar um sistema operacional, “comece pelo começo”. Você sabe realmente o que é um sistema operacional? Quais tipos existem (Time-Sharing, Real-Time, e etc)? Você sabe o que é um processo? O que é bufferização? Bem, isso já é um começo.
Andre,
É verdade, não só o Java, mas tudo roda mais rápido mesmo (incluindo download :lol: ).
Gambazinho, estudar S.O. é muito relativo. Um “hacker” normalmente conhece muito de redes e segurança da informação. Cuidado para não sair por ai fazendo besteira na internet, visto que sempre tem forma de achar seu rastro! 8)
Até +!
Pessoal,Sempre percebi que o Java possui melhor desempenho em GNU\Linux do que no Windows. Tanto para desenvolver quando para executar, a diferença é notável! Algum motivo específico para isso?
Até +
De certa forma sim, porque o io em sistemas Unix São bem mais otimizados. E um outro item importante é quê se o sistema é de 64 bits, todos os aplicativos e programas básicos também são, ao contrário do windws.
Andre,É verdade, não só o Java, mas tudo roda mais rápido mesmo (incluindo download :lol: ).
Gambazinho, estudar S.O. é muito relativo. Um “hacker” normalmente conhece muito de redes e segurança da informação. Cuidado para não sair por ai fazendo besteira na internet, visto que sempre tem forma de achar seu rastro! 8)
Até +!
mas pow e a programação??? eu pensei que ser um exímio programador era a base de todo hacker… estou enganado?
[quote=ViniGodoy]
Ha uns 8 anos atrás conheçi o JAVA como uma linguagem pouco eficiente em termos de processamento por ser interpretada e não compilada.
Entretanto nas publicações mais recentes é informado que isso está mudando. É verdade ? Até que ponto ?
Em primeiro lugar, porque é um erro comparar o Java com uma linguagem interpretada, tal como Javascript. Isso porque o Java usa uma abordagem mista. Você compila o programa num .class, e esse .class é um código otimizado, sem que seja necessário qualquer validação sintática e semântica, e já com a parte lexica pronta. Em resumo, basta que a VM execute o que está ali, sem grandes interpretações. É mais próximo de um assembly, o que reduz consideravelmente o esforço de execução.
Segundo, porque desde o Java 1.2, boa parte do código que está efetivamente rodando na máquina é compilado para plataforma nativa, através da Hotspot compilation. Como a VM sabe exatamente em que máquina está rodando e que comportamento o assembly tem, seu compilador pode ainda incluir otimizações específicas, coisa que uma aplicação simplesmente compilada não pode fazer. Alguns exemplos são usar conjuntos de instruções otimizados para um processador, dar preferência para DirectX ou OpenGL na hora do desenho ou ainda remover sincronização caso a aplicação não dispare mais de uma thread.
Finalmente, é bom lembrar que o gababage collector tem um papel fundamental em aumentar muito a performance da linguagem, uma vez que provê uma solução muito elegante para a gerência de memória. Não é à toa que uma aplicação Java, por padrão, chega a ser mais rápida que uma aplicação escrita em C ou C++, a menos que a equipe nessas linguagens seja extremamente cuidadosa, e dedicada ao ponto de escrever seus próprios memory managers.
Dê uma lida nos artigos técnicos do Goetz, que explicam bem várias das características do java.
Sobre lendas a respeito da linguagem:
http://www-106.ibm.com/developerworks/java/library/j-jtp04223.html
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html
http://www-106.ibm.com/developerworks/java/library/j-jtp1029.html
http://www.ibm.com/developerworks/java/library/j-threads1.html
Sobre o funcionamento e performance do garbage collector:
http://www-106.ibm.com/developerworks/java/library/j-jtp10283/
http://www-106.ibm.com/developerworks/java/library/j-jtp11253/
http://www-106.ibm.com/developerworks/library/j-jtp12214/
Sobre otimizações em sincronizações introduzidas na Mustang:
Ele também escreveu algumas dicas sobre como melhorar a performance do código, muitas não aplicadas só a Java:
Essa otimização é relevante somente em pequenos algoritmos. Com o aumento da complexidade dos objetos o Java tende a perder desempenho porque todos os métodos e variáveis São declarados como virtuais e tudo acaba sendo alocado no heap. Isso gera um consumo de memória grande e consequente perda de desempenho no processamento. Existe um artigo interessante na wiki sobre isso.
Essa otimização é relevante somente em pequenos algoritmos. Com o aumento da complexidade dos objetos o Java tende a perder desempenho porque todos os métodos e variáveis São declarados como virtuais e tudo acaba sendo alocado no heap. Isso gera um consumo de memória grande e consequente perda de desempenho no processamento. Existe um artigo interessante na wiki sobre isso.
Um dos graves problemas do Java é mesmo o consumo de memória. Muitas estratégias dele para ganhar performance envolvem caches.
Outro problema é o fato do garbage collector literalmente congelar a aplicação por alguns milissegundos, enquanto trabalha.
Agora, eu discordo com vc de que essas otimizações sejam válidas só em pequenos algorítimos. Não é incomum ver programadores C++ que usam o new e delete default, e isso gera um penaulty grave para performance. Você até pode contornar em alguns casos, mas em outros, pode ser que o código problemático esteja encapsulado numa biblioteca, e você só descubra tarde demais, ou esteja impossibilitado de substituí-la. Também é bastante fácil ser descuidado com I/O ao usar o fstream, sem se preocupar em você mesmo criar um cache (no java, qualquer programador jr. sabe criar seu BufferedInputStream).
Por isso costumo dizer que o C++ é mais otimizável que o Java, mas não necessariamente mais otimizado. O fato é que, se duas equipes gastarem esforços, um programa C++ certamente será algumas vezes mais rápido que um programa Java. Porém, o esforço para isso no C++ é gigantesco, exige um time experiente, horas de desenvolvimento e benchmarking e, portanto, tem um custo muito alto. Erros no C++ também podem ter um impacto muito mais sobre o desempenho. Vai ter sentido apenas em empresas que trabalham com tempo real: vídeo, jogos, etc.
Outro ponto positivo do Java, em termos de construir aplicações com performance, são os profilers. O fato de ter muita informação de contexto (graças ao reflection) e de ter a VM, permite que profilers excelentes sejam criados. E o melhor, profilers não intrusivos, que não exigem qualquer modificação em seu código. Nós mesmos somos bastante fãs do Visual VM e do profiler do Netbeans, ambos fornecidos de graça. E nem adianta falar do Valgrind. Ele é só para Linux e nem se compara a um profiler Java.
Agora vem o detalhe mais importante dessa discussão: Essa diferença de performance gera impacto perceptível na aplicação? Porque não adianta nada falarmos de performance da linguagem, se isso não for percebido pelo usuário. Em 90% dos casos, não. Só valerá a pena se preocupar com a linguagem em si, caso você trabalhe com sistemas de tempo real, críticos. Audio, vídeo, games, sistemas industriais, são exemplos de sistema assim. Ou seja, sistemas que são intensamente CPU Bound, que dependam muito de processamento puro e simples, e não irão perder tempo em I/O, rede, etc.
Para um servidor de rede você tem um gargalo gigante, que é a própria rede em si. Para uma aplicação comercial, os gargalos geralmente irão se concentrar no BD. Até por isso o PHP, que é uma linguagem extremamente lenta, tem aplicações ótimas e rápidas, como o Wordpress, simplesmente porque não adianta falar de performance, se não estivermos falando em otimização de gargalos. O fato é que a linguagem dificilmente será o gargalo, e tirando aplicações como as que eu e você desenvolvemos, acho que a maior parte do fórum jamais sequer terá a necessidade de migrar um código Java para um C++.
Vini realmente pode ser que o buraco seja mais embaixo mesmo e a resposta não seja tão determinística no sentido de apontar uma linguagem como tendo melhor performance.
Talvez tenhamos mesmo de levar em consideração a aplicação :
“…While C++ is faster than Java in most cases,[10] there are several studies of mostly numerical benchmarks, which argue that Java could potentially outperform C++ in some circumstances,.[11][12][13][14] However, it is widely recognized that numerical (micro-)benchmarks are not appropriate for evaluation of languages; two compilers with different performance on non-numerical sections of code may still be able to optimize numerical sections equally.[15][16][17] If referring to a real world program, Java would suffer because of a number of reasons:[18][19][20]…”
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B
O que voce disse pode resmir muito : Que na prática se levarmos a relação custo-benefício de um modo geral o Java pode ser uma melhor opção para 90% dos casos.
+++
Nossa, vocês viram as referências deles? As de Java, vem de faculdades, revistas e estudos aparentemente sérios.
As do C++, vem de sites pessoais, inclusive “why I hate java”. Tinham que melhorar isso aí.
Há referências sérias mostrando que C++ tem performance melhor também.
O fato é que todo benchmark que for CPU-bound irá favorecer o C++. E todo benchmark que mostrar alocação e desalocação no heap irá favorecer o Java.
E, claro, tudo depende do quão elaborado será o programa C++, do quanto vc investe nele. Como eu falei, se você se dedicar, você sempre conseguirá fazer um programa C++ mais rápido que um programa Java. E isso normalmente irá envolver olhar com muito cuidado como se aloca e desaloca memória (seja escrevendo um alocador próprio, ou mudando código do heap para o stack).
Mas a diferença só será significativa para o usuário se o programa for muito orientado a CPU.
Sistemas de tempo real, aplicações de processamento de dados (meteorologia, bolsa de valores), simulações matemáticas, etc…
Em aplicações comerciais normais, raramente a diferença de performance vai valer o sacrifício de ter novamente problemas com memory leaks e dangling pointers. Outros fatores, como ter ou não uma VM instalada, podem ter um peso muito mais significativo na escolha entre uma ou outra linguagem.
Nesse ponto eu concordo com o viny, na faculdade alguns colegas vivem criticando o java, apontando problemas e dificuldades de desenvolvimento por conta das configurações de variáveis de ambiente, tomcat, frameworks, mas tudo isso depende do programador, eu mesmo nunca tive tais problemas, agora pega um zé do PHP(sem querer desmerecer) e vem pro java achando que pode colocar array dentro de string, inteiro dentro de string, char dentro de string e por aí vai… java é uma linguagem fortemente tipada e é assim por ser segura, mas eles vivem falando “o que vc faz em 5 linhas no java eu faço em 2 no PHP”…
Essa questão de desempenho está muito mais relacionada ao desenho da aplicação e aos algoritmos utilizados que na questão física propriamente dita.
Esses problemas no java eu citei porque até hoje não entendo como não foram corrigidos. A CLR é bem mais otimizada nesse sentido de consumo porque não aloca tudo na memória. Já era hora da Oracle pensar nisso porque realmente é um empecilho grande usar aplicações desktop que geralmente ocupam umas centenas de Mb e muitos até Gb.
O custo benefício do java é grande? Claro que é, mas o desenho da jvm ainda pode e deve melhorar muito na minha opinião.