Performance von byte[], short[], int[]..?

[sirbender]

Hallo,

macht es einen Unterschied bei der Laufzeit wenn ich massive Arrays nutzen will?

1. bei der Array-Initialisierung bzw. Garbage-Collection?
2. Iteration
3. wenn ich einzelne Werte auslese bzw. setze?
4. irgendwelche anderen Dinge die ich vergessen habe?
5. wenn ich Operationen mit den einzelnen Werten durchfuehre (+-*/ etc.)


Einen bit-Array gibt es ja nicht in Java. Dafuer ein BitSet. Ist mit einem BitSet die Performance noch einmal besser?

 

[javampir]

idr sollte es keinen unterschied machen, da soweit ich weiß alles implizit in int umgewandelt wird, also sollte es nur bei long nen unterschied machen.
pro takt kannst du eh nur eine operation durchführen, wie breit der wert dann sein kann hängt von deinem system ab (32 bit / 64 bit). alles kleinere braucht trotzdem einen vollen schritt

 

[Thallius]

In dem Moment wo man sich in Java Gedanken über die Performance machen muss, sollte man einfach auf C umsteigen

SCNR

Claus

 

[thecain]

In dem Moment wo man sich allgemein Gedanken über Performance macht, muss man über seinen Code nachdenken, statt an Sprachfeatures/Sprachen

 

[javampir]

sorry, aber die beiden beiräge sind echt unangebracht.

In dem Moment wo man sich allgemein Gedanken über Performance macht, muss man über seinen Code nachdenken

was hat das denn zu tun mit einer frage über die verarbeitung von datentypen?

In dem Moment wo man sich in Java Gedanken über die Performance machen muss, sollte man einfach auf C umsteigen

?? willst du behaupten, man sollte wegen einiger schwierigkeiten und fragen zu performance alle anderen features von java einfach in den ofen werfen?

 

[Thallius]

Ich will damit sagen, dass Java im allgemeinen nicht geeignet ist um mit großen Datenarrays effizient und performant zu arbeiten. Java ist nunmal mit Abstand die langsamste aller Möglichkeiten um mit großen Datenmengen zu arbeiten.

 

[Joose]

macht es einen Unterschied bei der Laufzeit wenn ich massive Arrays nutzen will?

1. bei der Array-Initialisierung bzw. Garbage-Collection?

Zu diesem Thema gab es vor kurzen einem Thread. Bei der Inialisierung von Mehrdimensionalen Arrays muss man auf die Deklarierung aufpassen

int[][] twoDimensions = new int[2][1000000]; // Flott, da nur 2 Arrays mit der Größe 1000000 angelegt werden;
twoDimensions = new int[1000000][2]; // Langsamer, da hier 1000000 Arrays mit der Größe 2 angelegt werden;

 

[JStein52]

Aber Thallius hat doch recht ! Warum jaulen immer alle auf wenn das böse Wort "C/C++" fällt ? Es ist nun mal richtig dass man damit performantere Programme schreiben kann und ich verstehe nicht warum C immer von den Java-Puristen verteufelt wird. Wo es halt notwendig ist sich Gedanken über Performance zu machen muss man ganz nüchtern die Vor- und Nachteile der zu verwendenden Programmiersprache abwägen. Und wenn schon gefragt wird ob short[] oder int[] performanter ist dann scheint die Not ja gross zu sein. Und wenn dann Java dann sollte man natürlich auch so Dinge wie die von Joose erwähnten beachten.

 

[thecain]

sorry, aber die beiden beiräge sind echt unangebracht.

Statt irgendwas zu posten, das man eh nicht versteht oder über sachen nachdenkt, die irrelevant sind, sollte man an seinem Code / Algorithmus arbeiten, damit dieser effektiv ist. Dann sind Sprachfeatures, ausser in Ausnahemfällen sekundär.

ist z.b. so ein Ausnahmefall mit eine "Autoboxingpenalty"

public static void main(String[] args) {
   Long sum = 0L;
   for (long i = 0; i < Integer.MAX_VALUE; i++) {
    sum += i;
   }
   System.out.println(sum);
}

idr sollte es keinen unterschied machen, da soweit ich weiß alles implizit in int umgewandelt wird, also sollte es nur bei long nen unterschied machen.

Ist quatsch. Java ist durchaus in der Lage, 4 Byte in einem 32bit word zu speichern. Bei artihmetischen Operationen ist dann der Fall klar. Der Prozessor ist halt auf 32 Bit optimiert. Wobei bei einem C Struct à la

