Hallo Zusammen

Erstellt Delphi gleich effiziente Programme wie andere Programmiersprachen (z.b. C# oder C++)? Effizient auf die Ausschöpfung der maximalen Leistung von den Ressourcen bezogen.

Vielen Dank.

ich hab mal ein paar verschiedene mathematische algorithmen in delphi und c++ implementiert. da war delphi schon ziemlich lahm ! teilweise auch schlechter als java oder c#.

ich finde für applicationen die performance brauchen ist delphi nix. es hat seine stärken eher in bereichen wie soa, oop und datenbank anwendungen.

Eine Messung der c't hat da aber was ganz anderes ergeben

delphi ist wie jede native programmiersprache schneller als eine interpretative. ganz einfach deshalb, weil bei einer interpretativen wie z. b. java/.net noch in übersetzter dazwischen geschaltet ist, welcher auch noch 'n paar takte rechenzeit benötigt.

in delphi kannst du wunderbar optimierten code schreiben, ggf. noch mit 'n paar assembler routinen. eine andere native ist z.b. C ist ebenfalls recht schnell und mit 'n paar optimierten assembler routinen auch eine feine sache. am schnellsten wäre assembler ... aber da muss ich dir ja nix erzählen.

aber wie überall gilt. ein schlechter Algorithmus kann viel kaputt machen ... daher feilt man erst mal am algo... und erst zum schluss, noch die eine oder andere funktion ... dies ist aber in aller regel das letzte mittel.

ein vergleich von verschiedenen pascal compilern ergab auch, dass delphi das spitzenfeld mit anführt.. im gegensatz von dem was man öfters hört... war der freepascal in der performance weit hinter delphi ... also keine sorge, der delphi compieler macht schon einen guten job ... aber er kann halt nicht alles wissen ... und von daher kann man, wie fast in jeder sprache, noch manuell eingreifen.

<HTH> GG

Die effizienteste Programmiersprache nützt halt nichts, wenn der eigene Algorithmus selbst lausig implementiert wurde.

Grenzgaenger hat folgendes geschrieben:

delphi ist wie jede native programmiersprache schneller als eine interpretative. ganz einfach deshalb, weil bei einer interpretativen wie z. b. java/.net noch in übersetzter dazwischen geschaltet ist, welcher auch noch 'n paar takte rechenzeit benötigt. [...]

.NET-Sprachen als interpretativ zu bezeichnen ist aber jetzt doch ein wenig weit her geholt.

de.wikipedia.org/wik...rungsgeschwindigkeit

Also ich hab mal ein Primzahlsuchprogramm sowohl in C# und Delphi geschrieben, und so gut es geht gleich implementiert, und da war C# 10% schneller. Dass Delphi allgemein schneller ist als C# kann man wohl nicht sagen.

Hi,

Eigentlich haben Fallbeispiele - so lange es nicht enor viele, statistisch ausgewertet, sind - hier nichts zu suchen..

Wieauchimmer.. Zuerst müsste man mal sicherstellen, dass der source wirklich komplett identuisch ist; da kommt es sicherlich auch darauf an, Ausdrücke wie 'Inc' oder 'Succ' für beide Sprachen zu kennen.

Unterm Strich würd ich mich dann doch eher der c't anschließen: die haben einfach Stichproben des entsprechenden Umfangs

mfG,

Hidden hat folgendes geschrieben:

Wieauchimmer.. Zuerst müsste man mal sicherstellen, dass der source wirklich komplett identuisch ist;

Einspruch! Man sollte auf beiden Plattformen den Code schreiben, der dort am schnellsten läuft und die Vorteile der jeweiligen Plattform richtig ausnutzen. Das kann man nur, wenn man den Code an die jeweilige Plattform anpasst. Identischer Code auf beiden Plattformen macht für einen fairen Vergleich keinen Sinn.

Christian S. hat folgendes geschrieben:

Einspruch!

Ups, stattgegeben!

außerdem sind interpreter sprachen wie java durch jit compilierung beu algorithmen extrem schnell ! und jit und managed code gibts ja auch bei .net. damit kommen c# und java schon nah an native sprachen heran.

g1o2k4 hat folgendes geschrieben:

außerdem sind interpreter sprachen wie java durch jit compilierung beu algorithmen extrem schnell ! und jit und managed code gibts ja auch bei .net. damit kommen c# und java schon nah an native sprachen heran.

JIT-Compiler haben sogar den Vorteil, dass sie zur Laufzeit Optimierungen vornehmen koennen, also z.B. haeufig aufgerufenen Code optimieren koennen, waehrend selten aufgerufener Code die simpelste Uebersetzung bekommt. Z.B. kann dieser Code dann im Speicher optimal abgelegt werden, so dass er vollstaendig im Prozessor-Cache ablaeuft. Nach mehreren Durchlaeufen des Optimizers kann solcher Code dann den statisch compilierten durchaus abhaengen. (Immer vorausgesetzt, der Optimizer taugt etwas.)

Aber egal wie effizient ein Compiler sein mag: Wenn der Algorithmus schlecht ist, kann auch der Compiler nichts mehr rausreissen. Und man sollte auch nicht vergessen, dass (schnellere) Computer billig sind Programmierer aber teuer, sprich: Gut wartbarer Code ist wichtiger als effizienter - in Grenzen natuerlich.

twm

also den .Net Code den ich bislang als programme hate, sei es Windos/.net oder net/.net, ist a) mal nicht plattformübergreifend (für was sich interpretersprachen eigentlich eignen sollten und b) ca. 500 mal langsamer. man wartet sich zu tote bis sich irgend was tut ...

