Startseiterupture de caténaire

Interpretierte vs. Compilierte Sprachen in wissenschaftlicher Software (Bioinformatik)

Von / 5. November 2019 / 50 Kommentare / Seite 4 von 4 / Auf einer Seite lesen
Mehr

Und zu guter Letzt gibt es inzwischen auch gute Bibliotheken für die Bioinformatik, die das Entwickeln in C++ oder Rust vereinfachen. Und da purzeln auch Anwendungen heraus: Ein Silberstreif am Horizont bioinformatischer Anwendungsentwicklung …

 

* Ich “kompiliere” mit dem Compiler – ja, das ist inkonsequent.

** Wir haben derartige Rechnungen/Jobs stark eingeschränkt. Auf einem Tier3-System. Nur falls jemand mit HPC-Erfahrung verwundert einwenden will, dass so Etwas bei ihr / ihm ja gar nicht gehe.

*** Ja, es gibt mpi4Py oder Rmpi (bewußt nicht verlinkt), aber das unterstreicht eher meinen Punkt: Langsame Algorithmen / Implementierungen können viel besser skalieren (wenn ich meine CPUs lange nutze, kann das Zufügen von CPUs zu einer besseren scheinbaren Nutzung führen. Aber dennoch ist das a) eine Verschwendung von Ressourcen und b) gibt es bei interpretierten Sprachen viel engere Grenzen, der Skalierbarkeit. Es gibt keinen Fall, wo man damit viele tausend CPUs gleichzeitig nutzen kann.

flattr this!

1 / 2 / 3 / 4
Stichworte: , , , , , , , , ,
Mehr