unsigned char a;
long b;
long c;
long d;

Auch ein padding eingerechnet wird.

Aber ich glaube die wenigsten Java Entwickler sind in der Lage so effektiven C Code zu schreiben, dass er dann schneller ist, als der Javacode, zumal die Differenz nicht sehr hoch sein wird. Um Faktoren verbessert man Algorithmen wenn man von O(n^2) auf O(log(n)) kommt... nicht weil man von Java auf das "performantere" C wechselt.

 

[JStein52]

Aber ich glaube die wenigsten Java Entwickler sind in der Lage so effektiven C Code zu schreiben,

Das sehe ich ganz genau so aber das ist auch ein Problem. Ein Handwerker oder Arzt nimmt auch nicht für jedes Problem das gleiche Werkzeug sondern er weiss was wann zu tun ist. Nur wir Softwareentwickler können das nicht mehr ! Und es hält sich hartnäckig das Gerücht das Javacode ja auch nicht langsamer als C-Code sei. In der Regel stimmt das aber gerade wenn man bestimmte Schnittstellen bedienen muss mit ziemlich harten Anforderungen bzgl. Reaktionszeit ist C das Mittel der Wahl.

 

[MWin123]

Ein Handwerker oder Arzt nimmt auch nicht für jedes Problem das gleiche Werkzeug sondern er weiss was wann zu tun ist. Nur wir Softwareentwickler können das nicht mehr

Irgendwie passt das Beispiel nicht ganz.
Es gibt natürlich Entwickler, die mehrere Sprachen gut beherrschen.

Bin ich jedoch ein Hautarzt und ein Patient hat Zahnschmerzen, dann schicke ich ihn doch lieber zu einem Zahnarzt.

 

[JStein52]

Na siehst du, genau das meine ich ja. Und wenn ich sehe dass ich mit Java bestimmte Dinge nun mal nicht hinkriege schicke ich den Patienten zum C-Compiler. Und ich hatte in meinem Job schon öfter das Problem dass man bestimmte Dinge zwar mit Java versucht hat aber nach einem halben Jahr rumpfriemeln am Algorithmus, an den JVM-Parametern und was weiss ich nicht alles das ganze in C gelöst hat und alles war plötzlich gut. Der Hausarzt kann zwar das meiste behandeln aber eben nicht alles. Und deshalb bin ich dagegen gleich mal die Keule rauszuholen nur weil jemand mal C erwähnt.

 

[JStein52]

Und es ist übrigens schon so dass die Informatikstudenten heute von der FH oder Uni kommen und gar nicht mehr wissen dass es ausser Java noch was anderes gibt.

 

[MWin123]

Bei uns wird im ersten Semester Java gelehrt und wir haben Mikro-Programme für einen simplen Mikro-Prozessor in Maschinen- bzw. Assemblercode geschrieben. Im dritten Semester kommt dann noch Haskell dazu.

Edit: ISO-Prolog ist auch noch Pflicht.

 

[JStein52]

Ja mag sein. Aber ich hatte schon oft genug Bewerber vor mir sitzen die auf die Frage nach C/C++/C# nicht wussten was sie sagen sollten, rumdrucksen und dann schliesslich meinen "Ja aber das benutzt man ja heute eh nicht mehr". Statt dass sie mir erklären können wann man es benutzen sollte und wann nicht. Aber von mir aus können wir das Thema beenden ! Sonst weiss der TE gar nicht mehr wo ihm der Kopf steht

 

[sirbender]

