Wie heißt der Nachfolger ...

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?

Gregor

Original erstellt von volkard:
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.

Ich weiß nicht genau, wie Java das macht. Aber zumindest gibt Java Speicher, den es einmal hat, nicht mehr so schnell an das Betriebssystem zurück. Der Speicher wird dann wohl nur Java-intern frei gemacht. ...und unter Umständen irgendwann wieder belegt. Vielleicht reicht das schon aus.

HumeSikkins

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

Jo. Der sollte problemlos funktionieren. Nur haben mir mittlerweile einige Experten mitgeteilt, dass der Allokator nicht so toll sein soll, wie man sich das wünscht. Ich habe das irgendwann auch mal getestet, kann mich aber nicht mehr wirklich an das Ergebnis erinnern. Vom Hocker gehauen hat's mich aber auf jeden Fall nicht.

Man müsste mal schauen, wie schnell die Boost pool-Allokatoren sind.

[ Dieser Beitrag wurde am 27.11.2002 um 01:48 Uhr von HumeSikkins editiert. ]

volkard

Original erstellt von Gregor:
Bis wo soll ich j denn laufen lassen, damit du davon überzeugt bist, dass der GC sehr aktiv gewesen sein muss?

Er wurde aktiv, keine Frage! Wäre er nicht aktiv geworden, wärste voll in den Speicherflaschenhals gerannt. Mag sein, daß er weiß, wie groß der Cache ist, und bei new aufgerufen wird, wenn der Cache voll ist, damit top performance bei solchen Anwendungen garantiert ist. Ich traue da Deinem GC inzwischen viele tolle Tricks zu.

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

Kann sein, weil die Schleifen schneller brummen, wenn sie nicht auch noch mit Anwendungscode durchsetzt sind. Und kann auf jeden Fall sein, wenns ein anderer Thread auf nem anderen Prozessor macht. Kann aber auch sein, daß bei sofortigem Löschen mehr Cache-Treffer passieren.

Außerdem defragmentiert der GC nicht. Der Speicher wird einfach nicht fragmentiert. Der GC muss also garnicht defragmentieren.

Für Top-Speed in dieser Anwendung muß ich erst nen small object allocator besorgen. Kann aber sein, daß ich erst einen selber bauen will, was dann bestimmt bis ins neue Jahr dauert. Ich melde mich auf jeden Fall wieder.

Und dann wärs spannend, ne Anwendung zu bauen, die drauf ausgelegt ist, den Speicher gnadenlos zu fragmentieren, und mal zu gucken. Das könte dann den Beweis erbringen, daß es Anwendungen gibt, die nen echten GC wie in Java benötigen.

Gregor

Original erstellt von volkard:
**
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.
**

Bei anderen Dingen, die man programmiert ist es genau andersherum. Da ist man dann mit Java viel langsamer als mit C++, kann Java aber mit entsprechenden Optimierungen prozentual besser beschleunigen, als C++.

Es wundert mich, dass folgender Hauptnachteil eines GC noch nicht genannt wurde:

Wenn man einen GC hat, dann ist das Programm in dre Regel nicht echtzeitfähig, da der GC letztendlich jederzeit aktiv werden kann und so eine große Pause produzieren kann. Man kann sich zwar bemühen, den GC in Programmteilen aufzurufen, in denen man keine Performance braucht, IMHO kann man aber nicht 100%ig festlegen, dass der GC nicht irgendwann an einer Stelle aktiv wird, an der er nicht aktiv werden soll.

Gregor

Original erstellt von volkard:
**
Für Top-Speed in dieser Anwendung muß ich erst nen small object allocator besorgen. Kann aber sein, daß ich erst einen selber bauen will, was dann bestimmt bis ins neue Jahr dauert. Ich melde mich auf jeden Fall wieder.

Und dann wärs spannend, ne Anwendung zu bauen, die drauf ausgelegt ist, den Speicher gnadenlos zu fragmentieren, und mal zu gucken. Das könte dann den Beweis erbringen, daß es Anwendungen gibt, die nen echten GC wie in Java benötigen.**

Da bin ich mal gespannt!

Ist es in Java auch möglich den GC abzustellen und sich selbst um die Speicherfreigabe zu kümmern?

Gregor

Original erstellt von <Selbst ist der Mann>:
Ist es in Java auch möglich den GC abzustellen und sich selbst um die Speicherfreigabe zu kümmern?

Nein! ...da mußt du wohl D nehmen! ...bei Java kannst du aber zwischen verschiedenen GCs umschalten. Es gibt da verschiedene Taktiken, sowas zu implementieren. Habe ich aber noch nicht gemacht und ich kenne die Möglichkeiten auch nicht genau. Es soll z.B. nen GC geben, der sehr gut auf Multiprozessorsysteme ausgerichtet ist.

[ Dieser Beitrag wurde am 27.11.2002 um 02:06 Uhr von Gregor editiert. ]

Das ist ja wirklich schade, das man nicht selbst Hand anlegen darf.
Na ja, aber dann nehm ich doch lieber C anstatt D.

Gerard

11 sekunden

#include <iostream>
#include <stdlib.h>
#include <ctime>
#include <deque>

std::deque<int> pool;

class TestClass
{
   private :
   int number;

   public :

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

   int getNumber ()
   {
      return number;
   }

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

   void * operator new (size_t)
   {
       pool.push_back(0);
       return &pool.back();
   }

   void operator delete(void * s)
   {
       if(&pool.front() == s) // ohne das brauche es 19 sek
           pool.pop_front();
       else
           for(std::deque<int>::iterator i = pool.begin(); i != pool.end(); ++i)
                   // kann man bestimt noch schneller lösen
           {
               if(&(*i) == s)
               {
                   pool.erase( i );
                   break;
               }
           }
   }
};

int main(int argc, char *argv[])
{
  int size = 500;
  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;
}

der Allocator aus Loki brachte nichts

for(std::deque<int>::iterator i = pool.begin(); i != pool.end(); ++i)

Meinst du mit "kann man sicherlich noch schneller machen" den schleifenkopf? wenn ja, wie soll man das noch schneller machen können?

Gregor

Übrigens : Mein Profiler hat mir eben verraten, dass beim Java-Programm etwa 10% der Zeit für den GC benötigt wird. Das Löschen der Objekte scheint also tatsächlich deutlich schneller zu gehen als das Erzeugen der Objekte.

EDIT : @ Dimah : Ist der Rechner vergleichbar zu Volkards und meinem?

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

Was habt ihr beiden den für Rechner? (Prozessor, Speicher)

Gregor

Volkard : 400 MHz Celeron
Gregor : 1,2 GHz P4M
...beide hierbei mehr oder weniger gleich schnell.

[ Dieser Beitrag wurde am 27.11.2002 um 02:49 Uhr von Gregor editiert. ]