Warum Java vom Prinzip her schneller als C++?

Manuelh87

@ SideWinder:
Ja vom prinzip her sag ich ja garnichts gegen deine idee... ein gutes design (was sicher nicht jeder "erlernen kann" ist natürlich am wichtigsten... auch wenn es geringe kosten hat.

Aber vorsicht mit der äußerung: denn das ist genau das, das ich soo lange spüren habe müssen mit meinem alten pc. Anwendungen laufen grundlos nicht gut. Warum? ja weil der programmierer ungeschickt abstrahiert hat und dann auch noch soch schlecht wie möglich gecoded hat und ja, mit dem ergebnis dieser "arbeit" hab ich mich dann als anwender herumschlagen müssen.

Die kunst ist es gut zu abstrahieren und dazu auch noch performant zu coden. Und sag jetzt nich dass das nicht möglich ist. Sicher ist es möglich, es kann eben nur nicht jeder. Deshalb ist eben coden nicht ein einfaches handwerk sonder doch komplizierter (und wird ja auch dementsprechent entlohnt...)

[edit:]

und nicht immer ist ja performance wichtig.. bsp:
hab eine tcp/ip klasse, also server und client. Da hab ich natrülich nicht probiert das optimum an performance rauszuholen, da jeder weiß dass das tcp protokoll sowieso zu langsam ist für die bereiche wo man das optimum benötigen würde... da ging es mir eher darum so zu designen, dass ich als basisklasse die ostream klassen nehmen kann und somit die aspekte der oop noch besser genutzt werden können..

im gegensatz dazu wollte ich eine schnelle + dynamische vektor klasse für spätere spiele oder rechnereien... naja und da wurden natürlich alle tricks angewant die es sogibt (allerdings ohne inline asm).
Da hab ich eben for schleifen geunrollt (?? weiß ned wie man dazu sagt...)
usw... denn hier bringt es was. wenn ich die entsprechende funktion oft benötige...

mit unroll mein ich das:

// normaler code ... also ungefähr:
for (int i=0; i<3; ++i)
{
  array[i]=zahl;
}

// geunrollt:
array[0]=zahl;
array[1]=zahl;
array[2]=zahl;

gibt compiler die das automatisch machen... aber meiner glaub ich ned. Also hab das eh vorher getestet, da hat ers nicht gemacht...

mfg Manuel

Xin

SideWinder schrieb:

Ich habe mit 19 auch noch Prozessortakte gezählt. Schade, dass das heute keiner mehr macht.

Es geht nämlich gar nicht so sehr um das optimalste Ergebnis für einen kleinen Teil sondern um die Abbildung und Abstraktion eines Gesamtsystems am Computer.
Programmieren ist ja eigentlich ein besseres Handwerk das jeder erlernen kann. Trotzdem denkt der Programmierer immer er sei weiß ich was besonders wichtig.
Man stellt einen zweiten Server auf der in der heutigen Zeit sowieso nichts kostet und aus fertig.

Hehe, die Meinung würde ich für mich behalten, das ist so ziemlich das dümmste, was ich bisher gehört habe. Viele denken so, aber wenige sagen das so kompromisslos.

Das Modell der Fibunacci Funktion lautet:

f(0) = f(1) = 1;
f(x) = f(x-1) + f(x-2);

Die Umsetzung lautet:

int fibunacci( int i )
{
  if( i <= 1 ) return 1;
  else return fibunacci( i-1 ) + fibunacci( i-2 );
}

Bei ausreichend großem i ist jeder Sun-Ultra-Mega-High-End MegaCluster leider total überfordert.
Die Dinger sind alles andere als billig und wenn ich dann einen zweiten Server dazu stelle, dann kille ich den einfach, in dem ich i um 1 erhöhe.

Dann nimmt man einen unwichtigen Programmierer aus dem Ende der Nahrungskette, gibt dem einen C64 (fast 1MHz auf 8Bit Prozessorbreite) und der frisst mit seiner "Höllenmaschine" beliebig viele Mega-Workstations.

Das Beispiel ist optimistisch gewählt. Im Reallife wird noch viel mehr <bösesWort> programmiert.

Gregor

Naja, wenn hier schon so ein Simpel-Beispiel dafür gebracht wird, wie einfach man unperformanten Code schreiben kann, dann sollte man in diesem Zusammenhang auch mal sehen, wie groß der Unterschied zwischen Sprachen wie C++ und Java bei "einfachem" Code bezüglich der Performance ist. Ich hatte da vor Jahren mal einen kleinen Benchmark mit dem Sieb des Erathostenes gemacht. ...und da ist er, einmal in C++, einmal in Java:

gregor@linux:~/JavaProjects/Test/TestPrime> cat TestPrime.cpp

#include<iostream>
#include<time.h>
#include <cmath>

int main ()
{
   const int end = 1000000000;
   const long startTime = (long)time(NULL);
   const int arraySize = (end >> 5) + 1;
   int sieve [arraySize];
   for (int i = 0 ; i < arraySize ; ++i)
   {
      sieve[i] = 0;
   }
   int x, y, i;
   int primes = 1;
   const int sqrtEnd = (int)sqrt((double)end);
   x = 3;
   while (x <= sqrtEnd)
   {
      if ((sieve[x >> 5] & (0x1 << (x & 0x1f))) == 0)
      {
         y = x * x;
         i = x << 1;
         ++primes;
         while (end > y)
         {
            sieve[y >> 5] |= (0x1 << (y & 0x1f));
            y += i;
         }
      }
      x += 2;
   }
   while (x <= end)
   {
      if ((sieve[x >> 5] & (0x1 << (x & 0x1f))) == 0) ++primes;
      x += 2;
   }
   std::cout << "Zwischen 0 und " << end << " liegen " << primes << " Primzahlen." << std::endl;
   std::cout << "GesamtZeit : " << ((long)time(NULL) - startTime) << " Sekunden" << std::endl;
}
gregor@linux:~/JavaProjects/Test/TestPrime> cat TestPrime.java
public class TestPrime
{
   public TestPrime ()
   {
   }

   public static void main (String[] args)
   {
      int end = 1000000000;
      long time = System.currentTimeMillis ();
      int [] sieve = new int [(end >> 5) + 1];
      int x, y, i;
      int primes = 1;
      int sqrt = (int)Math.sqrt((double)end);
      x = 3;
      while (x <= sqrt)
      {
         if ((sieve[x >> 5] & (0x1 << (x & 0x1f))) == 0)
         {
            y = x * x;
            i = x << 1;
            ++primes;
            while (end > y)
            {
               sieve[y >> 5] |= (0x1 << (y & 0x1f));
               y += i;
            }
         }
         x += 2;
      }
      while (x <= end)
      {
         if ((sieve[x >> 5] & (0x1 << (x & 0x1f))) == 0) ++primes;
         x += 2;
      }
      System.out.println ("Zwischen 0 und " + end +
                          " liegen " + primes + " Primzahlen.");
      System.out.println ("GesamtZeit : " +
                          (System.currentTimeMillis () - time) +
                           " Millisekunden");
   }
}
gregor@linux:~/JavaProjects/Test/TestPrime> g++ -O3 -o TestPrime TestPrime.cpp
gregor@linux:~/JavaProjects/Test/TestPrime> /usr/java/jdk1.6.0/bin/javac TestPrime.java
gregor@linux:~/JavaProjects/Test/TestPrime> ./TestPrime
Zwischen 0 und 1000000000 liegen 50847534 Primzahlen.
GesamtZeit : 37 Sekunden
gregor@linux:~/JavaProjects/Test/TestPrime> /usr/java/jdk1.6.0/bin/java -Xmx256m TestPrime
Zwischen 0 und 1000000000 liegen 50847534 Primzahlen.
GesamtZeit : 41160 Millisekunden

Das ist wohl ziemlich gleichwertiger Code in beiden Sprachen, der zugegebenermaßen nicht besonders viele Sprachfeatures, wie zum Beispiel viel OOP und so nutzt. Aber schauen wir uns mal den Unterschied bei diesem Beispiel an.

Das C++ Kompilat braucht 37 Sekunden, das Javaprogramm 41. Das C++-Programm ist hier also etwa 10% schneller. ...hui, das bewegt die Welt und sollte in jedem Fall der entscheidende Faktor bei der Wahl der Programmiersprache sein, heh? Naja, glaube nicht. Aber um es mal auf den Punkt zu bringen: Hier ist Java offensichtlich nicht bedeutend langsamer. Wo ist es das denn dann? In welchen Anwendungsgebieten muss man Dinge von Java nutzen, die das Programm unnötig ausbremsen. Wenn die Leute hier andauernd sagen, wie lahm Java ist, dann sollten sie das ja auch belegen können. ...oder habe ich da aus Versehen eine Bremse in das C++ Programm eingebaut und das schafft die Aufgabe normalerweise in 5 Sekunden? Glaube nicht, aber ich kenne C++ auch nicht wirklich. Also: Zeigt mal, wo Java lahm ist.

Gregor

Xin schrieb:

Dann nimmt man einen unwichtigen Programmierer aus dem Ende der Nahrungskette, gibt dem einen C64 (fast 1MHz auf 8Bit Prozessorbreite) und der frisst mit seiner "Höllenmaschine" beliebig viele Mega-Workstations.

...und das kann er nicht deshalb machen, weil er besonders gut C++ oder Assembler oder Java oder sonstwas kann, sondern weil er denken kann (...oder weil er aufgepasst hat, als es in der Uni beim Thema Rekursion/Iterative Verfahren das typische Fibonacci-Beispiel gab). Das ist also ein ganz wunderbares Beispiel dafür, dass die Programmiersprache bezüglich der Performance nicht so relevant wie der Programmierer ist. Die Wahl der Programmiersprache ändert nicht die zeitliche Komplexität der gewählten Algorithmen.

Xin

Gregor schrieb:

Naja, wenn hier schon so ein Simpel-Beispiel dafür gebracht wird, wie einfach man unperformanten Code schreiben kann...

[Code...Benchmark]

Das C++ Kompilat braucht 37 Sekunden, das Javaprogramm 41. Das C++-Programm ist hier also etwa 10% schneller. ...hui, das bewegt die Welt und sollte in jedem Fall der entscheidende Faktor bei der Wahl der Programmiersprache sein, heh? Naja, glaube nicht. Aber um es mal auf den Punkt zu bringen: Hier ist Java offensichtlich nicht bedeutend langsamer.
Also: Zeigt mal, wo Java lahm ist.

Hmm... kann es sein, dass Du die letzten Seiten Postings gar nicht gelesen hast und Dein Posting daher voll am Thread vorbeigeht?
Nur so ein Gedanke... kann auch sein, dass ich nicht bemerkt habe, auf welches Posting Du Dich beziehst.

Aber... wenn Du unbedingt ein Benchmark diskutieren möchtest...
Welches Deiner beiden Programme verbrauchte effektiv mehr Speicher, um das Ergebnis zu produzieren?

Es ist unsinnig, mit Java gegen C/C++ anstänkern zu wollen, weil Java in diesen Disziplinen immer den kürzeren ziehen wird. Die Frage, wo Java langsamer ist, hast Du mit Deinem Benchmark selber belegt. 4 Sekunden zu ignorieren, bedeutet nicht, dass es gleich schnell ist. Insbesondere bedeutet es, dass Java nicht erste Wahl ist, wenn es um Resourcen geht, dein Dein Benchmark belegt ja, dass C++ schneller ist und damit in Deiner Fragestellung 1. Wahl.
Das dann als Erfolg verkaufen ist dann doch eher amüsant.

Wenn Du Java magst, was Dein gutes Recht ist, erfreue Dich an den Vorteilen der reichhaltigen Standardbibliotheken, die Dir als Java-Entwickler teilweise schnellere Ergebnisse liefern, aber versuch bitte niemanden zu überzeugen, dass Java bzgl. Resourcenverbrauch mit C/C++ mithalten könnte. Das wird immer nach hinten losgehen.

10% kann den Unterschied machen, ob ich einen zusätzlichen Server kaufen muss oder nicht und alle Folgekosten dazu tragen muss, die nicht erforderlich wären, wenn das Programm 10% schneller laufen würde. Wenn der Mehrverbrauch an Speicher dazukommt, entscheidet sich das evtl. noch schneller gegen Java.
Bei Aufgaben, die 10 Tage Rechenleistung fordern, sind 10% ein Tag. Das bedeutet hier, dass die vom Ergebnis abhängigen Arbeitnehmer einen Tag früher Ergebnisse haben und weiterarbeiten können. Die Rechenanlagen sind in der Regel auch nicht billig. Wenn die 10% mehr erledigen können, erzeugen die Rechner auch 10% mehr Ertrag. Wenn ein BWLer 10% mehr Ertrag hört, wird der Dir sagen, mit welcher Sprache Du ein echtes rechnerisches Programmierproblem zu lösen hast.

Wenn Du also von Deinem privaten Interesse an Primzahlen mal wegrückst, wirst Du vielleicht erkennen, dass es nicht nur HeimPCs und Anwendungsprogrammierung gibt, wo "nur" ein Privatmensch etwas kostenlose Freizeit verliert, weil er 10% länger vor dem Computer warten muss und sich ja 'ne neue CPU kaufen kann. Kostet heute ja nix mehr.
Angenommen jeder hätte einen Rechner, dann wären das hier rund 800 CPUs. An meinem Schreibtisch stehen 3 Rechner. Aber Kostet ja nix mehr.

Als Privatmensch mache ich gelegentlich Bild- und Videobearbeitung. Da interessieren mich 10% auch als Privatmensch schon, entsprechend kaufe ich das Produkt, dass schneller rechnet.

Manuelh87

du musst auch die auslastung usw... dazunehmen.. der benchmark zeigt nicht wirklich was... nochdazu steht auch nicht mit welchem compiler und wie optimiert wurde... das spiel ja alles eine rolle... würds ja selbst testen, aber hab keinen java compiler. Hast du java als exe compiliert oder ganz normal mit der virtual maschine laufen lassen?? denn man kann auch eine exe erzeugen (bei msj++ zum beispiel)..

Zeig mir einen java compiler der frei ist und den ich verwenden kann und ich zeigt dir wie das ergebniss mit nem guten c++ compiler und den besten einstllungen aussieht... dann geh ich doch von mehr als 10% unterschied aus... unter umständen.

Außerdem sagt ja niemand das du nicht java verwenden sollt und darfst. Nur probiert mit bitte nicht zu erklären dass java c++ überholt weil es Runtime-optimieren kann.. das ist BLÖDSINN.
Warum hab ich ja schon erklärt...

[edit]
@Gregor:
dein code für c++ ist fehlerhaft... muss noch schauen warum... aber er ist es.
der code ist leider recht kompliziert (shifts) weiß ned wielange das dauern wird...

[edit]
naja war nicht fehler haft aber naja bisl viel am stack... hab das mal ausgelagert also heap...

mfg Manuel

Oh das ist ja mal etwas interessantes ein vergleich zwischen Java und C++. Sowas habe ich ja noch nie gelesen.

JBeni

JBeni schrieb:

JBeni schrieb:

Über die seltsam unflexible, problemverursachende, unangepasste Pseudo-Verwaltung von Speicher bei der JVM, möchte ich mich lieber ausschweigen...

Warum? Reden ist Silber, Schweigen ist Gold?

Das System ist IMHO der grösste Nachteil der JVM, deshalb schweige ich.

Da stichel ich noch ein wenig...
Das wichtigste Merkmal von Java ist die JVM und die JVM ist der größte Nachteil von Java. Damit ist das wichtigste Merkmal von Java ein Nachteil, wenn ich das grade richtig verstehe!?

Jein.
Zum einen kann die VM den Code während der Laufzeit optimieren, was ohne nicht (es sei denn das OS spielt mit) oder nur schwer möglich wäre. Wieviel diese Optimierungen verglichen zum Overhead bringen, ist ein anderes Thema, verlässliche Statistiken kenne ich nicht.
GC ist kein Argument für eine VM, er würde auch ohne funktionieren.
Portierbarkeit: dass man sich beim Schreiben eines Programmes immer sicher sein kann, dass ein "int" 32 bit big endian ist, egal was man damit macht oder wo man ihn hinschreibt, empfinde ich als Vorteil.
Die seltsame Speicherverwaltung ist kein prinzipielles Problem einer VM, sondern ein speziefisches Problem der JVM. Insofern kann sich da durchaus mal was ändern in Zukunft. Dass die JVM laufend verbessert wird, bemerkt man ja bei jedem Release.
Die VM bietet Vor- und Nachteile (wär hätte das gedacht), nur welche wichtig und welche nicht so bedeutend sind, ist nicht klar. Da meine Programme auf vielen verschiedenen OS laufen müssen, teils solche die ich selbst nicht besitze, ist für mich die (einfache) Portierbarkeit des Codes sehr wichtig.

JBeni schrieb:

Stimmt. Aber wo ist das Problem - weigern sich Programmierer bzgl. GUI-Frameworks dazuzulernen?

Hoffentlich nicht *g*. Aber man kann ein Framework nicht in einem Tag kennen lernen. Wenn dann Wochen auf kennen lernen + coden + debuggen + etc. draufgeht ist das nicht so dolle.

Hmm.. wie sollte man sonst das Know-How steigern, dass die Firma anbieten kann?

Es gibt ja auch noch anderes zu lernen. Neue Datenbanksysteme, neue Eingabegeräte, wie man GUIs besser benutzbar macht, und und und.... alles kann man nicht lernen, dann sollte man die Zeit nicht für etwas verschwenden das man einfacher haben könnte/gar nicht benötigte.

JBeni schrieb:

Java 1.6 hat GARANTIERT ein Schlüsselwort, um Klassen zu verschachteln...

...

Ok, wir diskutieren auf verschiedenen Ebenen. Hab erst jetzt kapiert, wie du das meinst.

Die Zeitverzögerung wird bei vielen Problemen nicht groß auffallen, aber es bleibt dabei, dass Java bei jedem Zugriff zwei zusätzliche Takte verbrät, was in Schleifen oder vielen derartigen Zugriffen innerhalb von Schleifen sich schon zu bemerkbaren Sekunden zusammenaddieren kann.

Hm, 2 GHz / 2 = 1'000'000'000 Schleifendurchläufe für eine zusätzliche Sekunde. Hm, selbst eine leere Schleife benötigt schon ein Zeitchen um das durchzugehen (um die 15 Sekunden auf einem 600Mhz-er).
Wenn du Lust hast kannst du das gerne weiter ausprobieren, aber aussagekräftig ist es nicht. Es lässt sich auch irgendwas finden, wo Java schneller als C++ ist, genauso nichtssagend.
Aussagekräftiger wären da Tests die Geschwindigkeiten verschiedener komplexer Algorithmen messen.

Da die meisten Programmierer aber nicht fähig sind, sehe ich häufig beim ersten hinschauen, die Fehler im Sourcecode.

Das SchlagInDasGesichtGefühl?

b) es ist effizienter erst zu denken, dann zu programmieren. Selbst wenn man effizient Fehler findet, ist es ein tierischer Aufwand, den man sich in 90% der Fälle hätte sparen können, wenn man nicht einfach programmiert hätte nach dem Motto 'Wird schon passen'.

