In was ist GMX programmiert?

[Cash]

Hallo,

mich würde mal interessieren in was GMX eigentlich programmiert ist. Weißt das vielleicht jemand?

Über eine Antwort würde ich mich sehr freuen.

Cash

[Thomas]

Hi!
Ich glaube das meiste in Perl.

http://www1.gmx.net/de/
cgi >>> Perl
/count/4/home/gmx_produkte/62/produkte?LANG=de&AREA=freemail

http://www1.gmx.net/de/cgi/count/4/home/gmx_produkte/62/produkte?LANG=de&AREA=freemail

Thomas

Hallo,

mich würde mal interessieren in was GMX eigentlich programmiert ist. Weißt das vielleicht jemand?

Über eine Antwort würde ich mich sehr freuen.

Cash

[Thomas Utermark]

Hi,

http://www1.gmx.net/de/
cgi >>> Perl
/count/4/home/gmx_produkte/62/produkte?LANG=de&AREA=freemail

Alleine durch das "cgi" lässt noch nicht auf Perl schließen, falls du das meinst. Man kann zum Beispiel auch kompilierte C++-Binaries und eine Vielzahl anderer Sachen in das cgi-Verzeichnis legen.

Gruß Tom

[Sönke Tesch]

Ich glaube das meiste in Perl.

http://www1.gmx.net/de/
cgi >>> Perl
/count/4/home/gmx_produkte/62/produkte?LANG=de&AREA=freemail

http://www1.gmx.net/de/cgi/count/4/home/gmx_produkte/62/produkte?LANG=de&AREA=freemail

Was möchtest Du mit dieser kryptischen Ansammlung von Buchstaben andeuten? Nur weil irgendwo CGI steht, bedeutet das noch lange nicht, daß Perl dahinter steckt. Es gibt auch PHP als CGI-Version, selbst Basic-Programme oder Shell-Skripte können sich hinter CGI verstecken, und selbstredend auch kompilierte Programme aus C, Modula oder Assembler. CGI ist die Abkürzung für Common Gateway Interface, und genau das ist es auch, eine allgemeine Schnittstelle - nicht mehr, nicht weniger.

Davon mal abgesehen ist es rein vom kaufmännischen her eher unklug, bei steigender Last noch auf Interpreter zu setzen. Dieses Forum ist in seiner Perl-Version schon zusammengebrochen, was soll dann er bei GMX passieren?

Gruß,
  soenk.e

[Michael Schröpl]

Hi Sönke,

Davon mal abgesehen ist es rein vom kaufmännischen her eher unklug, bei steigender Last noch auf Interpreter zu setzen. Dieses Forum ist in seiner Perl-Version schon zusammengebrochen, was soll dann er bei GMX passieren?

was hat die Implementierungssprache einer Anwendung mit der Performanz ihrer Datenstrukturen zu tun?
Du vergißt offenbar, daß auch das aktuelle Forum zu wesentlichen Teilen in Perl geschrieben ist ...

Viele Grüße
      Michael

[Sönke Tesch]

Davon mal abgesehen ist es rein vom kaufmännischen her eher unklug, bei steigender Last noch auf Interpreter zu setzen. Dieses Forum ist in seiner Perl-Version schon zusammengebrochen, was soll dann er bei GMX passieren?

was hat die Implementierungssprache einer Anwendung mit der Performanz ihrer Datenstrukturen zu tun?

Ich gehöre zu den Leuten, die der Meinung sind, daß Maschinencode prinzipiell schneller läuft als Geschichten, die erst in Maschinencode übersetzt werden müssen. Ich wüsste nicht, was die internen Datenstrukturen daran großartig ändern sollen.

Du vergißt offenbar, daß auch das aktuelle Forum zu wesentlichen Teilen in Perl geschrieben ist ...

Sorry, dann leide ich wohl an Halluzinationen. Ich war irgendwie der Meinung, daß dieses Forum wegen der inakzeptablen Geschwindigkeit von Perl vor einer Weile in C neu geschrieben wurde.

Gruß,
  soenk.e

[Christoph]

Hi,

ich glaube das man mit einem guten und schnellen Server auch viel Performance rausholen kann...
Und ich kenne ja Communitys oder Foren wo weitaus mehr Leute angemeldet sind oder schreiben und die Seiten laufen auch schnell und gut auch mit Perl oder Php...

