Mensajes

Supongo que las optimizaciones que se puedan a hacer al codigo en C podrian tener distintos resultados dependiendo de la plataforma y flags del compilador.

Sin duda, la plataforma es fundamental y el compilador tambien tiene lo suyo.

Lo que comentan sobre si mov usa 3 o 4 bytes podria dejarse para aplicaciones muy especializadas  donde cada ciclo del procesador cuente.

Para PC es poco relevante segun mi opinion, en sistema embebidos - donde hay que ahorrar bateria muchas veces - es otra cosa.

Lo que sucede es que usar encontrar un espacio en HEAP del tamaño indicado para evitar fragmentacion implica esfuerzo para el SO.

Pero eso no es el codigo generado.

Moverse en la pila local es restar un literal a base pointer, un acceso al montón es cargar la dirección de memoria y despues hay que calcular el offset.

Repito: eso es dependiente de la plataforma. Comparar el acceso a un elemento de un array para hablar de optimizacion no me parece lo mas idoneo ... pero igual como vemos no hay instrucciones especiales para acceder a la pila, son simples mov.

Como se puede ver la escritura y la lectura en el montón, mediante puntero necesita de muchas más instrucciones que el acceso a un elemento el array.

No, lo que se puede ver no es eso sino el codigo que genero un compilador A con una configuracion B para una plataforma C. Y obviamente ese codigo estaba muy poco optimizado, dudo muchisimo que un compilador moderno no pueda llegar a esto e incluso a algo mas veloz:

Código (asm) [Seleccionar] Expandir

mov QWORD PTR [rbp-8], rax ;guardamos en la variable local array el resultado de malloc
mov DWORD PTR [rax + 0Ch], 3 ;escribimos en array[3]
mov eax, DWORD PTR [rax + 0Ch] ;leemos de array[3]

Igual no es una buena idea equiparar el numero de instrucciones a su velocidad de ejecucion, las instrucciones de 128 bits son mas largas para codificar y a la misma vez son mas rapidas para ejecutar.

PD. No se puede comparar el codigo optimizado ya que este codigo es tan trivial que al hacerlo el compilador directamente pone el numero 3 donde corresponda como parametro de printf.



Este si se puede comparar optimizado aunque sigue siendo trivial:

Código (cpp) [Seleccionar] Expandir

   #include <stdio.h>
   
   int main( void ){
       int array[5];
   
for (int x = 0; x < 5; ++x)
       array[x] = 5 - x;  
       printf("%i", array[3]);
   
       return 0;
   }

Código (cpp) [Seleccionar] Expandir

   #include <stdio.h>
   #include <stdlib.h>

   int main( void ){
       int *array = malloc(sizeof(int) * 5);
   
for (int x = 0; x < 5; ++x)
       array[x] = 5 - x;    

       printf("%i", array[3]);
   
       return 0;
   }

Compilador VC++ con configuracion para optimizar tamaño /O1 (y GS- para el ejemplo de la pila) en x64.

Código (asm) [Seleccionar] Expandir

main:
 0000000000000000: 48 83 EC 48        sub         rsp,48h
 0000000000000004: 33 C0              xor         eax,eax
 0000000000000006: 8D 48 05           lea         ecx,[rax+5]
 0000000000000009: 89 4C 84 20        mov         dword ptr [rsp+rax*4+20h],ecx
 000000000000000D: 48 FF C0           inc         rax
 0000000000000010: FF C9              dec         ecx
 0000000000000012: 48 83 F8 05        cmp         rax,5
 0000000000000016: 7C F1              jl          0000000000000009
 0000000000000018: 8B 54 24 2C        mov         edx,dword ptr [rsp+2Ch]
 000000000000001C: 48 8D 0D 00 00 00 00 lea         rcx,[??_C@_02IKAHHCAI@?$CFi?$AA@]
 0000000000000023: E8 00 00 00 00     call        printf
 0000000000000028: 33 C0              xor         eax,eax
 000000000000002A: 48 83 C4 48        add         rsp,48h
 000000000000002E: C3                 ret

Código (asm) [Seleccionar] Expandir

main:
 0000000000000000: 48 83 EC 28        sub         rsp,28h
 0000000000000004: B9 14 00 00 00     mov         ecx,14h
 0000000000000009: E8 00 00 00 00     call        malloc
 000000000000000E: 33 C9              xor         ecx,ecx
 0000000000000010: 8D 51 05           lea         edx,[rcx+5]
 0000000000000013: 89 14 88           mov         dword ptr [rax+rcx*4],edx
 0000000000000016: 48 FF C1           inc         rcx
 0000000000000019: FF CA              dec         edx
 000000000000001B: 48 83 F9 05        cmp         rcx,5
 000000000000001F: 7C F2              jl          0000000000000013
 0000000000000021: 8B 50 0C           mov         edx,dword ptr [rax+0Ch]
 0000000000000024: 48 8D 0D 00 00 00  00 lea         rcx,[??_C@_02IKAHHCAI@?$CFi?$AA@]
 000000000000002B: E8 00 00 00 00     call        printf
 0000000000000030: 33 C0              xor         eax,eax
 0000000000000032: 48 83 C4 28        add         rsp,28h
 0000000000000036: C3                 ret

