Das deutsche Python-Forum

Interessante Diskussion, zu der ich viel schreiben könnte, müsste ich nicht eigentlich Vortragsfolien ausarbeiten, mich davon aber immer wieder ablenke. Dennoch ein paar Statements.

Ich finde das Lernen einer neuen Sprachsyntax im Vergleich zum Lernen einer neuen Funktionsbibliothek vernachlässigbar einfach. Ich bringe mir gerade die Entwicklung von iPhone-Anwendungen bei. Die Sprache Objective-C ist harmlos, da ich in einem früheren Leben mal C-Hacker war und auch Smalltalk kenne. Die Klassenbibliothek hat es jedoch in sich. Jede Kleinigkeit muss ich nachgucken und die Entwicklung fühlt sich (noch) ungeheuer langsam an.

Somit halte ich das Argument, dass Boo wie Python aussieht, nicht für so entscheidend. Würde ich die CLR-Klassenbibliothek beherrschen und einfach nur ein bisschen Tipparbeit mit C# sparen wollen, sähe das vielleicht anders aus.

So plane ich, mir demnächst mal Duby anzuschauen, eine Variante von JRuby, die explizit ein Syntax-Skin für Java sein will, also ein Java mit Ruby-Syntax, das die Java-Klassenbibliothek benutzt. Diese beherrsche ich (aus dem FF) und somit könnte es spannend sein, zu schauen was ein bisschen Scripting a la Ruby besser macht. Dennoch bin ich skeptisch, dass es einen großen Vorteil gibt - Java-IDEs machen eigentlich auch das Arbeiten mit normalen Java-Quelltext durchaus erträglich.

Ich bin kein Experte für die CLR oder C#, aber wenn ich Mono und die JVM als Basis für Programmiersprachen vergleichen soll, dann würde ich immer die JVM als technisch überlegen vorziehen. Ich weiß, dass die JVM bei der Speicherverwaltung, Just-in-Time-Compilation und beim Multithreading einen großen Vorsprung hat. Außerdem ist das Ding rock-solid.

GUI-Programmierung, noch unter Linux, ist für mich kein wichtiger Punkt. Mono bringt wohl Bindings für GTK mit. Egal wie praktikabel das jetzt ist, mich würde (bei den Anwendungen, die ich im Kopf hätte) stören, dass das ein ziemlich primitives Rahmenwerk auf dem Stand von vor 20 Jahren ist. Wx und Tk, so wie ich das bei Python gesehen habe, sind da kein bisschen besser. Gleiches gilt für die WinForms der CLR. Swing ist da überlegen, auch wenn es den "Markel" hat, UIs selbst zu zeichnen. Ebenfalls (wie dynamische vs. statische Typisierung) ein uralter Streit. Anfang der 90er wurde für Smalltalk-80 (ObjectWorks später VisualWorks) ein UI entwickelt, das Vorbild für Swing (weil die Entwickler von ParcPlace zu Sun wechselten) und NextStep wurde und die selben Konzepte enthielt, die jetzt erst viele Jahre später bei WPF und Silverlight bzw. Flex einflossen. Diese beiden würde ich (neben Cocoa als Nachfolger von NextStep) dann auch als einigermaßen interessante UIs hervorheben. Tatsächlich wäre Silverlight für mich der Grund, mich mit diesem .NET-Subset zu beschäftigen. Damit ich dann aber da gerade nicht die CLR erlernen muss, würde ich auf IronRuby oder IronPython setzen.

Auch hier wäre meine Motivation nicht bessere Performance oder CLR-Kompatibilität, sondern die vertraute Sprache mit der vertrauten Funktionsbibliothek einsetzen zu können, um so nur das Minimum zu lernen, was notwendig wäre, um UIs zu bauen.

Übrigens, *objektive* Kriterien für die Sprachwahl gibt IMHO es sowieso nicht. Das ist alles immer und überall persönlicher subjektiver Geschmack. Bestenfalls kann man der Überzeugungskunst eines Evangelisten erliegen. Die Krux ist, das jeder andere *implizite* Kriterien hat, an denen er seine Bewertung und letztlich seine Entscheidung festmacht und da diese Kriterien nie genannt werden, kommt es regelmäßig zu erbitterten Wortgefechten.

Für mich ist die Gemeinde einer Sprache relativ wichtig. Sie muss zwar nicht groß, aber groß genug (zu groß kann wie im Fall von PHP auch ein Ausschlusskriterium sein) sein, damit ich nicht das Gefühl habe, ein totes Pferd zu reiten.

