elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Arreglado, de nuevo, el registro del warzone (wargame) de EHN


+  Foro de elhacker.net
|-+  Programación
| |-+  Programación C/C++ (Moderadores: Eternal Idol, Littlehorse, K-YreX)
| | |-+  ¿Rust sustituirá algún día a C?
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: 1 2 [3] Ir Abajo Respuesta Imprimir
Autor Tema: ¿Rust sustituirá algún día a C?  (Leído 5,511 veces)
eferion


Desconectado Desconectado

Mensajes: 1.248


Ver Perfil
Re: ¿Rust sustituirá algún día a C?
« Respuesta #20 en: 2 Diciembre 2014, 15:38 pm »

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.

Te cito:
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?

¿Entonces a qué te refieres?

Lo que en realidad discuto es que aqui se habló de que Rust es más rápido que Cpp.

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...

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.

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.

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

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.



En línea

_Enko


Desconectado Desconectado

Mensajes: 538



Ver Perfil WWW
Re: ¿Rust sustituirá algún día a C?
« Respuesta #21 en: 2 Diciembre 2014, 16:05 pm »

Cita de: eferion
¿Entonces a qué te refieres?
Estaba tratando de hacer la distincion entre un lenguaje qBasic, Cpp y sus compiladores Microsoft qBasic y VC++, gcc.

Citar
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.
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:
Código:
X = Z + 4 *Y;

Un compilador moderno y minimamente optimizado generará algo como esto:
Código:
lea eax, [ebx+4*edi]

Mientras que un compilador no optimizado va a generar algo como esto:
Código:
mov eax, edi
imul eax, 4
add eax, ebx

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.



En línea

engel lex
Colaborador
***
Desconectado Desconectado

Mensajes: 15.347



Ver Perfil
Re: ¿Rust sustituirá algún día a C?
« Respuesta #22 en: 2 Diciembre 2014, 17:08 pm »

poco conocedor de asm realmente...

asi que pregunto...

realmente un nucleo moderno hace
Código:
lea eax, [ebx+4*edi]
en un solo ciclo?  :o
En línea

El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.
_Enko


Desconectado Desconectado

Mensajes: 538



Ver Perfil WWW
Re: ¿Rust sustituirá algún día a C?
« Respuesta #23 en: 2 Diciembre 2014, 20:15 pm »

poco conocedor de asm realmente...

asi que pregunto...

realmente un nucleo moderno hace
Código:
lea eax, [ebx+4*edi]
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)
En línea

engel lex
Colaborador
***
Desconectado Desconectado

Mensajes: 15.347



Ver Perfil
Re: ¿Rust sustituirá algún día a C?
« Respuesta #24 en: 2 Diciembre 2014, 20:48 pm »

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

Citar
mov eax, edi
imul eax, 4
add eax, ebx

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

El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.
_Enko


Desconectado Desconectado

Mensajes: 538



Ver Perfil WWW
Re: ¿Rust sustituirá algún día a C?
« Respuesta #25 en: 2 Diciembre 2014, 20:57 pm »

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.

Código:
mov eax, edi
imul eax, 4
add eax, ebx
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.)
« Última modificación: 2 Diciembre 2014, 21:00 pm por _Enko » En línea

engel lex
Colaborador
***
Desconectado Desconectado

Mensajes: 15.347



Ver Perfil
Re: ¿Rust sustituirá algún día a C?
« Respuesta #26 en: 2 Diciembre 2014, 21:00 pm »

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
En línea

El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.
ivancea96


Desconectado Desconectado

Mensajes: 3.411


ASMático


Ver Perfil WWW
Re: ¿Rust sustituirá algún día a C?
« Respuesta #27 en: 2 Diciembre 2014, 21:06 pm »

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)
En línea

Páginas: 1 2 [3] Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
Anuncian Li-Fi; la luz sustituirá a las redes inalámbricas
Noticias
wolfbcn 0 1,020 Último mensaje 7 Febrero 2013, 17:50 pm
por wolfbcn
“El grafeno no sustituirá al silicio”
Noticias
wolfbcn 0 492 Último mensaje 6 Junio 2014, 02:00 am
por wolfbcn
Más de 300.000 jugadores han solicitado la devolución de Rust
Noticias
wolfbcn 0 451 Último mensaje 30 Junio 2017, 14:51 pm
por wolfbcn
Rust bypass para bloody mouse
Scripting
naruto20 0 317 Último mensaje 29 Marzo 2020, 19:08 pm
por naruto20
Android ya soporta oficialmente Rust
Noticias
WHK 0 325 Último mensaje 7 Abril 2021, 19:02 pm
por WHK
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines