Python und C++(C)

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Grossmeister_C
User
Beiträge: 36
Registriert: Montag 26. Februar 2007, 15:53

BlackVivi hat geschrieben:Ich persönlich verabscheue C alleine schon wegen den Pointern...
Was hast Du gegen Pointer ?
Benutzeravatar
Dill
User
Beiträge: 470
Registriert: Mittwoch 10. Januar 2007, 14:52
Wohnort: Köln

eine sprache hat keine geschwindigkeit. sie ist erstmal nur eine hilfsmittel für den programmierer. sie abstrahiert den für menschen schlecht lesbaren maschinencode.

die erste stufe der abstraktion ist assembler:

Code: Alles auswählen

LOAD 47, R0 # merke dir "47" in Register 1
LOAD 11, R1 # merke dir "11" in Register 2
ADD R0, R1  # addiere die beiden zahlen
in maschinencode könnte das dann so etwas sein:

Code: Alles auswählen

0F 47 00  #0F := LOAD, 2F := 47, 00 := R0 
0F 11 01 
0A 00 01  #0A := ADD
(diesen code kann die cpu direkt ausführen, sie liest zeile für zeile zahlen ein, schaut was sie jeweils tun soll,macht das, liest die nächste zeile ...)

wichtig ist hier, dass jedem assemblerbefehl eindeutig eine zahl zugeordnet ist. ( LOAD = 0F (hex) = 00001111 (bin) )
Die parameter sind auch einfach nur zahlen, LOAD erwartet hier zb zuerst ein INT, dann ein ziel register (ein kleiner, schneller speicherplatz im prozessor)

Die abstraktion von einfachen zahlen zu befehlen wie "ADD" ist zwar schon klasse, aber schöner ist doch etwas wie:

Code: Alles auswählen

R0 = 47 + 11
Sowas nennt man dann "höhere programmiersprache", also eine abstraktionseben höher. deutlicher wird das bei kontrollstrukturen wie einem einfachen if:

Code: Alles auswählen

if a > b:
  print 1
else:
  print 2
würde in assembler schon grausam aussehen, etwa so:

Code: Alles auswählen

LOAD A, R0
LOAD B, R1
CMP R0, R1 #vergleiche register 0 und 1
JGT :else    # springe zu else wenn 0 grösser 1
LOAD 1, R2
PRINT R2 
:else
LOAD 2 R2
PRINT R2 
Höhere sprachen wie C oder C++ werden vom Compiler (Übersetzer) in maschinencode übersetzt (Compilersprachen). Wenn man also von geschwindigkeiten von sprachen spricht, meint man damit: wie schnell ist das compilat (der resultierende maschinencode).

C(++) compilate sind deshalb so schnell, da der programmierer sehr hardwarenah programmieren kann (pointer).
Pointer gibt es aber auch in vielen anderen sprachen.
Selbst in Python oder Java, obwohl man sie hier nicht direkt verwenden kann.

Python funktioniert grundsätzlich anders als C: es wird nicht übersetzt, sondern interpretiert, dh es läuft ein programm (geschrieben in einer Compilersprache) das das python-programm zur laufzeit (also während das python-programmausgeführt wird) anaylsiert und zeile für zeile ausführt. Daher ist python grundsätzlich langsamer als C.
Könnte Python eigentlich ohne C++ existieren oder C oder eine andere sprache existieren?
Nein, Python braucht eine Compilersprache, also zb C, in der der Pythoninterpreter geschrieben ist. (theoretisch könnte man den auch direkt in assembler schreiben, aber s.o.)
Und kann es sein das viele Pythonia etwas oder einen leichten groll haben C(++) zu benutzen ?

C(++) sind grausame sprachen, die leider viel zu oft eingesetzt werden.
vor allem von leuten die sie nicht richtig (was schwer ist) beherrschen.
Viele probleme wären in anderen sprachen wie etwa python leichter lösbar, ohne performanceprobleme.
könnte man also zb. 3D Engines realisieren ohne irgendeine sprache zu benutzen auser Python
theoretisch ja. du kannst alles machen in phython (ausser ein betriebssystem) sobald der interpreter läuft ist alles möglich.
praktisch gibt es dinge die nach compilersprachen verlangen, dazu gehören definitiv 3D engines.
Zuletzt geändert von Dill am Samstag 10. März 2007, 00:22, insgesamt 1-mal geändert.
BlackJack