Kommentare (50)

  1. #1 Nestiiii
    Linz
    6. November 2019

    Hallo Christian – Netter Artikel – Danke dafür!

    Einen kleinen Hinweis hätt ich -> Du schreibst
    …”Sie ist immerhin schon 10 Jahre alt und listet zusätzlich C#, aber die Sprache ist mir egal, weil ich unter Linux arbeite (HPC cluster arbeiten z. Zt. ausschließlich unter Linux und zusätzliche Laufzeitumgebungen, wie mono, machen die Software nicht schneller oder leichter zu nutzen).” – Es gibt jetzt .NET Core – läuft super unter Linux, ist OpenSource und die Zukunft von .NET – die neusten C#8 Sprachfeatures sind mit .NET Core 3 verfügbar. Als IDE lässt sich VisualStudioCode unter Linux/Mac/Windows nutzen.

    Lg

    • #2 Christian Meesters
      6. November 2019

      mono war nur ein Beispiel, klar. .NET Core ist keine wirkliche Alternative: In der HPC Community fällt so ziemlich alles aus dem Redmonder Haus unter den Tisch. Der Grund ist einfach, dass man immer zusätzliche, unnötige Abhängigkeiten einhandelt und es gute freie Alternativen gibt. Vor allem aber, dass Parallelisierung über viele tausend Kerne mit .NET Core auch nicht angedacht, aber schlicht manchmal notwendig ist.

      Meine pers. Meinung: Ob Veröffentlichung wissenschaftlicher Resultate oder Programmierung – in keinem Fall sollte die öffentliche Hand Geld für Dienstleistungen ausgeben, die mit der angebotenen Lösung zusätzliche Abhängigkeiten und abermalige Investitionen erfordern. Vielleicht sollte ich mal darüber schreiben? Vielleicht mal über Matlab???

  2. #3 echt?
    6. November 2019

    Das Problem ist oft die Dokumentation der Ergebnisse. Wenn die Berechnungen nicht zu umfangreich sind, reicht da VBA in Excel völlig aus. Im Übrigen könnte die Ablehnung von “neuen” Programmiersprachen daran liegen, dass die User irgendwann keinen Bock mehr haben sich in die neuundneunzigste Programmiersprache einzuarbeiten. Kurioser Weise ist man bei VBA fast wieder beim uralten BASIC angekommen.

    Da gerade Wissenschaftler mit Zeitvertrag nicht ewig an Supersoftware fummeln können und die meiste Software nach der Promotion im Orkus verschwindet, sehe ich das Problem gelassen. Interessant wäre eine Abschätzung,

    • #4 Christian Meesters
      6. November 2019

      Da gerade Wissenschaftler mit Zeitvertrag nicht ewig an Supersoftware fummeln können und die meiste Software nach der Promotion im Orkus verschwindet, sehe ich das Problem gelassen.

      Na ja, aber das Software publiziert wird und allenfalls den “workfs-for-me”-Status erreicht ist schon problematisch: Zwar wird nur ein kleiner Prozentsatz aufgegriffen, aber die Bitte Tool X der neuesten Publikation zu installieren wird häufig an unsereins herangetragen. Wie oft mußte ich schon sagen: Jau, aber das geht nicht; die Entwickler melden sich nicht, um den Bug zu beseitigen; die Entwickler nehmen keinen Patch mehr an, etc. etc.. Insofern bin ich schuldig im Sinne der Anklage: Da fehlt mir Gelassenheit ;-).

  3. #5 echt?
    6. November 2019

    welcher Prozentsatz an “wissenschaftlicher” Software wirklich langfristig genutzt wird.

  4. #6 Karl Mistelberger
    mistelberger.net
    6. November 2019

    Bei diesem Thema kommt ein wichtiger praktischer Effekt viel zu kurz. Zwar sind kompilierte Programme bei gekonnter Optimierung schneller als interpretierte.

    Die typischen Aufgaben im Ingenieurwesen und in der Wissenschaft haben eines gemein: Die Leute benutzen in fast allen Fällen für die eigentliche Arbeit hoch optimierte Libraries, so dass die im Interpreter verbrachte Zeit zu vernachlässigen ist.

    Ein kleines Beispiel zur Veranschaulichung:

    https://www.fourmilab.ch/fbench/fbench.html

    Entscheidend ist also in den meisten praxisrelevanten Fällen nicht wie schnell eine Sprache ist, sondern ob es für sie optimierte Libraries gibt.

    • #7 Christian Meesters
      6. November 2019

      Völlig einverstanden – nur muss man halt seine Werkzeuge nach den Aufgaben auswählen. Ich schrieb glaube ich: Die Frage ist ja, soll meine Software nur eine kleine Tabelle bearbeiten oder terrabyteweise Daten?

  5. #8 H.Wied
    6. November 2019

    Bei Programmen ist auch der Kopierschutz wichtig. Damit ist jetzt der Klau der Idee gemeint, also der Quelltext.
    Eine .exe Datei zu kopieren hat wenig Sinn, weil das Progaramm damit nicht abgeändert werden kann. Der Ideenklau findet nicht statt.
    Bei Interpretern ist das anders. Da kann ein Programmierer, der den Sinn eines Programmteils versteht, diese Teile verwenden und sich damit viel Arbeit sparen.
    Ein compiliertes Programm ist einfach sicherer.

    • #9 Christian Meesters
      6. November 2019

      DA muss ich widersprechen: Wissenschaft lebt von Offenheit. Kompiliert oder nicht hat nichts mit der Frage zu tun, ob die Software quelloffen ist. Prä-kompilierte Programme installieren wir aus Performancegründen nur ungern – wenn überhaupt.

  6. #10 tomtoo
    6. November 2019

    @christian
    Wäre für die Bioinformatik eine Sprache wie Julia nicht genau das richtige? Compiliert, parallelisiert. Von Anfang an für den Wissenschaftler im Hinterkopf. Zudem leicht mit Phyton und c++ zu verbinden.

    • #11 Christian Meesters
      6. November 2019

      Wäre für die Bioinformatik eine Sprache wie Julia nicht genau das richtige?

      Klar, auch die Leute bei Julia versucht im Wettbewerb mit zu mischen. Hätte ich auch aufzählen müssen. Aber Julia ist mir seid der EuroScipy 2014 im Alltag nicht untergekommen. Der Grund ist mir nicht klar. Unser build-framework bietet nur prä-kompilierte Binaries, die offenbar kaum nachgefragt werden. Also: Warum Julia eine offenbar geringe Rolle spielt, kann ich nicht beantworten.

  7. #12 tomtoo
    6. November 2019

    Julia wäre doch evtl. eine passende Alternative?
    https://m.youtube.com/watch?v=6CpPd6tkokQ

  8. #13 Christian Meesters
    6. November 2019

    @all: Warum die Kommentare von mir freigeschaltet werden müssen, habe ich noch nicht raus. Eigentlich sollte das den Einstellungen nach nicht(!) der Fall sein. Ich werde nachfragen. Diskussionen unterbinden ist meine Sache nicht.

  9. #14 rolak
    6. November 2019

    habe ich noch nicht raus

    Wohl ein unterbliebener code review – und wenn es nur bzgl des GUI für den Blogger ist…

  10. #15 rolak
    6. November 2019

    (sorry für DoppelFreischaltArbeit, Thementeil verschlunzt)

    Der Unterschied zwischen CompilerSprache und InterpreterSprache ist doch konstruiert bzw unnötigerweise aber bewußt existent gehalten. Es ist halt ein Armutszeugnis, wenn für durchaus akzeptable InterpreterSprachen kein ordentlicher Compiler generiert wird. Klar, dann gehen einige SpezialEffekte nicht ohne (ins Kompilat einzubindende) InterpreterTeilruntime, als Beispiel nur das ziemlich verbreitete eval() und seine funktionalen Schwestern. Just diese Funktionalität wird typischerweise von denselben Dumpfbacken zwingend compilierbar eingefordert (bzw als ‘sorry’-Argument für ‘generell nicht kompilierbar’ vorgeturnt), die bei der kleinsten code-verändernden Praxis in ASM and elsewhere Zeter und Mordio schreien…

    Hab noch keinen (wg dem flotten turnaround) RAD-Nutzer sich beschweren hören, daß jedesmal so grotesk große libs eingebunden werden.

    • #16 Christian Meesters
      6. November 2019

      Es ist halt ein Armutszeugnis, wenn für durchaus akzeptable InterpreterSprachen kein ordentlicher Compiler generiert wird.

      Warum? Wie soll das im Allgemeinen funktionieren? Dynamische Sprachen können ja den Typ einer Variable ändern lassen. Zwar gibt es z. B. Cython, aber da werden im Python-Modus halt auch Pythonobjekte generiert. In C zwar und damit messbar schneller, aber immer noch viel langsamer, als wenn man die Typen definiert (wenn man sie eingrenzen kann).

  11. #17 Alexander Hoßdorf
    6. November 2019

    Hallo, als Informatiker fehlt mir bei deiner Bewertung die Betrachtung der Typsicherheit als wichtiges Qualitätskriterium zur Korrektheit der Software. Überspitzt ausgedrückt: Viele einfache Fehler findet der Entwickler bereits beim Kompilieren, während beim Interpretieren erst der Anwender der Software diese Art von Fehlern entdeckt.

    • #18 Christian Meesters
      6. November 2019

      Ja, das ist ein Aspekt, den ich unterschlagen habe. Danke.

  12. #19 LasurCyan
    6. November 2019

    Warum die Kommentare von mir freigeschaltet werden müssen, habe ich noch nicht raus.

    Teamwork Christian! Frag einfach bei Deinen Kolleg*nnen hier bei SBs nach..

    Danke für die Beiträge bisher, hier schau ich gern öfter vorbei, auch, oder gerade weil es überhaupt nicht mein Fachgebiet ist^^

    • #20 Christian Meesters
      6. November 2019

      Frag einfach bei Deinen Kolleg*nnen hier bei SBs nach..

      Das habe ich angekündigt und getan – auf Seiten von Konradin wird nach dem Fehler geschaut.

  13. #21 Spritkopf
    6. November 2019

    Was für Anwendungen werden denn überhaupt in der Bioinformatik entwickelt? Mir fehlt da ein bißchen der Überblick und daher kann ich deine Anmerkungen, welche Sprachen wieviel Hardwareleistung und Resourcen fressen, gar nicht einordnen. Wie du schon richtig schreibst: Wenn man nur ein paar Tausend Datensätze abzuarbeiten hat, dann langt dafür eine interpretierte Sprache vollauf. Bei Millionen oder noch mehr Datensätzen ist das gleich ein ganz anderer Schnack.

    Und C oder C++ stellen die meisten BioinformatikerInnen vor große Hürden.

    Das wundert mich. Ist denn die Informatik in der Disziplin Bioinformatik so stark unterrepräsentiert? (Jaja, ich weiß: C++ != Informatik).

    • #22 Christian Meesters
      6. November 2019

      Ist denn die Informatik in der Disziplin Bioinformatik so stark unterrepräsentiert?

      1. Ist das abhängig vom Studiengang und -ort.
      2. Gibt es nicht die Bioinformatik, sondern verschiedene Ebenen von der Anwendungsseite bis zu den genuinen “Ausschließlich-EntwicklerInnen”. Aber Software veröffentlichen tun alle.
      3. Und – das ist leider nicht unwichtig: Oft wird in nicht IT-affinen AGs ein/e IT-affiner Student/in darangesetzt ein spez. Problem zu lösen. Diese Lösung wird dann veröffentlicht.

      Offen einzusehen, was es so gibt ist BMC Bioinformatics – ja, da ist nicht alles so schlecht, wie ich suggeriere.

  14. #23 user unknown
    https://demystifikation.wordpress.com/
    7. November 2019

    Performance ist ein schwieriges Problembündel. Wenn man nicht tagaus/tagein programmiert, Erfahrungen sammelt, sich weiterbildet usw. verzettelt man sich leicht in Microoptimierungen.
    Vollzeitprogrammierern, die man beauftragt ein funktionierendes Programm nochmal umzusetzen, diesmal nach den Regeln der Programmierkunst, fehlt vielleicht für die Aufgabe dann das Biofachwissen. Abhängig von der Größe der Programme kann es ewig dauern, sich da einzuarbeiten.
    Wenn man sich nur die Programme vorknöpft, die häufig und/oder sehr lange laufen hat man vielleicht zu wenige Aufträge, um einen Programmierer wirtschaftlich gewinnbringend auszulasten.

    Mit Aufkommen des “just in time” Compilers in der Java-Virtual Machine (VM) wird nicht mehr “nur” interpretiert, doch andererseits gibt es kein ohne Java-VM ausführbares Programm.

    Das ist nicht klar verständlich. Der JIT-Compiler ist ja nicht erst gestern aufgekommen, sondern schon Ende der 90er. Aber von Beginn an wurden Javaprogramme compiliert — nicht zu Maschinensprache für die verschiedenen Zielplattformen, sondern zu einem Zwischencode, genannt Bytecode, obwohl ja auch Quellcode und Maschinencode in Bytes rumliegt.

    Also wann wurde Java Deiner Meinung nach nur interpretiert?

    Der JIT-Compiler hat dazu geführt, dass weniger vorher compiliert wird, weil erst zur Laufzeit die Maschine, auf der das Programm läuft, analysiert wird und daher individuelle Optimierungen möglich sind und zweitens der Programmfluss empirisch analysiert werden kann, so dass besonders häufig durchlaufene Teile aggressiver optimiert werden können.

    In Scala gibt es übrigens von Beginn an eine REPL, obwohl der Code auch zu Bytecode compiliert werden kann und Java hat sein wenigen Jahren jetzt auch eine JShell genannte REPL.

    Und von Nieschenprodukten, die Javacode in Maschinensprache umgewandelt haben, habe ich auch immer wieder gehört, mich allerdings nicht weiter dafür interessiert, weil ich es gerade interessant fand, zur Not für Windowstüten Programme unter Linux schreiben zu können. Bekannt wurde nichts davon – vielleicht haben die auch nur den Code zusammen mit einer JVM in ein Archiv gepackt, in dem die JVM versteckt war, und das Programm hat sich zur Laufzeit dann samt JVM immer entpackt und gestartet – keine Ahnung. Auf Linux gab es auch so eine merkwürdige Entwicklung mit nativ ausführbarem Javacode, der aber auch keine große Fanbasis fand – ob die irgendwie getrickst haben und was die gemacht haben, weiß ich auch nicht – normale ELF-Binaries sind da meine ich auch nicht rausgefallen – ich bin da nur oberflächlich informiert, weil das trotz einer gewissen Anfangsneugier nicht leicht zu eruieren war.

    Nun, und jenseits der PC-Welten gab es noch die Javacard, keine Intelplattform, die m.W. Javacode nativ ausgeführt hat und extra dafür entwickelt worden war, damals, bei SUN.

    Und einen 8- oder 16-Bit-Controller hatte ich namens JControl-Unit, der konnte mit einer Teilmenge der JRE-Libraries, sehr, sehr abgespeckt, arbeiten; die Syntax in der man seine Programme geschrieben hat war Java, aber wegen der Unvollständigen Standardimplementierung wohl nicht offiziell Java. Den Quellcode konnte man auch auf dem PC kompilieren und laufen lassen, aber in die umgekehrte Richtung das meiste nicht – keine Swing-GUI zum Beispiel. Aber da würde ich einräumen, dass man das nicht unbedingt Java nennen muss.

  15. #24 rolak
    7. November 2019

    Warum? Wie [compiler] (..) Typ einer Variable ändern [Cython langsam]?

    vorab) Du bist in eine andere Unterscheidung hinübergehüpft, Christian, unterscheidest nicht mehr (wie im Titel noch) zwischen verschiedenen Übersetzungs-, sondern zwischen verschiedenen SprachKonzepten. Selbsterständlich sind unterschiedliche Sprachkonzepte generell durch unterschiedlichen Aufwand bei Implementierung und Laufzeit ‘gesegnet’.

    /warum/ um möglichst viele mögliche Fehler bereits zur Übersetzungszeit abfangen zu können. Diese KundenSicherheit wird selbstverständlich, wie bereits von Alexander angemerkt, von diversen Sprachkonzepten mehr oder weniger gemindert bis torpediert. Letztere sind allerdings eine ProduzentenEntscheidung in Möglichkeitsbereichen à la dynamische Typisierung&Abarbeitung (automagisch ohne Nachdenken | benutzergeführt mit existentem Konzept) – und für ersteres gibt es ausreichend abschreckende Beispiele.

    /wie../ zuerst einmal wird nicht der Typ der Variable geändert, sondern der Typ des von ihr referenzierten(→) Objektes – und das ist Übersetzer-unabhängig zB durch Datenpaare (→TypeDef, →MemoryPicture) realisierbar, egal ob nun die Typdefinition in das Speicherbild integriert wird oder separat gelagert wird. (Bsp)

    • #25 Christian Meesters
      8. November 2019

      Du bist in eine andere Unterscheidung hinübergehüpft

      Na ja, Du bist angefangen einen Rant zu schreiben und ich habe, weil ich implizit ja nur dynamische Sprachen in dem interpretierten Töpfchen hatte, Annahmen getroffen, die ich an der Stelle wohl nicht hätte treffen sollen. Mea Culpa.

      Das Konglomerat Scala/Spark/(Hadoop/Java) habe ich ja überhaupt nicht betrachtet – es war einfach nicht im Fokus dieses Artikels.

  16. #26 Karl Mistelberger
    mistelberger.net
    7. November 2019

    Ohne ausgefeilte und effiziente Technik ist alles nichts, sei es bei der Hardware oder bei der Software:

    https://media.ccc.de/v/35c3-9703-supermuc-ng

  17. #27 Karl Mistelberger
    mistelberger.net
    7. November 2019

    > #13 Christian Meesters, 6. November 2019
    > Warum die Kommentare von mir freigeschaltet werden müssen, habe ich noch nicht raus. Eigentlich sollte das den Einstellungen nach nicht(!) der Fall sein. Ich werde nachfragen. Diskussionen unterbinden ist meine Sache nicht.

    Nicht nur auf die Hardware und die Software an sich kommt es darauf an. Da benutzen zwei Leute WordPress. Sie machen aber gänzlich unterschiedliche Erfahrungen:

    https://karlmistelberger.wordpress.com/2010/10/30/karls-hug-for-the-happiness-engineers/

  18. #28 Karl Mistelberger
    mistelberger.net
    8. November 2019

    > #23 user unknown, 7. November 2019
    > Performance ist ein schwieriges Problembündel. Wenn man nicht tagaus/tagein programmiert, Erfahrungen sammelt, sich weiterbildet usw. verzettelt man sich leicht in Microoptimierungen.

    Dass das Rumbasteln nicht viel bringt fällt ziemlich schnell auf und stellt daher kein Problem dar.

    > Vollzeitprogrammierern, die man beauftragt ein funktionierendes Programm nochmal umzusetzen, diesmal nach den Regeln der Programmierkunst, fehlt vielleicht für die Aufgabe dann das Biofachwissen. Abhängig von der Größe der Programme kann es ewig dauern, sich da einzuarbeiten.

    Um ein Programm zu optimieren braucht es kein Fachwissen. Es reicht, die verschiedenen Probleme der Benutzer zu analysieren und sich mit deren Unterstützung mit dem Ablauf der jeweiligen Berechnung vertraut zu machen. Um einen effizienten Mail Server zu schreiben braucht es kein Wissen darüber, was in den einzelnen Mails drinnen steht.

    Momentan bereiten mir Fotoalben Kopfzerbrechen, hier ein Beispiel:

    https://www.mistelberger.net/Tiger/index.html

    Alle meine Fotos sind derzeit in einem Album mit ca 60.000 Bildern und Filmchen aufgehoben. Wenn ich von einer Wanderung zurück komme lade ich die Fotos hoch, was sehr schnell erledigt ist (einige Sekunden).

    Für ein konsistentes Album müssen die zugehörigen 2.000 index.html und data1.json überprüft und gegebenenfalls aktualisiert werden. jAlbum bietet derzeit nur die Brute Force Methode: alle neu erstellen (einige Minuten) und hochladen (einige zehn Minuten).

    Ein make Algorithmus könnte die Prozedur erheblich abkürzen. Der Hersteller sieht sich aber nicht in der Lage, diesen zu implementieren.

    Preisfrage: Welche Optionen habe ich?

  19. #29 rolak
    8. November 2019

    angefangen einen Rant zu schreiben

    Nee, Christian, das war ein Kommentar mit einem kleinen RantMittelteil, gerichtet an die (vorgeblichen) Jünger* des auf ewig unveränderlichen Codes.

    nur dynamische Sprachen in dem interpretierten Töpfchen

    Nun, das war ja wohl bestenfalls eine Unterteilung nach ‘kennt man eher mit’, da in der I-Liste auch Sprachen mit Compiler, in der C-Liste auch Sprachen mit Interpreter sind (jaja, ich weiß, das scheinen viele nicht zu wissen (Bsp))

    Konglomerat Scala/Spark/(Hadoop/Java)

    Sorry? Hab ich davon?
     
    NeeNee, prinzipiell machen Interpreter und Compiler erst mal genau dasselbe: sie unternehmen den Versuch, den Quelltext mittels lexikalischer Analyse zu verstehen, zu überprüfen und zu übersetzen in (meta für Compiler2, bytecode für Interpreter2, incremental build, direkte Aktion, <was auch immer noch kommen mag>).
    Diese ach so tolle Wahlfreiheit bei der dynamischen LaufzeitTypisierung, ist sie überhaupt so frei? Wo kommt der neue, zur SourceGenese noch unbekannte Typ denn her? Kann es vielleicht doch sein, daß aus der lokalen codebase oder gar aus dem wildwildweb ein script nachgeladen wird, das (typischerweise für den Rest der Laufzeit) die entsprechenden Methoden und overloads für den neuen Typ bereitstellt?
    Was selbstverständlich (per Definition der jeweiligen Sekte) etwas völlig anderes zu sein hat als das LaufzeitLaden einer compilierten dynamischen Bibliothek, die (so lange wie geladen) Typ, Methoden und overloads bereitstellt.

    Klar, Compiler generieren typischerweise binblobs, doch die so hoch gelobten precompiled libs für Interpreter, die das Warten so angenehm verkürzen – das sind ebenfalls binblobs, nur vielleicht etwas niedlicher.
    Doch: Warum kein IDE mit einem Interpreter, das auf *click* ein Kompilat generiert, wenn der Zustand ‘so soll es sein’ erreicht ist? Klar, für dieses Konzept müßte auf ein wenig vom lazyweakTyping verzichtet werden (nicht auf das dynamische!), dafür gibts dann aber auch weniger Grusel bei den so häufigen unsicheren Typumwandlungen.

    • #30 Christian Meesters
      8. November 2019

      Sorry? Hab ich davon?

      Nee, sorry, da habe ich etwas aufgegriffen, dass nicht von Dir stammt.

      Zu Deiner Antwort: Ja, schon. Ich möchte, dass Du Verständnis dafür hast, dass ich stark vereinfache, weil ich immer wieder Leute vor mir habe, die ein erstes Mal ‘ls’ eingeben — und dann den Bogen über Programmierung, Debugging, Profiling bis zum Bauen von Workflows spannen muss. Du darfst mich gerne darauf hinweisen, wenn ich unzulässig vereinfache.

      Ja, Interpreter und Compiler sind sich sehr ähnlich, sie machen zunächst erst mal dasselbe. Allerdings arbeiten Compiler prinzipiell vor Start eines Programms, während Interpreter (der von mir genannten Sprachen) dynamisch auf (potentiell veränderlichen) Code reagieren müssen. Damit haben Compiler auch die Möglichkeit weitergehend zu optimieren und auch auf andere Instruktionssätze “zurückzugreifen”. (Ja, auch das ist vereinfacht und für mein Gebiet spielt das eine große, manchmal ideologisch überhöhte, Rolle.)

      … Doch: Warum kein IDE mit einem Interpreter, das auf *click* ein Kompilat generiert, wenn der Zustand ‘so soll es sein’ erreicht ist? Klar, für dieses Konzept müßte auf ein wenig vom lazyweakTyping verzichtet werden (nicht auf das dynamische!), dafür gibts dann aber auch weniger Grusel bei den so häufigen unsicheren Typumwandlungen.

      Ich verstehe worauf Du hinaus willst. Aber Du erwartest sicher von mir keine Antwort auf die Frage. Das sind schließlich Community-Entscheidungen oder / und die Einscheidungen von Sprachentwicklern.

      Es ist offenbar ein emotionales Thema. Mich würde interessieren warum. Wenn Du einen Gastartikel schreiben magst: Gerne. Ich kann andere Haltungen vertragen — und sachlich sehe ich keinen Konflikt (auch wenn ich jetzt bei all den Fragen und Betonungen nicht weiß, was ich als pers. Kritik auffassen soll).

  20. #31 Karl Mistelberger
    mistelberger.net
    9. November 2019

    > #30 Christian Meesters, 8. November 2019
    > Ja, Interpreter und Compiler sind sich sehr ähnlich, sie machen zunächst erst mal dasselbe.

    Die Java Virtual Machine ist schon einmal eine gute Idee:

    https://en.wikipedia.org/wiki/List_of_JVM_languages

    Damit geht alles:

    “In this post, I wanted to finally give a proper introduction to GCC-Bridge, a C/Fortran compiler targeting the Java Virtual Machine (JVM) that makes it possible for Renjin to run R packages that include “native” C and Fortran code without sacrificing platform independence.”

    https://www.renjin.org/blog/2016-01-31-introducing-gcc-bridge.html

    • #32 Christian Meesters
      9. November 2019

      Damit geht alles

      Die Frage ist aber nicht, was alles geht / möglich ist, sondern ob es praktisch in sinnvoller Zeit zu erreichen ist.

  21. #33 Dr. Webbaer
    9. November 2019

    Sehr interessant, der Schreiber dieser Zeilen glaubte bisher, dass das mit dem Kompilieren (vs. Interpretieren) von Code durch den Einsatz von Gerät, das vglw. günstig im Erwerb ist, verglichen mit dem Erwerb von Software-Entwicklern sozusagen weggehauen werden könnte, zumindest ein wenig zeitlich versetzt, wenn dann später das Gerät wieder günstiger und leistungsfähiger zu erwerben wäre.

    Der Schreiber dieser Zeilen hat die dankenswerterweise im dankenswerterweise beigebrachten WebLog-Eintag beigebrachten Visualisierungen bemerkt.

    Wenn Sie recht oder Recht haben, wäre dies wichtig.

    Wie stets beim Einsatz von sog. Software außerhalb der Bioinformatik, bspw. im Bereich der Wirtschaft, dort dann alles sozusagen weniger wichtig, weil die Bioinformatik eine Sonderrolle außerhalb gewohnter Wirtschaftlichkeit spielt?

    MFG – WB

    • #34 Christian Meesters
      9. November 2019

      …den Einsatz von Gerät, das vglw. günstig im Erwerb ist, verglichen mit dem Erwerb von Software-Entwicklern sozusagen weggehauen werden könnte,

      Das ist eine Frage des Geldes: Wenn die Probleme wirklich groß werden und man (also als Gesellschaft) wenig Geld hat, dann hilft nur die horizontale Skalierung (scaling out), also der Bau von Clustern. Mal abgesehen davon, dass wirklich große, fette Server irgendwann auch nicht fetter werden können: Irgendwann kommt der Punkt, wo man doch horizontal skalieren muss.

      Den Rest Ihrer Zeilen verstehe ich – mal wieder – nicht so gut, dass ich antworten möchte.

  22. #35 Dr. Webbaer
    9. November 2019

    PS :

    Ist es so, dass ein Interpretat (vs. Kompilat) einmal interpretiert, so im Rechnerspeicher bereit steht wie ein Kompilat – und wenn sich hier idF viele Nutzer-Anforderungen ergeben, es (die gesamte Ausführungsgeschwindigkeit meinend, die der Menge ihrer Ausführungen) (fast) egal ist, ob einmal (!) interpretiert statt nur geladen werden musste?

  23. #36 Solarius
    11. November 2019

    Es gibt doch compilierte Sprachen, die etwas leichter zu erlernen sind, als c und c++. Ich würde glatt mal behaupten, das Pascal ähnlich leicht ist, wie Python. Vielleicht sogar leichter. Und auch mit Pascal kann man Mehrprozessorsysteme programmieren:

    https://wiki.freepascal.org/Multithreaded_Application_Tutorial/de

    Das sieht jetzt allerdings wieder richtig kompliziert aus. Ich selber kann das nicht. Aber ich bin ja auch kein Programmierer. Ich glaube aber nicht, das das mit Python wirklich einfacher ist.

    Pascal/Lazarus wäre eine Programmiersprache, die ähnlich schnell ist wie c++ und dabei ähnlich leicht zu erlernen ist, wie Python.

  24. #37 Karl Mistelberger
    mistelberger.net
    12. November 2019

    > #32 Christian Meesters, 9. November 2019
    >> Damit geht alles
    > Die Frage ist aber nicht, was alles geht / möglich ist, sondern ob es praktisch in sinnvoller Zeit zu erreichen ist.

    Klar, schon Loriot hat festgestellt: Ein Leben ohne Mops ist möglich, aber sinnlos.

    Was mich zu meiner Zeit (1976-2003) immer verwundert hat: Die Berufspendler hatten angemessenes Geschick beim Lenken eine Autos. Wenn sie aber einmal beim Computer hinlangen sollten waren sie unbeholfen und ängstlich wie Fahrschüler.

    In der Welt von heute mit den potenziell unbegrenzten Möglichkeiten ist es notwendig, schnell und effizient den optimalen gangbaren Weg für ein bestimmtes Vorhaben herauszusuchen. Schaffen die das heute überhaupt?

  25. #38 Karl Mistelberger
    mistelberger.net
    13. November 2019

    > Bei Benchmarks, also dem systematischen Vergleich zwischen Programmen, Algorithmen, Implementierungen (also Umsetzungen in “Code”), usw. oder eben Programmiersprachen, verhält es sich ähnlich: Sie wecken schnell inneren Widerstand, weil schnell Gedanken aufkommen wie “die Leute haben X nicht berücksichtigt oder Y falsch gemacht”.

    Denken hilft hier nicht viel, hingucken macht immer schlauer:

    When Intel first released their (fantastic) compilers and MKL it was soon discovered that they worked for AMD processors but didn’t give very good performance (even though the core architecture was the same). Someone got the idea to spoof the processor ID (hard to do) on an AMD Opteron so that it responded as “Genuine Intel” sure enough the performance went way up!
    …
    Long story, short, there was a lawsuit and a settlement. Nothing much changed except that Intel has to include an “Optimization notice” on their publications.

    https://www.pugetsystems.com/labs/hpc/AMD-Ryzen-3900X-vs-Intel-Xeon-2175W-Python-numpy—MKL-vs-OpenBLAS-1560/

    Nicht zu vernachlässigen: https://itsfoss.com/linux-better-than-windows/

    • #39 Christian Meesters
      13. November 2019

      Herr Mistelberger, es erschließt sich mir nicht, welche Intention / Nachricht Sie mit Ihren Posts hier verbinden – an mich oder / und andere LeserInnen.

  26. #40 Karl Mistelberger
    mistelberger.net
    13. November 2019

    > es erschließt sich mir nicht, welche Intention / Nachricht Sie mit Ihren Posts hier verbinden

    Anderswo nennen sich die Posts ‘Gedanken’. Ich schreibe was mir bei Lesen einfällt.

    Wo drückt der Schuh am meisten? Nennen Sie eine Nummer.

    • #41 Christian Meesters
      13. November 2019

      Anderswo nennen sich die Posts ‘Gedanken’. Ich schreibe was mir bei Lesen einfällt.

      Gerne, nur eine Diskussion mit Mehrwert ergibt sich erst dann, wenn andere folgen können. Wo z. B. ist der Zusammenhang zwischen Intels seltsamer Geschäftspolitik und dem inneren Widerstand, welcher die Akzeptanz von Benchmarks schmälert?

  27. #42 echt?
    14. November 2019

    Selbst das alte Fortran lebt noch.

  28. #43 Solarius
    14. November 2019

    Selbst das alte Fortran lebt noch.

    Ist es denn auch leicht zu erlernen? Darum geht es ja. Herr Meesters schreibt ja, das c und c++ die meisten Bioinformatiker vor große Hürden stellen. Wobei er nicht weiß, woran das liegt. Python ist sehr schnell zu erlernen. Da gibt es ja das “A Byte of Python”, das bestand früher mal aus einem Blatt Papier. Damit konnte man sehr schnell Python erlernen. Inzwischen ist das aber auch ein richtiges Buch geworden.

    Vielleicht ist aber auch gerade diese Leichtigkeit ein Problem. Man programmiert ohne wirklich gut programmieren gelernt zu haben. Und dann wird eben auch Python mies umgesetzt. Auch darüber beschwert sich Herr Meesters ja.

    Womöglich mangelt es einfach nur an gutem Programmierunterricht? – Auch dafür wäre Pascal (also Lazarus) ideal geeignet.

    • #44 Christian Meesters
      14. November 2019

      Das bringt es ziemlich auf den Punkt. Danke. (Ich muss wohl lernen nicht so grantlerisch rüberzukommen 😉 .) Alldieweil Pascal? Informatiker (hier spare ich mir das Innen, denn die Aussage kenne ich nur von den Jungs) behaupten ja gerne, dass “wer eine Programmiersprache und die Konzepte gut kennt, auch alle anderen gut lernen kann”. Da mag ich prinzipiell nichts einwenden. In der Praxis aber habe ich schon etliche Informatiker gesehen (in Masterarbeiten und Dissertationen), die in Sprache X ziemlich Java-idiomatisch geschrieben haben — weil Java Sprache Nr. 1 im Studium ist. Insofern habe ich meine Zweifel, ob man den Leuten mit Pascal einen Gefallen tut. Aber ich kenne das Argument nicht gut genug: Würde ich aufrichtig gerne kennenlernen.

  29. #45 Karl Mistelberger
    mistelberger.net
    15. November 2019

    > #41 Christian Meesters, 13. November 2019
    > Wo z. B. ist der Zusammenhang zwischen Intels seltsamer Geschäftspolitik und dem inneren Widerstand, welcher die Akzeptanz von Benchmarks schmälert?

    Ich wollte mit dem Hinweis nicht die Geschäftspolitik von Intel kritisieren, sondern auf verborgene Fußangeln beim Benchmarking hinweisen. Mangelnde Akzeptanz von Benchmarks habe ich ausschließlich bei Leuten gefunden, die eher dilettantischen Umgang mit dem Computer pflegen.

    Experten kontern mit einem aussagekräftigen Gegenbeispiel, das es mir erlaubt, entweder ihre Argumente zu akzeptieren oder meinerseits mit einem Beispiel zu antworten.

  30. #46 rolak
    2. Januar 2020

    eval()

    Im Zuge des Sichtens des Nochnichtgesehenen vom 36c3 fiel das assoziierende Stichwort:

    eval() ist der Olympus Mons unter den schlechten Ideen
    (10608 15:2)

    Es gäbe übrigens von hier noch einen Kommentar vom 9.11., der irgendeinem glitch zum Opfer gefallen ist. Nochmal?

    • #47 Christian Meesters
      2. Januar 2020

      eval() ist der Olympus Mons unter den schlechten Ideen

      Jau, und auch ich möchte noch 36c3 sichten …

      Es gäbe übrigens von hier noch einen Kommentar vom 9.11., der irgendeinem glitch zum Opfer gefallen ist. Nochmal?

      Du führst Buch? Ich kann keinen nicht-freigeschalteten Kommentar vom 9.11.2019 (oder Tage um diesen Zeitraum herum) im System finden. Wenn es Dir wichtig ist: einfach nochmal posten?

  31. #48 rolak
    2. Januar 2020

    führst Buch?

    Jein. Generell nein, selbstverständlich manchmal ja – geht ja schon mit bookmarks los. Bei Moderation typischerweise urlMerken/TabZurück/urlAnhängen/tabAuflassen bis zum Bescheid. Nach jenem Kommentar (ulkigerweise aus diesem thread) gab es einen >24h-DauerRauswurf vom SB()-System und daher verlängerten die textareas irgendwann ‘hängende Texte’. Rekonstruierbar aus mailVerkehr zu dem Thema – und so spät, weil erst heute auffiel, daß es zwei Dateien dieses Namens gab :•/
    Wichtig? Nein.
    –✂–remaining optional——————————✂—-

    [solange Kommentare eh freigeschaltet werden müssen, erlaube ich mir reichlich links…]

    offenbar .. emotional

    Mir ist nicht klar, aus welcher Offensichtlichkeit dieser (bzgl. meiner Kommentare) unzutreffende Schluß gezogen wurde.

    stark vereinfache

    Dagegen ist überhaupt nichts zu sagen, doch dieser Ansatz ist keine valide Begründung dafür, mißverständliche bis falsche Aussagen unterzubringen. So ist es weiterhin kein Alleinstellungsmerkmal von Interpretern, dynamische Typisierung zuzulassen (#16→#24), ebenfalls keines, veränderlichen Code zuzulassen (#30→#15), ebenfalls keines, aus zur Laufzeit gewonnen Daten neuen Code bzw neues Kompilat-Verhalten zu generieren (Lisp, Prolog oder eben ein im Kompilat mitgelieferter JIT-Compiler(#15)).

    Nicht, daß meinerseits irgendwelche Einwände gegen CodeVeränderung zur Laufzeit bestünden (zB werden nicht nur, aber auch von den von ScienceBlogs() gelieferten Seitenquellen ua gewisse script-Einbindungen entfernt, bevor diese ihrerseits den Code verändern können), doch insbesondere in einer lazy-easy-sorglos-Interpreter-Umgebung sind aus Daten generierte Codebestandteile neben dem so befriedigenden ‘guck, so geht das ganz elegant und einfach’ immer noch dasselbe Hochrisiko, gegen das SQL-injection wie Kindergarten wirkt.

    Allerdings arbeiten Compiler prinzipiell vor Start eines Programms..

    Sorry, mein Fehler, dies nicht nochmals deutlich gemacht zu haben, da dies selbstverständlich auch nach mehrfacher Erwähnung hier im thread hätte unklar gewesen sein können.
    knr

    Allerdings scheint mir beim letzten Thema und mittlerweile statt ‘prinzipiell vor’ die Formulierung ‘generell vor’ passender, weil imho ansonsten die JITterbug-Tänzer außen vorblieben.
    ..der erste Abschnitt hat sich ja seitdem erledigt, Fortschritt live

    • #49 Christian Meesters
      2. Januar 2020

      Mir ist nicht klar, aus welcher Offensichtlichkeit dieser (bzgl. meiner Kommentare) unzutreffende Schluß gezogen wurde.

      Lies #15 mal durch.

      kein Alleinstellungsmerkmal …

      etc.
      Ja, da hast Du recht – ich habe in dem Kontext geschrieben, den ich offenbar nicht deutlich genug herausgestellt habe: HPC & wissenschaftliche Applikationen. Ja, auch da habe ich zu stark verallgemeinert: Asche auf mein Haupt. Da ist das JITisieren eher unüblich und ich sollte #30 präzisieren zu “der von mir genannten Sprachen in HPC & wissenschaftliche Applikationen” – und auch “generell” statt “prinzipiell” 😉

  32. #50 rolak
    2. Januar 2020

    Lies mal

    Geschah vorsichtshalber schon vorm Formulieren. Jetzt weiter eingegrenzt fiele mir ein: Falls sich der Eindruck auf ‘Dumpfbacke’ bezieht: im Kontext ‘bigotte Argumentation’ ist das(also ≈undurchdacht) imho die freundliche Einordnung, alles in Richtung ‘absichtlich’ wäre negativer. Das war allerdings nicht emotional bezeichnet worden, sondern nur möglichst passend. Auch Nominierungen für den bug-of-the-month-club oder Wertung als tdWTF-Kandidat sind trotz des typischen Anlasses ‘erschreckend’ nicht unbedingt emotional.
    Oder allgemein: Farbige Sprache belegt keineswegs emotionales Texten. Kann aber zugegebenermaßen zu diesem Schluß verführen.

    ich habe

    Die Tage nach dem erfolglosen postVersuch fiel mir ein, daß das Thema durchaus interpretiert werden kann als ‘wie unterscheiden sich die interpretierenden und die complierenden Sprachen i(n meine)m toolset’ – auch wenn diverse generellere Formulierungen dagegen zu sprechen scheinen. Deswegen kam nix mehr.