Gruß Christoph

[Sönke Tesch]

ich glaube das man mit einem guten und schnellen Server auch viel Performance rausholen kann...
Und ich kenne ja Communitys oder Foren wo weitaus mehr Leute angemeldet sind oder schreiben und die Seiten laufen auch schnell und gut auch mit Perl oder Php...

Da hast Du mich falsch verstanden, ich habe nicht gesagt, daß sowas mit Hilfe einer Interpretersprache nicht möglich wäre. Ich bin lediglich der Meinung, daß der Leistungsunterschied zwischen Maschinencode und Interpreter im Allgemeinen deutlich erkennbar und im Speziellen in den Regionen, in denen große Dienste wie GMX agieren, kostenrelevant ist.

Oder anders ausgedrückt: Warum soll man Leistung für das andauernde, sich immer gleich wiederholende Interpretieren von Skripten verbraten, die man sie genauso gut für die Bedienung weiterer 5000 Nutzer verwenden könnte? Warum eine Maschine für 5000 kaufen, wenn durch Verzicht auf den Interpreterweg auch eine für 2500 reicht? (Die Zahlen sind rein willkürlich gewählt.)

Das Übersetzen von Programmiersprache in Maschinencode ist Arbeit, die man problemlos einmal vorher erledigen kann. Pluspunkte können Interpretersprachen wie Perl, PHP und auch Java (_Java_, Javascript ist ein Sonderfall) letztenendes nur dort gewinnen, wo es um schnelle Umsetzung eines Konzepts oder absolute Portabilität geht (Systemsicherheit lassen wir mal außen vor).
Bei der reinen Ausführungsgeschwindigkeit müssen sie aber prinzipbedingt immer hinten anstehen.

Gruß,
  soenk.e

[Andres Freund]

Hi,

Bei der reinen Ausführungsgeschwindigkeit müssen sie aber prinzipbedingt immer hinten anstehen.

Stimmt schon, aber um das lästige Umsetzten in Maschienencode bei jedem Aufruf zu vermeiden, gibt es Sachen wie beim Apache mod_perl, fastcgi (und bei php zend-cache oder so ähnlich, da bin ich mir aber nicht sicher). Ich kann auch Perl oder PHP (bin ich mir nicht ganz sicher) in eine direkt ausführbare Version verwandeln, auch wenn dies noch nicht immer ganz zuverlässig funktioniert.
Auch diese sind immer noch ein wenig langsamer als eine in einer systemnahen Sprache programmierte vom funktionsumfang equivalente Anwendung. Aber man darf nat. nicht die zusätzliche Arbeitszeit vergessen, die zu höheren Personalkosten führt, wenn man alles in einer lowlevel Sprache schreibt. Ich denke diese sind wesentlich teuerer als zusätzliche Maschienen.
Dass es systemnah länger dauert, wird wohl kaum einer bezweifeln, denke ich, sonst würde man wohl alles in Assembler schreiben ;-). Auch dass oft Sprachen wie Java für irgendwelche Serverseitigen Sachen genutzt werden, bestätigt dies meiner Meinung nach.

Grüße Andres Freund

[Christian Kruse]

Hallo Andres,

Bei der reinen Ausführungsgeschwindigkeit müssen sie
aber prinzipbedingt immer hinten anstehen.
Stimmt schon, aber um das lästige Umsetzten in
Maschienencode bei jedem Aufruf zu vermeiden, gibt es
Sachen wie beim Apache mod_perl,

mod_perl setzt nicht in Maschinencode um, sondern speichert
die Scripte nur in einem direkt interpraetierbaren Zustand.

fastcgi

mod_fastcgi ist fuer Binaries gedacht ;)

Ich kann auch Perl oder PHP (bin ich mir nicht ganz
sicher) in eine direkt ausführbare Version verwandeln,
auch wenn dies noch nicht immer ganz zuverlässig
funktioniert.

Ja, aber die Binaries sind immernoch um ein vielfaches
groesser. Und auch ist die Umsetzung in C-Code bei weitem
nicht so effizient: der ganze Scriptsprachen-Overhead muss
mitgeschleppt werden.

Auch diese sind immer noch ein wenig langsamer als eine in
einer systemnahen Sprache programmierte vom
funktionsumfang equivalente Anwendung. Aber man darf nat.
nicht die zusätzliche Arbeitszeit vergessen,

Eine Lowlevel-Sprache ist ja nicht noetig. Man kann auch
Hochsprachen compilieren (siehe C++).

Dass es systemnah länger dauert, wird wohl kaum einer
bezweifeln, denke ich, sonst würde man wohl alles in
Assembler schreiben ;-).

Ich glaube, du verwechselst da was.

Auch dass oft Sprachen wie Java für irgendwelche
Serverseitigen Sachen genutzt werden, bestätigt dies
meiner Meinung nach.

Java wird benutzt, weil es Hype ist. Die Sprache verbraucht Unmengen an Speicher, ist buggy und sie ist kreuzlahm. Es gibt
keinen objektiven Grund, Java zu verwenden.

Gruesse,
 CK

[Andres Freund]

Hi Christian,

Ja, aber die Binaries sind immernoch um ein vielfaches
groesser. Und auch ist die Umsetzung in C-Code bei weitem
nicht so effizient: der ganze Scriptsprachen-Overhead muss
mitgeschleppt werden.

Hab ich auch glaube ich nie behauptet. Auf jeden Fall ist es um längen schneller, als ohne mod_perl, und bietet auch noch nette andere Fähigkeiten, wie persistente Dantenbankanbindung, Speichern von Daten, etc, was ebenfalls viel Ausführungszeit spart.

Eine Lowlevel-Sprache ist ja nicht noetig. Man kann auch
Hochsprachen compilieren (siehe C++).

Habe ich das Gegentleil behauptet? Das war nur darauf bezogen, das Sönke meinte, bei gmx müsste alles in einer vergleichsweise (zu Perl) lowlevel Sprache benutzen. Woei man lowlevel in diesem Fall besser durch kompilierbare Sprache ersetzen sollte.

Ich glaube, du verwechselst da was.

Warum? In Assembler kann man doch ohne Zweifel sehr schnell schreiben (womit die Ausführungsdauer gemeint ist, oder?)  Ausserdem war durch das ;-) klar, dass das kein ernst gemeinter Vorschlag war. Es sollte auch nur darstellen, das man in einer Programmiersprache zwar schnellere Ergebnisse produzieren, aber dafür vergleichsweise extrem lange braucht, bis das Programm fertig ist.

Java wird benutzt, weil es Hype ist. Die Sprache verbraucht Unmengen an Speicher, ist buggy und sie ist kreuzlahm. Es gibt
keinen objektiven Grund, Java zu verwenden.

Kann sein, ich mag java auch nicht, besonders grafische Oberflächen sind scheußlich. Aber es wird nun einmal viel benutzt, egal aus welchem Grund auch immer, und ich glaube auch nicht, dass ich daran etwas ändern kann.

Grüße Andres Freund

[Christian Kruse]

Hallo Andres,

Bitte reisse meine Aussagen nicht aus dem Zusammenhang:

Ja, aber die Binaries sind immernoch um ein vielfaches
groesser. Und auch ist die Umsetzung in C-Code bei
weitem nicht so effizient: der ganze
Scriptsprachen-Overhead muss mitgeschleppt werden.

Hier ging es nicht um mod_perl, sondern um perlcc und andere Mechanismen (Uebersetzung von Scriptsprachen in C).

Ich glaube, du verwechselst da was.
Warum? In Assembler kann man doch ohne Zweifel sehr
schnell schreiben

Du hast es schon wieder getan.
Du hast geschrieben, systemnah zu programmieren braechte
Performance. In Assembler kann man aber nur schwer systemnah
programmieren. Da programmiert man eher hardwarenah. Systemnah
bedeutet, nahe am System, also am OS.

Gruesse,
 CK

[Andres Freund]

Hallo Christian,

Bitte reisse meine Aussagen nicht aus dem Zusammenhang:

Tut mir leid, merke ich jetzt im nachhinein auch, war aber nicht beabsichtigt, ich versuche mal richtigzustellen, wie ich es meinte.

Hier ging es nicht um mod_perl, sondern um perlcc und andere Mechanismen (Uebersetzung von Scriptsprachen in C).