Selbst mit viel Erfahrung kann man nicht fehlerfreien Code schreiben (auch wenn ich dir ohne weiteres ein Verhältnis wie 1 Fehler / 5000 Zeilen zutraue).

JBeni schrieb:

schreib' mir eine PM

Funktioniert in diesem Forum nicht.

Wenn Du mir schreiben möchtest, wirst Du meine E-Mail-Adresse sicherlich rausfinden.
Ansonsten: fnfpun@ngebcf.pbz
Rot13 ist Dein Stichwort.

Maaaaaaaaaan, es geht nicht darum dass ich dich nicht finde. Es geht darum, dass ich einen Fehler in deinem Post gefunden habe

Gregor

Manuelh87 schrieb:

du musst auch die auslastung usw... dazunehmen.. der benchmark zeigt nicht wirklich was... nochdazu steht auch nicht mit welchem compiler und wie optimiert wurde... das spiel ja alles eine rolle... würds ja selbst testen, aber hab keinen java compiler. Hast du java als exe compiliert oder ganz normal mit der virtual maschine laufen lassen?? denn man kann auch eine exe erzeugen (bei msj++ zum beispiel)..

Zeig mir einen java compiler der frei ist und den ich verwenden kann und ich zeigt dir wie das ergebniss mit nem guten c++ compiler und den besten einstllungen aussieht... dann geh ich doch von mehr als 10% unterschied aus... unter umständen.

