Fun-Soft - Programmierforum

Autor

Thread - Seiten: [ 1 ] > 2 < [ 3 ]

010
17.04.2006, 20:15 Uhr
(un)wissender
Niveauwart

@Rexy

Zitat:

Das native Sprachen schneller sind als interpretierte, ist eine Tatsache, und auch die Pseudo-Kompilate von Java ändern daran nichts.

Was bringt dich zu dieser Äußerung? Die kann so überhaupt nicht stehen gelassen werden.
Im Gegenteil, Java ist teilweise sehr schnell, manchmal sogar schneller als vergleichbarer nativer Code. Wobei das auch nch immer von der VM und dem Compiler, dem Code und dem Zielsystem abhängt.
Deine generelle Aussage ist in dieser Form kompletter Unsinn, weil veraltet.

Bearbeitung:

Es hängt natürlich auch noch von Bibs ab. Oft werden Bibs-Benchmarks als "Sprachen"-Benchmarks verkauft.

--
Wer früher stirbt ist länger tot.

Dieser Post wurde am 17.04.2006 um 20:16 Uhr von (un)wissender editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

011
17.04.2006, 21:00 Uhr
Reyx
IT-fetischistischer Wurstsalat mit rostigem Berghorn
(Operator)

@mauralix
Da hast du meine Aussage falsch verstanden! Ich wollte damit zum Ausdruck bringen, dass die Leute, die mit Java programmieren, dafür einen Grund haben! Und das es deshalb völliger Unsinn ist, die mit den immer gleichen "Sprüchen" über Performance-Lecks einzupflastern.
Was ich meinte ist, dass man nicht immer in Frage stellen sollte, dass jemand Java nutzt (weil ja C/C++ sowieso viel besser sei und alles), sondern derjenige weiß warum er Java benutzt und dabei genau so berechtigt ist wie jemand, der C, C++, Delphi Language oder was auch immer benutzt!
Meine eigene Meinung sollte da eigentlich gar nicht wiedergegeben werden, zumal ich Java gegenüber eigentlich sehr offen bin

@(un)wissender
Veraltet ist unsinn. Das ist eine generelle Aussage weil sie auf generellen Tatsachen beruht. Optimierer, Pseudo-Compiler, was auch immer -> Begründe mir bitte, wie eine - auch wenn viele Java-Protagonisten das leider nicht sehen wollen, interpretierte Sprache genau so performant sein soll wie nativer Code? Gehen wir von gleichwertig guter Implementierung aus und etwa gleichem Know-How der Programmierer. Wie kommst du dann zu der Meinung, dass das JRE und dein geschriebenes Programm zusammen schneller sein können, als nativer Code?

P.s. @(un)wissender
Das mit dem x und dem y war doch ein Versehen, oder?

EDIT:
Och Mensch ... Jetzt haben wir ja doch schon wieder 'nen C++ vs. Java - Falewar

Dieser Post wurde am 17.04.2006 um 21:01 Uhr von Reyx editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

012
18.04.2006, 08:46 Uhr
(un)wissender
Niveauwart

Zitat:

[...] dass das JRE und dein geschriebenes Programm zusammen schneller sein können [...]

Hä?

Das ist hier eine total sinnlose Diskussion.
Virtuellen Maschinen, also auch .NET, stehen ganz andere dynamische Optimierungmöglichkeiten offen als statischen Compilern. Anpassung an den Cache, heißer/kalter Code, Instruction Set, Aliasing, usw.
Die statischen Compiler können zwar mit PGO auch was machen, aber lange nicht so gut wie VMs.
Garbage Collection ist bei schnellen System mit viel Speicher im allgemeinen Fall schneller als manuelle Speicherverwaltung.

Ich würde vorschlagen du bemühst google ein bisschen so kommst dann schon dahinter.
Und deine Aussage ist veraltet, weil sie nicht mehr stimmt.

Zitat:

Das mit dem x und dem y war doch ein Versehen, oder?

Welches x,y?
--
Wer früher stirbt ist länger tot.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

013
18.04.2006, 10:59 Uhr
Reyx
IT-fetischistischer Wurstsalat mit rostigem Berghorn
(Operator)

Zitat von (un)wissender:

@Rexy

Dieses x/y