Als Nemerle neu war, hatte ich mir das mal angeschaut, aber es erschien mir einfach yet-another-functional-language irgendeiner Hochschule (Breslau, Polen) zu sein. Davon gibt es einfach zu viele. Interessant war z.B. auch Alice (Saarland, Deutschland) aber letztlich auch todgeweiht. Hinzu kommt, dass ich ML-artige Sprachen nicht so spannend finde.

Eine Sprache im selben Bereich wie Nemerle, die es geschafft hat, ist da Scala. Vielleicht weil sie genug Kompromisse eingegangen ist, was die bekannte imperative Programmierung angeht. Ist aber leider genau wie C# ein Sprachmonster mit sehr komplexerem Sprachstandard. Dazu kommt (im Gegensatz zu C#) noch ein verdammt kompliziertes ("verdammt kompliziert" liegt zwischen kompliziert (C#) und unglaublich kompliziert (Haskell) und ist eine offizielle Klassifizierung) Typsystem.

Übrigens kann man auch Scala "skripten", sprich, es gibt einen Modus, dass der Quelltext von einem Befehl sowohl übersetzt und dann gleich gestartet wird. Sogar eine interaktive Befehlzeile gibt es.

Eine andere interessante Sprache, die es wohl geschafft hat, ist IMHO Clojure. Man muss die Lisp-Syntax nicht mögen (ach würde doch dieser erzkonservative engstirnige Entwicklerhaufen nur einmal die geistige Flexibilität besitzen, auch eine andere Syntax als die mit geschweiften Klammern zu akzeptieren) aber die Konzepte sind interessant. Und so etwas finde ich wichtig. Persistente Datenstrukturen und konsequente Anpassung der Sprache an die Anforderungen der Programmierung für viele Prozessoren sind ein wichtiges Thema.

Auf Burlis Frage, ob es Astra oder Golf sein soll, ist IMHO sehr wohl auch die Antwort erlaubt, dass beide Autos nichts taugen und man mit dem Mini am besten fährt. Ich finde ihn jedenfalls schick. Eine Entweder-Oder-Antwort zu verlangen ist illusorisch. Und eine ergebnisoffene Diskussion ist sowieso spannender :)

Oh, und ich stimme BlackJacks Antwort auf Burli zu: "bei .NET vs. JVM gewinnt die JVM".

Die JNI-Schnittstelle bei Java ist zugegeben umständlich, aber plattformübergreifend. P/Invoke ist einfacher, aber gerade unter Windows die Einladung, Windows-spezifischen Code zu schreiben, der dann nicht mehr portabel ist. Für Java würde ich einen Blick auf JNA empfehlen. Ursprünglich für JRuby entwickelt und inzwischen auch von Jython und anderen JVM-Sprachen benutzt ist das ein ctypes-ähnliches FFI.

SWT ist übrigens ziemlich populär, genau wie Eclipse populär ist, nur sieht man davon mehr in der Windows-Welt als in der Linux Welt. Swing ist allerdings einfacher zu benutzen und die "reine" Lehre. Daher wird es gerne gerade von Opensource-Verfechtern vorgezogen. Tatsache ist aber, dass Java-Entwicklung meist in der Web- und Server-Welt stattfindet und nicht so sehr auf dem Client.

Aber ich denke, dass ist sowieso ein genereller Trend. Web-Anwendungen werden mittelfristig die meisten Desktop-Anwendungen ablösen und daher werden betriebssystemspezifische UI-Toolkits immer unwichtiger. Vielleicht, so denke ich mir manchmal, läuft einfach die Linux-Welt diesem Trend nur hinterher, da sie sich freut, mit Ubuntu endlich einen Desktop zu haben (und das nur 25 Jahre nach dem MacIntosh oder 15 Jahre nach Windows 95) während die restliche Welt schon mal Richtung Browser zieht.

Und ja, mir ist bewusst, dass z.B. native iPhone-Anwendungen auch keine reinen Browser-Anwendungen sind, sondern ein eigenes UI-Toolkit haben, doch dieses wiederum integriert einen WebView als UI, der in den meisten Anwendungen eingesetzt wird, wo komplexere Textdarstellungen notwendig sind und alternative Technologien wie z.B. Adobe AIR setzen reine Browser- bzw. Flash-Anwendungen dagegen, die flexiblere UIs erlauben, als wie es mit dem selben Aufwand in CocoaTouch möglich wäre.