Dill hat geschrieben:Python funktioniert grundsätzlich anders als C: es wird nicht übersetzt, sondern interpretiert, dh es läuft ein programm (geschrieben in einer Compilersprache) das das python-programm zur laufzeit (also während das python-programmausgeführt wird) anaylsiert und zeile für zeile ausführt.
Das stimmt so nicht. Bei CPython wird der Python Quelltext in Bytecode übersetzt und nicht Zeile für Zeile interpretiert. Dieser Bytecode kann von einem JIT-Compiler wie Psyco auch in Maschinensprache übersetzt werden. Das gleiche gilt für IronPython und Jython.
Benutzeravatar
Dill
User
Beiträge: 470
Registriert: Mittwoch 10. Januar 2007, 14:52
Wohnort: Köln

:) ... ich wusste, dass das kommt.
wollte es aber nicht noch komplizierter machen, ist so wohl schon schwer verdaulich ...

wichtig ist aber, dass bei python kein fertiger maschinencode ausgeführt wird, sondern dieser erst zur laufzeit entsteht.
Ene Uran
User
Beiträge: 125
Registriert: Sonntag 17. September 2006, 20:14
Wohnort: Hollywood

Ein guter Dialog!

Die Idee hinter Python war, dass man die Sprache gut lesen und verstehen kann. Bausteine (modules) sind einfach einzubauen und man kann sie auch in anderen Sprachen schreiben. Python ist ein Interpreter, man kann Ideen leicht ausprobieren, das endlose compile/link ist einfach zu langsam. Python hat viele Dinge eingebaut von dem andere Sprachen nur geile Sehnsucht haben ...
Atomkraftwerkaktienbesitzer
Benutzeravatar
Dill
User
Beiträge: 470
Registriert: Mittwoch 10. Januar 2007, 14:52
Wohnort: Köln

Python ist ein Interpreter, man kann Ideen leicht ausprobieren, das endlose compile/link ist einfach zu langsam.
8) ... eben, python ist schneller als C++

wäre mal interessant zu wissen, wieviel geld in den sand gesetzt wird weil C++ statt einer dem problem angemessenen sprache eingesetzt wird.
BlackJack

Dill hat geschrieben:

Code: Alles auswählen

if a > b:
  print 1
else:
  print 2
würde in assembler schon grausam aussehen, etwa so:

Code: Alles auswählen

LOAD A, R0
LOAD B, R1
CMP R0, R1 #vergleiche register 0 und 1
JGT :else    # springe zu else wenn 0 grösser 1
LOAD 1, R2
PRINT R2 
:else
LOAD 2 R2
PRINT R2 
So sieht das übrigens in Bytecode von CPython aus:

Code: Alles auswählen

In [88]: def f(a, b):
   ....:     if a > b:
   ....:         print 1
   ....:     else:
   ....:         print 2
   ....:

In [90]: import dis

In [91]: dis.dis(f)
  2           0 LOAD_FAST                0 (a)
              3 LOAD_FAST                1 (b)
              6 COMPARE_OP               4 (>)
              9 JUMP_IF_FALSE            9 (to 21)
             12 POP_TOP

  3          13 LOAD_CONST               1 (1)
             16 PRINT_ITEM
             17 PRINT_NEWLINE
             18 JUMP_FORWARD             6 (to 27)
        >>   21 POP_TOP

  5          22 LOAD_CONST               2 (2)
             25 PRINT_ITEM
             26 PRINT_NEWLINE
        >>   27 LOAD_CONST               0 (None)
             30 RETURN_VALUE
lost_mind
User
Beiträge: 82
Registriert: Dienstag 13. Februar 2007, 11:55

