Python / Perl - was ist besser geeignet?

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.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

DanielH hat geschrieben:
Ich finde die Syntax von Ruby nicht ganz so toll, das überflüssige end hat mit meist
gestört und Ruby lädt irgendwie ein, tollen Code zu schreiben, der aber auch nicht ohne
weiteres verständlich ist.
Der Vorteil dabei ist, dass man den Code per Tastendruck einrücken lassen kann (falls die
IDE das unterstützt). So ist funktioniert das zumindest bei meiner php IDE (Zend Studio).

Oder funktioniert das auch mit Python? (Kann ja eigentlich überhaupt nicht gehen, soweit
ich das sehe).
Da hast du ganz recht - aus einem nicht eingerückten Code kannst du nicht automatisch eingerückten Code machen. Aber: das brauchst du auch nicht. Ich habe es in vier Jahren Python Nutzung kein einziges mal gebraucht. Ich schreibe ja Code der eingerückt ist (wobei mein Editor automatisch bestimmte Zeilen einrückt, so dass ich nur [Backspace] drücken muss, wenn ich mit dem Block fertig bin, um eine Einrückungsebene zu verlassen), andere schreiben genauso Code der eingerückt ist. Das tolle ist auch, dass sich fast alle an PEP8 halten, so dass der Code immer gleich eingerückt ist, du also in der Regel Code nicht manuell einrücken musst. Zudem kann mein Editor noch Block-Indentation, womit ich ganze Blöcke auf einmal einrücken kann. Damit bin ich wesentlich schneller unterwegs, als wenn ich überall 'end' tippen müsste, der Code bleibt gezwungernermaßen lesbar.
DanielH hat geschrieben:C# in Verbindungen mit ASP.NET soll auch extrem leistungsfähig sein (Für Server-
Applikationen). Allerdings wechsle ich demnächst von Windows zu Linux,
und da wäre es dumm, wenn ich C# lernen würde.
Du kannst durchaus ASP.NET mit C# oder IronPython unter Linux mit Mono und XSP nutzen. Aber ich habe es mir grade angeschaut - es schaut aus wie eine Templatesprache, also etwa PHP. Das fand ich auch toll, als ich nichts anderes kannte, aber seitdem es wirklich viele gute Frameworks gibt, fühlt es sich Amateurhaft an, Code mit HTML zu mischen.
DanielH hat geschrieben:
Die Antwort ist weder Python noch Perl (zumindest nicht erstrangig) sondern
Multiprocessing statt Multithreading. In der Oktoberausgabe des Python Magazine findest
zu ab Seite 5 eine Vorstellung von pyprocessing und Parallel Python, welche einem mit
Multiprocessing helfen. Natürlich kannst du das auch mit PHP, Perl oder Ruby machen...
Meinst du forken? Das war das Einzige, was ich zu dem Thema bei php gefunden habe.
Das scheint aber ziemlich schwierig zu sein (ich hab mehrmals gelesen, dass sogar
erfahrene php Entwickler vor forken zurückschrecken). Ich hab zwar eine php-classe
gefunden, die das forken vereinfachen soll (welche sich allerdings noch im Beta-Stadium
befindet), aber ich weiß nicht... php scheint für so was nicht gerade geeignet zu sein.
Lies doch die Artikel die ich dir verlinke.
Forking mit Parallel Python läuft so:

Code: Alles auswählen

import pp
job_server = pp.Server()
f1 = job_server.submit(func1, args1, depfuncs1, modules1)
f2 = job_server.submit(func2, args2, depfuncs2, modules2)
f3 = job_server.submit(func3, args3, depfuncs3, modules3)
r1 = f1()
r2 = f2()
r3 = f3()
D.h. also: das ganze Forken ist vor dir versteckt, ebenso wie die IPC. Darum kümmert sich `pp`, da musst du dir keine Gedanken mehr machen. `processing` ist ebenso einfach zu nutzen und wäre wohl für deinen Einsatzzweck besser geeignet (Worker-Prozesse die die zu verarbeitenden Daten aus einer Queue holen).
DanielH hat geschrieben:Ich denke ich werde lieber anfangen Perl zu lernen, anstatt mich mit php weiter zu
beschäftigen.
Gibs zu, du wolltest sowieso nur eine positive Meinung zu Perl hören, das der Rest dir bereits gesagt hat wie man das ganze effizienter ohne Threads lösen kann hat dich bisher nicht interessiert. Du hast dir nicht einmal den von mir verlinkten Artikel angeschaut.
DanielH hat geschrieben:Allerdings habe ich gedacht, dass Python die effizientere Sprache für's Internet ist. Der
Grund weshalb ich angefangen habe mich für Python zu interessieren, ist nämlich, dass
Googles Spider anscheinend in Python geschrieben ist (hab ich an zwei
verschiedenen Stellen gelesen). Und ich denke nicht, dass die bei den Millionen Seiten,
die Google pro Tag spidert, etwas nehmen, wenn es was geeigneteres gäbe. Aber wer
weiß, ob das überhaupt stimmt...
Wenn Google einen sehr effizienten Spider brauchte, dann würden sie C nutzen. Jedoch braucht der Spider keine so große Performance zu haben, da er sowieso oft auf Daten warten muss, da ist es egal ob er in C oder in Python geschrieben ist. Warum Google Python nutzt und nicht etwa Perl ist, dass die Codes lesbar sind. Stell dir vor, jemand hätte den Spider in Perl geschrieben und verlässt die Firma. Dann dürfte Google den Spider neu schreiben, da es in der Regel zu aufwendig ist fremden Perl-Code zu verstehen als einen neuen Spider zu bauen. Mit Python hat man C hingegen den Vorteil, dass man schnell neue Features einbauen kann, ohne sich mit aufwendiger Stabilitätsanalyse befassen zu müssen.