Nochmal zu IronPython. Dies ist IMHO kein krampfhafter und gescheiterter Versuch, Python auf die .NET-Plattform zu heben (wie burli sagte) sondern eben eine weitere Sprache für die CLR, die nicht ein C#-Syntax-Skin ist, sondern eine alternative Semantik bietet, um .NET-Anwendungen zu schreiben. Es ist der Versuch (und Beweis?) das es möglich ist, die CLR als alternatives "Betriebssystem" (neben C) für einen Python-Interpreter zu benutzen und das die CLR, obwohl für statische C#-artige Programmiersprachen entwickelt, auch für dynamische Sprachen taugt.

Doch auch hier würde ich eher auf die JVM setzen. IronPython und Jython kann man leider nicht vergleichen, weil Jython nur hobbymäßig entwickelt wird und immer noch eine Implementation der ersten Generation ist, während IronPython die nächste Generation darstellt. Doch IronRuby und JRuby spielen in der selben Liga und hier hat IronRuby sogar die Gnade der späteren Geburt, sprich konnte von JRuby und IronPython lernen. Dennoch performt das Ding auf der JVM deutlich besser und wird nochmals mit Java 7 einen entscheidenen Geschwindigkeitsvorteil herausholen.

Zu Boo selbst habe ich jetzt gar nichts mehr gesagt, aber genug geschwafelt. Ich muss meine eigentliche Arbeit machen... Grummel.

Stefan

Auf der Homepage hab ich ein paar Dinge gesehen die ganz interessant waren:

* quickly compile boo script to standalone cross-platform exe
* easy super(), and constructor automatically calls super() for you. If you don't have a constructor, one is created for you.
* set class properties via the constructor (constructor doesn't have to
handle them explicitly):
* built-in support for Regular Expressions
* extensible compiler pipeline
* custom Syntactic Macros

darii hat geschrieben:Ich finde es jedenfalls bemerkenswert, wie du M$ oder auch Ballmer im speziellen prinzipiell jegliche Lernfähigkeit absprichst. Das verstehe ich auch unter radikal.

Nicht die Lernfähigkeit spreche ich Ihnen ab, natürlich lernen sie aus ihren Fehlern, sie wollen ja Geld verdienen und da es nun mal nicht anders geht müssen sie sich auch dem Open Source Gedanken öffnen, doch wären sie nicht praktisch dazu gezwungen, sie wären nie einen Schritt in diese Richtung gegangen. Ähnlich ist es mit der Struktur vom Betriebssystem, es hat lange gedauert, bis Sicherheits-Experten aus allen Lagern in die Firma geholt wurden, um mal die größten Schwachstellen anzusprechen und aus dem Weg zu räumen.
Nein Sie sind lernfähig, aber ich unterstelle Ihnen eine tief verwurzelte Angst vor Open-Source-Konkurrenz und außerdem eine Monopolpolitik die sich nicht verbessert, wenn ihnen nicht die EU weiterhin ständig Strafen aufbrummt.
Rücksichtslosigkeit bis zum Letzten, das ist radikal. Sie verteilen sogar in Afrika Softwarepakete mit z.B. einem Jahr Lizenzgebührbefreiung, danach sind sie aber an Microsoft gebunden. Menschen die sowieso schon wenig Geld haben und kaum für das Mindeste aufkommen können, wurden hier mit hinterhältigen Lizenzverträgen auf lange Zeit zur Zahlung verpflichtet.

Es sind Sympathiefragen, für mich ist ein Produkt eines Konzern der so agiert wie Microsoft, keine Option.

burli hat geschrieben:Mindestens zwei Argumente, die die anderen Sprachen nicht haben. Python-ähnliche Syntax und wahlfreiheit zwischen statischer und dynamischer Typisierung. Außerdem Scriptfähig und interaktiver Modus. C# z.B. hat nach meinem derzeitigen Kenntnisstand keines davon. Ob Java, F# oder was auch immer sowas hat weiß ich nicht.

C# 4 hat ebenfalls wahlweise dynamische Typisierung. Und VB hat es schon seit Jahren. Warum wahlweise statische Typisierung jetzt aber ein Vorteil aus der Sicht von Python sein soll, weiß ich nicht. Das Typsystem von Boo (welches IMHO das von C# 2 oder so ist) ist nicht ausreichend, um die gewohnte "duck typing" Flexibilität die ein Python-Entwickler IMHO erwartet auszudrücken. Ich würde die Notwendigkeit, gewisse Dinge statisch zu typisieren, damit ich mit der CLR interagieren kann, als Übel in Kauf nehmen, aber das wäre es dann schon.

