frankx: (c)LISP (interpretiert) ca. 30 mal langsamer als FORTRAN oder C

Beitrag lesen

Hellihello

Moin.

Ein paar Anmerkungen zur Begrifflichkeit:

»» Liegt der Code nicht bei beiden Verfahren irgendwann im Stackframe des RAM, also als Assemblercode?

Was  bitte ist der 'Stackframe des RAM'?

http://en.wikipedia.org/wiki/Stack_frame#Structure sowas vor dem inneren Auge, ich dachte, da würde schlussendlich auch eine Funktion drinne landen, also eine do-Schleife zum Beispie?

Als Stackframe bezeichnet man normalerweise die für einen Funktionsaufruf nötigen, auf dem Stack abgelegten Werte.

Also nicht die Funktion "gehe von startwert bis endwert durch".

Wie genau ein solcher 'Rahmen' aussieht ist abhängig von der calling convention der entsprechenden Programmiersprache.

Also bei Assembly anders als bei C anders als bei Fortran anders als bei Lisp.

Desweiteren meinst du vermutlich Maschinen- und nicht Assemblercode, da letzterer vor seiner Ausführung selbst noch in ersteren übersetzt werden muss.

http://en.wikibooks.org/wiki/Reverse_Engineering/Functions_and_Stack_Frames#Functions_and_Stack_Frames  - da bin ich mir selbst nicht so ganz sicher. C resultiert doch in Assembly, oder? Nicht aber Java, PHP, Lisp, Fortran.

Ich vermutete nun sowas: irgendwie muss doch Maschinencode rauskommen. Und vielleicht wäre der dann irgendwie angeordnet wie Assembly-Code und läge im Ram. Und ich dachte, ab dem Moment wäre es eben ja wurscht, ob vorher kompiliert oder interpretiert wurde. Wenn aber immer wieder interpretiert wird, nur um die do-schleife weiterzuspulen, dann dauerts natürlich ewig. Das wäre ja, wie wenn der Fortran/C-Compiler für jeden Schleifendurchlauf neu komplieren würde (;-).

Dank und Gruß,

frankx

--
tryin to multitain  - Globus = Planet != Welt