Como podemos ver las instrucciones mov de la pila usan 4 bytes y las del monticulo 3

Los arrays y las tablas són siempre más eficientes, pues son datos que se guardan en la pila

Normalmente las variables locales van en la pila y las globales van en la sección de datos.

y el código que se genera para acceder a ellos es más rápido que acceder el montón.

¿Que? Esto dependera de la plataforma pero en PC las instrucciones de cadena son mas rapidas que push/pop seguro (y ni hablar las de extensiones multimedia) ... ademas la pila es memoria virtual igual que el monton (mov* se terminara usando para leer casi siempre).

También está el tema de pasar arrays a funciones como argumentos: como es un puntero se pierde totalmente la ventaja de un array propio ya que hay que tratarlo como si estuviera en el montón.

Tampoco lo entiendo, un puntero a la pila no guarda diferencia con un puntero al monton ...

No hay contradicciones en esta descripción, digo.

Cuando algo habla de un S.O. no aplica a todos.

No se hacen tareas ajenas.

[un]

http://www.cplusplus.com/reference/cstdlib/realloc/

void* realloc (void* ptr, size_t size);

Reallocate memory block
Changes the size of the memory block pointed to by ptr.

The function may move the memory block to a new location (whose address is returned by the function).

La palabra clave ahi es may, no siempre se mueve el bloque de memoria.

Acabo de confirmar al revisar el codigo fuente derealloc

Una aclaracion: ese es un codigo fuente, lo que vale es lo que dice el standard, todo lo demas son implementaciones.

Cuando aprendi programación iniciamos con orientado a objetos y despues ejemplos en C estandar y me agradaban mas los ejemplos sencillos en C, me gustaba tener mas control de la memoria y programar a mas bajo nivel.

Sabiendo que todo lo que hagas en C lo podes hacer en C++ no hay mucho como para discutir, con solo usar namespaces ya se obtiene una mejor organizacion del codigo, si a eso se le suman los paradigmas nuevos (como POO y programacion generica) y demas (la sobrecarga es muy util tambien) entonces se le empieza a sacar jugo al lenguaje. Y no hay ninguna razon para que C tenga mas control que C++ por ejemplo en un modulo de modo Kernel para Windows (normalmente llamado driver) tenes por fuerza que sobrecargar el operador new (llamando a la rutina principal del Kernel que reserva memoria) y ademas podes hacerlo de manera que un parametro adicional indique si la memoria sera paginable o no.

Esta simplicidad me encanta:

Código (cpp) [Seleccionar] Expandir

...
{
 mutex_holder lock(mt); //contructor adquiere mutex
 ++recurso;
} //destructor libera mutex
...


No se hacen tareas.

Gunhack: por favor no hagas tareas ajenas y menos con codigo completo y compilable, gracias.

i-node: por favor no hagas tareas ajenas, va contra las reglas del foro.

Me parece bien que creas eso, pero el "liberalismo" no es un blanco o negro. La alternativa, que es un estado controlandolo todo lleva mas a menudo a la corrupción y a la pobreza.

Asi que primero decis que el liberalismo no es blanco o negro y despues describis una sola alternativa como la antitesis del mismo. No se si asumir que es una broma o una estrategia de marketing fallida. ¿A una ***** le oponemos otra *****? Lo lamento pero no funciona en ningun caso, si estamos en una ***** por apuntar a otra ***** no vamos a dejar de estar en la misma, asi no van a conseguir que nadie deje de señalar las injusticias de las enfermas sociedades en las que vivimos.

Si no puedes apoyar una idea sin insultar con cliches como llamar "fascista rabioso" a todo el que no comulga con esa idea, no creo que valga la pena ni seguir arriesgandome a que me metan un ban por opinar diferente

Somos pocos y nos conocemos, no es ningun insulto ni cliche, es una descripcion precisa, los que ven comunismo a la vuelta de la esquina y no estan mas que rodeados de capitalismo salvaje a los cuatro costados son unos fascistas y si los tenemos cada dos dias aca en el foro defendiendo el legado del generalisimo solo faltaria que pidamos la ficha de afiliacion para certificarlo ... y que no vale la pena es evidente, tenemos concepciones del mundo muy diferentes.