Шум измерений. На выходе точность получается выше, чем у каждого из измерений, взятых по отдельности. Это очень хороший инструмент инженера и его не так сложно освоить, как кажется, когда смотришь в теорию.
Одна из базовых проблем быстродействия Питона кроется в невозможности файнтюнить выделения памяти. Питон все время выделяет маленькие кусочки памяти и это сразу ложится грузом на быстродействие.
Особенно ярко это проявляется, когда пытаешься распарсить какой-нибудь XML. Для каждого нода, для каждого аттрибута будет выделение памяти даже в том случае, если 99% этих данных ты даже не будешь считывать. Как позорное напоминание, есть С++ библиотека RapidXML++ с кастомным менеджером памяти, к которому Питон даже близко не может подойти по быстродействию.
Однажды молодые инженеры делали робота и у них был итеративный модуль «смягчения» пути: по грубым точкам пути надо было сделать более плавный путь, вставив промежуточные точки, и при этом уложиться в две миллисекунды. Проблема решилась написанием кастомного модуля на Cython только после того, как убрали выделение памяти с кучи (вся память выделялась на стеке).
Да, с нулевым. Именно так я начал работать в области Computer Vision — изучил небольшую тему, поискал задачу, решил, изучил следующую тему и т.д. Точно такая же история с нейросетями — предложил клиенту экспериментальное решение — получилось, уверенность в своих силах повысилась, работаю дальше. Семья с двумя детьми прилагается.
В Украине говорят «те самые $5k» подразумевая общепринятый потолок для синьйоров разработчиков. На фрилансе, разумеется, можно зарабатывать и больше. Особенно в сфере data science и computer vision.
Для датасаентиста при 50 долларах в час можно получать и больше 8000 в месяц, ведь можно пойти на перекус не выключая таймтрекер, пока комп тренирует модель. Это программисту надо беспокоиться — включил таймер, выключил, в итоге из восьмичасового дня получается шестичасовой.
Немного смешно читать про оптимизацию Python программ средствами самого Python. 1000 объектов теперь занимают не 100МБ, а 50МБ. Вау! При том, что на C/C++ эти же 1000 объектов уместяться в 64к.
А вообще, писать ускоряющие С/С++/Cython библиотеки для Python — это мой хлеб. И первое, что дает прирост в десятки, а иногда и сотни раз — отказ от использования питоновских объектов и питоновского же менеджера памяти. Больше всего мне нравится, когда в конце разработки клиент замеряет скорость работы и у него округляются глаза. Вычисления зависели, скажем, как O(n) и клиент начинал уже придумывать, как ему уменьшить «n», чтобы вложиться во временной интервал. А после ускорения оказывалось, что даже самый большой «n» клиента вписывается с запасом в одну миллисекунду.
Python хорош для прототипирования. Для Computer Vision или Machine Learning хорошо пробовать много разных вещей и Python тут раскрывается во всей красе. Но если надо запилить свой математический алгоритм, то это неподходящий инструмент.
У меня так произошла революция, когда я перешел с винды на стационарном компе на легкий MacBook Air. С макбуковским тачпадом мышка оказалась не нужна. POSIX-friendly операционная система. Да, сейчас посматриваю на линукс (нативный докер, huge pages и все такое), но сомневаюсь.
Так а что, это работа мечты? Надо какое-то образование, чтобы получать эти $15 в час в США? Человек не хочет учиться, зачем ему больше возможностей по самореализации?
Недавно разбирался с кривыми Безье для организации плавного движения манипулятора робота. Чем более плавное движение, тем большую скорость он может развить без нарушения физических ограничений движения => сможет сделать больше операций => больше профит при коммерческом использовании.
Обнаружил, что кривую Безье лучше сэмплировать не равномерным приростом аргумента, а по первой производной (= равномерно по интегралу второй производной).
Еще обнаружил занимательное исследование, что длина кривой Безье ограничена длиной задающих ее точек, поэтому ее длину можно найти итеративно с любой точностью, разбивая ее пополам на каждой итерации.
Для кривых Безье для максимальной плавности вам надо искать аргумент, который даст следующий прирост по x/y, для этого вы можете взять первую производную — она проще для вычисления.
Это была утечка документации Apple, но на самом деле уже проверено, что пока что новые ноуты Apple ремонтнопригодны сторонними производителями. Конечно, нет гарантии, что в будущем с очередным апдейтом операционной системы не активируется запрет на ремонт.
Я понимаю вашу боль. У меня ощущение, что большая часть молодых разработчиков обучается по stackoverflow, а не по книгам. В итоге смотришь в task manager, а там приложение Upwork стабильно съедает 30-40% CPU. И это чат + трекер времени! С каких пор трекер времени требует столько ресурсов? Это если умножить на количество пользователей Upwork, то можно посчитать, сколько электроэнергии/угля сжигается от лени разработчиков писать эффективный код. Видимо, для получения меньшего числа в массиве сначала сортируется весь массив, потом берется первый элемент, не иначе.
Держите и не благодарите. Когда это знаешь, то иногда получаешь х10 производительности, просто переставив порядок операций. С плавающей точкой аналогично — иногда, решая нелинейные уравнения, результат надо нормализовать по заданному эпсилону, чтобы случайно не взять sqrt(-1e-18), когда должен быть sqrt(0), и не получить nan во всех последующих результатах.
Почитать можно здесь How a Kalman filter works in pictures
Особенно ярко это проявляется, когда пытаешься распарсить какой-нибудь XML. Для каждого нода, для каждого аттрибута будет выделение памяти даже в том случае, если 99% этих данных ты даже не будешь считывать. Как позорное напоминание, есть С++ библиотека RapidXML++ с кастомным менеджером памяти, к которому Питон даже близко не может подойти по быстродействию.
Однажды молодые инженеры делали робота и у них был итеративный модуль «смягчения» пути: по грубым точкам пути надо было сделать более плавный путь, вставив промежуточные точки, и при этом уложиться в две миллисекунды. Проблема решилась написанием кастомного модуля на Cython только после того, как убрали выделение памяти с кучи (вся память выделялась на стеке).
А вообще, писать ускоряющие С/С++/Cython библиотеки для Python — это мой хлеб. И первое, что дает прирост в десятки, а иногда и сотни раз — отказ от использования питоновских объектов и питоновского же менеджера памяти. Больше всего мне нравится, когда в конце разработки клиент замеряет скорость работы и у него округляются глаза. Вычисления зависели, скажем, как O(n) и клиент начинал уже придумывать, как ему уменьшить «n», чтобы вложиться во временной интервал. А после ускорения оказывалось, что даже самый большой «n» клиента вписывается с запасом в одну миллисекунду.
Python хорош для прототипирования. Для Computer Vision или Machine Learning хорошо пробовать много разных вещей и Python тут раскрывается во всей красе. Но если надо запилить свой математический алгоритм, то это неподходящий инструмент.
Т.е. работает хуже и медленнее?
Обнаружил, что кривую Безье лучше сэмплировать не равномерным приростом аргумента, а по первой производной (= равномерно по интегралу второй производной).
Еще обнаружил занимательное исследование, что длина кривой Безье ограничена длиной задающих ее точек, поэтому ее длину можно найти итеративно с любой точностью, разбивая ее пополам на каждой итерации.
Для кривых Безье для максимальной плавности вам надо искать аргумент, который даст следующий прирост по x/y, для этого вы можете взять первую производную — она проще для вычисления.
1. Переключение между тремя полноэкранными приложениями свифтом:
Firefox — Sublime — iTerm
2. Три пальца на неизвестном английском слове — всплывает ABBY словарь с переводом
What Every Programmer Should Know About
Floating-Point Arithmetic
Держите и не благодарите. Когда это знаешь, то иногда получаешь х10 производительности, просто переставив порядок операций. С плавающей точкой аналогично — иногда, решая нелинейные уравнения, результат надо нормализовать по заданному эпсилону, чтобы случайно не взять sqrt(-1e-18), когда должен быть sqrt(0), и не получить nan во всех последующих результатах.