Effizient mehrere Zeichen ausgeben

[heinz]

Hallo wanne

Die Messungen sind grob unfair: Du misst immer nur den Zeitverbrauch der äußeren bash selbst.

Mein bestreben war auch nicht die exakte Zeit nur des Befehls zu messen, sondern eher verwertbare Vergleichswerte zu erhalten.
Wenn alle Befehle unter den gleichen Bedingungen gestartet werden (bash + Befehl) ist das doch auch gewaehrleistet. Oder sehe ich das falsch?
Time misst doch die Zeit, wie lange die bash gelaufen ist. Und die bash beendet sich erst wenn der Befehl durch ist.

Das gilt für das neue Script im im Post vor mir nicht mehr.

Warum? Ich kann in dem Script in der Funktion zur Zeitmessung keine Aenderung finden. (Kann aber auch an mir liegen, war sehr spaet gestern... )
(Aber mir ist gerade aufgefallen, das ich in der Funktion "Zeit_messen" die globale Variable $befehl verwende anstatt $1...)

Deswegen müssten die C-Varianten übelst abloosen, weil der gcc gar nicht schnell genug gestartet ist.

Aber genau darum geht es doch auch. Wie lange braucht ein Befehl um auf der Konsole eine Anzahl Zeichen zu schreiben.
Wenn ein Befehl z.B. awk nutzt muss halt auch erst awk gestartet werden. Das gehoert m.M.n. zur Laufzeit dazu.

Hier ein etwas erweitertes Script: pastebin/?mode=view&s=40718

In Zeile 30

Code: Alles auswählen

groesse_fuer_groessentest=0

noch die 0 weglassen, damit man das Script auch ohne Angabe der Zeichenmenge laufen lassen kann...

* Anzahl der # kan ausgewählt werden

Hatte ich mir auch ueberlegt aber es dann gelassen, da ich das Script auch fuer andere Zeitmessungen benutzen moechte,
bei denen es nicht um eine Ausgabe von Zeichen geht.
Z.B. Schnellere Methoden zu finden mit sdl bestimmte Grafikeffekte zu erzeugen.
Aber fuer die Augabenstellung hier ist das eine sehr gute Idee...

* Hash statt Dateigröße wird verglichen

Stimmt, so kann man auch erkennen ob auch wirklich alle Zeichen die Richtigen sind.

* Deafault auf builtin time gesetzt

Das wundert mich etwas, laut "help time" kennt bash/time die Optionen -a, -o und -f garnicht? Zeigt aber keine Fehlermeldung und funktioniert normal?

* mktmp genutzt.

Es wird nicht korrekt aufgeraeumt wenn das Script nicht ganz durchlaeuft / vorzeitig beendet wird...
Liegt wohl an der Variablen "madedir". Wozu hast Du sie eigentlich eingefuegt?
Ich weiss, nach dem naechsten Boot ist /tmp wieder leer. Soll auch keine Kritik sein.

Schoenes Wochenende noch.
Gruss, heinz

[wanne]

Wenn alle Befehle unter den gleichen Bedingungen gestartet werden (bash + Befehl) ist das doch auch gewaehrleistet.

Ja. Aber die bash läuft halt schon.

Oder sehe ich das falsch? Time misst doch die Zeit, wie lange die bash gelaufen ist

Nein die Zeit in der der Befehl gelaufen ist. Da gehört weder das starten der bash noch das parsen des Befehls dazu. nicht dazu. In deinem Script startest du jedes mal eine neue bash. Dann ist wieder alles OK.

Wenn ein Befehl z.B. awk nutzt muss halt auch erst awk gestartet werden. Das gehoert m.M.n. zur Laufzeit dazu.

Ja. Aber es gibt halt einen falschen Eindruck. Die C-Varianten sind bei extrem vielen # deutlich schneller als die Konkurrenten mit yes. Eigentlich will man einen Grafen haben.

In Zeile 30

Gibt nochmal eine Unzulänglichkeit in meinem sed. Kommt nochmal ne Version.

Wozu hast Du sie eigentlich eingefuegt?

Wollte die Dateien direkt in /tmp liegen haben können. Werde den default aber wieder ändern.

benchmarke Gerade werde gleich mal Ergebnisse raus geben.

[heinz]

Ja. Aber die bash läuft halt schon.

Ah, ok. Jetzt verstehe ich was Du meinst. (Glaub ich zumindest...)
Besser waere es also die Befehlsdatei ausfuehrbar zu machen und zu starten, anstatt sie mit /bin/bash zu starten.
Am liebsten waere mir auch gewesen den Befehlsstring, der ja schon in einer Variable steht, direkt auszufuehren ohne ihn in eine Datei zu schreiben.
Aber da in dem String die "wildesten" Zeichen vorkommen, hab ich es nicht anders hinbekommen.