Und meine Aussage ziehe ich nicht zurück. Alle Argumente, die du gebracht hast, sind Dinge, dir bei einem guten Programmierer selbstverständlich sind. Garbage Collection ist ein einzige Katastrophe (und ich sehe nicht eine einzige glaubhafte Begründung, warum es performanter sein soll, ständig eine Maschine im Hintergrund laufen zu lassen, die irgendwann wenn es ihr gerade passt den Speicher bereinigt und ihn ansonsten vollgestopft lässt mit Ressourcen, die im Programm längst Vergangenheit sind) und deine ach so tollen Optimierungen basieren letztendlich nur darauf, dass der Programmierer seinen Code so im Zusammenspiel mit der Umgebung aufsetzt, dass sie überhaupt erst nötig (und möglich) werden.

Das Java langsam ist sage ich nicht, aber dass es langsamer ist ja! Und dass sage nicht nur ich sondern das sagen auch
1. die Physik und
2. etliche renommierte Java-Entwickler in ihren Büchern nicht grundlos vorneweg.

Früher war das Argument, Java sei zu langsam -> Weil es das auch war! Bugs machten aufwendige Workarounds nötig und es gab viele Dinge zu beachten, um performante Java-Programme zu schreiben!
Heute aber zu behaupten, es gäbe keinen Unterschied mehr, oder Java sei sogar schneller, ist schlichtweg Unsinn!

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

014
18.04.2006, 11:14 Uhr
(un)wissender
Niveauwart

Mit der Zeit wird vielleicht die Einsicht kommen, mal sehen. Momentan bist du zu verbohrt, als das Argumente (von denen eigentlich von beiden Seiten kein einziges kam, es waren nur Behauptungen) hier helfen könnten.

Zitat:

[...] sind Dinge, dir bei einem guten Programmierer selbstverständlich sind [...]

Ich glaube, du weißt nicht wovon du redest. Auf die Codeanordnung hat der Programmierer keinen Einfluss, auf das Aliasing nur sehr begrenzt, in c gibt es immerhin __restrict.

Von Garbage Collection hast du auch keine Ahnung, schau dir mal Generational Garbage Collection der Stufe 2 an. Da läuft nichts die ganze Zeit. Wenn der Heap kompaktiert wird fallen die Kosten an. Dies geschieht aber eher selten.

Egal, für mich ist das Thema gestorben.
--
Wer früher stirbt ist länger tot.

Dieser Post wurde am 18.04.2006 um 11:15 Uhr von (un)wissender editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

015
18.04.2006, 12:02 Uhr
Reyx
IT-fetischistischer Wurstsalat mit rostigem Berghorn
(Operator)

OK, ich will mich da nicht streiten, aber ich habe halt meine Meinung ...

Für mich ist das ähnlich, als würdest du behaupten, ein unter Bochs emulitertes Windows würde schneller arbeiten als ein natives. Aber gut, jedem das Seine ... Vielleicht bekomme ich ja irgendwann doch noch die Eingebung

Belassen wir es mal dabei, auch wenn ich mal in Frage stelle, er hier verbohrt ist und wer nicht

Dieser Post wurde am 18.04.2006 um 12:13 Uhr von Reyx editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

016
03.05.2006, 14:04 Uhr
RHBaum

Zitat:

Von Garbage Collection hast du auch keine Ahnung, schau dir mal Generational Garbage Collection der Stufe 2 an. Da läuft nichts die ganze Zeit. Wenn der Heap kompaktiert wird fallen die Kosten an. Dies geschieht aber eher selten.

Wer hindert mich dran, sowas mit C/Assembler auch zu bauen ^^ In was werden wohl die Java Entwickler programmiert haben ? Mit C# ??? ^^

Richtig: Einige Sachen grad im Context mit .Net / java etc ... werden da im hintergrund optimiert.
Falsch: In C gibts das nicht (man kann das serwohl selber bauen ... und es gibt sogar GC libs fuer C)

Richtig: Einige Instruktionen von diversen prozessoren sind auf die Java RT angepasst ... oder doch andersrum, die JavaRT nutzt teilweisse erweiterte Prozessorfeatueres um zu optimieren.
Falsch: in C geht das nich (es gehr sehr wohl ... )

In C wenn mans draufanlegt wird man immer schneller wie in java sein, weil man die techniken die Java verwendet nachbauen kann, und dazu iss man noch flexiebler ... weil man nicht an die RT und an die GC's usw gebunden ist ^^