Der Python-Erfinder, Guido van Rossum, arbeitet inzwischen auch bei Google.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BlackJack

@DanielH: Ich denke Du machst Dir viel zu viele unnötige Gedanken um Threads und Performance. Insbesondere beim Thema "Internet", wo der Rechner wirklich die meiste Zeit mit warten auf IO beschäftigt ist und die Threads mehr in blockierenden Systemaufrufen stecken und "schlafen" als das wirklich gerechnet wird.

Auf der anderen Seite sind alle genannten Sprachen (Perl, PHP, Ruby, Python) bei wirklich CPU-lastigen Aufgaben "ungeeignet", da helfen auch keine Threads, da will man C/C++/Fortran verwenden bzw. Code in diesen Sprachen mit der höheren Sprache verbinden. Bei Python ist das klassische Beispiel das `numpy`-Paket für schnelles Rechnen mit mehrdimensionalen Arrays.

Perl, Ruby und Python sind alle geeignet für "Internetprogramme". Such Dir die Sprache aus, die Dir am ehesten zusagt.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

DanielH hat geschrieben:
Ich finde die Syntax von Ruby nicht ganz so toll, das überflüssige end hat mit meist
gestört und Ruby lädt irgendwie ein, tollen Code zu schreiben, der aber auch nicht ohne
weiteres verständlich ist.
Der Vorteil dabei ist, dass man den Code per Tastendruck einrücken lassen kann (falls die
IDE das unterstützt). So ist funktioniert das zumindest bei meiner php IDE (Zend Studio).

Oder funktioniert das auch mit Python? (Kann ja eigentlich überhaupt nicht gehen, soweit
ich das sehe).
Wenn man in Python vernünftig programmiert (wie auch in jeder anderen Sprache), dann braucht man kein automatisches Code-Formatting/-Tidying, falls du das meinst. Dennoch wird es das bestimmt auch für Python geben, möglicherweise bringt das PyDev-Modul für Eclipse diese Fähigkeit mit. Letztlich entscheidet bei mir aber nicht die IDE über die Programmiersprache, die ich verwende - eher umgekehrt. Und für Python braucht's keine IDE, hilft aber einigen Leuten.

DanielH hat geschrieben:Danke, ich schätze dann seh' ich mir erstmal Perl etwas genauer an. Meine Scripte sollen nämlich in erster Linie auf Servern laufen.
Glaub mir, da laufen Python-Anwendungen sehr gut und in sehr großer Zahl. Auch auf Servern ist Python mittlerweile schon schwer wegzudenken, weil doch so manche Tools darauf aufsetzen (wie es lange Zeit nur Perl vorbehalten war); bei modernen Distributionen ist das im Desktop-Bereich bei grafischen Tools noch stärker der Fall.
Ich denke, Perl wurde wegen der schlechteren Wartbarkeit und "Mehrentwickler-Fähigkeit" für neue Software nicht mehr gewählt.
DanielH
User
Beiträge: 5
Registriert: Donnerstag 15. November 2007, 20:13

Leonidas schrieb:
[...] (wobei mein Editor automatisch bestimmte Zeilen einrückt, so dass
ich nur [Backspace] drücken muss, wenn ich mit dem Block fertig bin, um eine
Einrückungsebene zu verlassen) [...]
Ok, das ist dann natürlich sogar noch praktischer.

Gibs zu, du wolltest sowieso nur eine positive Meinung zu Perl hören, [...]
Nicht wirklich. Soll ich ehrlich sein? Zum Zeitpunkt, zu dem ich den Thread eröffnet
habe, war Python ganz klar mein Favorit. Allerdings hatte ich mich zu dem
Zeitpunkt nur allgemein über Python, Ruby, Perl und andere Script- /
Programmiersprachen informiert.