Nein die Zeit in der der Befehl gelaufen ist. Da gehört weder das starten der bash noch das parsen des Befehls dazu. nicht dazu.

Vielleicht reden wir aneinander vorbei. Ich meine, so wie es im Moment in meinem Script implementiert ist wir doch alles gemessen.
Der Start der bash, des Befehls, die Ausfuehrung des Befehle und das alles wieder zu beenden.
Anders kann ich es mir kaum vorstellen. (Kann aber auch an meiner Vorstellung liegen... )

Ja. Aber es gibt halt einen falschen Eindruck.

Da hast Du natuerlich recht. Aber wie schon geschrieben, war meine Absicht irgendwie alles abzudecken um das Script auch fuer andere Zwecke nuetzlich zu machen.
(Bin auch nicht so der Profi im Programmieren...)

benchmarke Gerade werde gleich mal Ergebnisse raus geben.

Klasse, bin gespannt...


Hast Du uebrigens eine Erklaerung dafuer warum bash/time korrekt funktioniert obwohl es die Optionen garnicht kennen sollte?

Gruss, heinz

[wanne]

Vielleicht reden wir aneinander vorbei. Ich meine, so wie es im Moment in meinem Script implementiert ist wir doch alles gemessen.

Ja und ja.
In deinem Script ist das problem nicht mehr vorhanden. Nur bei den meisten Vorpostertn waren die bash-Befehle eben direkt hinter einem time und nicht eine extra bash geschrieben haben.

Hier meine Erlebnisse:
https://balja.org/pub/print.tar.xz
Hier die Ergebnisse:
https://balja.org/html/pics/printnum.svg
Leider wird das von Chrome und Firefox nicht angezeigt. Hab jetzt ne Stunde dran rumgespielt. Keine Ahnung, was da kaputt ist. Jeder andere Bildbetrachter hat kein Problem damit. Also einfach runter laden und ihr habt keine Probleme.

[wanne]

Hier nochmal die von mir genutzten Befehle
pastebin/?mode=view&s=40719
Noch ein paar Anmerkungen:

• Ich habe ein paar stellen Optimiert. Viele Befehle erzeugten falsche ausgaben. Neue Befehlsliste...
• Man achte auf die doppelt logarithmischen Achsen
• Ich habe immer irgend wann aufgehört, wenn die Laufzeiten zu lange wurden.
• Die Python Variante explodiert irgend wann auf Laufzeiten im Minutenbereich, weil sie irgend wann swappen anfängt.
• Für alle Varianten, wo die Ausgabe in 8 GiB passen ist die neue schnellste Variante eine in lua:

  Code: Alles auswählen

  echo "s=\"##########\";  for i=1,9 do; s=s .. s; end;  for i=1,math.floor(%numcharsHX/5120) do; io.write(s); end; for i=1,math.fmod(%numcharsHX,5120) do; io.write(\"#\"); end " | lua

  Die ist von mir stark optimiert. Aber auch ohne Optimierungen einfach mit einem loop der n mal die 10 # ausgibt ist die schneller als alles andere. (bzw. ähnlich wie die schnelleren perl Varianten) Der speed vom lua jit ist toll.
• Es ist schon abzusehen: Aber die C Variante die im Moment auf Platz 2 ist, geht bei noch mehr Zeichen auf Platz 1.
  Da ist mein tmpfs aber zu klein. Hab dann Zeichen nach /dev/null schreiben lassen.
  Trotzdem: Die schnellste Variante für lange Ausgaben heißt

  Code: Alles auswählen

  echo -e "#include <string.h>\n#include <unistd.h>\n#include <sys/ioctl.h>\n int main(){ int bufflen=10240; char s[bufflen]; memset(s,'#',bufflen); int i=%numcharsHX/bufflen; while(i--) write(1,s,bufflen); i=%numcharsHX%bufflen; while(i--) write(1,s,1); }" | gcc -xc -; ./a.out

  Interessant dabei: selbst bei 8000000000 macht die Compiletilme noch deutlich was aus.O3 ist deutlich länger wie ohne, Vermutlich könnte man das nochmal durch das weglassend er Header optimieren. Ich will aber korrekten C-Code schreiben. Sinnvoll ist O3 nur bei der Variante mit putchar.

[heinz]

Wow, da ist ja eine richtig wissenschaftliche Untersuchung daraus geworden.

Leider wird das von Chrome und Firefox nicht angezeigt.

Bei mir wird es korrekt angezeigt. (Firefox 66.0.5 (64-Bit))
Womit hast Du eigentlich die svg-Grafik erstellt? In der Datei "chart.eps" habe ich was von "PS-Adobe-3.0 EPSF-3.0" gelesen...

[wanne]

Womit hast Du eigentlich die svg-Grafik erstellt?

Inkscape. Habe auch ghostscript versucht. Produziert bei mir beides mal nur ein schwarzes Bild im Browser.
Die eps kommt einfach aus Libreoffice.