Die feinen Unterschiede der Programmiersprachen

AW: Programmiersprache (für Neuling) mit GUI

Hades85 schrieb:
C++ wesentlich weniger ressi-lastig als Java, dafür will ich aber ne Quelle sehen!?

Das kommt leider in vielen Bereichen noch hin. Ich kenne eine Firma, die eine Texterkennung geschrieben hat: Erst in Java (lief auf Android schon in Echtzeit bei Bildern etc.), wurde aber in C++ und dann nochmal in C neuimplementiert, weil sich einerseits der Verbrauch deutlich reduziert hat (dadurch auch die Schreib / Lesezeiten deutlich runtergegangen sind) und zum anderen die Performance insgesamt um Größenordnungen gestiegen sind. Jetzt geht 93% der Zeit für das Entpacken des Jpegs drauf (da basteln sie sich grad ne eigene Engine). Wenn sich das nicht so extrem gelohnt hätte, hätte keiner das Ding 3 mal implementiert, da gingen schon einige Stunden drauf.

Anderes Beispiel: Android vs. iOS vs. Windows Phone - das kann man vor allem mit dem hier diskutiertem Auto gut vergleichen. Wenn man ordentlich auf die Hardware optimiert, kann man da richtig viel rausholen. Ein iPhone mit DualCore und 1GB Ram bietet den Androids mit ihren Quads und 2GB+ Ram immer noch gut Paroli.

Und auch wenn man nicht extrem auf die Hardware optimiert (Windows Phone läuft ja schon auf recht vielen Geräten) kann man offenbar ganz gut was rausholen aus schwacher Hardware. Da scheint die JVM unter Android ja nach wie vor das Nachsehen zu haben.
 
AW: Programmiersprache (für Neuling) mit GUI

Autokiller677 schrieb:
Das kommt leider in vielen Bereichen noch hin. Ich kenne eine Firma, die eine Texterkennung geschrieben hat: Erst in Java (lief auf Android schon in Echtzeit bei Bildern etc.), wurde aber in C++ und dann nochmal in C neuimplementiert, weil sich einerseits der Verbrauch deutlich reduziert hat (dadurch auch die Schreib / Lesezeiten deutlich runtergegangen sind) und zum anderen die Performance insgesamt um Größenordnungen gestiegen sind.

Wobei mich dann der nochmalige Umstieg von C++ zu C schon erstaunt.
 
AW: Programmiersprache (für Neuling) mit GUI

antred schrieb:
Obwohl ich kein Freund von Java bin, behaupte ich, das liegt eher am Programmcode als an Java.

Das glaube ich nicht.

JDownloader:
Die GUI ist zäh von vorne bis hinten. Fängt schon damit an, bis das Programm mal endlich gestartet ist.

Eclipse (im Vergleich mit z.B. Visual Studio):
VS startet ein vielfaches schneller. Auch in der Bedienung wirkt es einen ticken flotter.

yEd (generell viele Open Source Software vom Ubuntu SW-Center, welche in Java geschrieben ist):
Man denkt sich sofort "Das Programm ist doch bestimmt in Java geschrieben..." und hat meist auch recht.


Womit wir auch schon am Ende von populärer Desktop-Software seitens Java wären.
 
AW: Programmiersprache (für Neuling) mit GUI

Ach GUI-Anwendungen… das ist einfach nicht Javas Domäne.

Ich habe aber an IntelliJ IDEA zum Beispiel nichts auszusetzen und die basteln gerade eine vielversprechende C++ IDE damit. Man kann wohl auf Grund der Vielzahl furchtbarer Java-GUI-Anwendungen sagen, dass es schwer ist eine solche vernünftig in Java zu implementieren. Davon aber auf die Performance der JVM zu schließen ist Quatsch.
 
AW: Programmiersprache (für Neuling) mit GUI

Ich möchte nochmal ein Aspekt hervorheben aus meinem letzen Beitrag, was ich zu dem Link geschrieben habe: nicht repräsentativ. Numerische Anwendungen sind ein Extremfall. Zuimindestens Java 7 unterstützte meines Wissens nach nicht SIMD Erweiterungen von Prozessoren. Diese kommen aber primär bei numerischen Anwendungen zum Tragen, wie sie in dem von mir angegebenen Link verwendet wurden. Wenn das eine anspruchslose GUI Anwendung mit viel Kontrollfluss-Konstrukten besteht, also quasi per-se langsamer Code ist, fällt der Unterschied dementsprechend geringer aus.