ah echt thx für die antworten jetzt sind die Fragezeichen über meinem Kopf weg :D wirklich gut erklärt
oliver1974
User
Beiträge: 97
Registriert: Donnerstag 26. Oktober 2006, 15:01

Diese Diskussion um verschiedene Programmiersprachen und Geschwindigkeit kommt ja immer wieder mal auf....

Man könnte jetzt auch noch die Kriterien "Speicherplatzverbrauch" und dergleichen anführen, und selbst dann hat man nur die halbe Wahrheit.

Wenn ich ein Programm entwickle, und dies in einer Sprache tue die mir "Komfort" und hohe plattformunabhängigkeit bietet (Python, Ruby, Java), dann zahle ich in der Regel dafür einen Preis.. Dieser Preis besteht in der Regel aus Elementen wie "niedrigere Geschwindigkeit", "höherer Speicherplatzverbrauch" usw.

Ich muss mir jetzt klarwerden, ob ich diesen Preis zahlen kann/will.

Wenn ich das ganze in einer Sprache (oder allgemeiner, "Umgebung") programmiere, die zwar ressourcenschonend ist, die aber dazu neigt, nachher schlecht wartbar und/oder anfällig zu sein, zahle ich für die Vorteile (kleine ausführbare Dateien, hohe Geschwindigkeit) auch wieder einen Preis.. und zwar nicht zu knapp.

Ich bin auch ziemlich sicher, dass es "da draussen" eine ganze Latte Projekte gibt, die besser in einer Sprache geschrieben worden wären,
die es den Entwicklern "einfacher" machen, und letztlich auch zu höherer
Qualität führen (z.B.weniger Abstürze (die sich der Programmierer dann manchmal auch kaum erklären kann...)) oder auch Einhalten der veranschlagten Projektzeit, als jetzt nur auf Geschwindigkeit und Ressourcenschonung zu schielen.

Die ganzen "Sprache X ist besser als Sprache Y" Diskussionen
führen in der Regel zu nix, die nächste Steigerungsform ist dann
in der Regel Heise-Forum, wo dann Aussagen hochkommen wie
"Wer Sprache X benutzt, kann kein ordentlicher Programmierer/Entwickler sein"...
Was ich persönlich für Dummfug halte....

Ach ja, "Python und Geschwindigkeit":
Als ich (auch erst vor kurzem) mit Python angefangen habe, habe ich mich auch gefragt:
"Ups, Ne Interpreter-Sprache... ist das überhaupt geschwindigkeitsmäßig zu irgendwas zu gebrauchen?"

Ich war mehr als angenehm überrascht. Bei manchen Sachen gibts nämlich auch sowas wie "gefühlte Geschwindigkeit.."

So ist Java mittlerweile auch nicht mehr wirklich langsam, auch wenn das immer noch gerne behauptet wird: Projekte wie "Jake2" die den guten, alten Quake2-Ego-Shooter nach Java portiert haben (mit einer Framerate, die manchen den Mund offen stehen lässt.. natürlich via OpenGL Zugriff), zeigen das Java durchaus rennen kann.

"Gefühlt" ist Java aber oft bei insbesondere einer Aktion langsam, dem Start eines Programmes, es dauert halt bis die VM hochgefahren ist.

Dazu kommt noch eine gewisse Trägheit bei Swing-GUI-Api,
auch wenn diese sich verbessert hat...
Eine Python - Applikation startet dagegen nach meinem Geschmack
wesentlich zügiger hoch, da sehe ich fast keinen Unterschied zu "nativen" Programmen, auch die GUI (bei mir wxPython) ist sofort da und reagiert zügig.

Der Benutzer neigt dazu, die Geschwindigkeit des Programmes nach Startup-Zeiten und der Reaktionsschnelligkeit der GUI zu beurteilen.. denn damit hat er am meisten zu tun bzw. ist am offensichtlichsten.
Und da schneidet bei mir Python in Verbindung mit wxPython zur Zeit ganz gut ab.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Zum Thema Geschwindigkeit haben wir die Wiki Seite [wiki]Python Performance[/wiki]die man mit deinem Posting etwas weiter ausführen könnte. :lol:

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Eve Online (ein Spiel) nutzt Stackless Python