Tut mir leid, ich hab leider falsch gequotet. Ich meinte, dass das Programm direkt in den Maschienencode für die VM übersetzt wird.

Hier ging es nicht um mod_perl, sondern um perlcc und andere Mechanismen (Uebersetzung von Scriptsprachen in C).

Eigentlich wollte ich _hierrauf_ antworten, dass ich nie gesagt habe, dass ein in c übersetztes Perl Programm mit einem direkt in c geschriebenen von der Geschwindigkeit her vergleichbar ist.

Du hast geschrieben, systemnah zu programmieren braechte
Performance. In Assembler kann man aber nur schwer systemnah
programmieren. Da programmiert man eher hardwarenah. Systemnah
bedeutet, nahe am System, also am OS.

Ok, dann korrigiere ich meine Aussage:
Ich bin der Meinung, dass man durch system und/oder Hardwarenahes Programmieren zwar sehr schnelle und effiziente Porgramme schreiben kann, aber dies sich oft nicht lohnt, da die höhere Effizienz nicht die durch die erhöhten Personalkosten, die entstehen, da man auf diese Weise unzweifelhaft länger braucht, ausgleicht. Sicher gibt es auch _sehr_ viele Anwendungsfälle in denen es wesentlich Ratsamer ist eine kompilierbare Hochsprache zu benutzen, da sonst die Geschwindigkeit zu niedrig ist, aber im Web-Bereich entstehen die Zeitverluste IMHO weniger durch die Geschwindigkeit des Programmes, sonder viel mehr durch andere Komponenten wie Verbindung zu einer Datenbank etc.

Vielen Dank, dass du mir manchmal noch die Unterschiede zwischen Hardwarenah und Systemnah deutlichmachst, dass wird sicher irgendwann mal nützlich sein. So lerne ich endlich mahl, mich richtig und genau auszudrücken.

Grüße Andres Freund

[Michael Schröpl]

Hi Andres,

Ich bin der Meinung, dass man durch system und/oder Hardwarenahes Programmieren zwar sehr schnelle und effiziente Programme schreiben kann, aber dies sich oft nicht lohnt, da die höhere Effizienz nicht die durch die erhöhten Personalkosten, die entstehen, da man auf diese Weise unzweifelhaft länger braucht, ausgleicht.

ich denke, das hängt davon ab, in wiefern ein "Skaleneffekt" eintritt, also sehr viele Leute von einem bestimmten Entwicklungsschritt profitieren.
Im Wesentlichen ist das wohl auch der Unterschied zwischen einem Produkt (dort mache ich eine solche Optimierung, falls möglich) und einer Lösung (da lohnt es sich meistens weniger).

Viele Grüße
      Michael

[Michael Schröpl]

Hi Sönke,

Warum eine Maschine für 5000 kaufen, wenn durch Verzicht auf den Interpreterweg auch eine für 2500 reicht? (Die Zahlen sind rein willkürlich gewählt.)

eben - und das ist das Problem. Tatsächlich reicht es ohne den Interpreter für 4785 Benutzer (weil die wesentlichen Zeitfresser nicht in der Interpretersprache stecken, sondern weiter innen - im HTTP-Roundtrip, in der DBI-Schnittstelle oder was auch immer), und dafür lohnt sich dann die Verwendung einer unterlegenen Entwicklungsumgebung nicht mehr.

Das Übersetzen von Programmiersprache in Maschinencode ist Arbeit, die man problemlos einmal vorher erledigen kann.

Das kannst Du nur dann sagen, wenn Deine Entwickler den Compile-Link-Go-Zyklus, den Umgang mit Makefiles und was auch immer von der Pike auf gelernt haben. Und was, wenn nicht?

Bei der reinen Ausführungsgeschwindigkeit müssen sie aber prinzipbedingt immer hinten anstehen.

Ja - aber um einen fast immer irrelevanten Faktor.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Sönke,

Du vergißt offenbar, daß auch das aktuelle Forum zu wesentlichen Teilen in Perl geschrieben ist ...

Sorry, dann leide ich wohl an Halluzinationen. Ich war irgendwie der Meinung, daß dieses Forum wegen der inakzeptablen Geschwindigkeit von Perl vor einer Weile in C neu geschrieben wurde.

