Lisp



  • Ist Lisp schweerer zu Optimierne, weil es nicht strong typed ist?



  • Ja. Nein.



  • ((((((((((((((((((Ja)))))))))))))))))



  • jujuj schrieb:

    Ist Lisp schweerer zu Optimierne, weil es nicht strong typed ist?

    Welchen Lisp-Dialekt meinst Du denn?

    Es ist schwer, darauf eine Patentantwort zu geben.

    In Common Lisp gibt es ja durchaus auch Type Declarations. Du schreibst einfach mal alles rein dynamisch typisiert und falls Du glaubst, irgendwo mit Typdeklarationen mehr Performance rausholen zu können, teilst Du das dem Compiler eben mit.



  • Auf der einen Seite ist es leichter zu optimieren, z.B. durch program fusion. Auf der anderen Seite erlaubt es auch maechtigere Konstrukte, die eben Overhead mit sich bringen.

    Ist Lisp schweerer zu Optimierne, weil es nicht strong typed ist?

    Wenn du nicht als Troll abgestempelst werden willst, dann solltest du dir bei deiner Frage etwas Muehe geben: 1) Rechtschreibung 2) mehr Kontext 3) "schwerer" als was 4) ... Auch glaube ich kaum, dass hier jemand einen optimierenden Compiler irgendeiner Sprache schon geschrieben hat, um das zu beurteilen (mich eingeschlossen). Ich glaube also kaum, dass du ernsthaft an der Frage interessiert bist und nur eine Diskussion lostreten willst.



  • knivil schrieb:

    Auch glaube ich kaum, dass hier jemand einen optimierenden Compiler irgendeiner Sprache schon geschrieben hat, um das zu beurteilen

    als Jugendlicher habe ich als Ferienprojekt mal einen Compiler programmiert, der einen erfundenen Forth-Dialekt auf M68K compilierte - ich erweiterte Forth um etwas Syntax für C- bzw- BCPL-kompatible Datenstrukturen, damit ich mit Forth bequem auf die Datenstrukturen des Betriebssystems zugreifen konnte - und dieser Compiler war in der Tat in gewissem Umfang optimierend. Er erkannte z.B. aufeinanderfolgende Ketten von push und pop, die er dann durch Registertransfers ersetzte.

    Ich darf also hier antworten ... Mist, ich weiß es auch nicht 😡 😃



  • Ich arbeite mich auch gerade in Forth ein. Die push/pop Optimierung ist mir auch als erstes durch den Kopf geschossen. Andere Sprachen wie Joy stehen auch auf meiner todo-Liste.





  • Ich habe den Artikel ueberflogen ... sorry nicht ernst zu nehmen. Man nehme C-Code, schreibe ihn genauso in Lisp und schaue was dabei raus kommt. Ich programmiere aber in Lisp anders als in C. Ich will Daten mit fold, map oder filter transformieren ... Welchen Grund gibt es denn Lisp zu nehmen, wenn ich auch nur so wie in C programmiere?



  • knivil schrieb:

    Ich habe den Artikel ueberflogen ... sorry nicht ernst zu nehmen. Man nehme C-Code, schreibe ihn genauso in Lisp und schaue was dabei raus kommt. Ich programmiere aber in Lisp anders als in C. Ich will Daten mit fold, map oder filter transformieren ... Welchen Grund gibt es denn Lisp zu nehmen, wenn ich auch nur so wie in C programmiere?

    80/20 Regel sagt dir was?



  • maximAL schrieb:

    80/20 Regel sagt dir was?

    Vielleicht magst du es etwas ausbauen, anstatt einfach eine rhetorische Frage einzuwerfen, vor allem mehr auf das Thema bezogen.



  • knivil schrieb:

    maximAL schrieb:

    80/20 Regel sagt dir was?

    Vielleicht magst du es etwas ausbauen, anstatt einfach eine rhetorische Frage einzuwerfen, vor allem mehr auf das Thema bezogen.

    Bei einem komplexen Programm wird typischerweise nur ein kleiner Teil wirklich performancekritisch sein. Eben diese Teile kann man - nachdem man sie identifiziert hat - nochmals gesondert optimieren, wobei der Großteil des Programms im Gegensatz zu einem reinen C-Programm immernoch recht elegant geschrieben sein kann. Und den Lisp-Code umzuschreiben dürfte immernoch schöner sein, als mit FFI rumzubasteln.



  • knivil schrieb:

    Andere Sprachen wie Joy stehen auch auf meiner todo-Liste.

    ich habe mir joy nur sehr oberflächlich angesehen. Kann man in Joy was machen, was in normalem Forth nicht geht ?

    Funktionale Elemente hat ja normales Forth auch, z.B. execute und ' wie in:

    : foo 3 4 rot execute ;
    ' + foo . ( => 7 )
    

Log in to reply