Je mehr ich mich über Dinge informiert habe, die ich später brauche, je geeigneter
kam mir Perl vor.

Und außerdem wäre ich wohl in einem Forum über Python falsch, wenn ich unbedingt
eine positive Meinung zu Perl hören wollen würde.

[...] das der Rest dir bereits gesagt hat wie man das ganze effizienter ohne
Threads lösen kann hat dich bisher nicht interessiert.
Mir geht es auch nicht darum, ob es funktioniert, sondern womit es am besten
funktioniert (siehe Thread-Überschrift ;) ). Und ich hab den Eindruck, dass Perl besser
geeignet ist.

Darüber hinaus gibt es aber noch einige andere Punkte, weshalb ich mich für Perl
entschieden habe (z. B. weil ich so bereits ein fast fertiges Script habe, bei dem ich
nur ein paar Änderungen machen muss / vermutlich werde ich viel mit RegEx arbeiten
müssen, und Python verwendet ja den engine von Perl, was langsamer sein dürfte / ...)

Du hast dir nicht einmal den von mir verlinkten Artikel angeschaut.
Also in erster Linie hatte ich mich zwar zu dem Thema in Sachen php informiert (wegen:
"Natürlich kannst du das auch mit PHP, Perl oder Ruby machen..."), aber natürlich habe ich
mir auch die Artikel angesehen.

"Meinst du forken?" hab ich gefragt, weil ich bei php nichts anderes
gefunden habe, was mit Multiprocessing zu tun haben könnte, nicht weil ich mir nicht die
Artikel durchgelesen habe.

Aber Apropos: ein anderer Punkt gegen Python war, dass mein Provider Python offiziell
nicht unterstützt (momentan hab noch „normalen“ Webspace). Inoffiziell könne ich zwar
Python-Scripte über CGI laufen lassen, aber sie würden keinen Support für Python
anbieten (welchen ich momentan ganz sicher brauchen würde).

Und dadurch, dass ich nur Webspace hab, kann ich 'Parallel python' sowieso vergessen,
bis ich mir nen eignen Server hole oder den Webhoster wechsle (weil soweit ich mich
erinnere, muss 'Parallel python' installiert werden, was ich ja vermutlich ohne root
Rechte vergessen kann).


BlackJack schrieb:
Ich denke Du machst Dir viel zu viele unnötige Gedanken um Threads und
Performance.
Das könnte stimmen ;)

Aber lieber mache ich mir zu viele Gedanke, als zu wenige (z. B. wie als ich entschieden
habe php zu lernen...)

Auf der anderen Seite sind alle genannten Sprachen (Perl, PHP, Ruby, Python) bei
wirklich CPU-lastigen Aufgaben "ungeeignet", da helfen auch keine Threads, da will man
C/C++/Fortran verwenden bzw. Code in diesen Sprachen mit der höheren Sprache
verbinden. Bei Python ist das klassische Beispiel das `numpy`-Paket für schnelles
Rechnen mit mehrdimensionalen Arrays.
Ja, stimmt, darüber hab ich mir auch schon gedankten gemacht, bzw. habe ich mich
informiert. Allerdings wäre es mir erstmal zu viel C/C++ zu lernen.

Wo Perl hier (vielleicht) noch einen Vorteil hat, ist dass es für Perl anscheinend einen
Compiler gibt, mit dem man Perl-Code in C- oder Assembler-Code
compilieren/konvertieren kann (Wobei das wohl auch nicht das Gelbe vom Ei ist;
aber für wenige Codezeilen funktioniert es vielleicht).

Perl, Ruby und Python sind alle geeignet für "Internetprogramme". Such Dir die
Sprache aus, die Dir am ehesten zusagt.
Ich denke Du hast Recht. Ich hab beschlossen einfach die Basics von beide
Scriptsprachen zu lernen. Dann kann ich am besten entscheiden, ob ich die eine, die
andere oder vielleicht sogar bei Scriptsprachen „richtig“ lernen möchte (eigentlich
spricht ja nichts dagegen beide Sprachen zu lernen, oder?).

Ich hätte sogar schon zwei Ideen, für die Python wesentlich besser geeignet wäre als
Perl. (Einmal ein Programm, was neben dem Desktop auch auf PDAs laufen soll, und
einmal ein Programm, was ich als „open source“ veröffentlichen möchte).
skypa
User
Beiträge: 97
Registriert: Freitag 5. Januar 2007, 03:13

hier noch kleiner Hinweis falls du darauf noch nicht gestoßen bist: www.perlboard.de :roll:
BlackJack

