Wie heißt der Nachfolger ...

[volkard]

Original erstellt von Gregor:
Verstehe ich nicht. Es ist IMHO schneller, sich mit einem vernünftigen GC Speicher für ein Objekt zu holen, als ohne.

Und das versteh ich nicht. Wodurch soll Speicher schneller verfügbar sein, nur weil ein GC da ist? Nimmst Du an, in C++ werde immer sofort jede freie Speicherseite dem BS zurückgegeben? Das ist wohl kaum der Fall, wäre ja auch viel zu lahm.

[Gregor]

So! Ich habe jetzt einfach mal 2 Programme geschrieben, die größtenteils das Gleiche machen. Eins in C++, das andere in Java. Es geht darum, wie schnell Objekte auf dem Heap erzeugt/gelöscht werden können. Das Ergebnis überrascht mich selbst etwas. Wahrscheinlich habe ich beim C++-Programm goßen Unsinn gemacht. Ich fange ja schließlich gerade erst mit C++ an!

C++-Programm :

main.cpp :

#include <iostream>
#include <stdlib.h>
#include <ctime>
#include "TestClass.h"

int main(int argc, char *argv[])
{
  int size = 3000000;
  long long sum = 0;
  clock_t time;

  TestClass ** array = new TestClass* [size];
  time = clock();
  for (int i = 0 ; i < size ; ++i)
  {
    array[i] = new TestClass(i);
  }
  std::cout << clock() - time << std::endl;
  time = clock();
  for (int i = 0 ; i < size ; ++i)
  {
    sum += array[i]->getNumber ();
    delete array[i];
  }
  delete [] array;
  std::cout << clock() - time;

  system("PAUSE");   
  return 0;
}

TestClass.h :

class TestClass
{
   private :
   int number;

   public :
   TestClass ()
   {
   }

   TestClass (int i)
   : number (i)
   {
   }

   ~TestClass ()
   {
   }

   int getNumber ()
   {
      return number;
   }

   void setNumber (int i)
   {
      number = i;
   }
};

Java-Programm :

TestMemory.java :

public class TestMemory
{

   /** Creates a new instance of TestMemory */
   public TestMemory ()
   {
   }

   public static void main (String [] args)
   {
      int size = 3000000;
      long sum = 0; 
      long time;
      TestClass [] array = new TestClass [size];
      time = System.currentTimeMillis ();
      for (int i = 0 ; i < size ; ++i)
      {
         array[i] = new TestClass(i);
      }
      System.out.println (System.currentTimeMillis () - time);
      time = System.currentTimeMillis ();
      for (int i = 0 ; i < size ; ++i)
      {
         sum += array[i].getNumber ();
         array[i] = null;
      }
      array = null;
      System.out.println (System.currentTimeMillis () - time);
      time = System.currentTimeMillis ();
      System.gc();
      System.out.println (System.currentTimeMillis () - time);
      System.out.println (sum);
   }

   private static class TestClass
   {
      private int number;

      public TestClass (int i)
      {
         number = i;
      }

      public void setNumber (int i)
      {
         number = i;
      }

      public int getNumber ()
      {
         return number;
      }
   }
}

Das Ergebnis ist folgendes :
Java braucht zum Erzeugen etwa 2 Sekunden, C++ mehr als 2,5 Sekunden. Java braucht zum Löschen keine 200ms, C++ braucht wieder mehr als 2,5 Sekunden. Ich denke, das Java-Programm bricht ab, bevor es mit dem Löschen fertig ist. Anders kann ich mir das nicht erklären.

[volkard]

@Gregor: wie schnell ist dein prozessor?

[Gregor]

Original erstellt von volkard:
@Gregor: wie schnell ist dein prozessor?

1,2 GHz P4M (bzw. 1,6 GHz, aber runtergetaktet, es lief aber auch noch was im Hintergrund. Bei beiden Programmen das gleiche, die Ergebnisse waren trotzdem reproduzierbar)

[davie]

lole:

import c.stdio;
import windows;

