Python ist ein Interpreter, man kann Ideen leicht ausprobieren, das endlose compile/link ist einfach zu langsam.
... eben, python ist schneller als C++So sieht das übrigens in Bytecode von CPython aus:Dill hat geschrieben:würde in assembler schon grausam aussehen, etwa so:Code: Alles auswählen
if a > b: print 1 else: print 2
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
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
Code: Alles auswählen
wirklich gut erklärt
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. Premature optimalization is the root of all evil.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.
Nö. Hab hier eine AMD X2-3800 und Python nutzt nur einen Kern. Ob die Python 64bit Version SMT fähig ist weiß ich nicht, da ich hier nur Windows XP in der 32Bit Version habe.BlackJack hat geschrieben: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.
Nein du hast dich schon richtige ausgedrückt (Finde ich zumindest). Das Python auf einen X-Core läuft ist ja klar, warum auch nciht. Aber der springende Punkt ist der, den du angesprochen hast -> Es wird immer nur ein Core genutzt.jens hat geschrieben: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.
Und wie soll das gehen? Wenn ich in Python ein Programm schreibe, wie sage ich dann Python das er das ganze auf verschiedene Kerne verteile soll? Ist es den möglich in Pythons Threads zu erzeugen die man bestimmten Kernen zuweisen kannBlackJack hat geschrieben:Und wenn man das Problem auf mehrere Prozesse aufteilt, dann werden auch mit Python mehrere Kerne ausgenutzt. Es gibt den zusätzlichen Vorteil, dass man mehrere Prozesse, bei entsprechenden Kommunikationsmöglichkeiten, auch auf verschiedene Rechner verteilen kann. Das skaliert also viel besser nach oben.
Wo wiederspricht das BlackJacks Aussage? Du bestätigst sie ja nur. Und nein, auch unter 64 Bit (IA64, x86_64, Alpha, UltraSPARC etc.) unterstützt Python kein SMP. Das liegt an der Architektur des Python-Interpreters.sape hat geschrieben:Nö. Hab hier eine AMD X2-3800 und Python nutzt nur einen Kern. Ob die Python 64bit Version SMT fähig ist weiß ich nicht, da ich hier nur Windows XP in der 32Bit Version habe.BlackJack hat geschrieben: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.
Sowas geht schlichtweg nicht. Alle Threads eines Python-Interpreters laufen auf einer CPU. Was man aber machen kann ist mehrere Interpreter auf verschiedenen CPUs zu starten und so zu kommunizieren.sape hat geschrieben:Und wie soll das gehen? Wenn ich in Python ein Programm schreibe, wie sage ich dann Python das er das ganze auf verschiedene Kerne verteile soll? Ist es den möglich in Pythons Threads zu erzeugen die man bestimmten Kernen zuweisen kannBlackJack hat geschrieben:Und wenn man das Problem auf mehrere Prozesse aufteilt, dann werden auch mit Python mehrere Kerne ausgenutzt. Es gibt den zusätzlichen Vorteil, dass man mehrere Prozesse, bei entsprechenden Kommunikationsmöglichkeiten, auch auf verschiedene Rechner verteilen kann. Das skaliert also viel besser nach oben.
Stimmt, hast Recht. Ich hatte BlackJack falsch verstanden.Leonidas hat geschrieben: Wo wiederspricht das BlackJacks Aussage? Du bestätigst sie ja nur.
Keine schöne Lösung. Ist von GvR in dieser Hinsicht was geplant oder geht es generell nicht Python so zu entwerfen das es SMP fähig ist?Leonidas hat geschrieben: Sowas geht schlichtweg nicht. Alle Threads eines Python-Interpreters laufen auf einer CPU. Was man aber machen kann ist mehrere Interpreter auf verschiedenen CPUs zu starten und so zu kommunizieren.
