Foro de elhacker.net

He leído un poco acerca del Rust y de su mantenimiento a cargo de Mozilla. Se supone que es mas seguro que C y mas rápido que C/C++ con la misma seguridad. También he leido que su síntaxis es mas sencilla pero va a tener las mismas funciones o mas que C/C++ y que es mas sencillo de aprender y escribir ya que se trata de un único lenguaje, no como C, C++, Objective-C, C#.
¿Sustituirá Rust algún día a estos lenguajes? ¿Deberíamos aprenderlo? Lo pregunto aquí porque creo que solo los que saben bastante de C/C++ pueden separar los pros y las contras de este lenguaje de programación y compararlo con la suficiente información y experiencia.

No lo veo lo suficientemente parecido como para compararlo con C.

no es comparable c a c# ni c++ a objetive c. Ademas si rust tiene exito posiblemente tendra derivados.

en cuanto a que lo vaya a reemplazar llevan mmuchos años hablando de la muerte de c y vemos que sigue siendo un lenguaje predominante.

Pues... sólo C, que C, llegó para quedar... C.

Ok no, pero no lo conocía siquiera, se ve bastante bueno... indagaré, muy probablemente lo aprenda... parece estar muy verde, pero creo que valdrá la pena, más aún si me permite un control de memoria tan directo y puro como el de C/C++... todo menos VB.

Por lo visto no lo conoce nadie  ;D

Nadie sabe con seguridad lo que pasara en el futuro pero a corto y mediano plazo no parece que fuera a pasar.

Sinceramente no entiendo como se puede comparar la velocidad de ejecucion  de dos lenguajes de programacion.

Puede ser que un compilador de Rust genere codigo objeto mas optimizado que otro compilador de C.
Y aun así, mas optimizado y veloz para que plataforma?  Corre mas rapido en un pentium 3.. pero lo hará en un i5?

Y aun suponiendo hipoteticamente y muy poco probable que uno de los compiladores de Rust realmente generen mejor codigo objeto.
¿Que impide optimizar mas algun compilador de C?

Es como comparar bicicletas con raquetas de tenis. Una cosa no tiene que ver con la otra.

PD: Y si fuera tan tan tan tan "magnifico"... ¿por que firefox sigue siendo  compilado con Microsoft Visual Studio para windows?"

Los gurús de las predicciones son esa clase de personajillos especialistas en explicar los motivos por los que sus demoledoras previsiones no se han cumplido en absoluto.


A ver, por defecto C tiende a ser más rápido que C++ y no depende en absoluto de las optimizaciones del compilador. Es más debido a las características del propio lenguaje. En C manejas la memoria a un nivel muy bajo, mientras que en C++ una simple línea de código puede desembocar en una serie de llamadas en cascada demoledora (resevas de memoria, herencia, métodos virtuales, ... )

Como norma general yo creo que cuanto más bajo sea el nivel del lenguaje más rápido tiende a ser, digo como norma general porque bien es cierto que los compiladores de lenguajes de alto nivel pueden llegar a hacer maravillas... aún así estas maravillas tienen un límite.

Nada más semejante a la realidad...