class BigClass {
    int number;
}

int main () {
    const int size = 3000000;

    int start = GetTickCount ();

    BigClass [] BC = new BigClass [size];       

    int end = GetTickCount ();
    printf ("Benoetigte Zeit: %i", end-start);

    return 0;
}

Witzigerweise ist dieser Code in D in der Debug Version um rund 40 Millisekunden schneller... (40ms)

[davie]

Achja, an alle nette Leute, die der Garbage Collector in D stört:
Hier klicken

[ Dieser Beitrag wurde am 26.11.2002 um 23:53 Uhr von Noesis editiert. ]

[Gregor]

@ Noesis : Bau doch mal ein Programm, das in D tatsächlich das Gleiche macht, wie das C++-Programm. Du erzeugst ja bisher nur ein großes Array. In den anderen Programmen werden auch noch ganz viele kleine Objekte erzeugt. ...und dann wieder gelöscht!

EDIT : ...oder werden die Objekte da schon miterzeugt?

[ Dieser Beitrag wurde am 27.11.2002 um 00:03 Uhr von Gregor editiert. ]

[davie]

Ähm, hollo, ich bin *noch* kein D Spezialist, aber mir bringt er die Fehlermeldung, wenn ich statische Arrays (arrays mit fixer Größe erzeuge, Typ [const größe] x)
"Stack overflow"
Dynamische Arrays (Typ [] x) legt er anscheinend auf dem Heap ab, aber nur wenn man sie mit new erzeugt (Typ [] x = new Typ[wieviele]), ansonsten ebenfalls am Stack
C-Arrays (Typ * x) nur mit new -> nur am Heap.
Ich werd mir mal etwas Zeit nehmen, um mir das gründlich anzuschauen...

[Gregor]

Das hört sich ja so an, als ob man auch Dinge gezielt auf dem Stack erzeugen kann. Ist das bei Objekten vielleicht auch möglich? Das würde ja heißen, dass die Diskussion oben umsonst war! ...ein Einwand weniger gegen D!

[davie]

Sieht seltsam aus, weil features to drpp: "Creating object instances on the stack. ..."
bin ich
auf jedenfall kann man sich den Garbage Collector abstellen, und auch selbst bestimmen, wann er wie reinigen soll (gehört zur Standard Library)

[volkard]

hab auch mal gemessen.

um sicherzustellen, daß er sum auch berechnet, hab ich int(sum) noch ausgegeben.

compiliert auf msvc60, gemessen auf celeron400.

2543
3645

hmm. mein rechner scheint ungefähr so schnell zu sein, wie deiner. du hast vielleicht auch nen celeron400.

mal schauen, was java da angestellt hat.
testhalber bau ich mal in die klasse das hier ein:

void operator delete(void* p)
{
}

2563
371

aha. java hat also ein wenig mehr gemacht also nix.

mal in der main noch einfügen array[i]=0;

2683
441

jo, das könnte es sein.

als wenn java da echt noch nix gelöscht hätte.

vielleicht bewirkt System.gc() hier noch kein echtes freigeben.

mal nen op new bauen, der zum free paßt.

void* operator new(size_t s)
{
if(free)
{
void* result=free;
free=*reinterpret_cast<void**>(free);
return result;
}
return ::operator new(s);
}
und das für c++ untypische array[i]=0; weg:

2763
691

vielleicht ist es auch das, was java gemacht hat.

public void gc()Runs the garbage collector. Calling this method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse.

und da die letzten 3000000 allokierungen ne TestClass angelegt haben, wärs ja eine ganz logische annahme, daß die nächsten 3000000 allokierungen wieder TestClass anlegen. Und Blöcke zusammenfassen kann man immernoch, wenn andere größen angefordert werden.

hier hab ich in c++ natürlich das problem, daß der speicher echt allokiert bleibt. und nen hintergrundprozess absetzen, der in idle-zeiten echt löscht, führt mich sofort in mehrkosten wegen multithreading und so. ihr habt das gleich dabei, was java hier recht lecker macht.

