In Erlang und OTP in Aktion (Seite 46) geben die Autoren folgendes an:
Es kann vorkommen, dass sich der in der Shell ausgewertete Code in einem seltsamen Fall etwas anders verhält als derselbe Code, wenn er als Teil eines Moduls kompiliert wird. In diesem Fall ist die kompilierte Version der Goldstandard. Die Shell versucht ihr Bestes, genau das Gleiche zu tun, wenn sie die Ausdrücke interpretiert.
Können Sie sich einen oder mehrere dieser ungeraden Fälle vorstellen? Was sind die kleinen Unterschiede in diesen Fällen?
Der Erlang-Interpreter erl_eval versucht sehr genau, sich genau wie kompilierter Code zu verhalten. Wenn es nicht ist, ist es wahrscheinlich ein Fehler.
Außer in einem Fall und das empfängt Nachrichten. Kompilierter Code kann auf die internen Anweisungen zugreifen, um auf die Nachrichtenwarteschlange zuzugreifen und diese zu bearbeiten. Der Dolmetscher kann das nicht tun. Es muss: Nachrichten aus der Warteschlange entfernen (mehr oder weniger mit receive X -> X end ); Testen Sie sie, um zu sehen, ob sie mit den Empfangsmustern übereinstimmen. behalte diejenigen, die nicht übereinstimmen; und legen Sie alle derzeit unerwünschten Nachrichten in die Warteschlange zurück (indem Sie alle Nachrichten empfangen und sie dann an sich selbst zurücksenden). Dies bedeutet, dass es eine kurze Zeit gibt, in der, wenn eine Nachricht eintrifft, sie nicht an derselben Stelle in der Nachrichtenwarteschlange wie für kompilierten Code endet.
Der wichtigste Unterschied ist, dass die Shell interpretiert wird, während der kompilierte Code ... gut .. kompiliert ist. Dies hat einen beobachtbaren Unterschied in der Ausführungsgeschwindigkeit und dem Speicherverbrauch der Funktion. Mit anderen Worten, Sie können feststellen, dass die interpretierte Variante langsamer ist oder all Ihren Speicher verbraucht, während die kompilierte Version dies nicht tut.
Dieses Problem hat viele junge Erlang-Programmierer gebissen. Er oder sie denkt, dass Erlang im Vergleich zu anderen Sprachen ziemlich langsam ist, während es in Wirklichkeit einen Test von interpretiertem Code gegen kompiliert.
Der Absatz ist eine Schutzmaßnahme. Grundsätzlich sollten sich der Interpreter und der Compiler auf alle Ein- / Ausgaben einer Funktion einigen. Aber das ist leider nicht immer der Fall. In der Praxis sind der Interpreter und der Compiler unterschiedliche Ausführungsmaschinen und können sich daher unterscheiden. Wenn Sie native über HiPE kompilieren, sind die Änderungen möglicherweise noch größer. In der Regel treten Probleme mit IEEE-754-Fließkommazahlen auf.
Tags und Links erlang