und das soll mir jetzt mal 'n physiker erklären weshalb die bahnfahrt von münchen über paris nach hamburg doppelt so lange brauchen soll wie eine bahnfahrt von müchen über rom, nach paris nach hamburg?

sämtliche bisherigen versuche in diese richtung, bestätigen dass die bahnfahrt von münchen über paris nach hamburg noch um einiges kürzer ist als über rom ...

aktuell stufe ich .Net als nicht tragbar für die anwendungsentwicklung ein, da sie einfach performance mässig ein grauss ist.... ggf. wird das in 5 jahren anders, wenn die rechner 10x schneller werden... aber aktuell.... vergiss .Net

habe leider mit ein paar .Net programmen zu tun... die jungs veschenken sie, weil niemand für die misserable performance zahlen würde...

sorry, aber es gab schon 'n paar killerapplikationen, wie z.b. visual basic... und nun... ist der strom doch aus...

man muss aber auch sagen, dass von seiten der performance die 3'rd sprachen den 2'nd den rang abgelaufen haben... die 2'nd sind zwar mind. noch um den faktor 10 bis 100 schneller allerdings sind die rechner zwischenzeitlich auch um einiges schneller geworden, so dass dies kein grosse rolle mehr spielt ... wer weiss, wie die welt in 10 jahren aussieht... aber aktuell sind die interpreter sprachen keine alternative!

Moderiert von Christian S.: Beiträge zusammengefasst

dummzeuch hat folgendes geschrieben:

JIT-Compiler haben sogar den Vorteil, dass sie zur Laufzeit Optimierungen vornehmen koennen,

auch diese optimierungen können nicht kostenlos sein!

denke hier ist immer noch ein compiler im vorteil, welcher die optimierungen bereits (einmalig) zur laufzeit vornimmt ... und nicht erst, zum zeitpunkt (jedesmal) der interpretation.

es müssen doch sämtliche regeln der physik gebrochen werden, wenn so etwas funktionieren sollte... und billy boy haätte zwischenzeitlich schon längst intel übernommen...

PS: die diskussion .Net erinnert mich irgendwie an MUMPS wo der code auch um so schneller wird, um so mehr datenmengen er zu verarbeiten hat...

Grenzgaenger hat folgendes geschrieben:

aktuell stufe ich .Net als nicht tragbar für die anwendungsentwicklung ein, da sie einfach performance mässig ein grauss ist.... ggf. wird das in 5 jahren anders, wenn die rechner 10x schneller werden... aber aktuell.... vergiss .Net

Von so pauschalen Aussagen halte ich überhaupt nichts. Genauso wenig würde ich von einer pauschalen Aussage "Nimm auf jeden Fall .NET" halten.

Man muss bei jeder Anwendung prüfen, welche Anforderungen bestehen und womit diese am Besten bedient werden können. Für 08/15-Anwendungen die einen moderenen Prozessor eh irgendwo in der Gegend von 10% auslasten dürfte, finde ich nicht, dass man da auf Grund der Performance von .NET abraten sollte. Bei solchen Anwendung überwiegt der Komfort, den .NET bietet, um ein Vielfaches!

Auch wenn man eine wirklich rechenintensive Anwendung schreibt, muss man abwägen: Ich habe mal eine Simulation geschrieben, die über anderthalb Jahre hinweg täglich eingesetzt wurde und dann pro Durchgang um die drei Stunden lief. Da lohnt es sich, diese mit C zu schreiben und mit dem Intel-Compiler "gründlich" zu compilieren. Allerdings musste ich da eine höhere Entwicklungszeit in Kauf nehmen, da ich auf den Komfort von .NET verzichtet habe. Aber bei einer solch langen Einsatzzeit lohnte sich das.

Ich hatte aber auch eine Anwendung, die nur einige wenige Male laufen sollte und die habe ich dann in .NET realisiert, weil das Gewicht der Entwicklungszeit viel höher war. Bei der Anwendung merkte ich aber auch, dass man sich auch bei .NET mit den Interna beschäftigen muss, um schnelle Anwendungen zu schreiben. Ich hatte z.B. keine Ahnung, dass der Konstruktor eines Structs extrem lahm ist. Als ich das wusste konnte ich mit Änderungen an vielleicht 10 Zeile Code die Anwendung um einen Faktor 2 beschleunigen

Inzwischen ändert sich aber auch meine Sicht von .NET in Bezug auf solche "Rechenmonster"-Anwendungen. Denn mit ParallelFX entwickelt Microsoft eine sehr leistungsfähige Bibliothek, um Aufgaben in mehreren Threads auf mehreren CPU-Kernen laufen zu lassen. Und als Oxygene-Entwickler kann ich dann solche Dinge machen:

