Странно. Сколько ни тестировал, Python уступал R по производительности. Причем существенно.
Что я не так делал?

vikkiv,

букв много, даже все прочитал. Но не нашел ответа на посталенный вопрос.

Меряться пиписьками не собираюсь. Вопрос не в том, сколько школьников изучило Python. А в том, что я не так делал, что у меня R существенно по производительности обгонял Python?
Причем, чем длиннее были вектора, больше фильтраций (медианная, скользящим средним, ql-нормальным), трансформаций (Power, BoxCox), интерполяций (Seasonal Decomposition, Kalman Smoothing), кроссвалидаций и т.п. - тем больше по производительности выигрывал R.

Проблемы с параллельностью решаются средствами PostgreSQL и dblink. То есть, R даже принудительно заставляю работать в один поток, но этих потоков запускаю из PostgreSQL функциями на plr по количеству доступных ядер.


Подозреваю, что есть разница в реализации векторов R и массивов Python.


OpenSource R под Linux без проблем собирается с BLAS и MKL. Но зато MS умудряется на один вызов R через sp_execute_external_script тратить почти 30 мс, тогда как plr в PostgreSQL вызывается меньше, чем 1 мс.

Если вызывать plr или plpython, как функции из PostgreSQL, используя параметры-массивы и для исходных данных, и для результатов, то ни pandas ни dataframe просто не нужны. И быстре получается, чем тащить данные из БД средствами R или Python.

Вы не заметили, что сами себе противоречите? Если задачу можно решать в несколько потоков, то совсем не обязательно одним вызовом скармливать ей весь объем данных сразу. Вам просто сложно осознать в голове концепцию того, что массу черновой работы по трансформации и очистке данных можно оставить на стороне SQL, отдавая plr/plpython только те задачи, которые они решают лучше, чем plpgsql. На практике, функции plr/plpython получаются довольно небольшими и простым. Ведь сам алгоритм реализуется в plpgsql. Бессмысленно кормить ту же ARIMA временной серией длиней нескольких сотен элементов. А вот подготовить временную серию длиной не более, чем в 300 элементов из миллиона - с этой задачей справляется plpgsql, задействуя оконные и/или агрегативные функции на R только в некоторые моменты.

Необходимое количество потоков не сложно реализовать через dblink средствами того же PostgreSQL. Это не менее эффективно, чем многопоточность средствами R или Python и позоволяет без особых проблем разпределять задачи не только между локальными ядрами, но и между серверами.

Что касается Spark, я его тоже рассматривал. Но для нашей задачи он оказался мало пригоден. Суть в том, что имея на входе свыше миллиарда событий, ML для тренинга достаются два миллиона разных по составу временных серий. Поэтому затраты на коммуникацию со Spark оказались существенно выше, чем передача в памяти массивов из PostgreSQL в R. Ведь и исходные данные и результаты все равно надо хранить в SQL БД.

P.S. plpython ограничений, по сравнению python почти не имеет. Точнее, это просто использование pyhton на прямую через so. Объективные ограничения возникают только из того, что консоли у такого python нет по определению.

Опять золотой молоток ?

Когда передо мной встала реальная задача, в которой потребовался ML я знал Python, но не знал R.
Но это мне совершенно не помешало за несколько дней изучить R в достаточном для НИОКР объеме.
Когда же я оценил производительность решений на R и Python, то оценил эффективность работы с векторами и матрицами в R и для этого конкретного проекта был выбран R.
На этом же проекты возникли проблемы с производительностью связки MS SQL+R Service. Зная PostgreSQL весьма поверхностно, я не поленился потратить несколько дней на его изучение и сравнить в данном применении связку PostgreSQL+R (plr). Последний выиграл с большим отрывом.

Если на следующем проекте на фазе НИОКР окажется эффективней Python - буду использовать его. Если вдруг окажется эффективней Julia - разберусь и с ней. Если эффективней окажется Spark или ClickHours - буду использовать их.
Никакого желания ограничивать себя "золотым молотком" не испытываю, чего и Вам желаю.

Я всегда искренне считал, что на этапе НИКОР просто необходимо рассматривать альтернативные варианты решения и сравнивать их. А не пытаться подогнать задачи проекта под уже освоенный "золотой молоток".

Александр Бердышев,

так только первую версию в продуктив в декабре запустили. Даже еще не открыли вакансии для ТП.
Сам я собираюсь только помочь в организации поддержки. Все результаты НИОКР обсуждались с руководством, риски учитывались и выбор технологий был санкционирован. Так что, строго говоря, это уже давно не моя головная боль.

Для R специалист уже есть. River Logic + Gurobi тоже. Для PostgreSQL нужно нанимать. Но там тупая арифметика сработала. Попытка решить задачу на MS SQL требовала обязательно Enterprise из-за ограничения на 4 ядра у R Service у Standard. А это свыше 7 тыс. вечнозеленых ежемесячно за 32 ядра, которые еще планируется нарастить до 64-х (на двух серверах). За такие деньги нанять специалиста на поддержку более чем реально.