Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.forth > #419

Re: Forth ist langsamer als C++

Show all headers | View raw

Manuel Rodriguez <aa5@gmx.net> writes:
>H=C3=A4ufig wird so getan als w=C3=A4re Forth eine ganz besondere
>Programmiersprache, die im Embedded Bereich ihre St=C3=A4rke hat. Leider is=
>t
>Forth im Vergleich zu C++ nicht konkurrenzf=C3=A4hig. Im folgenden gibt es =
>ein
>Programm, was die Zahlen hochz=C3=A4hlt von 0 bis 10 Mio und das ganze auf =
>die
>Kommandozeile ausgibt. Wenn man das startet stellt man fest, dass die C++
>Version nach 1 Sekunde fertig war, w=C3=A4hrend das Forth Programm stolze 8
>Sekunden zur Ausf=C3=BChrung ben=C3=B6tigt.
>
>C++: 0m0.968s
>Forth: 0m7.993s
>
>// Kompilieren: g++ -O3 5a.cpp
>// Aufruf: time ./a.out > tmp.txt
>#include <iostream>
>int main()
>{
>  for(int number=3D0;number<10000000;number++)
>    std::cout << number << "\n";
>}
>
>\ running: time gforth-fast 5.f > tmp.txt
>: main 10000000 0 DO I . CR LOOP ;
>main
>bye
>
>Aber wie kann das sein, dass eine bare-Metal-Sprache wie Forth so
>derma=C3=9Fen langsam ist?

In diesem konkreten Fall, weil das Ausgeben von Zahlen selten
performance-kritisch ist, und daher nicht besonders optimiert ist.
Probier lieber eine reale Anwendung, und vergleiche dabei.

Insbesondere gibt Forth ganze Zahlen immer als double-cell-Werte aus,
und verwendet daher bei 64-bit-Zellen fuer jede Ziffer eine
128/64->128-Division, eine Operation, die auf der Hardware nicht
direkt unterstuetzt wird.  Wenn das Ausgeben von Zahlen
performance-kritisch waere, wuerden wir den ineffizienten Umweg ueber
doubles natuerlich nicht gehen.

>Der Hauptgrund warum Forth
>nicht mit C++ konkurrieren kann liegt in der internen Struktur eines
>Forth-Systems. Gforth ist eine Implementierung unter Linux. Sie ist am
>ehesten mit einem Macroassembler zu vergleichen bei dem Forth Worte wie
>"DO" und "LOOP" auf Assembly-Befehle gemappt werden. Leider ist die
>Zuordnung nicht besonders effizient gew=C3=A4hlt. Der C++ Compiler hingegen
>f=C3=BChrt zwar ebenfalls nur Assembly Befehle aus, allerdings ist das Mapp=
>ing
>deutlich fortschrittlicher. Wovon in der Forth-Community nur geredet wird
>(indirect threading) ist im C++ Compilerbau nicht nur Standard, sondern
>es gibt noch viele weitere Techniken um die Performance zu erh=C3=B6hen.

Si tacuisses...

Wir koennen das ganze auch mit indirect threading in Gforth probieren:

Auf einem Core i5-6600K mit 4GHz:

gforth-fast: 3.160s
gforth-itc:  5.512s
C++       :  0.484s

GCC verwendet allerdings durchaus Dinge, ueber die in der
Forth-community nur geredet wird, wie globale Registerallokation, und
daher kommt bei einem etwas sinnvolleren Vergleich
<2016Nov30.183115@mips.complang.tuwien.ac.at> auch heraus, dass GCC
schnelleren Code produziert als die schnelleren Forth-Compiler.

Witzigerweise sind die Forth-Compiler, die normalerweise schnelleren
Code erzeugen als Gforth (das mehr in Richtung Portabilitaet als
Performance optimiert wurde), bei Deinem Benchmark langsamer als
Gforth:

