Cash: In was ist GMX programmiert?

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

  1. 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

    1. 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

    2. 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

      1. 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

        --
        T'Pol: I apologize if I acted inappropriately.
        V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
        (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
         => http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
        Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
        1. 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

          1. 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

            --
            Ich bin ein spezialisz!
            (Zitat von VENGA JO)
            sh:) fo:) rl:° br:& ie:| mo:) va:) fl:) ss:| ls:< js:|
            Die Erklärung zum Selfcode findest du hier: http://emmanuel.dammerer.at/selfcode.html
            Einen Decoder für den Selfcode findest du hier: http://peter.in-berlin.de/projekte/selfcode
            1. 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

              1. 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

                --
                ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|
                1. 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

                  --
                  http://cforum.teamone.de/
                  http://wishlist.tetekum.de/
                  If God had meant for us to be in the Army, we would have been born with green, baggy skin.
                  1. 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

                    --
                    ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|
                    1. 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

                      --
                      http://cforum.teamone.de/
                      http://wishlist.tetekum.de/
                      If God had meant for us to be in the Army, we would have been born with green, baggy skin.
                      1. 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

                        1. 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

                          --
                          T'Pol: I apologize if I acted inappropriately.
                          V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
                          (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
                           => http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
                          Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
              2. 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

                --
                T'Pol: I apologize if I acted inappropriately.
                V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
                (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
                 => http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
                Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
          2. 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

            --
            T'Pol: I apologize if I acted inappropriately.
            V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
            (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
             => http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
            Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
            1. 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

              1. 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

                1. 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

                  --
                  T'Pol: I apologize if I acted inappropriately.
                  V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
                  (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
                   => http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
                  Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
                  1. 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

                    --
                    http://cforum.teamone.de/
                    http://wishlist.tetekum.de/
                    If God had meant for us to be in the Army, we would have been born with green, baggy skin.
                    1. 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

                      --
                      T'Pol: I apologize if I acted inappropriately.
                      V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
                      (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
                       => http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
                      Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
                      1. 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

                        --
                        http://cforum.teamone.de/
                        http://wishlist.tetekum.de/
                        If God had meant for us to be in the Army, we would have been born with green, baggy skin.
                        1. 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

                          --
                          T'Pol: I apologize if I acted inappropriately.
                          V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
                          (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
                           => http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
                          Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
                          1. 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

                            --
                            http://cforum.teamone.de/
                            http://wishlist.tetekum.de/
                            If God had meant for us to be in the Army, we would have been born with green, baggy skin.
                            1. 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

                              --
                              RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
                              Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.
      2. 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

        --
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. 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

  2. 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

    --
    T'Pol: I apologize if I acted inappropriately.
    V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
    (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
     => http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
    Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
    1. Hi Cash,

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

      warum?

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

  3. 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

    --
    If "Actions speak louder than words," how is that "The pen is mightier than the sword."?
    1. 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

      1. Hi,

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

        Mooo-ment.

        Cheatah *g*

        --
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
    2. 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

      --
      Location: Swindon/Wiltshire/England/UK/Europe/Northern Hemisphere/Planet Earth/Solar System/Milky Way Galaxy/Universe
      http://www.ministryofpropaganda.co.uk/