JAVA/C#/C++
-
Optimizer schrieb:
Ahja. Ich schreibe mein Paint natürlich in Assembler, weil das ist ja schneller als C#.
Warum übertreibst Du so?
Ich habe gesagt, für "viele" Anwendungen.
Und eben weil ich diese Art Kommentare kenne, habe ich bewusst die Zusammenarbeit mit dem Framework mit einbezogen.
Und für ein Zeichenprogramm, wie Photoshop, wurden Zeitweise übrigens extra PCI-Karten verkauft, die nichts weiter konnten, als die Arbeit mit diesem Programm zu beschleunigen.
Für mich ist Geschwindigkeit nicht das einzige Kriterium, aber immerhin ein Wichtiges.
Und selbst wenn ein einzelnes Programm gerade so noch flüssig läuft, gibt es einige Leute, die mehrere Programme nebeneinanderlaufen lassen möchten und trozdem noch Leistungsreserven haben möchten.
Aber nein, warum sich darum scheren.Dazu gibt es ja Motherboards mit mehr als einer CPU.
-
Ich finde es einfach übertrieben, wie schon von Anfang an auf die Performance geachtet wird. Da kommen (jetzt nicht auf dich bezogen!) totale Anfänger daher und sagen: "Hey, welche Programmiersprache soll ich lernen? Ich habe gehört, dass C++ am schnellsten ist. Stimmt das?"
Das ist doch lächerlich, solchen Leuten muss man vor Augen führen, dass der bei weitem allergrößte Teil der Performance von dem Typen vorm Monitor abhängt. Natürlich glaub ich das schon mal, wenn in Java die Swing-GUI langsam ist, etc. Aber es gibt immer eine "bessere" Lösung (wenn man C++ jetzt mal als "nicht gut" darstellen würde), als alles in C++ oder C zu coden. Du kannst bestimmte Teile Native coden. Die GUI ist z.B. in C#.Net auch keineswegs irgendwie träge.
Ich finde solche generellen Aussagen einfach für den Allerwertesten. Vielleicht spare ich mir auch die halbe Entwicklungszeit und dafür braucht mein selbstgebauter ICQ-Client ne Sekunde länger zum Starten. Dafür läuft er auch auf Linux. Über sowas denkt aber keiner nach. C++ ist schneller (diese Verallgemeinerung ist sowieso falsch), also code ich C++.
-
Artchi schrieb:
Der Witz an der Sache ist, das Java für eine TIFF-Datei auf einem Pentium4 mit 2 GHz mehrere Sekunden benötigt, um diese entsprechend zu decodieren. Diese Grafik ist ca. 1600x1200 groß und s/w.
Da es in der Standardbibliothek von Java keine Möglichkeit gibt, TIFFs zu laden, würde mich interessieren, wie du das machst. JAI? Eigene Implementation? Ganz andere Bibliothek?
Grundsätzlich liegt so ein Problem nicht an Java, sondern an einer schlechten Implementation des Algorithmus. Wenn dir die genutzte Bibliothek zu lahm ist, dann nutze halt ne andere oder schreib das ganze selbst. Wenn es schon dein eigener Code ist, dann optimier ihn mal. Vielleicht hast du einfach vergessen, irgendetwas zu puffern oder so. Wer weiß.
-
kingruedi schrieb:
2. GULP ist nicht representativ und zweitens ist es jeden Monat anders, mal ist C++ vorne, mal Java und manchmal sogar COBOL...
Hmmm... COBOL war lange nicht mehr vorne.
Es mag sein, dass Gulp alleine nicht repräsentativ ist, aber wenn du dir diverse Jobbörsen etc. im Netz anguckst, dann wirst du schnell feststellen, dass an Programmiersprachen-Skills in erster Linie Java und C++ gesucht werden. Alle anderen folgen mit einigem Abstand.
-
Wir streben ein rundenbasierendes Strategiespiel an und da interessiert Geschwindigkeit schon...ich habe keine Luste mehrere Minuten auf die Züge der AI zu warten (Civilization 3 (hat das wer?) läßt grüßen...)
-
UNeverNo schrieb:
Wir streben ein rundenbasierendes Strategiespiel an und da interessiert Geschwindigkeit schon...ich habe keine Luste mehrere Minuten auf die Züge der AI zu warten (Civilization 3 (hat das wer?) läßt grüßen...)
Ihr wollt also Civilization 3 programmieren und wisst nicht mal welche Programmiersprache zu verwenden??
Na dann viel Spass! Post doch in 5 Jahren noch mal, wie weit ihr seid...
-
Nö nicht Civ3, was neues. Und wir wissen schon, daß es ein paar Jährchen dauern wird
Aber was wäre für die konkrete Anwendung nun das Beste?
-
warum sind es eigentlich immer die Spiele-Progger [sic] die immer wegen der Geschwindigkeit so besorgt sind, gerade bei so einem Spiel, kommt es auf 1 ms mehr oder weniger nicht an.
btw. natürlich würde ich das Spiel in C++ machen, weil ich es besser in C++ machen könnte, als zB. in Java. Aber generell würde ich empfehlen, dass man einfach die Sprache nimmt, die man am besten beherscht und wenn man dann doch noch Angst um die Geschwindigkeit von zB. seiner Java Anwendung hat, dann nimmt man einfach den GCJ und kompiliert das.
Geschwindigkeit wird idr. durch die verwendeten Algorithmen geholt und nicht durch die verwendete Programmiersprache.
-
Sgt. Nukem schrieb:
Im Prinzip wird da aber nur die ganze Java API reingepackt und mit einer Runtime versehen, d.h. aus Deiner 20 KB class-Datei werden 9 MB - fast so groß wie die Runtime zum Runterladen.
Die Aussage ist aber nicht dein Ernst oder? JBuilderX macht mir aus einem 600KB Jar eine Native Executeable mit 711KB, indem er nur das in die Exe Packt, was du auch benutzt. Du musst ja JDBC Komponenten usw. nicht mitlinken in die Exe, wenn du sie nicht brauchst.
-
Ich würd einfach auf http://www.99-bottles-of-beer.net// gehen und mir irgendeine der dort aufgeführten Sprachen auswählen.