VFX Forth:  2.164s user, 26.408s system
SwiftForth: 9.332s user, 26.292s system
FLK:        4.164s user,  9.948s system

Die verwenden offenbar, anders als Gforth, unbuffered I/O, deswegen
die hohe system time (bei Gforth und C++ nahe 0); wenigstens ist VFX
beim user-Teil schneller als Gforth-fast; warum die anderen beiden
dort langsamer sind, kann ich im Moment nicht erklaeren.  Andererseits
ist das auch nicht so wichtig, weil der Grossteil der Zeit in den
System calls verbraten wird.

>Was man von Forth jedoch nicht erwarten kann ist eine
>produktive Methode um Software zu schreiben.

Und das willst Du aus diesem Benchmark ablesen?

Ich denke, tatsaechlich ist es umgekehrt: In ihrem Streben nach tollen
Benchmark-Ergebnissen eliminieren die GCC- und Clang-Maintainer ihre
Compiler und im Linux-Bereich damit C und C++ aus dem Reigen der
produktiven Programmierwerkzeugen.  Denn wenn man deren Rat folgt,
muss man seine C- und C++-Programme staendig "sanitize"n, also
schauen, dass man ja kein "undefined behaviour" im Programm hat.  Denn
wenn Du "undefined behavior" im Programm hast, sehen sie das Programm
als buggy an, und fuehlen sich daher ermaechtigt bis verpflichtet, das
Programm anders zu compilieren als von Dir beabsichtigt, selbst wenn
die letzte Version ihres Compilers das Programm noch so compiliert hat
wie beabsichtigt.

Damit faellt bare-metal-Programmierung schon einmal komplett aus, das
ist alles "undefined behaviour"; und selbst wenn man sich davon fern
haelt, kann bei diesen Sprachen ganz leich einmal ein "undefined
behaviour" reinrutschen, also muesstest Du das Programm vor jedem
Release "sanitize"n.  Die geben Dir zwar "sanitzer" in die Hand, die
einige "undefined behaviours" finden, aber keine Garantie, dass sie
nur Programme kaputtmachen, deren "undefined behaviours" mit diesen
"sanitizer"n gefunden werden konnten.

>Forth ist auch heute noch als Gegenentwurf zur Unix Community gedacht. Es
>gibt auf der einen Seite die Unix/Linux Leute welche mit C und sp=C3=A4ter
>mit C++ herumspielen und damit Betriebssysteme, GUIs und Anwenderprogramme
>schreiben und auf der anderen Seite gibt es das Forth-Lager was kein UNIX
>braucht und auch keine Compilersprachen ben=C3=B6tigt. Ein aktuelles Linux
>wird man nur schwerlich auf einen C-64 oder einen Intel 4004 portieren
>k=C3=B6nnen, mit Forth ist das eine Kleinigkeit. Aber ist diese Antihaltung
>gegen=C3=BCber Unix heute noch angebracht? B=C3=B6se formuliert ist Microso=
>ft
>eine Weiterentwicklung des Forth-Gedankens, das hei=C3=9Ft wir haben das
>Forth/Microsoft Lager auf der einen Seite wo man mit MSDOS.SYS Dateien,
>Makroassemblern und Win32Forth arbeitet und auf der anderen Seite haben
>wir die Linux-Community wo man auf LLVM, Python und GTK+ setzt. Das eine
>ist OpenSource, das andere nicht. Auch Bill Gates wird nachgesagt, dass
>er ein heimlicher Forth-J=C3=BCnger ist und in der Lage ist ultrakompakten
>Code zu schreiben ...

Willkommen im postfaktischen Zeitalter.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

Back to de.comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Forth ist langsamer als C++ Manuel Rodriguez <aa5@gmx.net> - 2017-02-18 01:37 -0800
  Re: Forth ist langsamer als C++ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-18 11:50 +0000
  Re: Forth ist langsamer als C++ djc <ciesinger@gmx.net> - 2017-03-10 07:32 -0800

csiph-web