Aber ansonsten möchte ich noch auf einen anderen Aspekt anschneiden: Energieeffizienz. Eine langsame Anwendung mag vielleicht schnell genug laufen, aber wenn sie doppelt soviel Rechenzeit verbrät als eigentlich nötig, ist der Prozessor eben doppelt solange nicht im Tiefschlaf. Das kann bei Mobilnutzern wütende Kommentare über zu schnell entleerte Akkus geben.

Die angegeben Zahlen für das Schlafen und Zahl ausgeben Beispiel kommen mir mysteriös hoch vor. Ich hab zwar jetzt nur die moderne C++11 Variante später im Thread von Fonce ausprobiert, aber die Zahlen die da bei mir rauskommt, sind sehr viel niedrieger:
Private:
60 KB [heap]
40 KB /usr/lib64/libstdc++.so.6.0.19
16 KB /usr/lib64/libc-2.18.so
12 KB /home/kai/tmp/snippets/a.out
12 KB [stack]
8 KB /usr/lib64/ld-2.18.so
8 KB /usr/lib64/libm-2.18.so
8 KB /usr/lib64/libgcc_s-4.8.2-20131212.so.1

Shared:
476 KB /usr/lib64/libstdc++.so.6.0.19
284 KB /usr/lib64/libc-2.18.so
108 KB /usr/lib64/ld-2.18.so
60 KB /usr/lib64/libm-2.18.so
16 KB /usr/lib64/libgcc_s-4.8.2-20131212.so.1
4 KB [vdso]

Da KSysGuard auch einen Gesamtwert, bei dem shared durch die Anzahl der Anwendungen geteilt wird, die den Kram ebenfalls benutzen, komme ich für das C++ Beispiel auf meinem x86-64 Rechner auf einen Verbrauch von 194kB, also fernab der 2,2MB.
 
AW: Programmiersprache (für Neuling) mit GUI

antred schrieb:
Wobei mich dann der nochmalige Umstieg von C++ zu C schon erstaunt.
Die Begründung war (in etwa, ist schon ne Weile her und ich kann selber kein C): Nochmal näher an der Hardware, noch bessere Kontrolle darüber, was exakt gemacht wird und bessere Kontrolle darüber, wann was wo und wie im Speicher geschrieben und gelöscht wird und weniger "Unnötiges" beim Instanziieren bestimmter Datentypen etc.

Wie gesagt, dass Programm geht ganz schön ab (0.5 Millionen Seiten in einer halben Stunde auf einem Desktop PC mit i7 sind halt schon ne Ansage) und ich denke, dass jeder Performance Gewinn auch nochmal monetären Gewinn nach sich zieht.
 
AW: Programmiersprache (für Neuling) mit GUI

Autokiller677 schrieb:
Die Begründung war (in etwa, ist schon ne Weile her und ich kann selber kein C): Nochmal näher an der Hardware, noch bessere Kontrolle darüber, was exakt gemacht wird und bessere Kontrolle darüber, wann was wo und wie im Speicher geschrieben und gelöscht wird und weniger "Unnötiges" beim Instanziieren bestimmter Datentypen etc.

Klingt für mich nach fadenscheinigen Gründen. Du kannst in C++ genauso nah an der Hardware programmieren wie in C, und "Unnötiges" beim Instanziieren von Datentypen fällt nur an, wenn man nicht weiß, was man tut.
 
AW: Programmiersprache (für Neuling) mit GUI

Jack159 schrieb:
Das glaube ich nicht.

JDownloader:
Die GUI ist zäh von vorne bis hinten. Fängt schon damit an, bis das Programm mal endlich gestartet ist.
ach bitte, mein eigenes java programm mit GUI startet in einer halben sekunde...so viel dazu
 
AW: Programmiersprache (für Neuling) mit GUI

Jack159 schrieb:
Eclipse (im Vergleich mit z.B. Visual Studio):
VS startet ein vielfaches schneller. Auch in der Bedienung wirkt es einen ticken flotter.
Dass Eclipse etwas träge ist liegt in der Natur des Plugin-Konzepts und dem Lazy Loading der Komponenten.
 