El artículo (http://es.wikipedia.org/wiki/Rust_%28lenguaje_de_programaci%C3%B3n%29) en la wikipedia enuncia:


Me temo que nos estamos adelantando con prejuicios hacia un lenguaje que hasta la fecha no le ha hecho daño a nadie... al final, es imposible que sea más rápido que C, pero habrá que esperar documentación completa.

C seguirá siendo la base de los sistemas operativos y la programación en general, ergo no creo que "muera" dentro de mucho, mucho tiempo...

No termino de entender qué tiene que ver con lo que he comentado yo entre C y C++.


Tampoco recuerdo haber comentado nada acerca de la muerte de ningún lenguaje :S:S:S

No veo porque un compilador de Rust no pueda crear codigo mas optimizado que un compilador de C/C++...
a si, será tal vez porque C se está utilizando hace años y hay millones de dolares invertidos en por ejemplo VC++ para que esté MUY BIEN optimizado?

Hay que invertir mucho tiempo para optimizar un compilador, y luego tambien está el problema que no todas las optimizaciones son "mejorias" para diferentes plataformas.

Es más, invertiendo tiempo se puede hacer que le infame compilador QBasic de Microsoft de los 80 genere codigo más optimizado que VC++ o Intel C++. Pero claro, ¿Quien va a invertir en eso?

Creo que lo tomaste en contra, y de hecho, el comentario mio fue apoyando el tuyo...


Yo no he dicho que en un futuro muy lejano pueda pasar... pero por ahora, Syntax Error.

Además, creo que estás confundiendo algunas cosas... VC++ no es el único compilador que hay... GCC es uno muy bueno.

No entiendo tu ira hacia C/C++ o los inversionistas de VC++... es un estupendo lenguaje, ¿por qué intentar compararlo con otros? Cada uno tiene lo suyo y aporta algo a la informática... aunque odie a VB, me temo que cada cual tiene sus pro y sus contra y en diferentes ambientes será mejor uno u otro... ¿por qué esa necesidad de decirle al mundo que debe existir un lenguaje maestro?... la informática aún está libre de dogmas y deidades...

Mas optimizado.... no mas rapido...


El decir "que rust llegue a ser mas rapido que c" es un poco como tratar de decir "que sea mas rapido que asm" el trato de tan bajo nivel de C lleva a un manejo muy directo del procesador... y bueno seguir hablando sobre esto, seria repetir lo que ya dijeron...

Si, podría llegar cerca de la velocidad de c++ y tal vez para ciertas estructuras superarlo, pero si no tiene un nivel tan bajo nada se hace, y si se hace otro a nivel de c++ no es mas que un c++ con palabras y sintaxis diferentes, pero estructuras similares

Sí y es que nisiquiera leiste bien para darte cuenta de que digo:

¿Qué odio? Yo no veo odio en lo que dijo. Lo que veo yo es un punto de visto valido, lo siento si alguien no puede nisiquiera notarlo.

-

engel lex, ¿Cómo es que podes llegar a comparar en la rapidez de código C con código ensamblador?

Hey! :p no lo comparo directamente... por eso digo "es un poco como" haciendo referencia a lo bajo del nivel

Mh... si, es cierto, se puede tener un codigo objeto (ejecutable) más optimizada pero no necesariamente más  rápido para ejecutarse. (optimizacion en uso de memoria por ejemplo)

Pero la optimización que me refería es de velocidad de ejecucion, es decir que el compilador genere la minima cantidad de instrucciones en lenguaje máquina  necesarias para hacer lo que el programa indica y que lo haga utilizando aquellas instrucciones máquina que consuman la minima cantidad de ciclos reloj.
Eso es años de desarollo de un compilador, y en algunos compiladores de C han invertido años de trabajo, con lo que lleva unos costes impresionantes.

Vale... es lo que tienen los foros... no suelen transmitir lenguaje no verbal ;).

En serio que es que no entendía la respuesta, pensaba que habías malinterpretado mi comentario o algo así, no se.

Mil disculpas por intentar liarte jejejeje.


Pues fíjate que no me lo creo. Los procesadores nuevos tienen características que no existían en los años 80. Por tanto los compiladores de esa época no están preparados para trabajar a nivel óptimo con los compiladores actuales y, en consecuencia, no van a poder aprovechar todo el potencial que ofrecen los equipos modernos.

Pues me autocito xD

Cuando digo invertir tiempo, me refiero a  reiscribir el codigo del  compilador de QBasic... llamalo qBasic64 para plataforma de 64 bit inclusive y que incluya optimizaciones SSE3, SSE4 y demas.
(De lo contrario, de que inversión de tiempo podriamos estar hablando? era un compilador de 16bit, claramente requiere reescritura. Ejemplifiqué a QBasic porque es la cosa mas hororosa de los 80 que recuerdo... muy cerquita en el segundo lugar  el Turbo Cpp de Borland. O tal vez en el tercero? xD)

Si, es totalmente inutil y perdida de tiempo pero si posible.

A lo que voy, es que no se puede comparar la velocidad de lenguajes. Sino de ejecutables que genere un  compiladores. Un lenguaje no puede ser mas veloz que otro. Depende de las optimizaciones que tenga el compilador de dicho lenguaje.

Tranquilo, no pasa nada... sí, esto de los foros suele prestarse a malinterpretaciones, nos leeremos luego.