@DanielH: Du machst Dir *wirklich* zu viele Gedanken um Geschwindigkeit. So wie Du drauf bist, solltest Du am besten Assembler benutzen. ;-)

Dein Argument warum reguläre Ausdrücke in Python langsamer sein dürften habe ich übrigens nicht verstanden!?

Für eingeschränktes oder leicht modifiziertes Python gibt's mit Pyrex/Cython, RPython von PyPy, und ShedSkin auch Möglichkeiten C bzw. C++ Quelltext zu erzeugen. Und es gibt den JIT-Compiler Psyco. Aber hast Du denn überhaupt vor "Numbercrunching" zu betreiben? Denn ansonsten wird das typische "Internet"- oder "Loganalyse"-Skript die meiste Zeit mit warten auf Daten oder in der Implementierung von regulären Ausdrücken stecken, die sowieso schon in C geschrieben ist.
Mad-Marty
User
Beiträge: 317
Registriert: Mittwoch 18. Januar 2006, 19:46

skypa hat geschrieben:@DanielH:
Perl ist optimal für dein vorhaben, garantiert! ;)
Na das will ich doch mal aber ganz stark anzweifeln.

Perl's threading ist sowas von vermurkst, das man das garnicht so nennen kann. Gerade ältere Perl versionen sind da besonders grottig.

Dann stellt sich noch die Frage ob sein ProxyCheck von anderen OSen ausser linux aus laufen soll.

Select muss auch nicht unbedingt die beste Lösung sein, gerade wieder im hinblick auf Unterschiedliche OS.

Ich würds mit Python machen und erstmal Select versuchen.


Zur Performance: In allen Tests die ich gemacht habe schlägt Python Perl teils sogar gravierend.
skypa
User
Beiträge: 97
Registriert: Freitag 5. Januar 2007, 03:13

Mad-Marty hat geschrieben:
skypa hat geschrieben:@DanielH:
Perl ist optimal für dein vorhaben, garantiert! ;)
Na das will ich doch mal aber ganz stark anzweifeln.

Perl's threading ist sowas von vermurkst, das man das garnicht so nennen kann. Gerade ältere Perl versionen sind da besonders grottig.
Wer benutzt denn freiwillig eine ältere Version? Was für ein Argument! :roll:
BlackJack

Wenn man an das gebunden ist, was der Webhoster bietet, benutzt man vielleicht *unfreiwillig* eine ältere Version.
skypa
User
Beiträge: 97
Registriert: Freitag 5. Januar 2007, 03:13

Ja das stimmt wohl, hab von solchen Vorfällen auch schon gehört. Hab auch zu gegebener Maßen kaum was mit Hostern zu tun. Das kommt später mal :roll:
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Mir fällt es immer etwas schwer, das Argument der Webhoster nachzuvollziehen.

Wenn ich es professionell mache, ist es eine Frage des Stundenlohns, wenn ich es als Hobby mache, eines meiner Nerven.

Wenn man es billig will, kriegt man bei Hosteurope z.B.ab 3€/Monat einen Webspace mit Python. Da kann man imho auch als Hobbyist recht gut finanztechnisch mithalten.

Wenn man mal überlegt, was eine Stunde der eigenen Arbeit kostet (hoffentlich mehr als 10€) kann man nur sagen, dass man sich nur eine Stunde/Monat mit einer alten Version, falschen Sprache oder etwas anderem, bei webhostern unkontrollierbaren rumschlagen muss, dass sich ein vhost für 10€/Monat lohnt (wo man die totale kontrolle hat).

Kurz, ausser dem irrationalen Wunsch eines Kunden, mehr Geld auszugeben, oder eigenem Masochismus fällt mir nichts ein, was den Webhoster als Argument enthält.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

