Классная статья, спасибо за бенчмарки полноценные! Недавно начал пытаться разбираться в поисковых движках, интересно было узнать - что и без нейронок существовуют вероятностные анализаторы. Интересно, почему разрабы PyMorphy отказались от вероятностного анализа? Типо это чисто философский выбор или какие-то тех ограничения?
Cпасибо! Я перепроверил/подразобрался в теме этой. CC и CFLAGS реально применит авто векторизацию, а полученный код получается сопоставимый по скорости с LLVM.
Но в контексте моего бенчмарка(sum_of_squares.py) есть один нюанс в структуре данных (который можно тоже считать за не большой огрех в бенчмарке).
В примере на C-API цикл проходит по python списку с помощью PyList_GetItem. В каждой итерации происходит вызов функции C-API, извлечение PyObject*, проверка на float, конвертация. Для оптимизатора компилятора это каждый раз сюрприз. Типо он просто не уверен, что следующий элемент будет лежать в памяти подряд. Следовательно - не может векторизовать такой цикл.
В случае с Numba я передавал ей непрерывный numpy.ndarray. Для LLVM это предсказуемый массив данных. Он векторизуется дефолтно. (если передам то, что передавал в c++ - Numba упадет в object режим, что чревато еще более долгим выполнением чем чистый python)
По итогу я передавал по разному данные в c++ и Numba. Ну тут косяк.
Если переписать пример на с++ расширении. Принимать не список, а сырой указатель на память, и добавить в setup.py флагиextra_compile_args=['-O3', '-march=native'], то результаты C-API и Numba по логике должны быть практически одинаковыми.
Надо будет в гитхаб статьи добавить компиляцию с нужными флагами и c++ переписать малясь.
Классная статья, спасибо за бенчмарки полноценные! Недавно начал пытаться разбираться в поисковых движках, интересно было узнать - что и без нейронок существовуют вероятностные анализаторы. Интересно, почему разрабы PyMorphy отказались от вероятностного анализа? Типо это чисто философский выбор или какие-то тех ограничения?
Cпасибо! Я перепроверил/подразобрался в теме этой.
CC и CFLAGS реально применит авто векторизацию, а полученный код получается сопоставимый по скорости с LLVM.
Но в контексте моего бенчмарка(sum_of_squares.py) есть один нюанс в структуре данных (который можно тоже считать за не большой огрех в бенчмарке).
В примере на C-API цикл проходит по python списку с помощью
PyList_GetItem. В каждой итерации происходит вызов функции C-API, извлечениеPyObject*, проверка наfloat, конвертация.Для оптимизатора компилятора это каждый раз сюрприз. Типо он просто не уверен, что следующий элемент будет лежать в памяти подряд. Следовательно - не может векторизовать такой цикл.
В случае с Numba я передавал ей непрерывный
numpy.ndarray. Для LLVM это предсказуемый массив данных. Он векторизуется дефолтно. (если передам то, что передавал в c++ - Numba упадет в object режим, что чревато еще более долгим выполнением чем чистый python)По итогу я передавал по разному данные в c++ и Numba. Ну тут косяк.
Если переписать пример на с++ расширении. Принимать не список, а сырой указатель на память, и добавить в
setup.pyфлагиextra_compile_args=['-O3', '-march=native'], то результаты C-API и Numba по логике должны быть практически одинаковыми.Надо будет в гитхаб статьи добавить компиляцию с нужными флагами и c++ переписать малясь.