¿Y a vos quién te preguntó algo? anda mejor a publicar más inmadureces en mi blog... y de paso te repasas las normas de ortografía, que te metes con mi interpretación de la gramática y no sabes ni siquiera escribir bien...

Y ya deja de citarme crío, que a ti no te pregunté ni te respondí nada.

Eso es justamente lo que ha pasado con los compiladores que tienes hoy en día... han ido evolucionando a partir de lo que había en ese momento.

No puedo hablar de Basic porque no es mi campo y hace como que 15 años que no lo toco pero en C++ ha pasado justamente eso: El compilador C++ de gcc, por ejemplo, creo que nació en los 90... y desde entonces se le han ido aplicando mejoras y optimizaciones hasta llegar al día de hoy. Si me dices que un compilador de gcc de esa época era mejor que los de hoy en día entonces te digo con toda la tranquilidad del mundo que te equivocas.

Otra cosa que puede pasar es que estés más familiarizado con los compiladores de ese momento y sea más sencillo para ti usarlos, pero de ahí a afirmar que eran mejores que los que encuentras hoy en día...

Ha, pero si yo nunca dije que QBasic es mejor que cualquier compilador de hoy dia de Cpp. Al contrario, recuerdo haber dicho que use qBasic como ejemplo de lo peor que haya existido.

Y creo que los dos estamos de acuerdo, en los compiladores modernos de cpp han invertido años de tiempo y dinero para que sean como son ahora.

Lo que en realidad discuto es que aqui se habló de que Rust es más rápido que Cpp. E insisto, ¿Como un lenguaje puede ser más rápido que otro en sentido que produce mejores ejecutables?
Cuando en realidad es el compilador de dicho lenguaje  que es el encargado de esa tarea.

En el campo practico,  no veo como un compilador de un lenguaje moderno puede crear aplicaciones más optimizadas que un compilador como Gcc, VC++ o Intel C++ (que tienen años de desarollo)
Pero en el campo teorico, hipotetico, no descarto dicha posibilidad.

Si se quiere comparar dos lenguajes, pues el parametro a mi criterio es la versatilidad por ejemplo. Pero de ninguna manera velocidad.

Saludos.

Te cito:

¿Entonces a qué te refieres?


Lo cierto es que en el mundo de la programación aparece con demasiada frecuencia la intención de optimizar y hacer todo más rápido cuando lo cierto es que en el 90% de los casos no es necesario. Puedo entender que si un código tiene que ejecutarse en una millonésima de segundo o si resulta que la función en cuestión se llama de forma iterativa millones de veces pueda hacerse necesario algún tipo de optimización... pero una aplicación de escritorio que lee 1000 entradas de una base de datos y presenta una serie de datos, salvo que el programador sea un inutil o surja un requisito específico, no suele necesitar ningún tipo de optimización.

El ser humano mide el tiempo en segundos, minutos y horas y no es por casualidad. No somos capaces de notar la diferencia entre un evento de una milésima de segundo y otro de media milésima... de hecho nuestra vista no suele alcanzar los 100 imágenes por segundo, es decir, no es capaz de distinguir dos eventos que se producen en un intervalo menor a una centésima de segundo. Es más, aunque el evento que se lanza al presionar un botón tardase cerca de medio segundo (que ya es tiempo con los procesadores actuales) el usuario no le daría mayor importancia porque, simplemente, es un tiempo demasiado pequeño para percibirlo.

En cualquier caso, al que le preocupe el rendimiento y la velocidad, que pruebe a programar sistemas distribuidos y a programar los núcleos CUDA de las tarjetas gráficas, pero vamos, que se pueden contar con los dedos de una mano las situaciones en las que hace falta llegar a este extremo: ciencias experimentales, cálculos balísticos... vamos, algoritmos que se suelen aplicar en superordenadores.

Pero vamos, que las peleas en cuanto a la velocidad y rendimiento no es algo nuevo...


A ver, un lenguaje, perdón, el código generado a partir de de un lenguaje de programación puede ser por definición más lento que otro diferente, es un echo. Por ejemplo lo dicho, declarar una variable en C++ puede suponer una cantidad indeterminada de llamadas anidadas, mientras que en C tienes más control sobre este mismo proceso.

