Является ли производительность numpy различной в зависимости от операционной системы?
Читая интересную книгу "От Python to Numpy", я встретил пример, описание которого выглядит следующим образом:
Рассмотрим простой пример, где мы хотим очистить все значения из массива с dtype np.float32
. Как написать его для максимальной скорости?
Представленные результаты удивили меня, и когда я перепроверил их, у меня появилось совершенно другое поведение. Итак, я попросил автора дважды проверить, но он получил те же результаты, что и раньше (OS X 10) в таблице ниже:
Варианты были рассчитаны на три разных компьютера: mine (Win10, Win7) и автор (OSX 10.13.3). С Python 3.6.4 и numpy 1.14.2, где каждый вариант был рассчитан на фиксированные 100 циклов, лучше всего 3.
Изменение: этот вопрос не касается того факта, что на разных компьютерах с разными характеристиками я получаю разные времена - это очевидно :) Вопрос в том, что поведение в разных операционных системах сильно отличается - что не так очевидно? (если это, конечно, так, я был бы рад, если бы кто-то мог дважды проверить).
Настройка была: Z = np.ones(4*1000000, np.float32)
| Variant | Windows 10 | Ubuntu 17.10 | Windows 7 | OSX 10.13.3 |
| | computer 1 | comp 2 | comp 3 |
| --------------------------- | ------------------------- | --------- | ----------- |
| Z.view(np.float64)[...] = 0 | 758 usec | 1.03 msec | 2.72 msec | 1.01 msec |
| Z.view(np.float32)[...] = 0 | 757 usec | 1.01 msec | 2.61 msec | 1.58 msec |
| Z.view(np.float16)[...] = 0 | 760 usec | 1.01 msec | 2.62 msec | 2.85 msec |
| Z.view(np.complex)[...] = 0 | 1.06 msec | 1.02 msec | 3.26 msec | 918 usec |
| Z.view(np.int64)[...] = 0 | 758 usec | 1.03 msec | 2.69 msec | 1 msec |
| Z.view(np.int32)[...] = 0 | 757 usec | 1.01 msec | 2.62 msec | 1.46 msec |
| Z.view(np.int16)[...] = 0 | 760 usec | 1.01 msec | 2.63 msec | 2.87 msec |
| Z.view(np.int8)[...] = 0 | 758 usec | 773 usec | 2.68 msec | 614 usec |
| Z.fill(0) | 747 usec | 998 usec | 2.55 msec | N/A |
| Z[...] = 0 | 750 usec | 1 msec | 2.59 msec | N/A |
Как видно из этой таблицы, в Windows результаты не зависят от просматриваемого типа, но в OS X этот хак сильно влияет на производительность. Можете ли вы дать понять, почему это происходит?
Изменить: Как я уже писал выше, три компьютера разные.
Спецификации первого компьютера: Windows 10 и Ubuntu 17.10
Процессор: Intel Xenon E5-1650v4 3,60 ГГц
Оперативная память: 128 ГБ DDR4-2400
Спецификации второго компьютера: Windows 7
Процессор: Intel Pentium P6100 2,00 ГГц
Оперативная память: 4 ГБ DDR3-1333
Спецификации третьего компьютера: у меня нет этой информации :)
Ссылка на вопрос
Редактировать 2: Добавить результаты для первого компьютера на Ubuntu 17.10.
Ответы
Ответ 1
Имейте в виду, что Python - очень высокоуровневый язык программирования, Pandas также является высокоуровневой структурой.
То, что вам по существу уделяется работе, - это API высокого уровня для многих операций, которые вы можете выполнять на языке, без необходимости беспокоиться о базовой реализации.
Если вы должны были работать с API более низкого уровня, чтобы назначить массив переменной, вам нужно будет выделить некоторую память, создайте структуру для хранения ваших данных, соедините ее вместе (возможно, используя указатели на адреса памяти). И вы даже не касались фактического чипа, между виртуальным интерфейсом и фактическими данными, хранящимися на чипе, все еще происходит сопоставление виртуальной памяти. И эта сложность применяется в основном для всего, что вы делаете с Python & Pandas.
Тем не менее, вам нужно сделать только arr = [1, 2, 3]
, и не беспокойтесь об этом.
Теперь Python, как ожидается, будет работать на всех платформах, которые вы запускаете, по крайней мере, в большинстве случаев.
Теперь, после того, как за нами стоит скучное введение, вся идея "разоблачить единый API, не волнуйтесь о реализации" широко распространена в компьютерном программировании. Есть некоторые тонкие детали реализации, которые отличаются одной операционной системой от другой, что может повлиять или не повлиять на производительность вашего программного обеспечения. Я не ожидаю, что это будет значительным, но все равно там и стоит упомянуть.
Например, есть старый ответ о np.dot
функции np.dot
отличающийся от Linux и Windows. У автора есть больше знаний, чем я по этому вопросу, и указывает, что эта конкретная функция является оберткой подпрограмм CBLAS, которая будет использовать самые быстрые подпрограммы, доступные на данной платформе.
Это говорит о том, что панды представляют собой очень сложную библиотеку, которая направлена на то, чтобы сделать анализ данных настолько простым, насколько это возможно, путем предоставления простого API-интерфейса программисту. Я ожидаю, что гораздо больше мест, где Pandas отлично справляется с использованием лучших механизмов, доступных на вашей платформе, для выполнения своих задач так быстро, как только может.