das Forum wurde wegen inakzepabler Geschwindigkeit als _Client-Server-Applikation_ neu implementiert, wobei ein permanent laufender Server-Prozeß die Forums-Daten hält (deshalb geht auch etwas verloren, wenn dieser Prozeß crashed), während die Clients sich per socket mit diesem verbinden.
Der Server ist in C, die Clients in Perl
   (http://www.christian-seiler.de/projekte/cforum/installation.html#vorraussetzungen_perl)
, weil dort wohl das Parsen von Schablonen eleganter implementierbar war, glaube ich mich zu erinnern. Für die Geschwindigkeit ist die Sprache aber de facto egal.

Entscheidend war, daß die geänderte Architektur es nun ermöglicht, den Zustand des Forums permanent im Hauptspeicher zu halten, statt daß jedes einzelne CGI-Skript immer wieder die gesamten XML-Datenstrukturen parsen (und speichern!) muß - _das_ war in der bisherigen Version sehr teuer.
Die neue Architektur ist ein hochkomplexes Cache-System - praktisch eine Hauptspeicher-Datenbank. Und das macht den Unterschied aus - nicht die verwendete Sprache.

Viele Grüße
      Michael

[Christian Seiler]

Hallo Michael,

das Forum wurde wegen inakzepabler Geschwindigkeit als _Client-Server-Applikation_ neu implementiert, wobei ein permanent laufender Server-Prozeß die Forums-Daten hält (deshalb geht auch etwas verloren, wenn dieser Prozeß crashed), während die Clients sich per socket mit diesem verbinden.
Der Server ist in C, die Clients in Perl

Jain. Der Server, das "Leseprogramm" und der zukünftige Archivviewer sind alle in C geschrieben. Also alles, was schnell sein muss. Das "Postingprogramm" und die Benutzerkonfiguration sind dagegen in Perl geschrieben; ersteres, weil CK nach eigenen Aussagen nicht genug Zeit hatte, das in C zu realisieren; letzteres, weil die generische Datenbankanbindung von Perl zum Verwalten der Benutzer viel komfortabler als alle C-Lösungen ist. (CK hat das irgendwo im C-Forum mal erklärt, das jedoch gerade offline ist, daher kann ich den Link nicht raussuchen)

Für die Geschwindigkeit ist die Sprache aber de facto egal.

Jain. Die SELF-Suche hat einen neuen Überlastungsschutz bekommen, der in C funktioniert. (deswegen taucht da jetzt auch hack.cgi auf) Der Perl-Schutz der Suche hat sich als nicht resistent genug gegenüber DoS-Attacken erwiesen.

Viele Grüße,
Christian

[Sönke Tesch]

Jain. Der Server, das "Leseprogramm" und der zukünftige Archivviewer sind alle in C geschrieben. Also alles, was schnell sein muss.

Aha, "was schnell sein muß"..

[..] sind in Perl geschrieben; weil CK [..] nicht genug Zeit hatte, das in C zu realisieren; letzteres, weil die generische Datenbankanbindung von Perl zum Verwalten der Benutzer viel komfortabler als alle C-Lösungen ist.

Also kurz: Faulheit des Programmierers (nein, das soll kein Vorwurf sein, wir sind doch alle gern mal faul :).

[Michael]

Für die Geschwindigkeit ist die Sprache aber de facto egal.

Auch wenn es in Christians Beschreibung oben anders aussieht, die Ausführungsart mag meinetwegen dem SelfForums-Team egal gewesen sein, ich sehe da aber nirgends eine Begründung dafür, daß dieser Punkt generell egal ist, sprich daß ein Perl-Programm die gleiche Geschwindigkeit aufweist wie ein gleiches in Maschinencode. Michael, Du kannst doch nicht hingehen und zwei offenbar verschiedene Konzepte  (Du schriebst etwas von "geänderte Architektur") miteinander vergleichen und das Ergebnis dann auf die Ausführungsart übertragen. Das ist doch ein Vergleich von Äpfeln und Birnen.

Die _gleiche_ Vorgehensweise eines Programs ist in Maschinencode immer schneller ausführbar als in interpretierter Form. Natürlich mag es Unterschiede durch das Gewicht einzelner Teilaufgaben (insbesondere: Dateinein- und Ausgabe) geben, natürlich mag es bei quasi überdimensionierter Hardware auch vollkommen wurscht sein, aber das ändert nichts am Grundsatz und diese Punkte treten, um mal wieder zur Ausgangsfrage zurück zu kommen, bei steigender Anforderung gegenüber dem absoluten Leistungsverlust durch das Interpretieren in den Hintergrund.

Gruß,
  soenk.e

[Michael Schröpl]

Hi Sönke,

Michael, Du kannst doch nicht hingehen und zwei offenbar verschiedene Konzepte  (Du schriebst etwas von "geänderte Architektur") miteinander vergleichen und das Ergebnis dann auf die Ausführungsart übertragen. Das ist doch ein Vergleich von Äpfeln und Birnen.

doch, genau das kann ich tun. Komplexitätstheorie macht praktisch nichts anderes. Das eine ist ein Unterschied in der Komplexitätsklasse, das andere einer im skalaren Vorfaktor - und bei hinreichend großem <n> fällt letzterer hinter die Heizung.

Viele Grüße
      Michael

[Christian Kruse]

Hallo Michael,

Michael, Du kannst doch nicht hingehen und zwei offenbar
verschiedene Konzepte  (Du schriebst etwas von
"geänderte Architektur") miteinander vergleichen und
das Ergebnis dann auf die Ausführungsart übertragen.
Das ist doch ein Vergleich von Äpfeln und Birnen.

doch, genau das kann ich tun.

Aber nur, wenn du ausser acht laesst, dass die
Uebersetzungsphase bei compilierten Programmen bereits
geschehen ist, aber bei interpretierten Programmen noch
geschehen muss.
Aber nur, wenn du ausser acht laesst, dass zusaetzlich zu dem
zu ladenden Script noch die zu ladende Interpreter-Binary
kommt.
Aber nur, wenn du ausser acht laesst, dass die zu ladende
Interpreter-Binary im allgemeinen x-mal kleiner ist als die
compilierte Binary.

Das sind aber alles Sachen, die man beim Thema Performance
*nicht* ausser acht lassen darf.

Gruesse,
 CK

[Michael Schröpl]

Hallo Christian,

Das ist doch ein Vergleich von Äpfeln und Birnen.
doch, genau das kann ich tun.
Aber nur, wenn du ausser acht laesst ...

das tue ich gar nicht.

Aber es sind skalare Faktoren, während Deine architektonische Leistung den Wechsel in eine andere Komplexitätsklasse ermöglicht. Je größer die Datenmenge, desto unwesentlicher werden diese skalaren Faktoren.

Aber nur, wenn du ausser acht laesst, dass zusaetzlich zu dem
zu ladenden Script noch die zu ladende Interpreter-Binary
kommt.

Liegt der Perl-Interpreter bei Dir nicht im Festplattencache, wenn er ständig gebraucht wird?

Viele Grüße
      Michael

[Christian Kruse]

Hallo Michael,

Das ist doch ein Vergleich von Äpfeln und Birnen.
doch, genau das kann ich tun.
Aber nur, wenn du ausser acht laesst ...

das tue ich gar nicht.

Aber es sind skalare Faktoren, während Deine
architektonische Leistung den Wechsel in eine andere
Komplexitätsklasse ermöglicht. Je größer die Datenmenge,
desto unwesentlicher werden diese skalaren Faktoren.

Nun, das sehe ich nicht ganz so.

Aber nur, wenn du ausser acht laesst, dass zusaetzlich
zu dem zu ladenden Script noch die zu ladende
Interpreter-Binary kommt.

Liegt der Perl-Interpreter bei Dir nicht im
Festplattencache, wenn er ständig gebraucht wird?

Sicher -- aber was bringts? Sie muss trotzdem jedesmal geladen
werden (in den Hauptspeicher, in die EXU, etc).

Gruesse,
 CK

[Michael Schröpl]

Hallo Christian,

Liegt der Perl-Interpreter bei Dir nicht im
Festplattencache, wenn er ständig gebraucht wird?
Sicher -- aber was bringts? Sie muss trotzdem jedesmal geladen
werden (in den Hauptspeicher, in die EXU, etc).

wer sagt Dir, daß dasjenige Stückchen Festplattencache (d. h. derjenige Puffer des Dateisystems, der für den Zugriff auf diese Festplatte zuständig ist) nicht bereits im Hauptspeicher liegt?

Je öfter auf den Perl-Interpreter zugegriffen wird, desto wahrscheinlicher ist genau dies.

Viele Grüße
      Michael

[Christian Kruse]

Hallo Michael,

wer sagt Dir, daß dasjenige Stückchen Festplattencache
(d. h. derjenige Puffer des Dateisystems, der für den
Zugriff auf diese Festplatte zuständig ist) nicht bereits
im Hauptspeicher liegt?

Da haette man sich hoechstens einen (zugegebenermassen recht teuren) Schritt gespart ;) bleiben aber immer noch
Speicher<->Prozessor.

