Dotaz: rychlost skriptu na debian amd64 vs. gentoo

[hajoucha]

Dobrý den

mám následující skript:

#!/bin/bash

FILE=`basename $1 .out`

grep "TEMP_HOT" $1 | awk '{print $1, $3}' > $FILE.temp
grep "TEMP_COLD" $1 | awk '{print $1, $3}' > $FILE.cold
grep "CURRENT" $1 | awk '{print $1, $3}' > $FILE.curr
sed '/Time/!d; /???/d;' $1 |cut -d : -f 2- |sed 's/:/ /g' |awk '{print $1, $3, $5, $7}' |sort -n |uniq > $FILE.fin
echo "hotovo sefe!"

exit 0

ten pouštím na soubor, který má cca 200MiB. Na stanici s debianem amd64 (2GiB RAM) s procesorem :

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
stepping        : 3
cpu MHz         : 2812.829
cache size      : 1024 KB

trvá

real    1m12.978s
user    1m23.369s
sys     0m1.752s

kdežto na stanici s gentoo (zrejme 32bit, 1GiB RAM) s procesorem

model name      : AMD Athlon(tm) 64 Processor 3500+
stepping        : 0
cpu MHz         : 2203.408
cache size      : 512 KB

trvá:

real    0m26.438s
user    0m23.921s
sys     0m1.736s

Ani jeden stroj není jinými procesy nijak zatížen. Liší se pouze verze "sort" a "uniq". Gentoo má 6.4 vs. debianí 5.97. Ale i přesto... vysvětluje to tak závratný rozdíl v časech při takovém rozdílu hw? Zdrojová data jsou k mání třeba zde: data

Pozn: ten skript odpovídá mým skromným znalostem..., takže případná zlepšení jsou samozřejmě vítána :)

Odpovědi

[Ash]

Zásadní rozdíl v rychlosti u sort/uniq by mohlo způsobovat UTF8. LANG=C sort to přepnete do ascii. Není to ten důvod?

[hajoucha]

...ano, tohle docela pomohlo, leč stále (na debianu):

$ time ./rozhod.sh 2.5Anew.out
hotovo sefe!

real    0m39.779s
user    0m50.043s
sys     0m1.620s

Na gentoo je výsledek teměř totožný jako předtím:

$ time ./rozhod.sh 2.5Anew.out
hotovo sefe!

real    0m25.424s
user    0m23.621s
sys     0m1.672s

[Ash]

Tak to asi bude tím... Použil jste to pro všechny ty operace? Tedy i pro sed, awk... je to obecně problém multibyte kódování, protože při čtení každého znaku ze souboru se volá jakási mb_funkce() což v současné době způsobuje značné zdržení. Takže to ovlivnňuje všechny nástroje, grep atd.

[hajoucha]

..ouha, tak ted už ano:

real    0m26.678s
user    0m35.222s
sys     0m1.716s

Přestože jsou nyní výsledky srovnatelné, čekal jsem, že na debianu půjde skript mnohem rychleji, vzhledem k dvojnásobku paměti, dvojímu jádru a ješte rychlejšimu taktování. No nic, hlavní zádrhel je vyřešen, za což moc děkuji. K dalšímu zrychlení bude zřejmě potřeba se zamyslet nad strukturou toho skriptu jako takového... :)

[Michal]

Dvojjadro tomu nijak nepomuze, nemas to napsane multithreadove A vetsi pamet take ne. Kam se ztratil prirustek 20% narustu taktu? Dost mozna, ze v 64bitech. Ono gcc generuje nekdy naprosto uzasne prekvapujici kod, kde si clovek rika "takhle by me to v zivote ani nenapadlo napsat"

[hajoucha]

ano, to je pravda. Dvojjádro není žádný argument, nechal jsem se unést. Ovšem nerozumím té paměti.... je tím myšleno, že pokud se celý soubor vejde do RAM, tak už je to pak jedno? Jo, tak to bych taky bral.

No, když na ten skript tak koukám, tak mi přijde, že nejnáročnější bude sort. Zajímalo by mě, zdali třídí rovnou to co leze z roury, nebo jestli počká, až dostane všechno a pak to roztřídí naráz? Nebo jak to vlastně dělá?

Ze souboru potřebuji nejprve vybrat řádky obsahující slova TEMP_COLD, TEMP_HOT a CURR. Ŕádky s jednotlivými slovy chci uložit do zvláštních souborů. Nelze to udělat nějak lépe, než, že ten soubor projdu 3x za sebou? Jinými slovy, nelze místo prvních tří grepů pustit grep jenom jeden a říci mu, aby dával příslušné řádky do třech různých souborů? Počítám, že tohle přímo nepůjde, ale myšlenka je zřejmá...Nebo ještě jinak, když už prvním grepem najdu příslušné datové řádky, rád bych je alespoň zároveň vyhodil ze souboru, abych je nemusel příště procházet zase...To by šlo?

[Michal Kubeček]

je tím myšleno, že pokud se celý soubor vejde do RAM, tak už je to pak jedno?

Pokud na realizaci úlohy potřebujete určité množství paměti a toto množství máte k dispozici, pak je celkem jedno, jestli máte ještě nějakou navíc. Množství paměti se na rychlosti může projevit pouze v případě, že je buď paměti nedostatek a je nutno swapovat, nebo je při nedostatku paměti program nucen použít paměťově úspornější, ale pomalejší algoritmus.

[Fuky]

Prvních tří grepů se můžeš zbavit např. takto:

#!/bin/bash

echo -e "AAA nic TRI\nBBB nic TRI\nCCC nic TRI" |\
gawk '
  /AAA/ { print $1, $3 > "file.a" }
  /BBB/ { print $1, $3 > "file.b" }
  /CCC/ { print $1, $3 > "file.c" }