[...]

[edit]
@Gregor:
dein code für c++ ist fehlerhaft... muss noch schauen warum... aber er ist es.
der code ist leider recht kompliziert (shifts) weiß ned wielange das dauern wird...

mfg Manuel

AFAIK kommen einige C++ Compiler nicht mit dem großen Array zurecht. Dann müsstest du das auf dem Heap erzeugen. Ansonsten würde mich der Fehler sehr interessieren. ...und zeig mal, was du aus dem Programm noch so rausholst.

...zu den genutzten Compilern, JVM:

gregor@linux:~/JavaProjects/Test/TestPrime> g++ --version
g++ (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gregor@linux:~/JavaProjects/Test/TestPrime> /usr/java/jdk1.6.0/bin/java -version
java version "1.6.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-rc-b67)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b67, mixed mode, sharing)

Ich weiß jetzt nicht, was du unter "frei" verstehst. Die JVM kannst du dir zumindest kostenlos ohne Registrierung und inklusive Quellcode runterladen. Du darfst den Quellcode nur nicht verändern und dann deinerseits irgendwo veröffentlichen:

https://mustang.dev.java.net/

...naja, interessant, wie ihr so einen 10% Unterschied bewertet. Ich sehe das anders. Aber ich glaube nicht, dass wir uns da irgendwie einigen können. Also sollten wir das besser lassen.

Manuelh87

hab ich ja schon klargestellt; war kein echter fehler... obwohl man normalerweise solche mengen nicht auf den stack haut...sondern eben am heap anlegt... aber glaube das könnte man einstellen;

naja ab wieviel prozent bei dem gleichen algo würdst den meinen das der unterschied trastisch ist?

mfg Manuel

java\1:resize_message schrieb:

Oh das ist ja mal etwas interessantes ein vergleich zwischen Java und C++. Sowas habe ich ja noch nie gelesen.

Vor allem solch kompetente Äußerungen von "Experten" wie Manuelh87 und SIDEX sind mal was ganz neues

Gregor

Manuelh87 schrieb:

hab ich ja schon klargestellt; war kein echter fehler... obwohl man normalerweise solche mengen nicht auf den stack haut...sondern eben am heap anlegt... aber glaube das könnte man einstellen;

naja ab wieviel prozent bei dem gleichen algo würdst den meinen das der unterschied trastisch ist?

mfg Manuel

Hmmm... Wenn man das Array auf den Heap legt, wird das C++ Programm übrigens noch ein bischen langsamer. ...so schwinden die Prozente dahin. ...ein "macht man nicht so" und schon ist man noch ein Stückchen näher am Java-Level dran.

...hab die Obergrenze mal etwas erhöht.

gregor@linux:~/JavaProjects/Test/TestPrime> ./TestPrime
Zwischen 0 und 2000000000 liegen 98222287 Primzahlen.
GesamtZeit : 82 Sekunden
gregor@linux:~/JavaProjects/Test/TestPrime> /usr/java/jdk1.6.0/bin/java -Xmx384m TestPrime
Zwischen 0 und 2000000000 liegen 98222287 Primzahlen.
GesamtZeit : 86568 Millisekunden

...nur noch 5%. Naja, egal: Aus meiner Sicht ist es irrelevant, ob es 5% oder 10% sind. Ich halte es in beiden Fällen für nicht erwähnenswert und repräsentativ ist es natürlich auch nicht.

Du willst wissen, welche Abweichung bei der Performance ich für relevant halten würde? Naja: Am Anfang war Java um einenFaktor 100 langsamer als C++. da wurde es komplett interpretiert und natürlich galt es da als lahm. Später war es um einen Faktor 10 langsamer und natürlich galt es da immer noch als lahm. Noch später war so ein Faktor 2-4 drin und da fängt es dann schon an, für viele Dinge interessant zu werden. Jetzt ist es fast an der Performance von C++ dran und da gibt es dann aus meiner Sicht kaum noch Anwendungen, für die ein derartiger Unterschied noch relevant ist. Es kommt natürlich immer auf die spezielle Anwendung an und wenn man ein Programm hat, das tagelang rechnen muss, dann wird so ein Unterschied relevant. Aber das betrifft nicht sooo viele Programme. Für viele Anwendungsgebiete ist ein Faktor von 2 bis 4 durchaus akzeptabel, aber ich würde einsehen, dass man in diesem Bereich durchaus sagt, dass einem das zu langsam ist. Wenn der Geschwindigkeitsunterschied auf einen Faktor unter 2 absinkt, kann dieser Aspekt für die meisten Anwendungsgebiete IMHO nicht mehr ausschlaggebend sein. Bei 10% geht so ein Unterschied doch völlig neben irgendwelchen suboptimalen Algorithmen oder so unter. Man darf ja auch nicht vergessen, dass die Menschen, die davor sitzen, nicht das letzte aus der Sprache herausholen. ...die in den beiden Programmen realisierte Version des Siebs des Erathostenes ist ja auch nicht unbedingt optimal. Ich hatte das auch schonmal mit entsprechendem Aufwand deutlich stärker optimiert und habe da dann auch noch mehr als 10% rausgeholt. ...eher 50% oder so. Ich erinnere mich da nicht mehr so genau dran.

EDIT: Frag mal Optimizer! Vielleicht erinnert der sich noch besser daran.

@Optimizer: *SCNR*

Manuelh87

ich fühle mich ja geehrt das du mich als Experte bezeichnest...

das hab ich allerdings nie von mir behauptet, also: Aufforderung an alle: "Bessert mich bitte aus wo ich fehler gemacht habe!"

Das soll jetzt kein Angriff sein... werd auch garantiert nichts dummes (also in meinem fall garnichts) darauf antworten.

mfg Manuel

Gregor

java\1:resize_message schrieb:

Oh das ist ja mal etwas interessantes ein vergleich zwischen Java und C++. Sowas habe ich ja noch nie gelesen.

Oh, sorry, aber die anderen waren das letzte mal noch nicht da. Mir ist klar, dass es diesen Gesprächsverlauf schon diverse male hier gab. ...und ich nutze sogar die gleichen Benchmarks, die ich schonmal genutzt hatte.

...tja: Ich schreib halt wiederverwendbaren Code.

Xin

JBeni schrieb:

JBeni schrieb:

JBeni schrieb:

Über die seltsam unflexible, problemverursachende, unangepasste Pseudo-Verwaltung von Speicher bei der JVM, möchte ich mich lieber ausschweigen...

Warum? Reden ist Silber, Schweigen ist Gold?

Das System ist IMHO der grösste Nachteil der JVM, deshalb schweige ich.

Da stichel ich noch ein wenig...
Das wichtigste Merkmal von Java ist die JVM und die JVM ist der größte Nachteil von Java. Damit ist das wichtigste Merkmal von Java ein Nachteil, wenn ich das grade richtig verstehe!?

Jein.

Also nicht nein... :->

JBeni schrieb:

Zum einen kann die VM den Code während der Laufzeit optimieren, was ohne nicht (es sei denn das OS spielt mit) oder nur schwer möglich wäre. Wieviel diese Optimierungen verglichen zum Overhead bringen, ist ein anderes Thema, verlässliche Statistiken kenne ich nicht.

Ich auch nicht. Da ich auch nicht so programmiere, kann ich den Vorteil grade nicht einschätzen, da zur Laufzeit selten Klassen austausche, die ich zur Compilezeit nicht dafür vorgesehen habe.

JBeni schrieb:

Portierbarkeit: dass man sich beim Schreiben eines Programmes immer sicher sein kann, dass ein "int" 32 bit big endian ist, egal was man damit macht oder wo man ihn hinschreibt, empfinde ich als Vorteil.

Hehehe, Dir ist aber schon klar, dass eine Klasse 'bigEndian' im Aufwand etwa so kompliziert ist, wie ein Hallo World?

Hier sehe ich den Vorteil also irgendwie quasi gar nicht. Insbesondere auf Prozessoren nicht, die LittleEndian arbeiten und bei jedem Schritt erstmal selber umrechnen müssen. Ein int ist quasi eine Black-Box, die einen Wert repräsentiert. Man bearbeitet die BlackBox mit Operatoren und ansonsten nix damit zu tun.
Das Problem ist damit nicht das aktuelle System - das Problem tritt ja nur ernstzunehmenden auf, wenn Du zum Beispiel ein TIFF-Loader schreibst. Da weißt Du nämlich nicht, ob Du gleich Little oder Big Endian geliefert bekommst und musst genauso umbauen, wie in C.

JBeni schrieb:

Die seltsame Speicherverwaltung ist kein prinzipielles Problem einer VM, sondern ein speziefisches Problem der JVM.

Wo wir ja schon festgestellt haben, dass ich die GNU-JVM nicht nutzen darf, weil sonst Eclipse abschmiert und Java ohne JVM irgendwie auch witzlos ist. Fehler bei Zeigern sind auch nicht das Problem der Sprache, sondern des Programmierers, aber ohne Programmierer ist die Sprache auch witzlos ^^
Probleme der JVM sind also definitiv Probleme, die sich auf Java auswirken.

JBeni schrieb:

Da meine Programme auf vielen verschiedenen OS laufen müssen, teils solche die ich selbst nicht besitze, ist für mich die (einfache) Portierbarkeit des Codes sehr wichtig.

Und hier geht ein unbestrittener Punkt an Dich.

JBeni schrieb:

Aber man kann ein Framework nicht in einem Tag kennen lernen. Wenn dann Wochen auf kennen lernen + coden + debuggen + etc. draufgeht ist das nicht so dolle.

Hmm.. wie sollte man sonst das Know-How steigern, dass die Firma anbieten kann?[/quote]
Es gibt ja auch noch anderes zu lernen. Neue Datenbanksysteme, neue Eingabegeräte, wie man GUIs besser benutzbar macht, und und und.... alles kann man nicht lernen, dann sollte man die Zeit nicht für etwas verschwenden das man einfacher haben könnte/gar nicht benötigte.[/quote]

Dem kann ich kaum widersprechen und wie ich sagte, sind die Standardlibs eigentlich der Vorteil, den Java hat.
Es ist bedauerlich, dass sich da für C/C++ immernoch keiner dran gesetzt hat, um so weitreichend mal was anzubieten.
Stünde eine IBM hinter C++ und würde C++ pushen, wie Sun Java pusht und MS C# pusht, dann hätten wir wieder faire Verhältnisse und würde sich auf Qualitäten der Sprache beschränken können.

JBeni schrieb:

Hm, 2 GHz / 2 = 1'000'000'000 Schleifendurchläufe für eine zusätzliche Sekunde. Hm, selbst eine leere Schleife benötigt schon ein Zeitchen um das durchzugehen (um die 15 Sekunden auf einem 600Mhz-er).
Wenn du Lust hast kannst du das gerne weiter ausprobieren, aber aussagekräftig ist es nicht. Es lässt sich auch irgendwas finden, wo Java schneller als C++ ist, genauso nichtssagend.
Aussagekräftiger wären da Tests die Geschwindigkeiten verschiedener komplexer Algorithmen messen.

Normal... aber da gibt es soviele Dinge, die die Aussage wieder verfälschen, von daher beschränke ich mich auf die tatsächlichen Features.
C++ ist definitiv schneller. Es hat Nachteile in der Speicheralloziierung, die bei C++ über das OS (Syscall...) abgewickelt wird, wo Java sich aus dem Heap bedienen darf. Damit ist Java schneller fertig, weil es nach dem Alloziieren weiterarbeiten darf, während C++ unterbrochen wird, bzgl. Rechenzeit liegt C++ aber soweit ich weiß, weiter vorn. Das kann man notfalls mit einem MemoryPool umgehen, dann ist C++ wieder oben auf.

Es bleibt Frage der Machbarkeit: Es ist nicht machbar, schneller als Assembler zu werden. C ist nah dran, C++ arbeitet sich an C ran und Java kann gut programmiertes C++ nicht erreichen.

Da die meisten Programmierer aber nicht fähig sind, sehe ich häufig beim ersten hinschauen, die Fehler im Sourcecode.

Das SchlagInDasGesichtGefühl?

JBeni schrieb:

Selbst mit viel Erfahrung kann man nicht fehlerfreien Code schreiben (auch wenn ich dir ohne weiteres ein Verhältnis wie 1 Fehler / 5000 Zeilen zutraue).

Danke, aber das wäre zuviel der Ehre. Es gibt genug, die besser als ich sind.

JBeni schrieb:

schreib' mir eine PM

Funktioniert in diesem Forum nicht.

Wenn Du mir schreiben möchtest, wirst Du meine E-Mail-Adresse sicherlich rausfinden.
Ansonsten: fnfpun@ngebcf.pbz
Rot13 ist Dein Stichwort.

Maaaaaaaaaan, es geht nicht darum dass ich dich nicht finde. Es geht darum, dass ich einen Fehler in deinem Post gefunden habe [/quote]

Roar

Xin schrieb:

Als Privatmensch mache ich gelegentlich Bild- und Videobearbeitung. Da interessieren mich 10% auch als Privatmensch schon, entsprechend kaufe ich das Produkt, dass schneller rechnet.

nur um darauf mal zurückzukommen
warum ist dann gerade maya, ein java programm, eines der marktführenden programme für 3d modeling, animationing und rendering in der industrie
ich weiß, das ist nicht vergleichbar mit gelegentlicher bild- und videoverarbeitung. aber nur mal so als beispiel.

ps: vergurkter thread hier

Gregor schrieb:

EDIT: Frag mal Optimizer! Vielleicht erinnert der sich noch besser daran.

@Optimizer: *SCNR*

Das werd ich dir nie verzeihen.

mathik

SideWinder schrieb:

Ich habe mit 19 auch noch Prozessortakte gezählt. Schade, dass das heute keiner mehr macht.

Ich dachte wenigstens an der FH versuchen sie das einem auszureden. Offenbar nicht, wir leben weiterhin in einer kleinkarierten Programmierwelt. Es geht nämlich gar nicht so sehr um das optimalste Ergebnis für einen kleinen Teil sondern um die Abbildung und Abstraktion eines Gesamtsystems am Computer.
MfG SideWinder

ich sehe das genauso.

@manuel87 und @xin
euch ist schon klar, dass um komplexität beherrschen zu können man immer auf höheren abstraktionen aufsetzen muss? ich meine, wetten dass ich in HW viel schnellere programme hinbekomme als ihr mit c++ oder gar asm? die frage ist nur wie lange würde ich und wie lange würdet ihr dafür brauchen. deshalb hat man immer abstraktionen geschafft:
- transistoren
- logische gatter
- mikrocode
- maschinencode
- asm
- betriebssystem
- hochsprachen

und aussagen wie, die programmierer hätten auch in ihren über 500.000 zeilen code takte zählen können um daraus die beste performance rauszukriegen ist einfach realitätsfremd. das mag bei einigen auf wenige zeilen beschränkten algorithmen funktionieren jedoch nicht bei komplexen systemen! da wären wir heute noch auf dem stand aus den 60er jahren...

ich finde z.b. c++ eine geniale sprache, die einem viel freiheiten bietet. zudem kann man dort abstraktionen schaffen, die keine laufzeit kostet (z.b. mit templates). ich programmiere jedoch viel lieber in java, weil ich dort einfach geile bibliotheken und geile entwicklungsumgebungen habe. nichtsdesto trotz hole ich auch einen profiler raus und identifiziere die teile die viel laufzeit kosten. diese kann man dann optimieren.

Gruß mathik

JBeni

JBeni schrieb:

Portierbarkeit: dass man sich beim Schreiben eines Programmes immer sicher sein kann, dass ein "int" 32 bit big endian ist, egal was man damit macht oder wo man ihn hinschreibt, empfinde ich als Vorteil.

Hehehe, Dir ist aber schon klar, dass eine Klasse 'bigEndian' im Aufwand etwa so kompliziert ist, wie ein Hallo World?

Hier sehe ich den Vorteil also irgendwie quasi gar nicht. Insbesondere auf Prozessoren nicht, die LittleEndian arbeiten und bei jedem Schritt erstmal selber umrechnen müssen. Ein int ist quasi eine Black-Box, die einen Wert repräsentiert. Man bearbeitet die BlackBox mit Operatoren und ansonsten nix damit zu tun.

Ich unterstelle jetzt den Programmierern der JVM einfach mal, dass die JVM nicht unnötig Bytes von Ints rumdreht ;), der Geschwindigkeitsverlust also nicht vorhanden ist.
Andererseits, wenns zu Bitoperationen kommt: es gibt nicht mal die Chance eines Problems.
Wennns ums Datei lesen/schreiben geht: was man irgendwo geschrieben hat, kann man auch wieder lesen. Wenn man eine Datei nicht selbst geschrieben hat (oder bestimmte Hardware spezifische Formate einhalten muss), steht das ganze natürlich auf der Kippe.

