Случилась в начале 80-х забавная история, один из аспирантов В.Б.Брагинского уронил монокристалл сапфира, предназначенный для гравитационно-волнового детектора. После чего монокристалл перестал быть монокристаллом. Понятно, что в результате диссертация по графитационным волнам не состоялась, зато появилась диссертация на тему "как покоцанный кристалл сапфира превратить обратно в монокристалл" ))
О том и речь, исходная статья не про то как переходом на Rust ускориться в 180 000 раз, а о том, как оптимизацией алгоритма ускориться в 22 500 раз.
А вторая статья про оптимизацию исходного кода на Python и в конечном итоге переходу на Numba. Результат примерно тот же самый (170 000 vs 180 0000). Что не удивительно поскольку и у Rust и у Numba под капотом LLVM.
Спасибо за ссылочку, очень интересный материал, у автора помимо этого еще есть что почитать.
Гипотеза о том, что погодные условия оказывают влияние на ценообразование электроэнергии, в результате корреляционного анализа была опровергнута
Возможно имеется в виду цена генерации одного конкретного типа (тепловая, гидро-, ветрогенерация). Хотя как - вот к примеру в Саудовской Аравии допустим экстремальная жара стоит на месяц дольше (или температура на несколько градусов выше нормы), требуется увеличение объема тепловой генерации, растет спрос на мазут, растет соответственно цена на мазут, и как следствие цена киловатт-часа.
Машинное обучение является по существу разновидностью прикладной статистики, с акцентом на использование компьютеров для статистической оценки значений сложных функций, а не выводе доверительных интервалов для этих значений (Machine learning is essentially a form of applied statistics with increased emphasis on the use of computers to statistically estimate complicated functions and a decreased emphasis on proving confidence intervals around these functions)
А вообще приведенный пример - идеальное описание 99 (а то и 99,9) % проектов по применению машинного обучения - красиво, элегантно, но какая либо практическая польза как минимум не доказана. А скорее отсутствует.
Товарищи ученые сравнивали точность, с одной стороны, и требуемые ресурсы, с другой, для АРСС (оно же ARIMA), SVM и нейросетей.
И пришли к неутешительному выводу что некое повышение точности предсказания покупается ценой несоразмерного увеличения требуемых вычислительных ресурсов.
Для сравнения использовались данные по финансовым рынкам, прогнозированию погоды, энергопотреблению, дорожному движению, медицинской статистике.
Насколько разработанные вами модели зависят от требуемых ресурсов? К примеру, повышение точности прогноза (скажем, по среднеквадратичному уклонению) на XX % требует в YY раз больше вычислительных ресурсов (CPU/GPU, времени расчета и т.п.).
,,,
8. Переходить на Go ))
А, нашел
Всем спасибо ))
Кстати хороший вопрос, ну стянул я с зеркала / через прокси условный alpine@latest, а дальше мне как на него то что мне нужно установить?
В любом случае спасибо за наводку, занятная библиотека, надо будет глянуть при случае что там внутри ))
Мне одному эта фраза кажется странной? )) Вроде 600 x 12 = 7.200, не?
А вообще да, если у какой-либо конторы 600 рублей в месяц это проблема, то вряд ли она решится экономией этих самых шести сотен
Разработчики на Fortran до версии IV включительно скорее всего с этим утверждением согласятся (по крайней мере те кто еще с нами)
Создатели Go не согласны
Edit: Виноват, не дочитал тред до конца
Случилась в начале 80-х забавная история, один из аспирантов В.Б.Брагинского уронил монокристалл сапфира, предназначенный для гравитационно-волнового детектора. После чего монокристалл перестал быть монокристаллом. Понятно, что в результате диссертация по графитационным волнам не состоялась, зато появилась диссертация на тему "как покоцанный кристалл сапфира превратить обратно в монокристалл" ))
О том и речь, исходная статья не про то как переходом на Rust ускориться в 180 000 раз, а о том, как оптимизацией алгоритма ускориться в 22 500 раз.
А вторая статья про оптимизацию исходного кода на Python и в конечном итоге переходу на Numba. Результат примерно тот же самый (170 000 vs 180 0000). Что не удивительно поскольку и у Rust и у Numba под капотом LLVM.
Спасибо за ссылочку, очень интересный материал, у автора помимо этого еще есть что почитать.
Возможно имеется в виду цена генерации одного конкретного типа (тепловая, гидро-, ветрогенерация). Хотя как - вот к примеру в Саудовской Аравии допустим экстремальная жара стоит на месяц дольше (или температура на несколько градусов выше нормы), требуется увеличение объема тепловой генерации, растет спрос на мазут, растет соответственно цена на мазут, и как следствие цена киловатт-часа.
Хорошо было бы услышать разъяснения от авторов.
отсюда
А вообще приведенный пример - идеальное описание 99 (а то и 99,9) % проектов по применению машинного обучения - красиво, элегантно, но какая либо практическая польза как минимум не доказана. А скорее отсутствует.
Или как вариант на сэкономленные на ИИ деньги добавлять в шихту ГБЖ в таком количестве, что вопрос о качестве лома отпадет сам собой
Я не к тому что 100% так и есть, а к тому что да, интересно увидеть экономику такого проекта, но увы
Такое ощущение что комментарий в неправильной ветке оказался (здесь такое случается регулярно).
Он ведь не про исходную статью, а про комментарий выше.
Или нет?
@mikerosoft На схеме среди источников данных не увидел SAP. Его прибили / не используется / прячется за
Oracle (3 БД)?Товарищи ученые сравнивали точность, с одной стороны, и требуемые ресурсы, с другой, для АРСС (оно же ARIMA), SVM и нейросетей.
И пришли к неутешительному выводу что некое повышение точности предсказания покупается ценой несоразмерного увеличения требуемых вычислительных ресурсов.
Для сравнения использовались данные по финансовым рынкам, прогнозированию погоды, энергопотреблению, дорожному движению, медицинской статистике.
Насколько разработанные вами модели зависят от требуемых ресурсов? К примеру, повышение точности прогноза (скажем, по среднеквадратичному уклонению) на XX % требует в YY раз больше вычислительных ресурсов (CPU/GPU, времени расчета и т.п.).
в три раза больше если быть точным
Можете пожалуйста пояснить чего в
servingmlпринципиально не хватает чтобы пользоваться им в продуктивной среде?Выше @ivankudryavtsev высказал несколько замечаний, хотелось бы услышать Вашу точку зрения на этот счет
Добро пожаловать во взрослую жизнь ))
Программа на компилируемом языке работает быстрее чем на интрепретируемом. Надо же, кто бы мог подумать
Было бы интересно увидеть сравнение производительности с JAX и/или Numba, а так ни о чем статья
OpenOffice еще с каких-то лохматых времен макросы на Python поддерживал, ну и LibreOffice естественно не отстает
А эти проснулись наконец