Является ли python автоматическим распараллеливанием секций, связанных с IO и CPU, или с памятью?

Question

Это дополнительные вопросы к предыдущему .

Рассмотрим этот код, который менее забавен, чем тот, что был в предыдущем вопросе (но все же намного проще, чем мой настоящий)

import sys
data=[]

for line in open(sys.argv[1]):
    data.append(line[-1])

print data[-1]

Теперь я ожидал более продолжительного времени выполнения (мой файл теста имеет длину 65150224 строки), возможно, намного дольше. Это был не тот случай, он работает за ~ 2 минуты на том же hw, что и раньше!

Является ли data.append () очень легким? Я не верю в это, поэтому я написал этот фальшивый код для проверки:

data=[]
counter=0
string="a\n"

for counter in xrange(65150224):
    data.append(string[-1])

print data[-1]

Это выполняется за 1,5–3 минуты (между прогонами есть сильная вариабельность)

Почему я не получаю 3,5-5 минут в предыдущей программе? Очевидно, data.append () происходит параллельно с IO.

Это хорошие новости!

Но как это работает? Это документированная особенность? Есть ли какое-то требование к моему коду, которому я должен следовать, чтобы он работал как можно больше (кроме операций ввода-вывода с балансировкой нагрузки и операций с памятью / процессором)? Или это просто буферизация / кеширование в действии?

Опять же, я отметил этот вопрос как "linux", потому что меня интересуют только ответы, относящиеся к linux. Не стесняйтесь давать ответы, не зависящие от ОС, или даже от других ОС, если вы считаете, что это стоит делать.

Answer 1

Очевидно, data.append () происходит параллельно с IO.

Боюсь, что нет. возможно распараллелить ввод-вывод и вычисления в Python, но это не происходит волшебным образом.

Одна вещь, которую вы можете сделать, это использовать posix_fadvise(2), чтобы дать ОС подсказку о том, что вы планируете читать файл последовательно (POSIX_FADV_SEQUENTIAL).

В некоторых грубых тестах, выполняющих "wc -l" для файла 600 мегабайт (ISO), производительность увеличилась примерно на 20%. Каждый тест был выполнен сразу после очистки дискового кэша.

Интерфейс Python для fadvise см. python-fadvise .

Answer 2

Если ваши времена выполнения меняются на эту величину для второго примера, я бы заподозрил, что ваш метод определения времени или внешних воздействий (других процессов / загрузки системы) искажает время до такой степени, что они не достоверная информация.

Answer 3

Я не вижу никаких доказательств того, что «data.append () происходит параллельно с IO». Как и Бенджи, я не думаю, что это так автоматически, как вы думаете. Вы показали, что выполнение data.append (строка [-1]) занимает примерно столько же времени, сколько и lc = lc + 1 (по существу, совсем не время, по сравнению с вводом-выводом и разделением строк). Не удивительно, что data.append (строка [-1]) очень быстрый. Можно было бы ожидать, что вся строка будет в быстром кеше, и, как отмечалось, append заранее готовит буферы и редко перераспределяет их. Более того, строка [-1] всегда будет '\ n', за исключением, возможно, последней строки файла (не знаю, оптимизирует ли Python для этого).

Единственная часть, которая меня немного удивляет, это то, что xrange настолько изменчив. Я ожидал бы, что это всегда будет быстрее, поскольку нет ввода-вывода, и вы фактически не используете счетчик.

Answer 4

Почему вы думаете, что list.append () будет медленной операцией? Это очень быстро, учитывая, что массивы внутренних указателей, используемые списками для хранения ссылок на объекты в них, размещаются во все более больших блоках, так что каждое добавление фактически не перераспределяет массив, и большинство может просто увеличить счетчик длины установить указатель и увеличить.

Answer 5

Насколько большие строки в вашем файле? Если они не очень длинные (вероятно, что-то меньше 1 КБ), то вы, вероятно, видите повышение производительности из-за буферизации ввода.