JBeni schrieb:

Probleme der JVM sind also definitiv Probleme, die sich auf Java auswirken.

Ohne Zweifel.

Es ist bedauerlich, dass sich da für C/C++ immernoch keiner dran gesetzt hat, um so weitreichend mal was anzubieten.
Stünde eine IBM hinter C++ und würde C++ pushen, wie Sun Java pusht und MS C# pusht, dann hätten wir wieder faire Verhältnisse und würde sich auf Qualitäten der Sprache beschränken können.

Das Zusammengesuche von Libs, wenn man mal mehr als einen vector benötigt, stört mich schon bei C++.
Andererseits ist die Java-Library langsam ziemlich überladen. SQL-Befehle in derselben Lib wie GUIs, ein Collectionframework mit seltsamen Klassenhierarchien, naja...
Manchmal wünsche ich mir, da würde mal jemand mit dem Rotstift fett Klassen rauswerfen. Die Vielfalt wird durch eine alles erschlagende Standardlibrary auch nicht gefördert. Also 1/4-Punkt an das C++ Model.

Xin

mathik schrieb:

SideWinder schrieb:

Ich habe mit 19 auch noch Prozessortakte gezählt. Schade, dass das heute keiner mehr macht.

Ich dachte wenigstens an der FH versuchen sie das einem auszureden. Offenbar nicht, wir leben weiterhin in einer kleinkarierten Programmierwelt. Es geht nämlich gar nicht so sehr um das optimalste Ergebnis für einen kleinen Teil sondern um die Abbildung und Abstraktion eines Gesamtsystems am Computer.