mal nen test machen, wo die freien blöcke auch wiederverwendet werden.

int main()
{
  int size = 3000;
  __int64 sum = 0;
  clock_t time;

  time = clock();
  for(int j=0;j<3000;++j)
  {
      TestClass ** array = new TestClass* [size];
      for (int i = 0 ; i < size ; ++i)
      {
        array[i] = new TestClass(i);
      }
      for (int i = 0 ; i < size ; ++i)
      {
        sum += array[i]->getNumber ();
        delete array[i];
      }
      delete [] array;
  }
  std::cout << clock() - time<<std::endl;
  std::cout << int(sum) <<std::endl;

  system("PAUSE");   
  return 0;
}

17505

uih.

und mit selbsgebautem new und delete mit verketteter liste freier blöcke:
741

was macht java hier? ich nehme an, auch schnell, aber ohne, daß der user so lästige sachen wie eigenes new/delete bauen muß?

[volkard]

Original erstellt von Gregor:
1,2 GHz P4M (bzw. 1,6 GHz, aber runtergetaktet, es lief aber auch noch was im Hintergrund. Bei beiden Programmen das gleiche, die Ergebnisse waren trotzdem reproduzierbar)

das läßt mich befürchten, daß was an der messung nicht ok ist, denn mein celeron400 hatte fast die gleichen zeiten fürs anlegen. evtl nicht alle optimierungen beim compiler an? ka. oder die zeit geht für die RAM-Zugriffe drauf und der Prozessor dreht größtenteils Däumchen.

[Gregor]

Original erstellt von volkard:
**
hmm. mein rechner scheint ungefähr so schnell zu sein, wie deiner. du hast vielleicht auch nen celeron400.
**

...oder vielleicht ist der Flaschenhals hier ganz wo anders! ...ich tippe auf die Speicherperformance!

EDIT : Vielleicht sollten wir mal ein kleines Array nehmen, was in den Cache paßt und welches dann sehr oft gefüllt und wieder geleert wird.

[ Dieser Beitrag wurde am 27.11.2002 um 00:36 Uhr von Gregor editiert. ]

[davie]

btw eigentlich sollte das hier nicht zum Kampf zwischen Java und C++ ausarten...

naja, in D ist auf jedenfall

Blabla x;
und
Blabla x = new Blabla;
sowie
Blabla *x = new Blabla;
erlaubt...
confusing, ich find aber einfach nicht genug infos.
kann sein, dass ich schon recht müde bin...
die spezif. sagt auch, dass D keine Objekte mehr am Stack anlegt.
Aber wie kommt es dann zu o.g. Stack Overflow? Hab ich was falsch gelesen?

[Gregor]

Original erstellt von Noesis:
**btw eigentlich sollte das hier nicht zum Kampf zwischen Java und C++ ausarten...
**

Es ist ein Kampf GC gegen nicht GC! ...den ich mit den neuen Programmen bestimmt gewonnen habe! ...kommt gleich!

[davie]

OK

[Gregor]

neue main.cpp :

#include <iostream>
#include <stdlib.h>
#include <ctime>
#include "TestClass.h"

int main(int argc, char *argv[])
{
  int size = 500;
  long long sum = 0;
  clock_t time;

  TestClass ** array = new TestClass* [size];
  int i,j;

  time = clock();
  for (j = 0 ; j < 200000 ; ++j)
  {
    for (i = 0 ; i < size ; ++i)
    {
      array[i] = new TestClass(i);
    }
    for (int i = 0 ; i < size ; ++i)
    {
      sum += array[i]->getNumber ();
      delete array[i];
    }
  }
  delete [] array;
  std::cout << clock() - time;

  system("PAUSE");   
  return 0;
}

neue TestMemory.java :

public class TestMemory
{

   /** Creates a new instance of TestMemory */
   public TestMemory ()
   {
   }