Und dann wird einWert im Hintergrund gerechnet und erst wenn ich ihn brauche, wird drauf gewartet, dass die Berechnung fertig wird. Oder sowas:

führt dazu, dass ParallelFX automatisch eine sinnvolle Anzahl Thread ermittelt, die verschiedenen Iterationen aufteilt und ausführt und während der Ausführung auch noch dynamisch umverteilt, wenn irgendwo gerade Resourcen frei werden.

Und damit hab ich wieder die Situation, dass ich in .NET einfach und wenig Fehler-Potential eine multi-threaded Anwendung schreiben kann, die dadurch auf Multi-Core-Systemen an Performance gewinnt. Selbst verständlich kann ich so eine Anwendung auch in Delphi schreiben, aber so lange es kein Gegenstück der ParallelFX für Delphi gibt, werde ich dafür viel mehr Entwicklungszeit und damit auch Geld investieren müssen.

Fazit meiner Meinung: Pauschale Aussagen sind IMHO nicht sinnvoll, man sollte bei jedem Programm neu überlegen, was die beste Lösung ist. Tendeziell: Standard-Desktop-Anwendungen laufen sehr gut unter .NET, rechenintensive Anwendung eher nicht, auch wenn sich das durch ParallelFX demnächst verschieben kann.

Viele Grüße
Christian

Grenzgaenger hat folgendes geschrieben:

...aktuell stufe ich .Net als nicht tragbar für die anwendungsentwicklung ein, da sie einfach performance mässig ein grauss ist...

Da bist du nicht der Einzige. Viel schlimmer ist aber, dass namhafte Software-Entwickler es schlichtweg ablehnen etwas zu machen, was eigentlich für .NET gemacht werden sollte. Bereits 2001 wurde für .NET auf RTL (TV) Reklame gemacht. Keiner wusste näheres. Die letzte Zeit sowas gesehen ? Glaubs kaum. Sieht langsam eher nach Rohrkrepierer aus. Mit Vista gehts dann nahtlos so weiter. Vielfach wird auch Marktführerschaft mit Technologie-Führerschaft verwechselt.

Christian S. hat folgendes geschrieben:

du weisst aber schon, dass du da eine raupe mit einem überschallflugzeug vergleichst...

auch M$ hat es eingesehen, dass die performance von .NET 'n grauss ist ... und versucht daher die performance von .NET 3.5 mit .NET 3.5 SP1 um 40 bis 60% zu heben... das würde heissen, dass .NET zukünftig die geschwindigkeit eines käfers zu einem compiler resp. eines überschallflugzeugs zum assembler entspricht...

nix für ungut, aber 'n interpreter kann einfach nicht mithalten... dafür hat 'n interpreter andere vorteile

GG

Grenzgaenger hat folgendes geschrieben:

Christian S. hat folgendes geschrieben: du weisst aber schon, dass du da eine raupe mit einem überschallflugzeug vergleichst...

Mein Punkt war, dass man da differenziert vergleichen muss und nicht pauschal "aktuell stufe ich .Net als nicht tragbar für die anwendungsentwicklung ein" sagen kan, sondern das von Anwendung zu Anwendung entscheiden muss. Für viele Anwendungen braucht man kein Überschallflugzeug, weil es die Turbine gerade so hoch laufen lässt, dass die Instrumente Strom haben.

Ich denke, meine vorige Antwort war differenziert genug, ich hab nix weiter zu sagen

hier im thread geht es um die performance ... oder wurde der titel in der zwischenzeit geändert?

mir ist klar, dass jede sprache seine vor- und nachteile hat und man daher in jedem anwendungsfall entsprechend entscheiden muss.

denn jede sprache hat seine vor- und nachteile. dasss ist mir schon klar ..

wurde hier die antwort zwischenzeitlich geändert?

Zitat:

dummzeuch hat folgendes geschrieben: JIT-Compiler haben sogar den Vorteil, dass sie zur Laufzeit Optimierungen vornehmen koennen, auch diese optimierungen können nicht kostenlos sein! denke hier ist immer noch ein compiler im vorteil, welcher die optimierungen bereits (einmalig) zur laufzeit vornimmt ... und nicht erst, zum zeitpunkt (jedesmal) der interpretation.

Angenommen, der Code in einer Schleife wird 1 Mio mal ausgfuehrt. Der JIT kann dabei die Pfade durch den Code analysieren und sie z.B. so im Speicher re-arrangieren, dass die am meisten durchlaufenen Pfade lokalisiert sind, also Cache-Hits ueberwiegen. Das kann ein statischer Compiler nicht, da er keine Informationen ueber die Daten und das Laufzeitverhalten hat.

Natuerlich hat ein statischer Compiler den Vorteil, dass er sich "beliebig" lange Zeit zur Optimierung lassen kann, der JIT-Compiler muss eine Gratwanderung zwischen Analyse/Optimierung und Performance machen.

Bei einem Programm, welches die meiste Zeit in irgendwelchen vorcompilierten Bibliotheken verbringt, ist es voellig egal, ob es compiliert oder interpretiert wird.

twm