DanielH hat geschrieben:Mir geht es auch nicht darum, ob es funktioniert, sondern womit es am besten
funktioniert (siehe Thread-Überschrift ;) ). Und ich hab den Eindruck, dass Perl besser
geeignet ist.
Wenn man die Diskussion so verfolgt, liest man dass du überlegst, wo Threads am besten funktionieren. Nicht wie man das Problem am besten löst ;) Vielleicht solltest du deine Idee, Threads zu verwenden loslassen :idea:
Über die Thread-Performance von Python vs Perl kann man aber wenig aussagen, da müsste man das gleiche Programm in beiden Sprachen schreiben und gucken.
DanielH hat geschrieben:vermutlich werde ich viel mit RegEx arbeiten
müssen, und Python verwendet ja den engine von Perl, was langsamer sein dürfte / ...)
Also das Argument verstehe ich nun überhaupt nicht. Erstens nutzt Python nicht die Engine von Perl, auch nicht PCRE. Zweitens sehe ich nicht was daran per-se so dramatisch langsamer sein soll. Reguläre Ausdrücke so wie sie in Perl, Python, Ruby implementiert sind nun mal recht langsam, siehe Regular Expression Matching Can Be Simple And Fast.
DanielH hat geschrieben:Aber Apropos: ein anderer Punkt gegen Python war, dass mein Provider Python offiziell
nicht unterstützt (momentan hab noch „normalen“ Webspace). Inoffiziell könne ich zwar
Python-Scripte über CGI laufen lassen, aber sie würden keinen Support für Python
anbieten (welchen ich momentan ganz sicher brauchen würde).
Den "Support" von Providern kann man in der Regel vergessen, von denen kannst du (in aller Regel) nichts erwarten. Da mich das auch gestört habe, und ich einen zusätzlichen Shared Hosting-Account (mit Python und allem drum und dran) gebraucht habe, bin ich Pyhosting beigetreten. Kann ich eigentlich nur empfehlen.
DanielH hat geschrieben:Und dadurch, dass ich nur Webspace hab, kann ich 'Parallel python' sowieso vergessen,
bis ich mir nen eignen Server hole oder den Webhoster wechsle (weil soweit ich mich
erinnere, muss 'Parallel python' installiert werden, was ich ja vermutlich ohne root
Rechte vergessen kann).
In der Regel kannst du Python-Pakete ohne root-Rechte installieren. Das mache ich auf meinem Shared-Hosting-Account auch so. Ein SSH-Account ist da jedoch von Vorteil.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
DanielH
User
Beiträge: 5
Registriert: Donnerstag 15. November 2007, 20:13

hier noch kleiner Hinweis falls du darauf noch nicht gestoßen bist: www.perlboard.de
Kannte ich schon, aber trotzdem danke.

@DanielH: Du machst Dir *wirklich* zu viele Gedanken um Geschwindigkeit. So wie Du drauf bist, solltest Du am besten Assembler benutzen. ;)
Langsam fang ich auch an dran zu glauben ;)
Naja, egal, außer etwas Zeit, die ich eventuell verlieren könnte, wenn ich Perl UND Python lerne, sehe ich keine Nachteile (dafür aber viele Vorteile).

Und so lange wird es wohl nicht dauern die Basics von Perl zu lernen (Ich hab jetzt angefangen ein Tutorial zu lesen; wenn ich mit dem Tempo weiter lerne, bin ich in 1 bis 3 Tagen fertig).


BlackJack hat folgendes geschrieben:
Dein Argument warum reguläre Ausdrücke in Python langsamer sein dürften habe ich übrigens nicht verstanden!?

Leonidas hat folgendes geschrieben:
Also das Argument verstehe ich nun überhaupt nicht. Erstens nutzt Python nicht die Engine von Perl, auch nicht PCRE. Zweitens sehe ich nicht was daran per-se so dramatisch langsamer sein soll. Reguläre Ausdrücke so wie sie in Perl, Python, Ruby implementiert sind nun mal recht langsam, siehe Regular Expression Matching Can Be Simple And Fast.
Ach so, da hab ich dann wohl irgendwas falsch verstanden. Erstmal dachte ich PCRE sei der leicht modifizierte Perl engine, und dann dachte ich Python würde diesen verwenden (Und dadurch, dass Python nicht seinen eignen engine benutze, wäre Python langsamer).


BlackJack hat folgendes geschrieben:
Für eingeschränktes oder leicht modifiziertes Python gibt's mit Pyrex/Cython, RPython von PyPy, und ShedSkin auch Möglichkeiten C bzw. C++ Quelltext zu erzeugen.
Danke für den Hinweis! Das muss ich mir dann auf jeden Fall ganz genau ansehen.

Aber hast Du denn überhaupt vor "Numbercrunching" zu betreiben?
Ich denke „erstmal“ nein.

Denn ansonsten wird das typische "Internet"- oder "Loganalyse"-Skript die meiste Zeit mit warten auf Daten oder in der Implementierung von regulären Ausdrücken stecken, die sowieso schon in C geschrieben ist.
Ach so, ich dachte dadurch, dass ich mehrere Anfragen auf einmal mache, „umgehe“ ich die Wartezeit, und kann die Ressourcen voll ausnutzen, wodurch es einen zusätzlichen Vorteil geben würde, wenn ich kompilierten Code verwende.


Mad-Marty hat folgendes geschrieben:
Dann stellt sich noch die Frage ob sein ProxyCheck von anderen OSen ausser linux aus laufen soll.
Nein, das Script soll nur unter Linux laufen (Windows soll ja für multi-threading nicht gerade ideal sein, hab ich gelesen..).


keppla hat folgendes geschrieben:
Mir fällt es immer etwas schwer, das Argument der Webhoster nachzuvollziehen.

