--parallel = N, не доставляющий требуемые результаты

Я работал над сравнением сценария генерации данных образца, используя обычный параллельный запуск &. Я использую библиотеку GNU 'parallel' для параллельного запуска скрипта. Сценарий генерирует случайные записи в фиксированных столбцах из 100 & различного размера строки. Ниже мой сниппет, который генерирует случайные записи:--parallel = N, не доставляющий требуемые результаты

for i in $(seq $rows) 
do 
tr -dc A-Za-z0-9 < /dev/urandom | head -c 2000 > tmp 
gawk '$1=$1' FIELDWIDTHS='I put here the varying column lengths' OFS=, tmp >> tmp1 
done

Вот статистика Я собираемые:

"# of Rows" "# of columns" "Time took(sec)" "Time took, using & (sec)" "Time took Parallelism=4(sec)" 
100  100 1 1 ~0 
1000 100 6 5 5 
10000 100 51 59 51 
100000 100 895 576 543 
1000000 100 10462 11765 11468

Даже если ввести параллельную обработку с помощью утилиты «параллельного», я не вижу любое изменение прошедшего времени по сравнению с тем, что я получаю при нормальной обработке. Любые идеи, идеи, помощь будут оценены.

Мой процессор имеет 4 ядра, и я хочу убедиться, что программа использует все ядра во время выполнения.

Спасибо, Адиль

источник

2015-03-10 knowone

Возможно, вам захочется определить, где находится узкое место. –

Maxim, Поскольку я не использую какую-либо ручную процедуру для введения параллелизма в скрипт, сама идентификация узкого места является узким местом. Тем не менее, я мог видеть mstat, пока скрипт выполняет то, что все ядра используются в какой-то или другой момент времени, но основная часть% простоя остается выше (<80%) почти все время. Любые указатели были бы полезны. – knowone

Я бы посмотрел, как читать из шкал '/ dev/urandom'. –

@Maxim имеет хорошую точку. Попытка:

cat /dev/urandom | pv > /dev/null

Это дает данные достаточно быстро? Если не попробовать установить haveged.

/dev/urandom дает вам 8-разрядные случайные данные, но вы сохраняете только 62 значения, поэтому вы будете выбрасывать множество значений. Если /dev/urandom является узким местом, то улучшение будет заключаться в использовании полного значения случайных данных. Если вы MIME-кодируете случайное значение, вы будете использовать все байты и получить 6-битные значения (= 64 разных значения).

источник

2015-03-10 10:42:45

Преимущество 'urandom' заключается в том, что он не блокируется, когда он ограничен энтропией. Это тоже недостаток, потому что это означает, что качество случайного числа хуже. Если вас беспокоит случайное качество, тогда вы просто не должны этого делать, и если вы не ... почти любой RNG будет в любом случае прекрасен;) – Sobrique

Скорость генерации данных составляет ~ 11 МБ/с с/dev/urandom , Это быстро. Еще не использовали MIME, попробуем. Но вернувшись к этой проблеме, я все еще не получаю медленную производительность. – knowone

@Sobrique вы будете хорошо читать http://www.2uo.de/myths-about-urandom/ –

Я нашел ошибку, и вы скажете DOH!

Вы пишите в> tmp. Поэтому, если вы запускаете несколько заданий параллельно, вы будете перезаписывать этот файл снова и снова. Решение состоит в том, чтобы пропустить файл tmp. Таким образом, вы можете сопоставить скорость/dev/urandom, которая затем становится узким местом:

orig() { 
    rows=$1 
    for i in $(seq $rows) 
    do 
    tr -dc A-Za-z0-9 < /dev/urandom | head -c 2000 > tmp 
    gawk '$1=$1' FIELDWIDTHS="$(seq 100|xargs)" OFS=, tmp >> tmp1 
    done 
} 

rm tmp1 
# Around 200 KB/s 
(orig 1000; cat tmp1) | pv | wc -c 

pipeversion() { 
    rows=$1 
    base64 -w 2000 < /dev/urandom | head -n $rows | 
    gawk '$1=$1' FIELDWIDTHS="$(seq 100|xargs)" OFS=,; 
} 

# Around 12 MB/s 
pipeversion 1000 | pv | wc -c 

export -f pipeversion 

# Around 12 MB/s - because /dev/urandom is the bottleneck 
seq 100 | parallel pipeversion 1000 | pv | wc -c

источник

2015-04-04 13:54:31

--parallel = N, не доставляющий требуемые результаты

ответ

Смежные вопросы