AW: Programmiersprache (für Neuling) mit GUI

ich stimme ja zu, dass ein algorithmus, den man vernünftig mit gleichem optimierungsaufwand in java und C/C++ implementiert (das ist ein wesentliches kriterium, um belastbare zahlen zu bekommen!), in der regel in C++ etwas schneller ist. was etwas hier bedeuten soll, kann und will ich nicht genau quantifizieren, ich vermute aber im kleinen zweistelligen bereich. es gibt auch einige fälle, wo java dem kompilat eines gcc überlegen ist, weil der maschinencode dynamisch erzeugt werden kann (jit).

ich behaupte aber, dass ein ganz wesentlicher punkt ist, dass java einen höheren abstraktionsgrad hat als C/C++ und man weniger mitbekommt, wo eigentlich die laufzeit verloren geht. wenn man nie selbst ein malloc aufruft und sich nicht bewusst ist, welche codestellen (auch triviale wie z.B. stringkonkatenierung) mallocs verursachen, schreibt man eben leichter ineffizienten code.
 
AW: Programmiersprache (für Neuling) mit GUI

Der Java-Entwickler weiß vielleicht nicht, was ein malloc ist (die meisten vermutlich schon), aber er weiß, dass eine String-Konkatenierung ein neues Objekt erzeugt und das grundsätzlich mit Kosten verbunden ist. Deswegen weiß der Java-Programmierer, dass er bei häufiger Konkatenierung in Folge eben einen StringBuilder anwerfen muss, um zu performen.

In diesen "mehr Ahnung vom Blech"-Storys steckt viel Selbstbeweihräucherung von Low-Level-Entwicklern. Und wenn man schon von der Abstraktion redet, muss man auch erwähnen, dass Abstraktion nichts Schlechtes ist, sondern in der Regel höhere Entwicklungsgeschwindigkeit und bessere Wartbarkeit mit sich bringt. Während die C++-Programmierer noch den richtigen Datentyp suchen, der auf allen Plattformen zum gleichen Ergebnis führt, basteln die Java-Programmierer schon an der eigentlichen Logik, die meiner Meinung nach das Programmieren ausmacht.
 
Zuletzt bearbeitet:
AW: Programmiersprache (für Neuling) mit GUI

Der Punkt bei der String-Konkatenierung ist weniger, dass ein neues Objekt erzeugt wird, sondern, dass ein neues Objekt erzeugt wird, das Speicher auf dem Heap alloziiert. Im Vergleich dazu ist ein neues Objekt auf dem Stack mit ein paar Byte billig.

Dass man in Java in der Regel wahrscheinlich weniger Zeit mit (Speicher-) Debuggen und Typengefrickel vergeudet, stimmt wahrscheinlich.
 
Zuletzt bearbeitet: (typo)
AW: Programmiersprache (für Neuling) mit GUI

Das ist ja schön das zu wissen, um vor wem auch immer zu glänzen, aber wo bitte bringt dir das in deiner täglichen Arbeit den Vorteil?
 
AW: Programmiersprache (für Neuling) mit GUI

Wenn man effiziente Anwendungen schreiben will, muss man sowas wissen. Mit "effizient" meine ich hier: Es ginge nicht um einen Faktor 1.5+ (willkürliche Zahl) schneller, ohne wesentlich mehr Aufwand betreiben zu müssen.

Natürlich ist das in der Praxis oft egal - ob ich in einer Desktopanwendung in einer Sekunde mal 1000 Strings konkateniere oder nicht, merkt keiner.

Da der Code, den ich "in meiner täglichen Arbeit" schreibe, zu großen Teilen laufzeitkritisch / laufzeitlimitiert ist, versuche ich solche Effekte sehr wohl zu berücksichtigen.
 
Zuletzt bearbeitet:
AW: Programmiersprache (für Neuling) mit GUI

maxwell-cs schrieb:
Der Punkt bei der String-Konkatenierung ist weniger, dass ein neues Objekt erzeugt wird, sondern, dass ein neues Objekt erzeugt wird, das Speicher auf dem Heap alloziiert. Im Vergleich dazu ist ein neues Objekt auf dem Stack mit ein paar Byte billig.

Dass man in Java in der Regel wahrscheinlich weniger Zeit mit (Speicher-) Debuggen und Typengefrickel vergeudet, stimmt wahrscheinlich.