Wenn ich es professionell mache, ist es eine Frage des Stundenlohns, wenn ich es als Hobby mache, eines meiner Nerven.

Wenn man es billig will, kriegt man bei Hosteurope z.B.ab 3€/Monat einen Webspace mit Python. Da kann man imho auch als Hobbyist recht gut finanztechnisch mithalten.

Wenn man mal überlegt, was eine Stunde der eigenen Arbeit kostet (hoffentlich mehr als 10€) kann man nur sagen, dass man sich nur eine Stunde/Monat mit einer alten Version, falschen Sprache oder etwas anderem, bei webhostern unkontrollierbaren rumschlagen muss, dass sich ein vhost für 10€/Monat lohnt (wo man die totale kontrolle hat).

Kurz, ausser dem irrationalen Wunsch eines Kunden, mehr Geld auszugeben, oder eigenem Masochismus fällt mir nichts ein, was den Webhoster als Argument enthält.
Im Prinzip hast Du vollkommen Recht. Ca. Anfang des nächsten Jahres werde ich mir wohl auch einen VPS holen, denke ich. Bis dahin will ich mir aber nicht extra noch ein weiteres Hostingpaket zulegen (ich hab sowieso schon viel zu viele Domains und Hostingpakete, die quasi ungenutzt sind ;) )


Leonidas hat folgendes geschrieben:
Wenn man die Diskussion so verfolgt, liest man dass du überlegst, wo Threads am besten funktionieren. Nicht wie man das Problem am besten löst Vielleicht solltest du deine Idee, Threads zu verwenden loslassen
Also eigentlich ist mir egal *wie*, Hauptsache schnell ;)
Ich weiß nicht mehr wo, aber irgendwo hab ich gelesen, dass eine Kombination aus Prozessen und Threads effizient sein soll (also dass es mehrere Prozesse gibt, welche jeweils mehrere Threads haben).


Mad-Marty hat folgendes geschrieben:
Zur Performance: In allen Tests die ich gemacht habe schlägt Python Perl teils sogar gravierend.
Leonidas hat folgendes geschrieben:
Über die Thread-Performance von Python vs Perl kann man aber wenig aussagen, da müsste man das gleiche Programm in beiden Sprachen schreiben und gucken.
Ich glaub, wenn ich die Basics von Perl und Python einigermaßen schnell lerne, schreib ich das Script nochmal in Python. Meine Neugierde ist jetzt viel zu groß, um das nicht zu machen.

In der Regel kannst du Python-Pakete ohne root-Rechte installieren. Das mache ich auf meinem Shared-Hosting-Account auch so. Ein SSH-Account ist da jedoch von Vorteil.
SSH hab ich anscheinend nicht, aber ich denke, ich werde die Python-Scripte ertmal auf meinem PC testen/laufen lassen (ich hab ja dann sowieso schon die Perl Variante, die auf dem Server laufen kann).

Den "Support" von Providern kann man in der Regel vergessen, von denen kannst du (in aller Regel) nichts erwarten.
Da geb ich Dir zu 100% Recht; Bei den meisten Hostern ist der Support extrem schlecht.
Mein Hoster ist da allerdings eine Ausnahme ( http://all-inkl.com/ ).

Zum Beispiel hab schon oft mitten in der Nacht (ca. 2 bis 4 Uhr) ne Anfrage gesendet, und hatte i. d. R. immer nach 30 bis 60 Minuten eine Antwort. Und die Antworten vom Support sind immer extrem hilfreich.
Zweimal haben die mir sogar gesagt, warum mein Script nicht läuft (nachdem ich es dem Support gesendet hatte, weil ich den Verdacht hatte, dass es wegen der Server-Konfiguration nicht läuft). Als ein Script nicht funktioniert hat, weil ich es mit php 5 entwickelt hatte, auf dem Server aber nur php 4 war haben die meine Domains ect. *über Nacht* auf einen Server mit php 5 verschoben.

Ich kann nur sagen, der Webhoster ist der Oberhammer ;)


PS: eine Sache, die ich bei Perl extrem beschissen finde, ist dass fast jeder Variablentyp anders gekennzeichnet wird (int./float/string = $, array = @, assoziatives array bzw. hash = %). Bei php ist alles mit $ gekennzeichnet und bei Python gibt es überhaupt keine Kennzeichnung (wenn ich das richtig in Erinnerung habe). Aber das ist wohl nur eine Gewöhnungssache...
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Multithreading und Multiprocessing ist sinnvoll fuer CPU-lastige nebenlaeufige Programme, fuer IO-lastige Programme aber eventuell nicht optimal. Es gibt noch eine andere Moeglichkeit! Ich zitiere mal die Doku vom asyncore-Modul:
There are only two ways to have a program on a single processor do ``more than one thing at a time.'' Multi-threaded programming is the simplest and most popular way to do it, but there is another very different technique, that lets you have nearly all the advantages of multi-threading, without actually using multiple threads. It's really only practical if your program is largely I/O bound. If your program is processor bound, then pre-emptive scheduled threads are probably what you really need. Network servers are rarely processor bound, however.

