Duda con threads

Iniciado por patilanz, 15 Mayo 2014, 13:33 PM

0 Miembros y 4 Visitantes están viendo este tema.

Eternal Idol

Cita de: eferion en 19 Mayo 2014, 10:48 AM
Si yo hago un bucle con strings sin usar punteros... en C++ tendré un uso bastante estable de la memoria.

Código (c++) [Seleccionar]
string p;
for (int x = 0; x < 500; ++x)
  p.insert(p.end(), 1024 * 1024, '.');


Tal vez se me pierde el objetivo y/o sentido del bucle pero si hace algo que no se pierde inmediatamente ...
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón

eferion

Obviamente todos los almacenes de información a lo largo de un algoritmo implican un mayor consumo de recursos... en C, C++, C#, Java, Perl, PHP, ADA, Pascal, javascript y cualquier otro.

Sin embargo la cosa cambia cuando te encuentras con algo tal que:


#include <limits.h>
#include <iostream>

int main( )
{
  for ( unsigned int i=0; i<UINT_MAX; i++ )
  {
    for ( unsigned int j = 0; j < UINT_MAX; j++ )
    {
      string variable = "ALGO" + std::to_string( i ) + std::to_string( j );
      std::cout << variable << std::endl;
    }
  }
}


Código (csharp) [Seleccionar]

public class Program
{
  public static void Main()
  {
    for ( uint i=0; i<uint.MaxValue; i++ )
    {
      for ( uint j = 0; j < uint.MaxValue; j++ )
      {
        string variable = "ALGO" + i.ToString( ) + j.ToString( );
        System.Console.WriteLine( variable );
      }
    }
  }
}


Ya te garantizo yo que el consumo total de memoria del segundo programa en C# es bastante superior. Y cuando digo "bastante superior" me refiero descontando el consumo adicional de memoria que por defecto tiene C# con respecto a C++.

amchacon

#22
Cita de: Eternal Idol en 19 Mayo 2014, 10:17 AM
Te recomiendo Java y C#.
Esos no son punteros crudos al viejo C xD

Yo los situaría como las referencias de C++ (aunque estas se pueden modificar).
Por favor, no me manden MP con dudas. Usen el foro, gracias.

¡Visita mi programa estrella!

Rar File Missing: Esteganografía en un Rar

Eternal Idol

eferion: me debo estar perdiendo algo otra vez, ya que no se hace uso intensivo de la memoria dinamica (son unas cadenas de tamaño infimo) en tu ejemplo y se podria solventar facilmente usando una variable definida fuera del bucle en C# (acudo a la logica simplemente, no trabajo en .NET pero como el framework este medio bien hecho - tambien queda la JVM - al asignarle un nuevo puntero a variable deberia liberar la memoria anterior sin necesidad de recolectar basura posteriormente).

amchacon: por eso, si los punteros son el pasado ...
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón

amchacon

Cita de: Eternal Idol en 19 Mayo 2014, 12:03 PMamchacon: por eso, si los punteros son el pasado ...
En C++, el uso de punteros ya no es tan necesario. Para modificar variables y tal, prefiero mil veces las referencias.

El único uso que le veo a los punteros en C++ es para el polimorfismo. Para todo lo demás tienes las STL y las referencias:

Código (cpp) [Seleccionar]
unique_ptr<int> MemoriaDinamica(new int);

array<int,10> MemoriaDinamicaArray;

vector<int> MemoriaDinamicaVector(10);


Los punteros son suceptibles a los memoryleaks, las STL no ^^
Por favor, no me manden MP con dudas. Usen el foro, gracias.

¡Visita mi programa estrella!

Rar File Missing: Esteganografía en un Rar

eferion

#25
Se hace uso intensivo de memoria porque cada vez que creas un string, en la versión de C# (igual pasaría con Java) se está creando bajo la figura de un puntero... cuando se sale del ámbito, la instancia de string se marca para ser reciclada por el recolector de basura. Dado que el proceso está ocupado con la ejecución del bucle, el recolector de basura no entra en juego... y eso sucede a lo largo de toda la vida del código que he puesto.

Resultado: 4 * 4,294,967,295^2 instancias de string esperando a ser liberadas... y ocupando espacio en memoria.

el 4 viene porque:

Código (csharp) [Seleccionar]
string variable = "ALGO" + i.ToString( ) + j.ToString( );

Esta línea implica la creación de 4 strings:

* primer string: "ALGO"
* segundo string: i.ToString( )
* tercer string: j.ToString( )
* cuarto string: variable = todo_lo_demas

Bueno, realmente creo que sería más correcto decir que en cada iteración se crean 5 strings... ya que los operadores de suma se resuelven uno a uno.

Citar
En C++, el uso de punteros ya no es tan necesario. Para modificar variables y tal, prefiero mil veces las referencias.

El único uso que le veo a los punteros en C++ es para el polimorfismo. Para todo lo demás tienes las STL y las referencias:

Los punteros son suceptibles a los memoryleaks, las STL no ^^

Totalmente de acuerdo.

Además, usando referencias evitas la tentación de hacer delete donde no corresponde :)

Eternal Idol

#26
Tal vez un experto en .NET pueda resolver con facilidad este "problema". Es posible que no exista ninguna optimizacion ni en Java ni en C# como para resolver algo tan sencillo como que una variable temporal (todas las que no son variable que deberia poder ser liberada en cada iteracion con un cambio de ambito, cosa que podria ser aplicada a las demas variables temporales tambien llegado el caso) sea destruida inmediatamente pero me resulta dificil creerlo.




EDITO: acabo de probar tu codigo con el framework v2.0.50727 (el mas antiguo en mi maquina) el uso de memoria no aumenta ni siquiera por cada iteracion de i. "ALGO" no es un objeto segun ildasm.
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón

eferion

Después de realizar algunas comprobaciones debo reconocer que .NET ha mejorado enormemente los problemas que comento.

Me apunto probar con strings más grandes... ya que el "tamaño" que ocupa uno de estos es francamente pequeño... y no se puede hacer un subclass de "string" porque es una clase "sealed".

Aún así me ha sorprendido la mejora de rendimiento al respecto.