ich sehe das genauso.

@manuel87 und @xin
euch ist schon klar, dass um komplexität beherrschen zu können man immer auf höheren abstraktionen aufsetzen muss?

und aussagen wie, die programmierer hätten auch in ihren über 500.000 zeilen code takte zählen können um daraus die beste performance rauszukriegen ist einfach realitätsfremd.

Es ist nicht nur realitätsfremd, vor allem ist es nicht die Aussage, die hier getroffen wurde.

Es zu können halte ich für wichtig. Es im richtigen Moment anzuwenden halte ich für wichtig. Jedes "Hallo Welt" hochgradig zu optimieren ist Schwachsinn und bei aktuellen Entwicklungswerkzeugen nicht sinnvoll umsetzbar.
Wer im Falle der Notwendigkeit, aber nicht zu weiß, wie man benötigte Takte reduzieren kann, hat leider verloren. Von daher ist die Benutzung eines Profilers genau das, was gefordert wird. Damit zeigst du ja eben, dass Du versuchst, auf Resourcen entsprechend Deinen Möglichkeiten zu achten.
Das ist bei der Anwendungsprogrammierung natürlich in der Regel nicht notwendig, da der Computer eh zu 99% auf den Anwender wartet.

---------------------------------------------
Kommen wir nun zu etwas völlig anderem:

