Bash echo >> ... nur, wenn noch nicht vorhanden?

[CyborgBeta]

Der spielt hier 4D-Schach,

(BeBur spielt hier Weiß )

 

[BeBur]

Mir würde schon reichen, wenn "Es macht keinen Unterschied" vs. "Der Unterschied ist irrelevant", nicht schon Probleme verursacht.

 

[CyborgBeta]

Probleme verursacht

Inwiefern?

Es macht keinen Unterschied

Ob es einen Unterschied gibt, ist noch ungeklärt bzw. offen.

Der Unterschied ist irrelevant

Vielleicht nicht gerade irrelevant, aber zumindest vernachlässigbar.

vs.

Für eine komplette Gegenüberstellung muss erst die Prämisse geklärt sein. Soll heißen, ob und wenn ja welchen Unterschied es gibt, und welche Auswirkungen dieser hinsichtlich der Laufzeit (hierbei) überhaupt hat.

A=B?	Zeit(A)!=Zeit(B)?
✅	⭕
⭕	❔

 

[nutrix]

Mir hats doch keine Ruhe gelassen, und ich hab mir mal die Sourcen der Bash angeschaut:

https://github.com/bminor/bash
Nur mal stark verkürzt
|| (OR_OR) und && (AND_AND) führen nach
make_cond_node (make_cmd.c) -> cm_cond (execute_cmd.c)
return (make_command (cm_if, (SIMPLE_COM *)temp));
https://github.com/bminor/bash/blob/master/make_cmd.c

#if defined (COND_COMMAND)
struct cond_com *
make_cond_node (type, op, left, right)
     int type;
     WORD_DESC *op;
     struct cond_com *left, *right;
{
  COND_COM *temp;

  temp = (COND_COM *)xmalloc (sizeof (COND_COM));
  temp->flags = 0;
  temp->line = line_number;
  temp->type = type;
  temp->op = op;
  temp->left = left;
  temp->right = right;

  return (temp);
}
#endif

COMMAND *
make_cond_command (cond_node)
     COND_COM *cond_node;
{
#if defined (COND_COMMAND)
  COMMAND *command;

  command = (COMMAND *)xmalloc (sizeof (COMMAND));
  command->value.Cond = cond_node;

  command->type = cm_cond;
  command->redirects = (REDIRECT *)NULL;
  command->flags = 0;
  command->line = cond_node ? cond_node->line : 0;

  return (command);
#else
  set_exit_status (2);
  return ((COMMAND *)NULL);
#endif
}

if (IF) führt nach
make_if_command (make_cmd.c)-> cm_if (execute_cmd.c)
https://github.com/bminor/bash/blob/master/make_cmd.c

COMMAND *
make_if_command (test, true_case, false_case)
     COMMAND *test, *true_case, *false_case;
{
  IF_COM *temp;

  temp = (IF_COM *)xmalloc (sizeof (IF_COM));
  temp->flags = 0;
  temp->test = test;
  temp->true_case = true_case;
  temp->false_case = false_case;
  return (make_command (cm_if, (SIMPLE_COM *)temp));
}

Sprich, es wird doch unterschiedlich interpretiert und die if-Konstruktion führt zu weniger Budenzauber als || und &&. Man sollte doch einfach mal direkt immer Sourcecode lesen, wenn das nicht immer so aufwendig wäre. 😔

 

[CyborgBeta]

und die if-Konstruktion führt zu weniger Budenzauber

Und woran machst du das fest? Im Return von make_if_command steht doch noch einmal ein make_command? Un es ist doch noch nicht geklärt, wie COMMAND oder IF_COM dann abgearbeitet wird... Wir sind noch (weit) weg von Prozessorinstruktionen, denke ich.

Ergänzung (20. März 2025)

Vielleicht könnte man auch ein Mikrobenchmark machen... Aber ich hab ehrlich noch nie jemanden gesehen, der zwei Bash-Scripte gebenchmarkt hat...

 

[BeBur]

Vielleicht könnte man auch ein Mikrobenchmark machen... Aber ich hab ehrlich noch nie jemanden gesehen, der zwei Bash-Scripte gebenchmarkt hat...

Aber es macht doch einen Unterschied!!
/s

 

[CyborgBeta]

😬

&& und || sind schneller!

1.sh

#!/bin/bash
cnt=1
n=1
while [ $n -lt 1000000 ]; do
  if [ $((n % 3)) = 0 ]
  then
    cnt=$((cnt-1))
  else
    cnt=$((cnt+1))
  fi
  n=$((n + 1))
done
echo "$cnt"

2.sh

#!/bin/bash
cnt=1
n=1
while [ $n -lt 1000000 ]; do
  [[ $((n % 3)) = 0 ]] && cnt=$((cnt-1)) || cnt=$((cnt+1))
  n=$((n + 1))
done
echo "$cnt"

Beide Scripte sind semantisch identisch. Ich gehe nicht davon aus, dass Optimierungen vorgenommen werden.

Unabhängig von der Aufrufreihenfolge:

$ time bash 1.sh
333334

real    0m6.295s
user    0m6.291s
sys     0m0.004s

$ time bash 2.sh
333334

real    0m5.433s
user    0m5.433s
sys     0m0.000s

Wir sprechen hier von einem Laufzeitunterschied von ca. 15 % (!)

 

[CyborgBeta]

@BeBur und @nutrix ich glaube, der Unterschied ist, weil das Script nicht einmal als Ganzes interpretiert und zwischengespeichert wird, sondern jedes Mal Zeile für Zeile durchgegangen wird ... sogar bei einer Schleife.

Es kommt also nicht darauf an, welche Befehle der Prozessor letztendlich ausführt, sondern wie "geparst" und interpretiert wird, denke ich.

Vermutlich kann das Beispiel in jeder anderen Programmiersprache, die nicht, oder die nicht Zeile für Zeile interpretiert wird, schneller ausgeführt werden. n=1 Million Additionen ist für eine CPU eigentlich keine Herausforderung, die 100 Millionen Instruktionen pro Sekunde ausführen kann.

Ich denke, man kann sagen, für komplexe Berechnungen ist ein Bash-Script einfach nicht gedacht. Ein Hoch auf Java und JavaScript.

 

[nutrix]

Wir sprechen hier von einem Laufzeitunterschied von ca. 15 % (!)

Danke, daß Du Dir die Mühe gemacht hast. Ich hatte auch schon was gebastelt, war aber noch nicht reif und ganz so schick wie Deines. Interessant, daß es doch so ein großer Unterschied ist.

Ich denke, man kann sagen, für komplexe Berechnungen ist ein Bash-Script einfach nicht gedacht.

Korrekt, es ist Batch, um Alltagsaufgaben eines Admins für diverses Zeugs zu erledigen, und dafür funktioniert es sehr gut. Klar hatte ich früher auch mal Bash mißbraucht, um ETL light zu machen und Massendaten zu verwerten, aber das war nur eine Notlösung, weil ich sonst nichts beim Kunden verfügbar hatte.

Ein Hoch auf Java und JavaScript.

Java ja, JS eher mäh. Leider ist das Leben immer kein Wunschkonzert, und man muß sich mit dem Plagen, was vor Ort verfügbar ist.

 

[CyborgBeta]

Ich musste aber auch ein wenig in die StackOverflow-Trickkiste greifen. 😰

Mit sh ist das übrigens nicht startbar - es muss bash sein...