Code: Alles auswählen

7.4 How is the game logic implemented in EVE?

EVE uses a special Stackless version of Python for both the server and the client. This makes for a much simpler creation of game logic than what was available in the past. The control structures provided by Stackless allow for a more “procedural syncronous” model, rather than an “event driven asynchronous,” or thread pooling.

In more simplified terms, this means that a large number of actors can perform tiny tasks without the added complexity or overhead of the other two execution models. Our game logic scripters are thereby freed from many of the mundane tasks associated with models that don’t benefit from the control structures provided by Stackless. The creative process of writing interesting game behavior is no longer bogged down by software or system limitations.

This approach also means that making changes to the game is much easier than it has been historically. Many improvements or tweaks can be added even when the world is online and going strong without the need to reboot the servers. This process is called a hot fix.

Please help us support Stackless Python and the excellent contribution it is making to online gaming. 
StacklessPython ist durch weglassen des Stacks schneller weil alles sofort bearbeitet wird? Stacless.com ist nicht erreichbar kann leider nicht mehr lesen über das Thema. Bassiert StacklessPython noch auf C ?

***edit***
Zu gefühlter Geschwindigkeit:
Ich habe es schon gehabt. Ich habe mich gefreut etwas deutlich zu verbessern und den Menschen dadraußen gegeben und was war die erste Frage: "Was hat sich verändert sieht doch alles gleich aus?!". Ich kann keinen damit beeindrucken das mein Programm eine Aktion in 50 statt 80ms ausführt ohne das es vorher Performanceprobleme gab.
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

Programme schreibt man, um Probleme zu lösen.
Je schneller man ein Problem gelöst hat, umso besser.
Wenn du nun eine für eine Implementation in C 3 Tage brauchst, und diese dann 5 Stunden braucht, ist das schlechter, als wenn du in Python 1 Tag brauchst und dieses dann 8 Stunden läuft.

Das ist natürlich ein sehr vereinfachtest Beispiel, aber Code in Hochsprachen ist in der Regel einfacher zu warten und dementsprechend auch schneller an neue Gegebenheiten anzupassen.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sr4l hat geschrieben:Ich kann keinen damit beeindrucken das mein Programm eine Aktion in 50 statt 80ms ausführt ohne das es vorher Performanceprobleme gab.
Premature optimalization is the root of all evil.

Wenn etwas keine Performanceprobleme macht, ist es in der Regel nicht nötig etwas weiter zu optimieren. Außer man kann damit die Codequalität steigern, aber das interessiert den Benutzer deies Programmes keinen Deut, also brauchst du von dieser Seite nicht auf Anerkennung zu hoffen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Man sollte sich auch stets vor Augen halten, dass die meisten Anwendungs-Programme einen Grossteil der Zeit idle sind. Sie warten auf Benutzereingaben, bzw. viele Benutzereingaben fordern ein Programm nicht wirklich (Menues oeffnen, Text eintippen, Webseiten scrollen sind normalerweise ein Klacks.). Wenn dann mal wirklich etwas gefordert wird, gibt es andere Flaschenhaelse als die CPU-Zeit (beim Laden von Webseiten die Internetverbindung, beim Laden von Dateien den Festplattenzugriff etc.), die unabhaenging von der Programmiersprache sind. Wenn ich meine Rechner bei normalem Arbeitspensum so beobachte, stelle ich fest, dass die CPU sich doch ziemlich langweilen muss, Arbeitsspeicher ist da schon eher ein Problem (ein augelasteter Arbeitsspeicher faellt auch viel unangenehmer auf als eine ausgelastete CPU).

Klar gibt es auch Programme, die richtig viel CPU benoetigen, wenn man z.B. das Wetter von morgen oder die naechste unbekannte Primzahl berechnen will -- da wuerde man dann schon auf C oder Fortran zurueckgreifen. Aber ich denke, bei den heutigen Rechnerleistungen sollte eine Interpretersprache bei durchschnittlichen Anwenderprogrammen keine Performancenachteile bringen, die dem Anwender gross auffallen wuerden, bzw. anfaengliche Ladezeiten sind ja bei den meisten Programmen auch ok.