JBeni schrieb:

Andererseits, wenns zu Bitoperationen kommt: es gibt nicht mal die Chance eines Problems.

Wenn alles LittleEndian ist oder alles BigEndian, dann gibt es kein Problem.
Probleme gibt es nur, wenn Daten von außerhalb reinkommen und dann spielt es keine Rolle, ob Java grundsätzlich BigEndian nimmt oder wie in C die Sache nicht festlegt.

JBeni schrieb:

Es ist bedauerlich, dass sich da für C/C++ immernoch keiner dran gesetzt hat, um so weitreichend mal was anzubieten.
Stünde eine IBM hinter C++ und würde C++ pushen, wie Sun Java pusht und MS C# pusht, dann hätten wir wieder faire Verhältnisse und würde sich auf Qualitäten der Sprache beschränken können.

Das Zusammengesuche von Libs, wenn man mal mehr als einen vector benötigt, stört mich schon bei C++.
Andererseits ist die Java-Library langsam ziemlich überladen. SQL-Befehle in derselben Lib wie GUIs, ein Collectionframework mit seltsamen Klassenhierarchien, naja...
Manchmal wünsche ich mir, da würde mal jemand mit dem Rotstift fett Klassen rauswerfen. Die Vielfalt wird durch eine alles erschlagende Standardlibrary auch nicht gefördert. Also 1/4-Punkt an das C++ Model.

Ich finde, da verdient keiner 'nen Punkt. Schwierigere Verfügbarkeit ist nicht wirklich besser als überlandene Standards.
Der Vorteil bei C ist lediglich, dass sich nur jemand hinsetzen müsste und einen Standard ausrufen.

Wer Programme nach dem XXX-Standard schreibt, benutzt STL, GTK, folgende Datenbank Interfaces, blablabla. Muss ja nichtmals wichtig sein, aber wenn man hätte eine Anlaufstelle, wo man Informationen finden kann.
Wie bei Java. Ich suche was, surfe bei Sun vorbei und finde, was ich suche - wenngleich manches auch schon unter veraltet läuft.