Wow. Da hab ich ja in ein Wespennest gestochen 8(

Mich wundert, dass niemand Fortran erwaehnt. Vor allem der Intel-Compiler spuckt im Allgemeinen performanteren Code aus als C. Meiner Erfahrung nach.

Nur kann man halt auch nicht immer Fortran/C verwenden. Das hat nicht immer was mit Know-How zu tun
http://arstechnica.com/science/2014...can-any-coding-language-top-a-1950s-behemoth/
http://julialang.org/benchmarks

Apropos, ich kenne mich nicht unerheblich bei "scientific computing" aus. Massive Simulationen werden auch heute noch sehr oft mit uralt Fortran/C angetrieben. Und in dem begrenzten Feld wo ich mich auskenne muss ich leider sagen, dass der Code so kaputt ist, dass da eigentlich nur Zufallszahlen rauskommen und dann so lange rumgerechnet wird, bis die Simulation irgendwie auf Daten in der Realitaet "fitbar" ist. Aber von Fortran/C kommt man da halt nicht weg - und nein, ich sage nicht, dass das alle Probleme loesen wuerde.

Beim Thema Klimaforschung kenne ich mich jetzt mit den Simulationen nicht so aus. Laeuft deren Software auch groesstenteils auf Fortran/C? Ich frage mich in letzter Zeit wie belastbar deren Simulationen und damit die Vorraussagen sind.

Ich finde bei Artikeln zu Klimawandel und Co. sollte immer dabeistehen ob das auf empirischen Daten beruht oder auf Simulationen. Ich glaube ja an globale Erwaermung und Klimawandel...aber nur weil man halt sowas wie CO2 PPM messen kann und Eisbohrkerne hat.

Deren Simulationen glaube ich aber nicht die Bohne. Der wird auch nur solange rumgerechnet bis man seine Theorie bestaetigt oder zufaellig empirische Daten nachvollzieht.

 

[Thallius]

Und was willst Du uns damit jetzt sagen?

Das wenn Du das alles in Java programmieren würdest, dann würden die Simulationen stimmen?

 

[sirbender]

Und was willst Du uns damit jetzt sagen?

Das wenn Du das alles in Java programmieren würdest, dann würden die Simulationen stimmen?

Man muss nur genau lesen was ich gesagt habe

Ich zitiere mal: "und nein, ich sage nicht, dass das alle Probleme loesen wuerde".

Und trotzdem: viele Probleme wuerde es loesen. Du glaubst gar nicht wie der F77 Code aussieht. Da wird einem uebel. Sowas kann man mit Java oder auch C# gar nicht machen.

Dann noch ein paar JUnit Tests und die Software waere halbwegs glaubwuerdig.

 

[Thallius]

Das ist doch totaler blödsinn und hat überhaupt nichts mit der Programmiersprache zu tun. Ich kann in C Code schreiben der viel schöner ist als die meisten Java Codes die hier so gezeigt werden. Ich warte teilweise noch Software die ich vor über 20 Jahren in C geschrieben habe ohne Probleme.

Objektiv orientiertes programmieren ist auch nicht immer das gelbe vom Ei und oft auch vollkommen fehl am Platz.

 

[sirbender]

Das ist doch totaler blödsinn und hat überhaupt nichts mit der Programmiersprache zu tun. Ich kann in C Code schreiben der viel schöner ist als die meisten Java Codes die hier so gezeigt werden. Ich warte teilweise noch Software die ich vor über 20 Jahren in C geschrieben habe ohne Probleme.

Objektiv orientiertes programmieren ist auch nicht immer das gelbe vom Ei und oft auch vollkommen fehl am Platz.

Meine Antwort war eine Reaktion auf die anderen Antworten.

In jeder Sprache kann man schrecklichen Code schreiben. Und die Leute die hier so mit C auftrumpfen wegen der Performance sollten dann zu Fortran greifen weil da mit dem richtigen Compiler noch ein paar Prozent rauszuholen sind.

Ich wuerde das aber heutzutage (nicht mehr) machen.

Ich weiss nicht warum du dich aufregst. Mit jeder Sprache kann man schrecklichen Code schreiben. Wobei es manche Sprachen sehr einfach machen. Das merkt man schon wenn man sich C/C++ Buecher durchliest. Meistens haarstraeubend. Es zeigt sich also, dass selbst die Buch-Autoren scheinbar Probleme damit haben.

Mir sind Sprachen relativ egal und ich will diese Diskussion nicht fuehren. In ein paar Jahren juckt das sowieso niemand mehr, weil viel mehr ahead-of-time compiliert wird. Und dann wird auch aus Java direkt Maschinencode den man "sehen" und "anfassen" kann anstatt die Magie des JIT compilers.

LLVM, RoboVM, Google's neue ART Runtime, ...die Zahl waechst. Und die Frage ist dann nur wie gut das LLVM backend fuer deine Sprache ist. Und natuerlich wird eine Sprache die Speicherverwaltung eingebaut hat dann nie genauso schnell sein wie eine die das weglaesst.

 

[klauskarambulut]

Speicherplatz ist immer ein Problem.

Aber das kann man nachmessen mit
http://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html

Ausreichend großes Array mit gewünschtem Typ erstellen, evtl. auch mal Befüllen.
Mit totalMemory() minus freeMemory() von Runtime den Speicherverbrauch berechnen und dann mal hier im Forum Werte posten.

Bit Array entspricht einem boolean-Array. Jedes Feld entweder True oder False wie bei einem Bit. Bitset ist wesentlich Speichersparender und das macht sich bemerkbar.
Solltest du auch mal Durchmessen.

Je weniger Speicher verbraucht wird, desto größer die Performance, da in weniger Schritten mehr Informationen in den Cache geladen und dort vorgehalten werden können.

Bezgl. Performance muss man zwischen AOT und JIT unterscheiden. AOT sorgt dafür dass die VM viel weniger zu tun hat was erstmal gut ist. JIT sorgt dafür, dass zur Laufzeit mit den zusätzlichen zur Laufzeit verfügbaren Informationen effizienter Maschinen-Code erstellt wird. Ersteres ist bei kleinen Programmen von Vorteil, die gestartet werden kurz durchrennen und ein Ergebnis liefern, letzteres zeigt seine stärken bei langlaufenden Berechnungen, Server-Anwendungen usw.

C ist eine Geschichte für puristen. Hier muss man wirklich wissen was man tut, wie man Speicher verwaltet und rein Prozedural zu Ergebnissen kommt.
C++ ist etwas unter dem jeder etwas anderes versteht und niemand weis wie man es nun zu verwenden hat. Es bietet mehr Möglichkeiten als C, bietet aber genauso die selben Möglichkeiten sich ins Bein zu schießen. Jede Software die ich in C++ bisher gebaut habe hat Compilezeiten jenseits von Gut und Böse. OpenCV z.B. halbe Stunde Desktop, 6 Raspi 2 oder Tage auf dem Raspi.

Den besten Kompromiss den ich zur Zeit gefunden habe ist Go. Schnelles Kompilieren, Cross-Kompilieren möglich, statisch gelinktes Binary mit einer Runtime, keine VM, daher schnell, denoch mit Speicherverwaltung und GC, sowie Interface-Konzept das Polymorphie ermöglicht.

 

[Thallius]

Zum Glück wird es immer den embedded Bereich geben wo so etwas nicht passieren wird.

 

[sirbender]

Was meinst du genau mit "statisch gelinktes Binary mit einer Runtime" ?

Ich finde C eigentlich sehr gut wenn man ein paar grundsaetzliche Regeln befolgt.

C++ finde ich ehrlich gesagt immer schlimmer. Ich will das gar nicht erst ausfuehren weil es da so viele Stellen gibt die mich einfach nur noch erschrecken. Steinigt mich ruhig

 

[klauskarambulut]

Folgendes static vs dynamic linking
http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking

Go liefert ein Binary in dem alles drin ist. Ein Go-Hello-World produziert ein Binary das auf linux64 1,7 MB groß ist. Fertig. Da ist dann aber auch alles dabei was es zum laufen braucht. Deployment/Installation ist ein einfaches Kopieren.

In C hat ein Hello World 8-kb. Benötigt aber libc. Und libc in Version 6. Und das kann bei Nicht-trivialen Programmen zum Problem werden, wenn verschiedene Versionen auf einem System benötigt werden.

Mit Runtime meine ich das dort alles dabei ist für Speichermanagement, Nebenläufigkeit und GC ohne den Overhead einer VM mitzubringen.

 

[sirbender]

Ja, libc Abhaengigkeiten finde ich auch uebel. Ich muss mir mal Go und Rust anschauen. Da hoert man ja staendig davon - wobei die Performance noch hinter Java zurueckstehen soll (hab mal irgendwo einen Benchmark gelesen).

Fuer Java koennte sicher auch alles in ein Binary gepackt werden. Also mit AOT. Es muss halt nur jemand entwickeln. Bei RoboVM kann man das heute schon und das ganze fuer iOS, OSX, Linux, usw.

Was produziert eigentlich ART (also die neue Android Runtime) ? Ein einziges ausfuehrbares Binary? Wohl kaum, oder? Da wird es doch sicher Abhaengigkeiten zur Android Platform geben, oder?

Ich finde jedenfalls, dass die Sprache immer irrelevanter wird. Was am Ende rauskommt haengt nicht unbedingt von der Sprache ab, vor allem bezueglich Performance. Sieht man ja auch schoen bei Go, Julia, Android's AOT, RoboVM, usw.