Como te comenté, los compiladores encargados de lidiar con un lenguaje de programación en completo pueden llegar a hacer maravillas en cuanto a optimización, pero éstas tienen un límite, ya que no pueden impedir, en el caso concreto del C++, las llamadas encadenadas que se producen en los constructores en herencia.

La naturaleza propia de un lenguaje de programación va a marcar la hoja de ruta del proceso de compilación y eso va a limitar la capacidad del compilador para proporcionar código eficiente.


Comparar lenguajes de programación siempre es polémico. Generalmente no se pueden comparar... es como comparar dos frutas, cómo catalogas el tamaño? y el sabor? y el color? ... la versatilidad tampoco se libra, ¿cómo se mide?

Se pueden hacer estudios más o menos específicos que apliquen un baremo establecido previamente para intentar dar una nota a cada lenguaje, pero aun así sigue siendo algo totalmente subjetivo. Cada lenguaje se ha creado pensando en satisfacer una serie de necesidades más o menos concretas.

Estaba tratando de hacer la distincion entre un lenguaje qBasic, Cpp y sus compiladores Microsoft qBasic y VC++, gcc.

Con un micro de 8 nucleos me imagino que no xD. Con la velocidad de procesadores modernos optimizacion es requerida en pocos casos eso es cierto.
Pero tampoco exagerar.

Por ejemplo:

Un compilador moderno y minimamente optimizado generará algo como esto:

Mientras que un compilador no optimizado va a generar algo como esto:

Esto es una optimiacion de lo más basica que hacen los compiladores. Ambos codigo objeto producen el mismo resultado. Solo que el segundo ocupa x5 veces mas ciclos reloj del cpu.

Ahora imagina dicho codigo repetido miles de veces en una ejecutable. La falta de optimizacion se va notar a la larga.

Notese que es un ejemplo muy muy basico de optimizacion y me imagino que todos los compiladores modernos lo hacen.

Sobre la definicion de variables de cpp y clases, si es cierto, la herencia haría que haya más codigo del necesario. Pero se sacrifica velocidad en beneficio de mejor encapsulacion y facilidad en diseño de grandes proyectos.


Sobre la comparacion de lenguajes, versatilidad era un ejemplo nomas, hay como ya dijiste mas parametros y si, se hace dificil comparar.
Pero la velocidad no lo sería y aqui añado siempre y cuando se trate de lenguajes del mismo tipo. Estructurados, Objeto Orientados y otros.

poco conocedor de asm realmente...

asi que pregunto...

realmente un nucleo moderno hace
en un solo ciclo?  :o

No, tendria que ver la documentacion, pero serían ponele 3-5 ciclos.

mientras que mov+imul+add serían 15-20 ciclos.

Es decir, consumirian el triple de ciclos. (5 veces mas tal vez fue un toque exagerado, pero cuarduple posible)

el asm que trabajo es el de pic y esto (bueno el equivalente)


serían literalmente 3 ciclos, cada linea de asm representa un ciclo, en asm para pc no?

Cada linea en asm es una instruccion para el cpu en el caso.
Diferentes instrucciones consumen distinta cantidad de ciclos reloj.
Por ejemplo XOR, MOV, TEST, JMP consumen menos  ciclos que iMul o iDiv.

Dependiendo de las instrucciones, a groso modo se puede decir que mientras mas instrucciones haya, mas ciclos reloj se van a consumir.
A la inversa,  (de nuevo, a groso modo) se puede afirmar que menos instrucciones, menos consumo de ciclos, codigo mas rapido.

No se cuantos ciclos reloj consume cada una de esas instrucciones, y tambien va depender del cpu. Pero  si se puede decir que IMUL>ADD>MOV.
O sea IMUL es la que mas consume, mientras que MOV la menor.
(Tiene que ver con la complijidad de la instruccion. Multiplicar es mas dificil que Sumar. Y Sumar es mas dificil que asignar un valor.)

ya... no sabia... por lo menos el xor, mov, jmp y not deberian ser literalmente un solo ciclo... pero ya entiendo entonces porque la arquitectura risc era tan fuerte contra la cisc y entonces la risc es más eficiente (más bajo nivel que la cisc) XD

Si no me equivoco, es proporcional a la cantidad de bytes que ocupa la instrucción en memoria, ¿o no? (Es una pregunta xD, que es algo que siempre dudé jaja)