Wenn schon, dann hätte ich gerne ein Typsystem, das auf Strukturtypen basiert, so wie es bei Go der Fall ist. Oder mit Traits. Oder noch schwächer als es bei C# ist, etwa wie bei Objective-C. Hat Boo eigentlich generische Typen? Das ist IMHO der Anfang vom Ende der Verständlichkeit eines Typsystems.

Übrigens, auch für Java gibt es einen interaktiven Modus. Sowohl Beanshell als auch Groovy sind Supersets von Java und da beide Scripting-fähig sind, kann man damit folglich Java-Programme skripten. Das Scala auch wie eine Skriptsprache funktionieren kann, hatte ich ja schon erwähnt.

Und C# kann man auch skripten. Miguel hatte glaube das auf der letzten MiX-Konferenz vorgestellt. Zusammen mit Silverlight oder so. Er freute sich dabei, dass sie damit mehr konnten, als Microsoft selbst, die aber glaube ich auch nachgezogen haben und es jetzt neben IronDingensBums auch möglich ist, C# und VB.NET als Scripting-Engines zu benutzen.

Stefan

sma hat geschrieben:Ich bin kein Experte für die CLR oder C#, aber wenn ich Mono und die JVM als Basis für Programmiersprachen vergleichen soll, dann würde ich immer die JVM als technisch überlegen vorziehen. Ich weiß, dass die JVM bei der Speicherverwaltung, Just-in-Time-Compilation und beim Multithreading einen großen Vorsprung hat.

Ich bin definitiv kein Experte und möchte dir nicht widersprechen, aber so eine Aussage ist für mich schwer zu glauben. Die Gefühlte Geschwindigkeit von .net und clr ist VIEL höher und die eigentliche habe ich eigentlich immer auf ungefähr das gleiche niveau wie die JVM und Java geschätzt. Ich irre höchstwahrscheinlich, aber möchte mal Beispiele sehen, wenn das möglich ist.

Ich stehe hier nicht fest mit dem Standpunkt "CLR IS DOCH VIEL SCHNELLER" sondern möchte mich viel mehr überreden lassen.

[subjektiv]
C# fühlt sich trotzdem viel moderner und schöner als Java. Java fühlt sich an wie'n Klotz am Bein.
[/subjektiv]

@BlackVivi: Die „gefühlte“ Geschwindigkeit?! Oh je …

lunar hat geschrieben:@BlackVivi: Die „gefühlte“ Geschwindigkeit?! Oh je …

*seufz* Anstatt so abwertend meinen Begriff zu benutzen und mich damit zu degradieren, hättest du fragen können was ich damit meine, oder? Ich empfinde das als recht fies.

Mit gefühlter Geschwindigkeit mein ich, wie schnell Applikation starten, wie schnell GUIs reagieren, wie schnell kleine Popup Fenster auftauchen und all dies. Das fühlt sich bei .net Sachen flotter an. Vielleicht wegen Swing, vllt weil... keine Ahnung.

Auf jedenfall fand ich das nicht sonderlich nett von dir.

Einen Benchmark für verschieden Sprachen gibt es hier

Der Vergleich zwischen C# und Java sagt, dass Java gleich schnell oder sogar schneller ist, aber C# im schlechtesten Fall genauso viel Speicher braucht, im Idealfall sogar nur ein sechstel.

Das sagt aber nur etwas über manche Berechnungen aus, nichts über die GUI oder das Startverhalten. Ich schätze, die Hauptbremser bei Java sind SWT oder Swing.

Ich habe dieses GTK Beispiel in Boo einmal ausprobiert. Compiliert startet es quasi sofort und es benötigt zur Laufzeit gerade mal 5MB RAM. Das letzte "Hello World", das ich in Java gesehen hab, hat schon über 10MB benötigt.

Dieses einfache Java Programm braucht fast 10 Sekunden für den Start und belegt 85 MegaByte. Ich weiß nicht, was das Programm macht, dass es so lange zum starten benötigt und so viel Speicher benötigt, aber für ein Programm mit einem Hauptfenster und drei Dialogen ist es definitiv zuviel.

Ich korrigiere. Inzwischen benötigt das Programm sogar schon 98,5MiB!! Selbst bei einem zweiten Start braucht es trotz Cache immer noch 6 Sekunden. Programme wie Eclipse sind da auch nicht besser. Braucht fast 30 Sekunden, bis das bei mir gestartet ist und schluckt nach dem Start, ohne etwas gemacht zu haben, aktuell 337,9MiB. Nach ein paar Klicks war es schnell auf fast 360MiB.