Objekte in Java sind grundsätzlich auf dem Heap! Egal ob das eine Referenz auf einer lokale Variable oder eine Instanzvariable ist.

Oder was genau möchtest du uns sagen? :-)
 
AW: Programmiersprache (für Neuling) mit GUI

Exakt, außerdem ändert das nichts daran, dass jeder Java/C# Entwickler weiß, dass in solchen Situationen ein StringBuilder angebracht ist. Selbst wenn man diesen nicht verwendet, macht übrigens soweit ich weiß der Compiler manchmal einfach einen StringBuilder draus ;)
 
Zuletzt bearbeitet:
AW: Programmiersprache (für Neuling) mit GUI

S.Kara schrieb:
C++

- weil es trotz der vielen sonderzeichen logisch ist
- es ein super ide namens RAD Studio gibt
- man zu den problemen bei google hilfe findet
- die GUI kann man im baukasten bauen
- man ist nicht auf die JVM angewiesen
- höhere Leistung
- mehr Möglichkeiten als mit Java

;)
- google gibts nicht nur für c++
- JVM braucht man nicht, stimmt, aber dafür GCC oder LLVM oder dergleichen...
- weil man für eine GUI die in einem Thread läuft auch maximale Performance braucht?
- So 0815 C++ alles andere ist Scheiße Post...
Wahnsinn, wieso nicht gleich mit Assembler starten, wo die Lernkurve noch steiler ist?....
 
AW: Programmiersprache (für Neuling) mit GUI

Hades85 schrieb:
Objekte in Java sind grundsätzlich auf dem Heap! Egal ob das eine Referenz auf einer lokale Variable oder eine Instanzvariable ist.

Oder was genau möchtest du uns sagen? :-)
Unabhängig davon, wo der String lebt, alloziiert er einen zusätzlichen eigenen Speicherbereich auf dem Heap (der Array von chars), und das ist der, von dem ich sprach.

Java ist nicht die einzige Sprache, in der man Strings konkatenieren kann. Für ein javaspezifisches Statement kannst du das inkorrekte "Objekt auf dem Stack" durch "Bytes auf dem Stack" ersetzen.
 
Zuletzt bearbeitet:
AW: Programmiersprache (für Neuling) mit GUI

SymA schrieb:
- google gibts nicht nur für c++
- JVM braucht man nicht, stimmt, aber dafür GCC oder LLVM oder dergleichen...
- weil man für eine GUI die in einem Thread läuft auch maximale Performance braucht?
- So 0815 C++ alles andere ist Scheiße Post...
Wahnsinn, wieso nicht gleich mit Assembler starten, wo die Lernkurve noch steiler ist?....
Klar gibt es für Java ebenfalls gute IDE's und logischerweise läuft C++ auch nicht mit Luft und Liebe. Je nachdem was man machen will, sollte man halt beachten, dass C++ eine höhere Performance hat und weniger Ressourcen benötigt. Auch ist man in Java durch die JVM in den Möglichkeiten beschränkt.
Dass das alles in den meisten Fällen im Desktop-Bereich kein Problem darstellt ist klar, man muss halt nur sein Ziel kennen.
 
AW: Programmiersprache (für Neuling) mit GUI

BlooDFreeZe schrieb:
Selbst wenn man diesen nicht verwendet, macht übrigens soweit ich weiß der Compiler einfach einen StringBuilder draus ;)
Würde ich mich nicht drauf verlassen. Das letzte mal hatte ich das mit Java6 getestet und da gab es dann Leute bei denen es keinen Unterschied in der Performance gab und welche bei denen es teilweise deutliche Unterschiede gab(wie bei mir).
Bei einfachen String Concatenation mit 3 Elementen mach es sich kaum bemerkbar, aber wenn ich 20, 30 Elemente zu einem String machen will ohne StringBuilder, dann kann sich das schon bemerkbar machen.

EDIT:
Auch allgmein würde ich niemals einfach nach dem Motto arbeiten "Ach der Compiler wird das schon wegoptimieren".
Neben dem das man dabei ganz böse falsch liegen kann, führt es oft zu schlechtem Code und wenn man Pech hat schaft man sich damit Sicherheitslücken.
 
Zuletzt bearbeitet:
Zurück
Oben