   public static void main (String [] args)
   {
      int size = 500;
      long sum = 0; 
      long time;
      int i,j;
      TestClass [] array = new TestClass [size];
      time = System.currentTimeMillis ();
      for (j = 0 ; j < 200000 ; ++j)
      {
         for (i = 0 ; i < size ; ++i)
         {
            array[i] = new TestClass(i);
         }
         for (i = 0 ; i < size ; ++i)
         {
            sum += array[i].getNumber ();
            array[i] = null;
         }
      }
      array = null;
      System.gc();
      System.out.println (System.currentTimeMillis () - time);
      System.out.println (sum);
   }

   private static class TestClass
   {
      private int number;

      public TestClass (int i)
      {
         number = i;
      }

      public void setNumber (int i)
      {
         number = i;
      }

      public int getNumber ()
      {
         return number;
      }
   }
}

Ergebnis : Java braucht etwa 7 Sekunden, C++ braucht etwa 2 Minuten.

EDIT : Hier wird der GC mit Sicherheit aktiv, da der Speicher, den Java zur Verfügung hat, sonst nicht ausreicht.

[ Dieser Beitrag wurde am 27.11.2002 um 00:54 Uhr von Gregor editiert. ]

[Gerard]

der Java GC bringt sicherlich etwas Speed beim Anlegen von Objekten, da er den Heap nicht so fragmentiert, aber es ist uns doch klar dass das defragmentieren selbst Speed kostet und ein GC insgesamt mehr kostet, dafür hat der GC den Vorteil das es beim anlegen schneller ist, also uns da Speed bringt wo es wichtig ist.
Und der Test wird verfälscht, das kann man schon an den Ergebnis ablesen, was ist wahrscheinlicher das Java 17 mal schneller ist oder das der gc nicht das macht was man erwartet.

und ein Small Objekt Allocator sollte auch C++ ein guten Sprung nach vorne verpassen.

[ Dieser Beitrag wurde am 27.11.2002 um 01:11 Uhr von Dimah editiert. ]

[Gregor]

Naja! ...wenn ich j bis 400000 statt bis 200000 laufen lasse, dann steigt die Zeit bei beiden Programmen linear an. Bis wo soll ich j denn laufen lassen, damit du davon überzeugt bist, dass der GC sehr aktiv gewesen sein muss?

...im Übrigen stimme ich nicht damit überein, dass der GC insgesamt mehr Zeit brauchen muss. Er kann alle Objekte auf einmal behandeln. Sowas kann von vorteil sein. Außerdem defragmentiert der GC nicht. Der Speicher wird einfach nicht fragmentiert. Der GC muss also garnicht defragmentieren.

[volkard]

136055, also 2:16 min. Der Flaschenhals liegt irgendwo anders.

mit eigenem op new/delete:
5748

uih, was hätte ich viel rausholen können, wenn ich damals den messages noch nen richtigen allocator verpaßt hätte. so hab ich nur in die doku geschrieben, daß meine nachfolger das mal machen sollten, die habens aber sicherlich nicht getan.

also sowas darf man mit ungetuntem c++ ja gar nicht machen. und ich hatte immer angenommen, der msvc würde bereits für kleine objekte sonderbehandlungen machen.

also ich gebe zu, daß der user bei java mit dem gc keinen bedarf hat, sich irgendwelche gedanken zu machen, obs schneller ginge, man nimmt die standard-sachen und hat bereits was sehr sehr gutes.

in c++ ohne gc kann man schneller sein, aber zu vielfachem programmieraufwand. den irgendjemand mal macht, und man inkludiert dann das zeugs. ich vermute jetzt, daß es nicht wirklich am gc liegt, sondern daß java nen small object allocator hat, der immer gleich nen batzen auf einmal vom bs holt (4096 bytes wäre wohl klug, weils eine speicherseite ist), und dann da die neu zu erzeugenden objekte einfach reinsetzt wie in ein array. das sollte eigentlich völlig ausreichen, um die hier sichtbare performance zu bringen.

@hume: dein loki-port ist so vollständig, daß der small object allocator klappt?