Wenn man sowas sieht muss man sich über den Ruf von Java als lahmer Speicherfresser nicht wundern.

Hier nochmal ein Vergleich mit allen Tests und allen Sprachen in einer Gegenüberstellung. Interessant ist hier der "median" Wert. Ich nehme an, mit CPython ist 2.6 gemeint. Dann hätte Python 3 doch einen guten Sprung nach vorne gemacht.

Ah, da steht es.
java version "1.6.0_18"
Mono JIT compiler version 2.6.1
Python 3.1.1 (r311:74480, Jan 30 2010, 11:48:03) [GCC 4.4.1] on linux2
Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] on linux2

Interessant ist auch, dass F# ein wenig schneller ist als C#

Edit Wie dieses Beispiel zeigt ist mit Python 3 wohl auch Multiprozessing möglich. Also nehme ich diesen Punkt zurück. Das ändert aber nichts daran, dass Python auf 4 Kernen immer noch 10x langsamer ist als C# auf einem Kern.

@burli: Das `multiprocessing`-Modul gibt's auch für CPython 2.x. Und das reines Python für "number crunching" nicht das Beste ist, sollte echt nicht weiter verwundern. Ebensowenig, das F# bei so etwas ziemlich gut ist, wird es doch unter anderem als Fortran-Ersatz gehandelt. Das zeigt IMHO aber dass Dein Ansatz "eine Sprache für alles" nicht der Weisheit letzter Schluss ist.

@burli: Microbenchmarks ala Shootout sind in der Hinsicht kaum aussagekräftig. Sie laufen ja meist nicht mal lange genug, als das die JVM hinsichtlich Speicherverwaltung und JIT-Übersetzung punkten könnte. Und um zu wissen, dass CPython ziemlich langsam ist, muss man eigentlich keinen Benchmark bemühen. Auch die Geschwindigkeit von F# sollte nicht überraschen … schließlich hatte Microsoft mit Ocaml eine gute Vorlage.

Aus dem Speicherverbrauch kann man auch nicht gleich auf Ineffizienz schließen. Freier und unbenutzter Speicher macht das System weder toller noch schneller. Meist ist das Gegenteil der Fall. Speicherallokation über das Betriebssystem ist teuer und aufwendig, zudem kann die JVM ihren Speicher effizienter verwalten als das Betriebssystem. Daher fordert die Umgebung verhältnismäßig viel Speicher an, um gewisse Freiheiten bei der Speicherverwaltung zu haben.

Diesen Benchmark Vergleich fand ich sehr interessant und zum Teil überraschend:
- Ich hätte nicht gedacht, daß Perl lahmer ist als Python
- Pascal ist sicher nicht 6mal zu langsam wie C
- Ich hätte auch nicht gedacht, daß Haskell gegen Ocaml deutlicher besser abschneidet
- Go fand ich durchaus solide, dafür das es faktisch nicht älter als ein Jahr oder so ist

@hendrikS: Ich denke hier kommt auch mal wieder ins Spiel, dass Sprachen keine Geschwindigkeit haben, man aber gerne so tut. Man muss bei sowas auch immer den Compiler und die Optionen beim Übersetzen dazu sagen. Pascal muss nicht langsamer sein als C, aber wenn zum Beispiel die Überprüfung von Array-Grenzen zur Laufzeit passiert -- was einige Pascal-Compiler so übersetzen, wenn man das nicht abstellt -- dann kann Pascal bei entsprechenden Programmen halt auch langsamer sein.

Dadurch wird es aber nicht unbedingt schlechter, denn es ist in Bezug auf das Überschreiten von Array-Grenzen ja dann etwas sicherer, was man durchaus als Vorteil sehen könnte. Auch so eine Frage bei solchen Benchmarks: Womit erkauft man sich die Geschwindigkeit, und ist es das wirklich Wert.

Soweit ich das verstanden habe werden die Sourcen von der Community beigesteuert. Das heißt, es kann durchaus passieren, dass ein unfähiger Programmierer einen reichlich unoptimierten Code einreicht und eine Sprache dadurch schlechter erscheint als sie wirklich wäre.

Das Python kein Numbercruncher ist ist schon klar. Und ein Beispiel rauszupicken, in dem Python besonders schlecht abschneidet, ist natürlich unfair. Zur Ehrenrettung muss man auch erwähnen, dass Python bei regex-dna trotz Single Core richtig gut abschneidet. Außerdem brauchen Python Programme teilweise nichtmal die Hälfte der Codezeilen