If your operating system supports the select() system call in its I/O library (and nearly all do), then you can use it to juggle multiple communication channels at once; doing other work while your I/O is taking place in the ``background.'' Although this strategy can seem strange and complex, especially at first, it is in many ways easier to understand and control than multi-threaded programming. The asyncore module solves many of the difficult problems for you, making the task of building sophisticated high-performance network servers and clients a snap. For ``conversational'' applications and protocols the companion asynchat module is invaluable.
Offizielles Python-Tutorial (Deutsche Version)

Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
BlackJack

Wo Perl für mich an Grenzen gestossen ist, waren verschachtelte Datenstrukturen und OOP. Da hat für mich Python klar die Nase vorn.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

DanielH hat geschrieben:Naja, egal, außer etwas Zeit, die ich eventuell verlieren könnte, wenn ich Perl UND Python lerne, sehe ich keine Nachteile (dafür aber viele Vorteile).

Und so lange wird es wohl nicht dauern die Basics von Perl zu lernen (Ich hab jetzt angefangen ein Tutorial zu lesen; wenn ich mit dem Tempo weiter lerne, bin ich in 1 bis 3 Tagen fertig).
Ja, die Basics bekommst du schnell hin, das stimmt. Aber die richtigen Features einer Programmiersprache lernst du erst wenn du dich intensiv damit beschäftigst. Damit will ich dich natürlich nicht von dem Entschluss beide Sprachen zu lernen abbringen, will dir nur sagen, dass nachdem man die Basics hat, die richtig tollen Sachen erst noch kommen. Das sehe ich an mir selbst, wenn ich meine alten Programme anschaue und mir an den Kopf fassen muss, was ich damals zusammengeschrieben habe. :)
DanielH hat geschrieben:Ach so, da hab ich dann wohl irgendwas falsch verstanden. Erstmal dachte ich PCRE sei der leicht modifizierte Perl engine, und dann dachte ich Python würde diesen verwenden (Und dadurch, dass Python nicht seinen eignen engine benutze, wäre Python langsamer).
Das Verwenden von "Fremdengines" muss nicht per-se langsam sein. Die Python-Regex-Engine besteht aus einer Mischung von Python-Dateien und einem C-Shared-Object (also etwa einer DLL), `sre`. Wenn Python PCRE verwenden würde, dann wäre es ganz ähnlich. Die Performance der Regular-Expressions ist eher weniger durch die Art der Anbindung definiert, sondern durch die Geschwindigkeit der Regex-Engine. In Python kannst du (theoretisch) neben `sre` auch `Oniguruma` oder `TRE` verwenden. Praktisch geht das nicht, weil beide Bindings noch nicht funktionieren.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

DanielH hat geschrieben:Da geb ich Dir zu 100% Recht; Bei den meisten Hostern ist der Support extrem schlecht.
Mein Hoster ist da allerdings eine Ausnahme ( http://all-inkl.com/ ).

Ich kann nur sagen, der Webhoster ist der Oberhammer ;)
Letzteres kann ich bestätigen: Zu meiner Zeit bei all-inkl tauche mal eine weitere Datenbank im Frontend (PMA) auf. Nach etwas Überfliegen stellte sich heraus, dass dies eine produktiv genutzte Datenbank eines anderen Kunden war. Die schlauerweise auch noch Passwörter enthielt - im Klartext! *Das* war der Oberhammer ;)

Den einen oder anderen Tag habe ich abgewartet in der Annahme, das würde sicher jemand bemerken und korrigieren - dem war jedoch nicht so. Entsprechend habe ich den Support auf die Problematik aufmerksam gemacht und es wurde immerhin entsprechend reagiert.

Tjoa, und einige Zeit später wechselten wir dann zu einem anderen Hoster, der hoffentlich mehr von Sicherheit verstand. Bei All-inkl kann man schon mal leicht am falschen Ende gespart haben.
DanielH
User
Beiträge: 5
Registriert: Donnerstag 15. November 2007, 20:13

Multithreading und Multiprocessing ist sinnvoll fuer CPU-lastige nebenlaeufige Programme, fuer IO-lastige Programme aber eventuell nicht optimal. Es gibt noch eine andere Moeglichkeit! Ich zitiere mal die Doku vom asyncore-Modul:
Danke Rebecca, jetzt versteh ich's ;)

