| View previous topic :: View next topic |
| Author |
Message |
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
 Posted: Sat Apr 14, 2018 7:02 pm Post subject: Einfaches BASIC gesucht |
 |
|
In US bedeutet Basic sowohl Programmiersprache als auch Grundlage
Und nein, ich möchte nicht Python lernen (CPU-Lock)
Und auch kein Ruby
C++ hab ich mal mit VisualStudio angetestet. Da konnten dann auch <Click>-Buttons angelegt werden.
Aber schreib mal ne Header-Datei. Da läßt dich die Doku voll hängen.
| Code: | C64 V2.0 Basic -> finde ich nicht
GFA-Basic 3.06 -> finde ich nicht
Amiga-Basic 4.05 -> finde ich nicht
Pure-Basic -> finde ich nicht...........also in Linux |
Porthole und EIX konnten mir auch nicht weiterhelfen.
GFA/Pure verarbeiten z.B. auch Assembler-Befehle (z.B. INC A)
Ich möchte gar keine GUI schreiben. Nur sowas wie
| Code: | For i=1 to 1000: a=a+1: Next
For i=1 to 1000: inc a: Next |
Weshalb Mono-Basic keine Lösung ist.
Habe hier noch NASM gefunden
-----------------------------------------
Besteht eigentlich die Möglichkeit eine man-page nach Goog*e-Translate zu schicken ?
English geht ja noch etwas, ...aber US (ne, Out of Error) |
|
| Back to top |
|
 |
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Sat Apr 14, 2018 11:28 pm Post subject: |
|
|
Wenn es unbedingt Basic sein muss, kannst du dir Gambas für Gentoo installieren. Es gibt dazu ein Overlay, das gambas-overlay heisst. Kannste mit Layman dazuholen, und dann ganz normal wie alle Gentoo Pakete bauen.
Alternativ wenn du dich für die alte Programmiersprache Pascal interessierst, schau dir Lazarus. Das findest du im Gentoo Tree.
Beide Sprachen sind aber kaum für irgendwas im Einsatz. Ich hab früher in der Schule Pascal gelernt, aber abgesehen davon keinen Gebrauch. Als Lernsprache ist es durchaus zu brauchen.
Ansonsten hast du dir auch mal Java angesehen? Dazu gibts auch eine gute IDE im Gentoo Tree die Netbeans heisst. Das eigentliche Java ist dann entweder Icedtea oder oracle-jdk-bin. Beides ist auch im Gentoo Tree. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Sun Apr 15, 2018 3:06 pm Post subject: Re: Einfaches BASIC gesucht |
|
|
| LuxJux wrote: |
| Code: | C64 V2.0 Basic -> finde ich nicht
[...]
|
|
Das ist eigentlich eher ne Schwämerei. Du kannst den C64 emulieren und bekommst dann auch das von dir gesuchte Basic in seiner Version so aus der Zeit der 1970er/1980er Jahre.
Schau dir app-emulation/vice an. Aber zum Lernen ist das nix. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Apr 25, 2018 7:09 pm Post subject: Re: Einfaches BASIC gesucht |
|
|
| LuxJux wrote: | | Python lernen (CPU-Lock) |
Wie meinen? Von der Geschwindigkeit her dürften sich python, perl, und Basic-Interpreter nicht viel nehmen. Syntax ist so verschieden auch nicht. Wichtigster Unterschied ist, dass es bei python und perl zusätzlich noch echte Datentypen und sogar Klassen gibt. Das musst Du aber am Anfang nicht benutzen.
| Quote: | | C++ [...] Aber schreib mal ne Header-Datei. Da läßt dich die Doku voll hängen. |
Kommt auf die Doku an. Es gibt sehr gute C++-Lehrbücher. Wenn für Deine Anwendung Geschwindigkeit wesentlich ist, lohnt sich das Lernen von C++. Ich würde schätzen, dass es 10-100 mal schneller ist, als eine interpretierte Sprache wie python, perl oder Basic. (Außer natürlich, Dein Programm besteht hauptsächlich aus Aufrufen von Bibliotheksfunktionen; diese Funktionen sind natürlich i.d.R. selbst in C oder C++ geschrieben).
| Quote: | | GFA/Pure verarbeiten z.B. auch Assembler-Befehle (z.B. INC A) |
Ähem. Nein. Sie haben die Syntax von ein paar Befehlen an die Syntax von ein paar Befehlen gewisser Assembler-Dialekte angelehnt. Mehr nicht.
| Quote: | Ich möchte gar keine GUI schreiben. Nur sowas wie
| Code: | For i=1 to 1000: a=a+1: Next
For i=1 to 1000: inc a: Next |
|
Egal, welchen Basic-Dialekt Du benutzt, Du wirst sowieso eine Menge umlernen müssen.
Ich würde Dir daher empfehlen, perl zu lernen. Das gibt es auf viel mehr Systemen als Basic und ist von Syntax und der gesamten Denkweise her Basic sehr ähnlich.
Eigentlich ist es von der Syntax her sehr vielen Sprachen sehr ähnlich (Shell, C, awk, usw.), was Teil der Philosophie der Sprache ist.
Zum Vergleich: Der obige Code kann in Perl so aussehen:
| Code: | | for $i (1..1000) { $a = $a + 1 } |
oder so:
| Code: | | for $i (1..1000) { ++$a } |
oder so:
| Code: | for ($i = 1; $i < 1000; $i = $i + 1) {
$a = $a + 1
} |
oder so ... oder so ...
Assembler ist nun so weit weg von Basic, wie es nur geht. Wenn es Dir auf Geschwindigkeit ankommt, ist in 99.9% der Fälle C++ die bessere Wahl. Assembler lohnt sich nur dann, wenn Du für extrem zeitkritische Sachen noch ein wenig mehr Leistung herauskitzeln musst und das Problem eine Struktur/Komplexität/Länge hat, bei der Du auch realistisch annehmen kannst, besser als der C++-Compiler optimieren zu können - was heutzutage i.d.R. nur für sehr speziellen und überschaubaren Code zutreffen kann.
| Quote: | | Besteht eigentlich die Möglichkeit eine man-page nach Goog*e-Translate zu schicken? |
| Code: | | app-i18n/translate-shell |
Edit: Syntaxfehler in Perl-Code gefixt.
Last edited by mv on Thu Apr 26, 2018 12:35 pm; edited 1 time in total |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2283
Location: Adendorf, Germany
|
| Posted: Thu Apr 26, 2018 9:38 am Post subject: Re: Einfaches BASIC gesucht |
|
|
| LuxJux wrote: | | Code: | | Amiga-Basic 4.05 -> finde ich nicht |
|
Möchtest du wirklich ein Microsoft-Produkt verwenden? Kein Scherz, das Amiga Basic wurde von Microsoft entwickelt. Ich fand es damals so scheußlich (kam vom C16 und C64), dass ich recht schnell auf GFA-Basic umgestiegen bin. Zum Glück bekam ich 1989 "Aztec C 5" (für Nostalgiker  ), und von dem C/C++-Zug konnte mich auch auch Amos nicht mehr runter werfen... (schwärm...)
Ansonsten rate ich dir dazu auf mv zu hören, er weiß wovon er spricht! (+1 für Perl!)
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Fri Apr 27, 2018 12:39 pm Post subject: |
|
|
Ganz herzlichen Dank 
zum einen für die Schließung von Wissenslücken, als auch für den Hinweis zu perl |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Fri Apr 27, 2018 9:11 pm Post subject: |
|
|
Bin hier hängen geblieben
| Tyrus wrote: | | LuxJux wrote: |
| Code: | C64 V2.0 Basic -> finde ich nicht
[...]
|
|
Das ist eigentlich eher ne Schwämerei. Du kannst den C64 emulieren und bekommst dann auch das von dir gesuchte Basic in seiner Version so aus der Zeit der 1970er/1980er Jahre.
Schau dir app-emulation/vice an. Aber zum Lernen ist das nix. |
bei Steem 3.9 SSE mit GFA-Basic 3.5e
------------
Und ein kleiner Benchmark
| mv wrote: |
| Quote: | | GFA/Pure verarbeiten z.B. auch Assembler-Befehle (z.B. INC A) |
Ähem. Nein. Sie haben die Syntax von ein paar Befehlen an die Syntax von ein paar Befehlen gewisser Assembler-Dialekte angelehnt. Mehr nicht.
|
| Code: |
a=0
zeit1=TIME$
FOR i=1 TO 1000000
a=a+1
NEXT i
zeit2=TIME$
PRINT zeit2-zeit1
|
"3,75"
| Code: | REM -------------------
a%=0
zeit1=TIME$
FOR i%=1 TO 1000000
INC a%
NEXT i%
zeit2=TIME$
PRINT zeit2-zeit1
|
"0,97"
Bringt schon was.
Für meine 2-Zeiler reicht das. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Apr 28, 2018 8:58 am Post subject: |
|
|
| LuxJux wrote: | | Bringt schon was. |
Natürlich. Weil der Interpreter zu blöd ist, a=a+1 vernünftig zu optimieren, sondern vom Benutzer erwartet, selbst solche trivialen Optimierungen selbst vorzunehmen, C++-Compiler sind da wesentich intelligenter. Die ziehen sogar Dinge selbstständig aus Schleifen heraus, rollen Tail-Rekursionen iterativ auf usw.
Zu meinem Bedauern musste ich feststellen, dass perl hier anscheinend auch nicht besser optimiert als es GFA-Basic tat, wenn man es nicht selbst macht:
| Code: | % perl -e 'use Time::HiRes qw{time}; $time=time; $a=0; for $i (1..1000000) { $a=$a+1 } print time-$time'
0.222642183303833%
% perl -e 'use Time::HiRes qw{time}; $time=time; $a=0; for $i (1..1000000) { ++$a } print time-$time'
0.132398843765259 |
Mein Rechner ist eigentlich ziemlich langsam, aber perl ist immerhin noch ca 10-15 mal schneller als Dein GFA-Basic. Ist natürlich kein Wunder, denn Dein Rechner muss ja den Prozessor emulieren.
Also zum Arbeiten mit vernünftiger Geschwindigkeit würde ich Dir keinesfalls zu emuliertem GFA-Basic raten: Selbst die langsamste Interpretersprache schlägt natürlich eine Interpretersprache, die auf einem iintepretierten Prozessor-Code läuft, um Größenordnungen.
Edit: Python3 scheint klug genug zu sein:
| Code: | % python3 -c 'import time; time1 = time.clock()
a = 0
for i in range(1, 1000000):
a = a + 1
print(time.clock() - time1)
time2 = time.clock()
a = 0
for i in range(1, 1000000):
a += 1
print(time.clock() - time2)'
0.443171
0.44757900000000006 |
Python2 hingegen nicht, obwohl es insgesamt in diesem Fall schneller ist (was vermutlich daran liegt, dass "range" in python3 generischer geworden ist).
Edit 2: Falls Du DIch über die umständlichen "use" bzw. "import"-Befehle wunderst: Bei python ist time eine Bibliotheksfunktion, die man eben nur dann lädt, wenn man sie braucht. Bei perl ist es ähnlich: Zwar bietet perl den Befehl "time" von Haus aus, aber der ist nur sekundengenau; für höhere Genauigkeit (die es nicht auf allen Systemen gibt), muss man "time" aus der Bibliothek überladen. |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Sat Apr 28, 2018 4:43 pm Post subject: |
|
|
| Yamakuzure wrote: |
@Hilefoks : Ja, es hat viele Leute begeistert, das cmake Visual Studio Solutions bauen kann... ^^ |
Edit: vorletzter Beitrag
Edit2: Vielleicht braucht das Rad ja gar nicht neu erfunden werden |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Sun Apr 29, 2018 4:42 pm Post subject: |
|
|
| Letzter Beitrag von gestern war ein Flüchtigkeitsfehler. Funktioniert natürlich nur mit WinDose. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue May 01, 2018 4:51 pm Post subject: |
|
|
| LuxJux wrote: | | Allerdings ist mir noch nicht so klar, wann Python 2.7 bzw. für welchen Zweck, 3.4 bevorzugt werden sollte |
Wenn Du selbst etwas schreibst, benutze einfach immer das neueste Python. Du musst schon ziemlich tief in den Details von Python stecken, um die Unterschiede überhaupt zu bemerken.
Die alten Versionen von Python sind eigentlich nur aus Kompatibilitätsgründen nützlich (entweder, wenn man spezielle Bibliotheken braucht, die es [noch] nicht für das neueste Python gibt, oder wenn man für jemanden schreibt, der nur eine alte python-Version hat).
Im Normalfall ist python3 auch immer schneller als python2; dass es in diesem speziellen Beispiel anders war, ist wohl die große Ausnahme. |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Wed May 02, 2018 8:00 pm Post subject: |
|
|
LOL,
mal sehen, ob's noch mehr (nur diese) Ausnahme gibt.
Andererseits hab ich ja kein Haus gekauft. Welche Sprache für welches Projekt eingesetzt wird, kann dann entsprechend ausgewählt werden.
Auf den ersten Blick scheinen sowohl Python als auch Perl (ziemlich) BASIC ähnlich zu sein. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu May 03, 2018 1:35 pm Post subject: |
|
|
| LuxJux wrote: | | mal sehen, ob's noch mehr (nur diese) Ausnahme gibt. |
Dieser Link beschreibt es sehr gut:
| Quote: | | The core devs are also actively working on optimizing Python 3 -- each new release of Python 3 has been faster then the last. |
| Quote: | | Python 3 has some new optimizations in part of the language, but Python2 has the pypy JIT VM which can get you major speed improvements. |
Die "Optimizations in part of the language" bedeuten dabei insbesondere folgendes: Der Code | Code: | | for i in range(1, 100000) |
besagt in python2: Erzeuge eine Folge mit den Zahlen 1...100000 und durchlaufe diese dann in der Schleife. In python3 hingegen wird „nur so getan“, als wenn diese Folge erzeugt worden wäre: In Wirklichkeit liefert dort range keine Folge zurück, sondern eine Funktion, die bei jedem erneuten Aufruf (also bei jedem neuen Schleifendurchlauf) das jeweils nächste Folgenelement liefert.
(In python2 gibt es speziell für „range“ einen Workaround: Es gibt dort die Funktion xrange die das selbe tut wie „range” in python3; insofern müsste man also für einen „fairen” Vergleich von python2 und python3 hier xrange anstelle von range bei python2 benutzen; tatsächlich schneidet dann python2 in diesem Beispiel noch ein paar Prozentpunkte besser ab).
Der Punkt ist aber, dass "xrange" eine individuelle Optimierung von python2 in diesem Sonderfall ist, während bei python3 diese Optimierung generell gemacht wird, weil die Sprache um ein Konstrukt erweitert wurde, das solche Optimierungen zum „Normalfall“ macht. |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3337
Location: de
|
| Posted: Mon May 07, 2018 6:04 pm Post subject: |
|
|
Dass ich mal in die Situation komm, mvs Beiträge zu ergänzen oder zu korrigieren. 
| mv wrote: | | Du musst schon ziemlich tief in den Details von Python stecken, um die Unterschiede überhaupt zu bemerken. |
Nö, ist einfacher als man denkt:
Python ist aufwärtskompatibel, d.h. die Python3-Version funktioniert auch in Python 2, aber nicht umgekehrt. Bei Python3 gibt's dann natürlich diverse Libs, die zusätzliche Funktionen bieten, die in Python2 noch nicht vorhanden sind. Es gibt aber auch ein Tool zur Umwandlung von Python2-Code nach Python3.
| mv wrote: | | Die alten Versionen von Python sind eigentlich nur aus Kompatibilitätsgründen nützlich (entweder, wenn man spezielle Bibliotheken braucht, die es [noch] nicht für das neueste Python gibt, |
Der letzte Teil ist der ausschlaggebende. Python2 hat durchaus in diversen kommerziellen Bereichen (z.B. Finanzbranche) eine gewisse Bedeutung erlangt. Da wurden haufenweise Libs erstellt. Portiert auf Python3 wurde da allerdings ziemlich wenig. Deswegen ist Python2.7 noch immer mindestens so relevant wie Python3.x und wird auch in einigen Jahren noch existieren.
Ein Beispiel aus einem anderen Bereich ist Pyload. Da wird schon seit einigen Jahren an einer Nachfolgeversion auf Python3-Basis gearbeitet, die aber von einem benutzbaren Stadium noch immer weit entfernt ist.
| LuxJux wrote: | | Und nein, ich möchte nicht Python lernen |
Also ich würde Dir Python empfehlen. Es ist sogar in gewisser Weise ähnlich in der Syntax zu Basic, meiner Meinung nach aber viel schöner und sauberer zu lesen und zu programmieren.
| LuxJux wrote: | | C++ hab ich mal mit VisualStudio angetestet. |
Falscher Ansatz. Nimm einen einfachen Editor mit Syntaxhighlight und die Kommandozeile zum Compilieren. VS ist für größere Projekte geeignet, aber nicht zum Lernen.
| LuxJux wrote: | | Aber schreib mal ne Header-Datei. Da läßt dich die Doku voll hängen. |
Ich weiß, ich hatte anfangs auch meine Verständnisschwierigkeiten. Ist aber im Endeffekt wesentlich weniger Magie als du denkst. Dazu brauchst du 'ne Headerdatei nicht mal, wenn Dein Programm nur aus einer Quellcodedatei besteht.
| LuxJux wrote: | | C64 V2.0 Basic -> finde ich nicht |
Da solltest du Dich allerdings schon mit dem C64 etwas vertraut machen. Ich hab vor 20 jahren viel Basic auf dem C64 programmiert. Ist definitiv eine Sackgasse - besonders die Peeks und Pokes.
| LuxJux wrote: | Ich möchte gar keine GUI schreiben. Nur sowas wie
| Code: | For i=1 to 1000: a=a+1: Next
For i=1 to 1000: inc a: Next |
|
Tipp mal:
| Code: | python<ENTER>
a = 0<ENTER>
for i in range(1,1000):<ENTER>
<TAB> a = a+1<ENTER>
<ENTER>
print(a)<ENTER> |
Das kannst du auch in eine Datei schreiben und mit:
ausführen.
Ich hab übrigens in meinem Ex-Job mal 3 Jahre lang Visual Basic Classic (6.0) programmieren müssen. Das will ich nie wieder machen. Ich finde Basic eklig. Ich halte es auch als Einstieg in die Programmierung für ungeeignet, da man sich jegliches Sprachgefühl versaut. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue May 08, 2018 7:31 am Post subject: |
|
|
| musv wrote: | | mv wrote: | | Du musst schon ziemlich tief in den Details von Python stecken, um die Unterschiede überhaupt zu bemerken. |
Nö, ist einfacher als man denkt:
|
Jein: Wenn jemand nach einer python3-Anleitung lernt (was nach meiner Empfehlung natürlich Sinn macht), merkt man den Unterschied nicht, weil man dann sowieso Klammern setzt.
Aber Du hast recht, dass ich das als i.W. einzigen sichtbaren Unterschied hätte erwähnen sollen. (Ich hatte mir überlegt, auch die unterschiedlichen Default-Stringtypen zu erwähnen, aber das erschien mir dann doch "tief in den Details", obwohl man erstaunlich früh auf Probleme damit stößt - und zwar auf mehr Probleme in python3 als in python2, was m.E. zeigt, dass es eine Fehlentscheidung war.)
| Quote: | | Bei Python3 gibt's dann natürlich diverse Libs, die zusätzliche Funktionen bieten, die in Python2 noch nicht vorhanden sind. |
Beispielsweise so triviale Sachen wie Ausgabe ohne Zeilenvorschub, wo man sich bei python2 mit dem dubiosen sys.write einen abbrechen muss
Glücklicherweise kann man die print-Funktion aus python3 in python2 importieren.
| Quote: | | Da wurden haufenweise Libs erstellt. |
Die Frage von LuxJux scheint mir nicht darauf hinzudeuten, dass er vor hat, proprietäre Bibliotheken zu benutzen.
| Quote: | | meiner Meinung nach aber viel schöner und sauberer zu lesen und zu programmieren. |
Da bin ich anderer Meinung, und ich halte die Python-Philosophie für ziemlich schräg.
"Ask forgiveness not permission" bedeutet beispielsweise, dass man für trivialen Code anstelle eines Funktionsaufrufs ein mindestens 4-zeiliges try/catch-Konstrukt mit weiteren Einrückungen braucht und dann aus irgendwelchen Gründen immer noch einem anderen Fehler mit dem selben Fehlerobjekt aufsitzen kann. Lesbarkeit ist m.E. was anderes.
Vor allem aber halte ich den PEP8 Styleguide mit den Einrückungen für ziemlich krank: Obwohl für jeden Furz eine neue Ebene aufgemacht werden muss (wie eben gesehen), wird der gigantische Wert von 4 Leerzeichen pro Ebene vorgeschrieben. Das - kombiniert mit dem 80-Zeichen-pro-Zeile-Limit und den Umbrechregeln, bei denen man noch viel mehr einrücken muss - hat zur Folge, dass gerade in komplexen Funktionen - wo man Lesbarkeit am dringendsten braucht - der Code am rechten Rand fast wortweise untereinander geschrieben steht, und die Funktionen über viele Seiten statt ein paar Zeilen gehen. Von Übersicht und Lesbarkeit keine Spur. |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Tue May 22, 2018 9:59 pm Post subject: |
|
|
Oh je. Der GFA-Editor hat genau das richtig in die Schleife eingebaut.
Dann nochmal das .gfa zu .prg mit dem Compiler übersetzen lassen.
Mit Steem die Geschwindigkeit von (original) auf (Schieb den Regler nach rechts->FullSpeed@3.6Ghz) reicht eigentlich.
0.0025436362 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed May 23, 2018 5:54 am Post subject: |
|
|
| LuxJux wrote: | | mit dem Compiler |
Vorsicht bei Benchmarks mit Compilern:
- Bereits gcc -O1 würde die Schleife als redundant erkennen und vollständig eliminieren (selbst wenn a danach benutzt wird, übersetzt gcc -O1 das in eine einzige Zuweisung). Aber auch mit -O0 ist in C/C++ zwischen Hunderttausend und einer Million Schleifendurchläufen mit "time" noch kein reproduzierbarer Timing-Unterschied zu erkennen. Bei 200 Millionen werden die Zeiten mit denen von Perl und Python für eine Million vergleichbar. Aber:
- Selbst wenn die Schleife erzeugt wird, misst der Vergleich Interpreter<->Compiler bei solchen Trivialschleifen eher, ob der gesamte Code in den Level 1-Cache passt. Bei Hochsprachen-Interpretern ist das eher unwahrscheinlich, vor allem bei solchen, die auf Multitasking ausgelegt sind und deswegen grundsätzlich die Zweischenergebnisse in den Speicher zurückschreiben. Deswegen ist der Faktor 200 zwar in schlechten Benchmarks (wie diesem) vorhanden, in realistischen Programmen ist der Unterschied aber deutlich geringer.
- Bei Vergleichen auch nicht zu vergessen: Die Größe des Integer-Datentyps. Python ist da unbegrenzt, und die Verwaltung dafür kostet natürlich extra Zeit. Perl hat 64 bit (je nach Prozessor), GFA-Basic ist auf 32 bit begrenzt (oder waren es sogar 16 bit - kommt eigentlich 1 Million heraus, oder gibt es da sogar schon unbemerkten Overfow?)
- Auch nicht zu vergessen: Zumindest bei mir sind Perl und Python mit Flags „gegen“ spectre übersetzt und mit Dingen wie stack-protector, stack-clash-protection und pie versehen. Beim Assembler-Code von steem wird auf all das vermutlich nicht geachtet, und beim C Compiler in diesem Fall ebenfalls nicht (weil der C-Compiler ärgerlicherweise keinen Schalter hat, der spekulative Ausführung bei allen bedingten Sprüngen verhindert).
Andererseits: Wenn Du nicht gerade schwierige numerische Aufgaben mit riesigen Datenmengen angehen willst (Machine Learning oder Video-Encoding beispielsweise) oder es mit NP-vollständigen Problemen zu tun hast, ist bei heutigen Rechnern ein Faktor von 200 ohnehin ziemlich egal. Für Probleme, für die er nicht egal ist, solltest Du hochoptimierende Compiler wie C, C++, Go, oder Rust nehmen. |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German) 