Aber am Beispiel von Mandelbrot kann man auch schön sehen, dass Multiprozessing unter Python 3 wohl noch nicht ganz optimal funktioniert, da nur einer der vier Kerne zu 100% ausgelastet wird, die anderen nur jeweils zu rund 15%.

Ich finde, es ist nicht nur ein interessanter Vergleich zwischen verschiedenen Sprachen sondern auch eine schöne Plattform zum Programmieren üben. Hier kann man sich schöne Kenntnisse in der Programmierung und Optimierung von Algorithmen aneignen. Die gelisteten Programme stellen nur den aktuellen Stand dar und jeder kann versuchen, die Aufgabe weiter zu optimieren. Immerhin heißt es ja "Language Benchmark Game"

burli hat geschrieben:Aber am Beispiel von Mandelbrot kann man auch schön sehen, dass Multiprozessing unter Python 3 wohl noch nicht ganz optimal funktioniert, da nur einer der vier Kerne zu 100% ausgelastet wird, die anderen nur jeweils zu rund 15%.

Interessant, auf meinem Linux-Rechner laste ich alle Kerne auf 100% aus. Meint ihr psyco verursacht hier noch große Sprünge?

burli hat geschrieben:Ich finde, es ist nicht nur ein interessanter Vergleich zwischen verschiedenen Sprachen sondern auch eine schöne Plattform zum Programmieren üben. Hier kann man sich schöne Kenntnisse in der Programmierung und Optimierung von Algorithmen aneignen.

Das finde ich auch! Danke für den Link.

BlackJack hat geschrieben:@hendrikS: Ich denke hier kommt auch mal wieder ins Spiel, dass Sprachen keine Geschwindigkeit haben, man aber gerne so tut. Man muss bei sowas auch immer den Compiler und die Optionen beim Übersetzen dazu sagen.

Das ist natürlich absolut korrekt.

Um das nochmal zu verdeutlichen. Die Benchmarks, bzw die Ergebnisse derselben, müssen kein direktes Indiz für die Leistungsfähigkeit der Sprache sein sondern sind in erster Linie auf die Fähigkeiten des Programmierers zurückzuführen, der das Programm eingereicht hat.

Wie man sieht gibt es bei manchen Benchmarks einige Sprachen mehrfach, unterschieden durch ein # und eine Zahl. Die Ergebnisse zwischen den einzelnen Programmen unterscheiden sich teilweise dramatisch.

Zudem der schnellste Code nicht immer der idiomatische ist, den man so üblicherweise schreiben würde.

burli hat geschrieben:Aber am Beispiel von Mandelbrot kann man auch schön sehen, dass Multiprozessing unter Python 3 wohl noch nicht ganz optimal funktioniert, da nur einer der vier Kerne zu 100% ausgelastet wird, die anderen nur jeweils zu rund 15%.

Nein, das deutet vor allem erstmal darauf hin, dass es unter den beim vorherrschenden Testbedingungen irgendwo ein Nadelöhr bei dem Algorithmus gab.

burli hat geschrieben:Das Python kein Numbercruncher ist ist schon klar.

Du solltest mal ein scipy-Meeting besuchen ...

burli hat geschrieben: Aber am Beispiel von Mandelbrot kann man auch schön sehen, dass Multiprozessing unter Python 3 wohl noch nicht ganz optimal funktioniert, da nur einer der vier Kerne zu 100% ausgelastet wird, die anderen nur jeweils zu rund 15%.

... dort würde über das Beispiel eher gelacht. Es ist nämlich nicht sehr pythonisch und insgesamt etwas seltsam.

Also ok, Python ist vielleicht nicht *die* Sprache für numbercrunching, aber man kann viel mit den existierenden (!) Extensions machen. numpy (+ guter Einsatz von multiprocessing, vor allem aber anderer Tools und ggf. auch numexpr zum Speichersparen und ggf. PyTables für performates I/O) ist Dein Freund.
Diese Benchmarks jedenfalls zeigen ein anderes Bild - und sie sind veraltet.

Und Python in HPC? Das ist allerdings noch eine Baustelle ... In anderen Sprachen aber auch.

Naja, es steht jedem frei, eigene Versionen einzureichen. Ich weiß allerdings nicht, was alles zulässig ist. Bei C hab ich zumindest mal Boost gesehen. Also sollte Numpy theoretisch auch möglich sein.

Andererseits geht es ja um Python, nicht um C.