dawurde gesagt, dass single rechnungen schnellersein können, aber nicht in delphi. kann mann denn da in c++ mereinstellungen vornehmen und so rechnungen beschleunigen?

und generell: hatt c++ geschwindigkeitsvorteilr (schliesslich sind glaub ich alle Spiele in C++),oder warum nehmen die sonst C++?

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Weil es mittlerweile zu einem völlig veralteten Marketingschlachtruf geworden ist. In meinen Augen ist es vollkommen egal in welcher Sprache (C++ oder Delphi) ein Programm verfasst worden ist. Es wurde schön öffers versucht subjektiv zu Testen was von beiden schneller ist. Nur sind solche Test fern von jeder Realität. Ich habe beruflich sehr viel mit Delphi und C++ zu tun. Und von daher kann ich nur sagen, dass es eher darauf ankommt was DU programmierst als wo die Unterschiede zwischen den Sprachen liegen. Es ist viel wichtiger wie man einen Quellcode schreibt als irgendwelche Unterschiede in der Sprache. C++ ist in manchen Bereichen schneller als Delphi. Keine Frage. Delphi ist wiederum aber aber in manchen anderen Bereichen schneller als C++.

Achte lieber auf das was du programmierst dann ist es egal worin es geschrieben wurde!!

PS: Man kann in beiden Sprachen ein Programm versauen.
Und ich würde das Thema nicht weiter ausholen, da es im "Offtopic" und im "Allgemeinen" schon oft genug durchdiskutiert und geschlossen wurde.


Zu deiner Frage wegen der Genauigkeit. Zu 95% komme ich mit einer Singlegenauigkeit aus. Diese kann allerdings bei gewissen Zahlen eine leichte abweichung beinhalten. Das ist aber meist nicht schlimm. Es wurde aber auch gesagt, dass Delphi Intern so wieso mit Extended arbeitet. Das kann ich allerdings nicht bestätigen oder abweisen. Aber ich meine ich hätte anderweitig auch mal so etwas gehört. Aber wie gesagt. Vom der Geschwindigkeit sollte sich da nichts ändern. Es kommt halt immer darauf an wie genau du es benötigst. Und single ist das fast immer ausreichend. Aber das musst du selber entscheiden.

schankedöhn!!! hatt ich mir schon gedacht, dass die gleichschnell sind.

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Delphi lässt die FPU standardmäßig mit Extended(also 80Bit) Genauigkeit Zwischenberechnungen durchführen. Mit dem Befehl Set8087CW lässt sich jedoch das Control Flag der FPU verändern - man kann also auch Single oder Double Genauigkeit einstellen. Soviel zur fest eingestellten FP-Genauigkeit von Delphi.

Ähh?
wenn ich nu den befehl tippe, ändert der dann auf ne nidrigere ganauigkeit, oder brauch der befehl noch wat hintendrann in klammern (vieleicht den typ single oder extendet oder so) oder so?

hab gerade kein delphi zum testen da. aber bis jetzt hab ich als antwort auch immer bekommen,dass die interne genauigkeit festgestellt ist. verwirrend.

Aber soweit schon mal danke

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Der Auszug aus der Delphi-Hilfe zu SetPrecisionMode sollte die Sache klären :

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

cool bin gespannt ob dat leistung bringt!!! müsste ja logischer weise

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Ich habe das auch gerade mal ins Allgemein verschoben, weil es ja nicht viel mit OpenGL zu tun hat.

Geo: Ich gehe mal sehr stark davon aus, dass du erst einem rechtigen Unterschied festellen wirst, wenn du mehrere Millionen Berechnungen durchführst. So in etwa wie bei dem Aufruf von Round. 100 Millionen Aufrufe davon benötigen auf meinem Rechner (Duron 1.2Ghz) gerade mal knappe 300ms. Lässt sich allerdings nur sehr schwer mit richtigen Berechnungen vergleichen. Es ist nur mal so als Beispiel angedacht um zu zeigen, dass bei solchen Sachen nur recht wenig Zeit verbraten wird. Der übeltäter liegt oftmals woanders.
PS: Wenn man Round in einer Methode kappselt die auch wieder nur Round aufruft benötigt es dann glatte 8 Sekunden.

na mahl sehen:
programm zur simulation von elektronenbewegung in gekreuzten feldern (nur aus spass, weil mein physiklehrer in der LK Klausur ne Aufgabe falsch korigiert hatt bis jetzt 100000 Iterrationsschritte mal etwa 300Elektronen und für jedes gamma, beschl, geschw und neue position berechnen. Hatt mir einfach spass gemacht dass zu optimieren,weil es so ein einfacher Quellcode ist. Bin aber von schon von 30000 auf 100000 schritte pro sekunde hoch nur durch dass einsparen von allen unötigen zwischenspeicherungen von ergebnissen.
und watt mann im kleinen lehrnt wirdsich in komplexeren programmen jawohl genauso gut anwenden lassen.

Hab da grosse pläne, bei denen meine cpu denk ich aufgeben wird. aber die forschung schläft ja nicht.

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Ja wie? Verdammt, ich sollte mir wohl doch mal die Anschaffung eines neuen Delphis überlegen... Naja, ich war bislang fähig, ins Intel Pentium Handbuch zu schaun, also werd ich das auch in Zukunft sein...

Eine Nachteil hat die Floating-Point geschichte unter Delphi. Normalerweise werden 32-bit-Zahlen (Single sind auch 32-Bit) in Registern gehandhabt und auch an Funktionen übergeben. Delphi greift bei Single-Variablen in Punkto Berechnung zwar auf FPU-Befehle zurück, an Funktionen werden die Werte allerdings aus mir unerklärlichen Gründen nicht per Register (wie Integer-Werte) sondern per Stack übergeben.

Das könnte ein Programm dann doch auf Dauer etwas verlangsammen (wenn man von einer 150 MHZ CPU als Basis ausgeht ) Abgesehen davon, dass an OpenGL die Daten sowieso per Stack übertragen werden, spielt das ganze also keine Rolle. Wollte es nur der Vollständigkeit halber erwähnen. Das sind dann eben die 0.0012 ms mehr Geschwindigkeit, die ein C/C++ Programm bei abstrakten Zeitmessungen (welche meistens fernab der Realität liegen) schneller ist!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Es nützt ja ohnehin nicht viel, da der normale 80x87 Befehlssatz intern immer mit 80 Bit rechnet. Da ist höchstens über den Speicherdurchsatz noch etwas (wenig) herauszuholen.

Es tut mir leid, wenn ich da (unnötigerweise) Verwirrung gestiftet habe: auch C++ Kompiler bieten in der Hinsicht keine bessere Unterstützung, da die direkte Programmierung von 3DNow oder SSE(2) zwangsläufig die halben Prozessoren außen vor lassen würde.

Meines Wissens gibt es von Intel einen Kompiler, der recht gut auf SSE optimiert - aber wer so aufwändige Berechnungen hat, dass das tatsächlich einen Unterschied macht, kann auch gleich Teile des Codes in Assembler programmieren.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/