Jump to content
Sign in to follow this  
OldCoder

C++ linguagem que produz o código mais rápido entre linguagens OO

Recommended Posts

KTachyon

Não é assim tão surpreendente :)


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Share this post


Link to post
Share on other sites
OldCoder

É bom realçar que para obter executáveis mais rápido, o C++ exige mais do programador que maior partes das linguagens OO. Esta conclusão também é importante.

Mais uma vez, pode não ser novidade, mas é sempre bom ver estes resultados publicados por investigadores da Google.

Share this post


Link to post
Share on other sites
KTachyon

Pois, o problema com as outras linguagens é que nem sequer consegues chegar à mesma optimização (tal como consta na conclusão) :)


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Share this post


Link to post
Share on other sites
kaub0st3r

wohhhhhh até vou trabalhar melhor no meu projecto  :cheesygrin: tinha noção das potencialidades do c++, mas a maior parte dos artigos que encontro a

debater o c++ é falar das dificuldades que o programador vai ter em relação as outras linguagens oo,  :smoke: andava mesmo a espera de uma razão para não

mudar de linguagem sendo assim vou continuar por aqui (pelo c++).

P.S. obrigado pelo artigo  :)


blogue: migalhasfrog.blogspot.comtwitter: ricardo_pt

Share this post


Link to post
Share on other sites
SirDave

Não me surpreende, mas programar à homem é Assembly  :cheesygrin:

Agora a sério, Java é OOP mas sendo interpretada é mais lenta.

Go ainda é nova, mas não sei se o código compila directamente para Assembly.

Depois há o .NET mas exclui-se por ser direccionada para Windows e lento.

Portanto, quase que só resta o C++ (das grandes). Por isso é que não me surpreende.

Ah, e é preciso notar que estámos a falar de OOP.


Be nice to see your eyes, blink them from time to time to relax your retina when using the computer. Blink now!

Share this post


Link to post
Share on other sites
KTachyon

Agora a sério, Java é OOP mas sendo interpretada é mais lenta.

Tecnicamente, Java não é uma linguagem interpretada. É tudo compilado para bytecode que é interpretado por uma máquina de Java. A máquina de Java tem, depois, diversos processos que permitem que o bytecode não necessite ser reinterpretado diversas vezes na mesma execução.

Go ainda é nova, mas não sei se o código compila directamente para Assembly.

Tens um erro nessa afirmação. Um compilador não "compila para assembly". Um compilador (no core da definição) transforma código em instruções que o computador percebe. Assembly é, no fundo, uma representação directa das instruções do processador de uma forma minimamente perceptível por um ser humano.

Claro que, o normal é o compilador transformar sucessivamente a linguagem em operações mais simples por forma a conseguir construir o binário, passando, muito provavelmente, pela notação assembly. Mas é apenas por uma questão de facilidade.

Para além disso, de indicar que qualquer linguagem pode ser traduzida para assembly, incluindo o Java. Só cabe a um compilador fazê-lo.

Eu já cheguei a desenvolver um cross-compiler que "compilava" um subset de Lisp, que é, tradicionalmente, uma linguagem interpretada.

Portanto, quase que só resta o C++ (das grandes). Por isso é que não me surpreende.

Ah, e é preciso notar que estámos a falar de OOP.

Se falarmos em programação procedimental também não deverão haver grandes dúvidas.


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Share this post


Link to post
Share on other sites
SirDave

Tecnicamente, Java não é uma linguagem interpretada. É tudo compilado para bytecode que é interpretado por uma máquina de Java. A máquina de Java tem, depois, diversos processos que permitem que o bytecode não necessite ser reinterpretado diversas vezes na mesma execução.

Eu sei, mas eu acho que é mais interpretada do que compilada. Vejamos, Pyton interpreta o código na forma ASCII (tal e qual como o utilizador escreve) e Java interpreta o código em Java Bytecode, que é compilado previamente de ASCII.

Depois tem vários processos para acelerar tal como o que deste, mas ainda assim tudo isto não permitem que seja especialmente rápida.

Tens um erro nessa afirmação. Um compilador não "compila para assembly". Um compilador (no core da definição) transforma código em instruções que o computador percebe. Assembly é, no fundo, uma representação directa das instruções do processador de uma forma minimamente perceptível por um ser humano.

Claro que, o normal é o compilador transformar sucessivamente a linguagem em operações mais simples por forma a conseguir construir o binário, passando, muito provavelmente, pela notação assembly. Mas é apenas por uma questão de facilidade.

Para além disso, de indicar que qualquer linguagem pode ser traduzida para assembly, incluindo o Java. Só cabe a um compilador fazê-lo.

Eu já cheguei a desenvolver um cross-compiler que "compilava" um subset de Lisp, que é, tradicionalmente, uma linguagem interpretada.

Um compilador compila para bytes, mas "compilar para assembly" é uma maneira de dizer que compila para bytes, mas sim tens razão não é a expressão mais correcta.