Es ist einfach wesentlich mehr, was der Perl-Interpreter alles
machen muss. Ein kompiliertes, auf den Zweck hin optimiertes
Programm muss viel weniger tun, weil es viel weniger allgemein
ist als der Perl-Interpreter.

Gruesse,
 CK

[Philipp Hasenfratz]

Halihallo Christian

Es ist einfach wesentlich mehr, was der Perl-Interpreter alles
machen muss. Ein kompiliertes, auf den Zweck hin optimiertes
Programm muss viel weniger tun, weil es viel weniger allgemein
ist als der Perl-Interpreter.

Man vergleiche hierzu die Ausgaben von perlcc eines "hello world" Perl-Scripts, mit
seinem C-Äquivalent.

@Michael: Das Caching des OS mag einiges helfen und dennoch hat Perl vergleichsweise
beträchtlich hohe Starup-Times. Diese liessen sich mit vorkompiliertem Perlopcode zwar
noch etwas verbessern, aber es ist immer noch ziemlich langsam. Zudem: Egal was das
Script macht, ein Startup braucht es _bei jedem Start_ (egal ob von Cache oder Platte)
und genau diesen kann man ja einsparen.

Viele Grüsse

Philipp

[Cheatah]

Hi,

Nur weil irgendwo CGI steht, bedeutet das noch lange nicht, daß Perl dahinter steckt.