Das tolle an Python ist ja, dass man jederzeit Teile seines Codes in C auslagern kann, wenn man merkt, dass das doch noetig werden sollte.
Mad-Marty
User
Beiträge: 317
Registriert: Mittwoch 18. Januar 2006, 19:46

Ein Python(CPython) variiert geschwindigkeitsmäßig stark.
Eine rechenschleife wird Python unendlich lahm aussehen lassen, selbst mit Psyco ca 5x langsamer als C++.

Bei echten Programmen sieht das aber besser aus, da man relativ viele built-ins nutzt - da sind es nur noch ca 20-25 % langsamer.

Auch 3D Spiele ist kein problem, benutzt einfach http://directpython.sourceforge.net/.

OK die ansteuerung an DirectX via python-berechnungen ist langsam, aber da ca 80 % von 3D berechnungen in DirectX + Treiber bzw. bei anderen 3D Libs OGL + Treiber stattfinden, fällt das nicht wirklich auf.

Die Libs sind idR stark optimiert.

Typisches ingame scripting ist im endeffekt völlig gering vom overhead, weil zu ein paar scriptchecks millionen von 3D berechnungen passieren für einen frame.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beim letzten [wiki=User_Group_Köln#BisherigeVortrge]Python-Treffen in Köln[/wiki] hatten wir den Vortrag Python in der Luft- und Raumfahrt.
Dort wird unterm Strich Python überall da eingesetzt wo es nicht auf nackte Rechenleistung ankommt. Für die eigentlichen Berechnungen/Simulationen kommt i.d.R. uralter Fortran Code oder C zum Einsatz. Python steuert/koordiniert das ganze dann... Auch langfristig wird das wohl so bleiben. In dem Falle liegt das aber nicht unbedingt an Python selber. Viel mehr sind die kosten für eine Neuentwicklung bestehender Rechenmodelle einfach zu groß.

Dennoch ist es schade das Python z.Z. nicht mit Dual-/Multi-Core Prozessoren zurecht kommt. Man bedenke nur das aktuelle Main-Stream Rechner schon mit Dualcores ausgestattet sind.
Ich weiß auch nicht wie es mit 64Bit Unterstützung ausschaut. Von wegen mehr als 2GB Speicher nutzten.

Hat da Python einen Trend verschlafen? Weiß jemand wie die Entwicklung in dieser Richtung aussieht?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Wieso kommt Python nicht mit Dualcore zurecht? Die Programme laufen auch dort.

Und um einen Vorteil von mehreren Prozessoren zu haben, muss man das Problem, das man lösen möchte, erst einmal parallelisieren. Falls das möglich ist. Auf jeden Fall ist das mit Arbeit verbunden.
Benutzeravatar
Dill
User
Beiträge: 470
Registriert: Mittwoch 10. Januar 2007, 14:52
Wohnort: Köln

wie ist das wenn mein python-programm multithreaded ist.
werden die threads nicht automatisch vom os auf die zur verfügung stehenden kerne verteilt?
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Klar läuft Python auf Dualcores, da hab ich mich falsch ausgedrückt. Aber so weit ich weiß, wirt auch mit multithreading nur immer ein core genutzt.

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Dill
User
Beiträge: 470
Registriert: Mittwoch 10. Januar 2007, 14:52
Wohnort: Köln

http://www.parallelpython.com/

standardmässig laufen threads auf einem core.
liegt wohl daran, dass die ja irgendwie kommunizieren wollen und das ist nicht ohne weiteres möglich zwischen 2 cores.
habe jetzt auf anhieb aber nichts sinnvolles dazu gefunden, ausser dass das "obviously" nicht geht :)

tollerweise hat sich meine hochschule dazu entschieden alle vorlesungen zu parallelem rechnen und clustern abzuschaffen ... grade jetzt wo multicores für alle bezahlbar werden.
nervt mich dass ich davon kein plan hab.
Antworten