Se falarmos em programação procedimental também não deverão haver grandes dúvidas.

C? Eu não conheço as diferenças de velocidade, mas tenho ideia que C é mais rápido.


Be nice to see your eyes, blink them from time to time to relax your retina when using the computer. Blink now!

Share this post


Link to post
Share on other sites
KTachyon

Eu sei, mas eu acho que é mais interpretada do que compilada. Vejamos, Pyton interpreta o código na forma ASCII (tal e qual como o utilizador escreve) e Java interpreta o código em Java Bytecode, que é compilado previamente de ASCII.

Depois tem vários processos para acelerar tal como o que deste, mas ainda assim tudo isto não permitem que seja especialmente rápida.

Sim, mas esses processos diferenciam logo à partida de uma linguagem interpretada. O Java é compilado para bytecode e esse bytecode é compilado on-the-fly (durante a execução). No final de tudo já estarás a executar um programa compilado.

C? Eu não conheço as diferenças de velocidade, mas tenho ideia que C é mais rápido.

Para mim, dizeres C++ ou C, vai dar ao mesmo. Como podes utilizar C simples em C++, não existe nenhum problema em conseguires o mesmo tipo de optimização. Quando dá mais jeito, ou quando é mais eficiente, utilizas o subset que mais se adapta ao que necessitas.

Eu até utilizo 3 em simultâneo: C, C++ e Objective-C :)


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Share this post


Link to post
Share on other sites
SirDave

Sim, mas esses processos diferenciam logo à partida de uma linguagem interpretada. O Java é compilado para bytecode e esse bytecode é compilado on-the-fly (durante a execução). No final de tudo já estarás a executar um programa compilado.

Mas todo esse processo é complexo e diminui a velocidade do Java, era esse o meu ponto previamente. Não vamos agora discutir se Java é interpretado ou compilado porque não é nenhum.

O que eu quero dizer é que se usarmos pure C, ou seja, o GCC com livarias de C temos resultados mais rápidos do que com o G++ com livrarias de C++.


Be nice to see your eyes, blink them from time to time to relax your retina when using the computer. Blink now!

Share this post


Link to post
Share on other sites
KTachyon

O que eu quero dizer é que se usarmos pure C, ou seja, o GCC com livarias de C temos resultados mais rápidos do que com o G++ com livrarias de C++.

Não é certo. Podes estar a utilizar libs de C++ que estão tão optimizadas como se fizesses em C. Até pode ser possível que estejam mais optimizadas, mas isso já é outra história. O que interessa é que, dentro de C++, podes programar em C, e dentro de programação OOP também tens programação procedimental. Em determinadas situações em que necessites de optimizar melhor um determinado conjunto de operações, podes sempre utilizar C simples, ou até assembly no meio do código :)


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Share this post


Link to post
Share on other sites
SirDave

Sim eu recorro à multi-linguagem em C++ várias vezes, mas nunca usei Obj-C, fico-me sempre pelo C e pelo Assembly.

Para processos mais importantes nos núcleos dos programas uso Assembly para ficar mais rápido, mas por vezes mais vale usar C/C++ com um código mais pequeno e "readable" do que Assembly.


Be nice to see your eyes, blink them from time to time to relax your retina when using the computer. Blink now!

Share this post


Link to post
Share on other sites
KTachyon

Eu uso Objective-C porque programo para OS X e iOS. Devem ser raras as pessoas que programam em Objective-C sem esta finalidade.


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Share this post


Link to post
Share on other sites
SirDave

Pois já sabia que as plataformas Apple usam Obj-C. Agora que fui pesquisar até fiquei a saber que tem OOP.

Só uma pergunta um bocado OffTopic, usas "extern" dentro de código C/C++/Obj-C ou escreves o código inline com recurso às livrarias de uma ou outra linguagem?

Eu uso a segunda, mas já vi uma pessoa a usar a primeira.


Be nice to see your eyes, blink them from time to time to relax your retina when using the computer. Blink now!

Share this post


Link to post
Share on other sites
KTachyon

Não me lembro de alguma vez ter utilizado extern em apps de OS X ou iOS. Assim que me lembre, precisei de desenvolver um algoritmo com uma heurística que precisava de ser bastante eficiente e que tive que me basear muito em C, mas sempre tudo inline.


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Share this post


Link to post
Share on other sites
shumy

Esta coisas são sempre muito duvidosas. Depende sempre do artista, onde está a ser aplicado e que tipo de problema.

No artigo está:

Jeremy Manson brought the performance of Java on par

with the original C++ version. This version is kept in the

java_pro directory. Note that Jeremy deliberately refused

to optimize the code further, many of the C++ optimizations

would apply to the Java version as well. The changes include:


Aqui há coisa de 2 anos fazia umas malhas de croché, depois fartei-me e fui para informática!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.