es heißt nicht mal, dass CGI dahinter steckt :-)

Cheatah

[Sönke Tesch]

Nur weil irgendwo CGI steht, bedeutet das noch lange nicht, daß Perl dahinter steckt.

es heißt nicht mal, dass CGI dahinter steckt :-)

Auch wieder wahr. Was'n Mumenschanz ;)

Gruß,
  soenk.e

[Michael Schröpl]

Hi Cash,

mich würde mal interessieren in was GMX eigentlich programmiert ist.

warum?

Weißt das vielleicht jemand?

GMX selbst weiß es sicherlich.

Viele Grüße
      Michael

[O-Mann]

Hi Cash,

mich würde mal interessieren in was GMX eigentlich programmiert ist.

warum?

neue Variante?
Ich habe mit "definiere GMX gerechnet" !!! ;-)

[Calocybe]

Hi!

mich würde mal interessieren in was GMX eigentlich programmiert ist. Weißt das vielleicht jemand?

Also... GMX ist eine Firma, und Firmen werden nicht programmiert, sondern gegruendet bzw. angemeldet oder vielleicht auch "aufgebaut". Ich frage mich also, was Du jetzt eigentlich wissen willst.

So long

[Wilhelm Turtschan]

Moin Roland,

Also... GMX ist eine Firma, und Firmen werden nicht programmiert, sondern gegruendet bzw. angemeldet oder vielleicht auch "aufgebaut". Ich frage mich also, was Du jetzt eigentlich wissen willst.

<Troettrottroet>

Dafuer kriegst Du den "cheatah der Woche". :-)

Gruesse
Wilhelm

[Cheatah]

Hi,

<Troettrottroet>
Dafuer kriegst Du den "cheatah der Woche". :-)

Mooo-ment.

Cheatah *g*

[Armin G.]

Tach auch,

Also... GMX ist eine Firma, und Firmen werden nicht programmiert, sondern gegruendet bzw. angemeldet oder vielleicht auch "aufgebaut".

Besessen werden sie auch noch bzw in sie investiert. Im Fall von GMX von der 1&1 Internet AG, die wiederum zur United Internet AG gehoert.

Nur der Vollstaendigkeit halber ;-)

Gruss,
Armin