'

[hajoucha]

zdá se, že to nebyl dobrý nápad:

real    0m58.647s
user    0m59.440s
sys     0m1.216s

#!/bin/bash

FILE=`basename $1 .out`

LANG=C gawk '
  /TEMP_HOT/ { print $1, $3 > "file.temp"}
  /TEMP_COLD/ { print $1, $3 > "file.cold" }
  /CURRENT/ { print $1, $3 > "file.curr" }
' $1
LANG=C sed '/Time/!d; /???/d; s/:/ /g' $1 | LANG=C awk '{print $3, $5, $7, $9}' |LANG=C sort -n |LANG=C uniq > $FILE.fin
echo "hotovo sefe!"

exit 0

[Fuky]

Zkoušel jsem:

#!/bin/bash

if [ "$2" == "gawk" ]; then
  gawk '
    /AAA/ { print $1, $3 > "gawk.a"; next }
    /BBB/ { print $1, $3 > "gawk.b"; next }
    /CCC/ { print $1, $3 > "gawk.c"; next }
  ' $1
elif [ "$2" == "grep" ]; then
  grep "AAA" $1 |gawk '{ print $1, $3 }' > grep.a
  grep "BBB" $1 |gawk '{ print $1, $3 }' > grep.b
  grep "CCC" $1 |gawk '{ print $1, $3 }' > grep.c
elif [ "$2" == "sed" ]; then
  grep "AAA" $1 |sed -n 's/\([^ ]\+\) \+\([^ ]\+\) \+\([^ ]\+\)/\1 \3/p' > sed.a
  grep "BBB" $1 |sed -n 's/\([^ ]\+\) \+\([^ ]\+\) \+\([^ ]\+\)/\1 \3/p' > sed.b
  grep "CCC" $1 |sed -n 's/\([^ ]\+\) \+\([^ ]\+\) \+\([^ ]\+\)/\1 \3/p' > sed.c
elif [ "$2" == "bash" ]; then
  grep "AAA" $1 |while read c1 c2 c3; do echo $c1 $c3; done > bash.a
  grep "BBB" $1 |while read c1 c2 c3; do echo $c1 $c3; done > bash.b
  grep "CCC" $1 |while read c1 c2 c3; do echo $c1 $c3; done > bash.c
elif [ "$2" == "c" ]; then
  grep "AAA" $1 |./column > c.a
  grep "BBB" $1 |./column > c.b
  grep "CCC" $1 |./column > c.c
fi

Nejvíce zdržuje vypsání prvního a třetího sloupce. Rychlejší způsob než C jsem nenašel.

column.c:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define BUFFER_MAX 1024

int main(void)
{
  int i;
  char buffer[BUFFER_MAX];
  char *p_buffer;
  char *column;

  while (fgets(buffer, BUFFER_MAX, stdin) != NULL) {
    p_buffer = buffer;

    for (i = 0; i < 3; ++i) {
      if (p_buffer == NULL) {
        continue;
      }

      while (*p_buffer == ' ') {
        ++p_buffer;
      }

      if ((column = strsep(&p_buffer, " ")) == NULL) {
        continue;
      }

      switch (i) {
        case 0: printf("%s", column);  break;
        case 2: printf(" %s", column); break;
        default:                       break;
      }
    }
  }

  return 0;
}

[Fuky]

Jestli Tě zajímá jak pracuje sort, máš k dispozici jeho zdrojáky Všimni si, že si vytváří v /tmp pomocné soubory (ls -lh /tmp/sort*), takže když ho použiješ na velký soubor může pomalé RW disku znatelně zpomalit jeho běh, což může být další zásadní rozdíl mezi sestavami, na kterých jsi prováděl testy.

[hajoucha]

:) zdrojáky si nechávám jako opravdu až tu nejzazší možnost, hlavně proto, že nejsem v C vůbec zběhlý a tak se obávám, že by mi to zabralo příliš mnoho casu

Ovšem s těmi disky to bude skvělá trefa. Sestava s gentoo má zřejmě disky o něco rychlejší.

[Michal]

<sarkasmus>Predne bych ti chtel napsat co to jsou komprimacni programy. Kdyz nimi prozenes textovy soubor (obzvlaste s takovym mnozstim opakujicich se casti jako tento) tak dokazou zmensit jejich objem na 1/25 a lidi pak stahujou mnohem mensi mnozstvi dat. U sebe to pak dekomrimuji a ziskaji puvodni soubor. Opravdu. Nekecam! viz napr. man bzip2<sarkasmus>

Pro srovnani vysledky z gentoo 64bit, Core 2 Duo E6600 @ 3.5GHz

real    0m10.949s
user    0m13.385s
sys     0m1.212s

real<(user+sys) takze asi preci jen to je napsano mutithreadove.

[hajoucha]

už jsem to opravil... sbalene to ma nejakych 8MiB. Člověk holt nemyslí na všechno :)

sbalena data

[hajoucha]

už jsem to opravil... sbalene to ma nejakych 8MiB. Člověk holt nemyslí na všechno :)

sbalena data

[hajoucha]

hrome... překlep! Platí až ten druhý link.

[Michal Kubeček]

Na to, abyste využil více procesorů (jader), nepotřebujete multithreadovou aplikaci. Když propojíte dva příkazy (náročné na procesor) rourou a nic jiného v systému procesor(y) zatěžovat nebude, poběží každý na jednom procesoru a na dvouprocesorovém systému to bude rychlejší i bez multithreadových aplikací. Schválně se můžete podívat do zdrojáků použitých utilit, zda někde volají pthread_create().