(Du hattest ja schon mal asyncore erwähnt; allerdings bin ich nicht auf die Idee gekommen mal danach zu googln, bzw. ich hab gedacht ich wüste ungefähr, was es ist)

Ja, die Basics bekommst du schnell hin, das stimmt. Aber die richtigen Features einer Programmiersprache lernst du erst wenn du dich intensiv damit beschäftigst. Damit will ich dich natürlich nicht von dem Entschluss beide Sprachen zu lernen abbringen, will dir nur sagen, dass nachdem man die Basics hat, die richtig tollen Sachen erst noch kommen. Das sehe ich an mir selbst, wenn ich meine alten Programme anschaue und mir an den Kopf fassen muss, was ich damals zusammengeschrieben habe.
Da hast Du sicherlich Recht. Vermutlich werde ich mich auch früher oder später mit einer Sprache intensiver beschäftigen, als mit der/den Anderen (ich denke das kommt ganz automatisch ;) ).

Aber ehrlich gesagt bin ich schon glücklich, wenn ich fremde Scripte einigermaßen gut verstehe (mit ner kurzer Recherche nach unbekannten Funktionen ect.). Denn, erstens kann man alleine durch das Abändern von fremden Scripte eine Menge realisieren, und zweitens lernt man dadurch auch ziemlich schnell (finde ich).

Letzteres kann ich bestätigen: Zu meiner Zeit bei all-inkl tauche mal eine weitere Datenbank im Frontend (PMA) auf. Nach etwas Überfliegen stellte sich heraus, dass dies eine produktiv genutzte Datenbank eines anderen Kunden war. Die schlauerweise auch noch Passwörter enthielt - im Klartext! *Das* war der Oberhammer

Den einen oder anderen Tag habe ich abgewartet in der Annahme, das würde sicher jemand bemerken und korrigieren - dem war jedoch nicht so. Entsprechend habe ich den Support auf die Problematik aufmerksam gemacht und es wurde immerhin entsprechend reagiert.

Tjoa, und einige Zeit später wechselten wir dann zu einem anderen Hoster, der hoffentlich mehr von Sicherheit verstand. Bei All-inkl kann man schon mal leicht am falschen Ende gespart haben.

Ui, ok, das ich schon heftig. Wann war das denn? (Ist hoffentlich schon länger her ;) )

Das ist aber ehrlich gesagt erst das erste Mal, dass ich über die was schlechtes gehört habe.

Ach so, da hab ich dann wohl irgendwas falsch verstanden. Erstmal dachte ich PCRE sei der leicht modifizierte Perl engine, und dann [...]
Das scheint aber zu stimmen? Auf jeden Fall konnte ich quasi keinen Unterschied zwischen Perl engine und PCRE feststellen.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

DanielH hat geschrieben:Ui, ok, das ich schon heftig. Wann war das denn? (Ist hoffentlich schon länger her ;) )
Ja, das ist schon einige Jahre her. Das muss dennoch nichts heißen.
DanielH hat geschrieben:Das ist aber ehrlich gesagt erst das erste Mal, dass ich über die was schlechtes gehört habe.
Das mag daran liegen, dass unzufriedene Kunden oft ihr Feedback für sich behalten. Oder daran, dass viele "bei mir lief alles glatt" mit "alles ist perfekt" gleichsetzen und das dann so propagieren.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

DanielH hat geschrieben:
Ach so, da hab ich dann wohl irgendwas falsch verstanden. Erstmal dachte ich PCRE sei der leicht modifizierte Perl engine, und dann [...]
Das scheint aber zu stimmen? Auf jeden Fall konnte ich quasi keinen Unterschied zwischen Perl engine und PCRE feststellen.
Nein, stimmt nicht:
Wikipedia zu PCRE hat geschrieben:Perl Compatible Regular Expressions (kurz PCRE, deutsch Perl-Kompatible Reguläre Ausdrücke) ist eine Programmbibliothek zur Auswertung von Regulären Ausdrücken. Der Name bezieht sich darauf, dass die Syntax der Ausdrücke der Programmiersprache Perl entliehen wurde. Sie entsprechen etwa dem Stand von Perl 5.0, beinhaltet aber auch zusätzliche, im POSIX-Standard definierte Ausdrücke, die auch teilweise erst von Perl 5.10 aufgenommen werden. Trotzdem gibt es viele Unterschiede zwischen den heutigen, von Perl verwendeten Regex und PCRE da perl nach 5.0 stark erweitert wurde.
Die Unterschiede beziehen sich wohl auf weniger bekannte Features der Perl-Regex. Perl Regular Expressions sind unglaublich umfangreich, aber der Versuch diese Features zu nutzen kann recht einfach zu absolut unlesbaren Programmen führen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Antworten