Wenn java so flott ist, warum gibts da noch keine richtigen Spiele im Umfang von Battlefield, Wow Oblivion ..... was in java geschrieben wurde ? Sollte doch dann einfacher sein oder ? warum machen sich die spieleentwickler dann die Muehe und lernen C/C++ ?

Gibts eigentlich schon ne DirectX binding fuer Java ?

Ciao ...

Dieser Post wurde am 03.05.2006 um 14:10 Uhr von RHBaum editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

017
03.05.2006, 16:32 Uhr
Reyx
IT-fetischistischer Wurstsalat mit rostigem Berghorn
(Operator)

Zitat von RHBaum:

Gibts eigentlich schon ne DirectX binding fuer Java ?

Afaik nicht offiziell, aber inoffiziell schon (ich meine, mich da an etwas zu erinnern).

Über dieses Thema braucht man sich aber nicht streiten. Java wird immer langsamer als eine entsprechende native Sprache sein, ebenso wie die Sprachen des .Net-Frameworks. Wer das nicht wahrhaben will ist schlichtweg ein Träumer oder ein Ignorant, der sich auf die Inkompetenz oder Unfähigkeit des agierenden Programmierers beruft.

Dieser Post wurde am 03.05.2006 um 16:33 Uhr von Reyx editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

018
03.05.2006, 16:42 Uhr
xXx
Devil

jojo... seids alles ops... guckt mal auf den titel des threads... aja... wenn de das wirklich machen willst... da gibt es nen paar ganz nette artikel zu... wie man in realtime z.B. die Erdatmosphere rendern kann usw

bsw. hat die TU Wien dazu www.cescg.org/CESCG-2005/papers/Brno-Josth-Radovan/index.html rausgebracht

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

019
03.05.2006, 17:29 Uhr
(un)wissender
Niveauwart

@Reyx

Zitat:

Über dieses Thema braucht man sich aber nicht streiten.

Also hast du recht! Tolles Argument. Aber es stimmt schon, die Fakten sprechen einfach für sich. Schau dir Benchmarks und Papers von 2005/2006 an, lies was über Garbage Collection und Optimierungstheorien im Allgemeinen.

Zitat:

Java wird immer langsamer als eine entsprechende native Sprache sein, ebenso wie die Sprachen des .Net-Frameworks. Wer das nicht wahrhaben will ist schlichtweg ein Träumer oder ein Ignorant, der sich auf die Inkompetenz oder Unfähigkeit des agierenden Programmierers beruft.

Im Gegenteil, zukünftig werden Java und .NET schneller sein. Schon heute ist das teilweise so. Nur weil du behauptest, das könne nicht sein, muss sich die Realität nicht dran halten.

@PHBaum
Deine Theorie des Nachbauens hinkt ganz schön. Klar kannst du immer alles in Perfektion schreiben, aber der Zeitaufwand ist total unrealistisch.

Für Spiele braucht mal oft Kontrolle über Speicher und andere Hardware, die über die angebotenen Javamöglichkeiten gehen. Und im Schnitt ist es auch so, das ein C++ deutlich weniger Speicher frisst. Das macht dann den Unterschied.

Ach ja, und Spiele werde vermutlich demnächst hautsächlich in C# entwickelt.

@all
Gewisse Optimierung kann der (statische) C++-Compiler gar nicht wirklich vornehmen. Bspw. unterstützung der Branch Prediction, spekulatives entfernen von virtual, Aliasing Annahmen, ... Teilweise wird das heute (z.B. gcc 4.1 (glaube ich) und vc++ 8.0, intel compiler) durch PGO erledigt. Die Resultate sind dann aber immer noch statisch. Ändert sich das Nutzungsprofil muss neu kompiliert werden. Java erledigt das dynamisch.
Nur um mal eine Größenordung zu nennen: der SQL-Server von MS soll um 30% schneller geworden sein, nur durch PGO. Und Java ist da halt noch flexibler.

Bearbeitung:

Ach ja und die ganze Geschichte hat mit gutem und schlechtem Programmierer überhaupt nichts zu tun. Wieso auch?

--
Wer früher stirbt ist länger tot.

Dieser Post wurde am 03.05.2006 um 17:31 Uhr von (un)wissender editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

Seiten: [ 1 ] > 2 < [ 3 ] [ Ideen & Projekte ]

ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: