Это уже 2-я ваша статья на эту тему, абсолютно непонятно зачем вообще это все нужно и какую вообще проблему решает DI и ваш фреймворк в частности. У вас все создания обьектов явно описаны в "Application Container", что мешает сделать тоже самое в функции create_app и без всякого фреймворка? Результат будет одинаковый.
В Rust с одной стороны есть возможность обьявить свой собственный аллокатор что удобно, но нет возможности использовать несколько разных, т.к. аллокатор глобальный. Надеюсь что в следующих версиях починят, вроде бы технически это вполне решаемо
Поможет в том плане что можно создание 90% временных обьектов перенести в стек. Понятно это не решает полностью проблемы фрагментации, но условно меняет ситуацию с "сервис надо рестартить раз в день" на "сервис надо рестартить раз в год"
из моего опыта основные потери связаны с большой фрагментацией памяти. Любые выделения памяти происходят на куче и типичный паттерн поведения это:
1) создается 1000-10К короткоживущих обьектов
2) создается относительно небольшое количество долгоживущих обьектов которые в памяти расположены после обьектов из пункта 1.
3) короткоживущие обьекты освобождаются
4) обьекты созданные в пункте 2. фрагментируют память и не дают вернуть большие блоки памяти в ОС
Т.е. с точки зрения Python все корректно но можно было бы написать сервис гораздо лучше, если бы было больше контроля за тем где именно располагаются обьекты.
это звучит как «поначалу воняет, но потом принюхиваешься»
Имхо больше похоже на то: раньше (на Python) можно было создавать сотни мусорных обьектов и все кое как работало (правда медленно и с повышенным расходом памяти), а теперь приходится думать о концепции владения и продумывать моменты когда эти обьекты перестают быть нужны и выражать это в понятиях Rust.
Для меня совсем не очевидно что Gnome написанный на Rust был бы непременно быстрее написанного на Go.
Конечно это не гаринтировано, тут более интересно послушать примеры из того же Firefox — они долго пытались переделать расчет и рендер CSS написанный на С++, но так и не осилили переписать его для корректной паралельной работы. В итоге переписали на Rust и оказалось что средствами языка можно гарантировать корректность многопоточного решения.
что значит «должно быть»? И 100 и 200 лет спустя и вообще? Я полагаю что «оно» никому и ничего не должно ))
Как минимум до тех пор пока ИИ не научится писать системные драйвера и прочие низкоуровневые приложения.
У Go в основе синтаксиса лежит цельная идеология. Да, у него есть недостатки, но он хотя бы создаётся с последовательной философией.
философия у Go конечно есть хотя на мой взгляд она и ущербная. В том же Go есть ряд сложно решаемых проблем которых априори нет в Rust. В свежей версии вон вставили очередной костыль в планировщик (вытеснение корутин) который нужен для устранения последствий предидущего костыля (корутин без возможности их остановить). В этом плане если вы поймете философию Rust вы увидите что она гораздо более строгая и красивая и содержит меньше противоречий чем в том же Go.
У Python тоже самое, Гвидо имеет фантастическую интуицию что стоит добавлять а что нет.
Python отличный язык и я сам большую часть времени на нем пишу, но это не отменяет того что в нем есть фундаментальный костыль GIL, да и вообще производительность приложений на чистом питоне оставляет желать лучшего. Так что здесь просто надо понимать что вам важнее — внешняя простота или все же возможности которые вам даны через эти закорючки.
Скажу из своего опыта — прежде всего стоит начать с прочтения Rust book для того чтобы без привязки к закорючкам понять именно философию языка. А уже осознав основные идеи и зачем они нужны смотреть на то какими закорючками это выражается. Как показывает моя практика простая программа на Rust выглядит почти также как простая программа на Python. Необходимость в закорючках возникает тогда когда вы делаете вещи которые принципиально невозможно реализовать в Python. А если писать на Rust сложные вещи то поначалу бывает сложно перестроить способ мышления для того чтобы выражать те или иные вещи в понятиях Rust. Но проблема не в закорючках, а все таки в необходимости по другому организовать работу с данными для того чтобы эффективно использовать ресурсы железа
"ручное управление ДОЛЖНО быть" Его сложно назвать действительно ручным (скорее полуавтоматическим), т.к. не нужно в явном виде расставлять free(..) в коде. Но управление таки должно быть если вы хотите добиться максимальной производительности от своего кода. ИМХО вы несколько неправильно воспринимаете Rust. Вы смотрите на него с со стороны какого нибудь высокоуровневого языка типа Python,Go,C#,etc. и поэтому он вам кажется переусложненным, т.к. Ваш язык прячет от вас все те детали которые тут торчат наружу. Вместо этого ИМХО надо на Rust смотреть со стороны того же C и видеть что, не уступая в точности управления памятью и ресурсами программам на С, Rust при этом дает вам возможности близкие к тем что есть в высокоуровневых языках. Т.е. надо его воспринимать не как недо-Python. а как следующее поколение С (не будем упоминать С++ чтоб не вызвать новый холивар от батхерта отдельных товарищей)
Атомарные операции происходят быстро, но тем не менее имеют определенный оверхед (например на синхронизацию кешей разных процессоров). Поэтому в том же Rust есть Rc (не потокобезопасный смарт пойнтер) и Arc (потокобезопасный). В том и прелесть что вы можете использовать ровно тот тип управления памятью который нужен для вашей задачи. И для 80-90% задач достаточно использовать обычные ссылки
Почему ОДИН? если вы используете неизменяемую ссылку то у вас может быть множество указателей на один и тот же участок памяти, а оверхеда все еще нет :)
Потому что использование обычных ссылок за которыми следит Borrow Checker не накладывает рантайм оверхед который есть у ARC. А также вообще не предполагает что ваш процессор поддерживает atomic операции. По сути раст ссылки это некий аналог смарт пойнтеров которые существуют на этапе компиляции, но в рантайме представляют собой просто сырые указатели
Это вы сами придумали? Можно ссылку на документацию которая утверждает что Borrowing это тот же самый ARC? ARC подразумевает некий рантайм оверхед на управление пойнтером чего нет в случае использования обычных ссылок.
Как раз преимущество Rust в том что если вам не нужны смарт пойнтеры то вам хватит и обычных ссылок за которыми следит Borrow Checker. Если вам не хватает стандартных ссылок то в стандартной библиотеке есть полный набор из смарт пойнтеров на все возможные ситуации
2 ReLU используется повсеместно (и уже не новая) как функция активации, потому что дает более быстрое обучение. Она не может служить заменой SoftMax. Вы что-то путаете
Решал похожую задачу. ИМХО можно было бы немножко улучшить систему если:
1) Строить базу используя более длинный эмбендинг (в моем случае 256 бит) и использовать расстояние Хэмминга для расчета похожести лиц.
2) Для поиска похожих эмбендингов можно использовать алгоритм Vantage Point Tree. Данный алгоритм имеет ряд преимуществ перед простым k-d tree по эффективности поиска на больших объемах данных
Из минусов такого решения — все также есть постепенная деградация дерева при вставке новых элементов (можно предпринять ряд шагов для того чтобы сильно замедлить деградацию и практически убрать необходимость перестраивать дерево, но эту часть я уже не могу раскрывать)
Поддержу предыдущего оратора, непонятно за что его заминусовали… Все эти сложные схемы с релиз бранчами, хотфиксами и прочими штуками реально нужны в 5-10% проектов. Во всех остальных прекрасно можно жить имея одну ветку мастер и фиче бранчи. В статье для начинающих на мой взгляд было бы лучше расписать именно такой тривиальный случай который подходит для несложных проектов (все равно начинающим девопсам не доверять в одиночку настраивать процесс для сложного проекта). А уже потом им надо учить и разбираться в каких случаях может быть оправдан более сложный подход.
Ваша картинка для привлечения внимания показывает излишне усложненную схему разработки. Использование такой схемы в 90% случаев приводит к проблемам и ошибкам. Поэтому рекомендовать ее для прод использования или ставить как КДПВ имхо не стоит.
Вы не правы. Вот например https://github.com/xacrimon/dashmap отличный пример как lock-free структура данных спокойно живет с гарантиями Rust. Реализовано это через внутренюю мутабельность и имея immutable ссылку на непосредственно словарь (обычно разделяемую через Arc) можно удобно обращаться к ней из многих потоков. Понятно что внутри реализации есть определенный процент магии атомик переменных и страшных вещей, но при этом внешний интерфейс простой и удобный для прикладного программиста
Тег это просто метка и постоянный указатель на коммит. За годы развития гита было множество вариантов их использовать. Наиболее популярный из тех что есть сейчас — это использовать теги для версионирования. Но при этом в самом гите на этот счет ничего не сказано и вы имеете все возможности использовать их так как вам удобно. Например в одном из наших workflow мы ставим несколько тегов на один коммит — один тег помечает комит как версию, а еще 2 тега на тот же коммит подписаны людьми ответственными за выпуск релиза и соответственно удостоверяют подписью их согласие на выпуск. Соответственно деплой prod окружения происходит при наличии 3-х тегов а не одного. Соответственно мы используем этот механизм так как это удобно нам. Поэтому я не понимаю почему вы считает что для хранения легаси веток их нельзя использовать только потому что Github не дает вам удобной UI для их просмотра
Он решает ее криво, с побочками в виде мусорных тегов, и это просто неудобно.
Чем мусорная закрытая ветка отличается от мусорного тега?
И как это сделать скажем в гитхабе/битбакките, чтобы посетитель репозитория зайдя в раздел релизов не видел там дохлых веток?
Ну это уже вопрос собственно к гитхабу и битбакету, если они не реализовали подобный функционал значит спрос на него небольшой. Это не проблемы гита как системы контроля версий как там гитхаб их отображает
Это уже 2-я ваша статья на эту тему, абсолютно непонятно зачем вообще это все нужно и какую вообще проблему решает DI и ваш фреймворк в частности. У вас все создания обьектов явно описаны в "Application Container", что мешает сделать тоже самое в функции create_app и без всякого фреймворка? Результат будет одинаковый.
Лучше бы тогда уже в таком стиле делали-
В Rust с одной стороны есть возможность обьявить свой собственный аллокатор что удобно, но нет возможности использовать несколько разных, т.к. аллокатор глобальный. Надеюсь что в следующих версиях починят, вроде бы технически это вполне решаемо
Поможет в том плане что можно создание 90% временных обьектов перенести в стек. Понятно это не решает полностью проблемы фрагментации, но условно меняет ситуацию с "сервис надо рестартить раз в день" на "сервис надо рестартить раз в год"
из моего опыта основные потери связаны с большой фрагментацией памяти. Любые выделения памяти происходят на куче и типичный паттерн поведения это:
1) создается 1000-10К короткоживущих обьектов
2) создается относительно небольшое количество долгоживущих обьектов которые в памяти расположены после обьектов из пункта 1.
3) короткоживущие обьекты освобождаются
4) обьекты созданные в пункте 2. фрагментируют память и не дают вернуть большие блоки памяти в ОС
Т.е. с точки зрения Python все корректно но можно было бы написать сервис гораздо лучше, если бы было больше контроля за тем где именно располагаются обьекты.
Имхо больше похоже на то: раньше (на Python) можно было создавать сотни мусорных обьектов и все кое как работало (правда медленно и с повышенным расходом памяти), а теперь приходится думать о концепции владения и продумывать моменты когда эти обьекты перестают быть нужны и выражать это в понятиях Rust.
Конечно это не гаринтировано, тут более интересно послушать примеры из того же Firefox — они долго пытались переделать расчет и рендер CSS написанный на С++, но так и не осилили переписать его для корректной паралельной работы. В итоге переписали на Rust и оказалось что средствами языка можно гарантировать корректность многопоточного решения.
Как минимум до тех пор пока ИИ не научится писать системные драйвера и прочие низкоуровневые приложения.
философия у Go конечно есть хотя на мой взгляд она и ущербная. В том же Go есть ряд сложно решаемых проблем которых априори нет в Rust. В свежей версии вон вставили очередной костыль в планировщик (вытеснение корутин) который нужен для устранения последствий предидущего костыля (корутин без возможности их остановить). В этом плане если вы поймете философию Rust вы увидите что она гораздо более строгая и красивая и содержит меньше противоречий чем в том же Go.
Python отличный язык и я сам большую часть времени на нем пишу, но это не отменяет того что в нем есть фундаментальный костыль GIL, да и вообще производительность приложений на чистом питоне оставляет желать лучшего. Так что здесь просто надо понимать что вам важнее — внешняя простота или все же возможности которые вам даны через эти закорючки.
Скажу из своего опыта — прежде всего стоит начать с прочтения Rust book для того чтобы без привязки к закорючкам понять именно философию языка. А уже осознав основные идеи и зачем они нужны смотреть на то какими закорючками это выражается. Как показывает моя практика простая программа на Rust выглядит почти также как простая программа на Python. Необходимость в закорючках возникает тогда когда вы делаете вещи которые принципиально невозможно реализовать в Python. А если писать на Rust сложные вещи то поначалу бывает сложно перестроить способ мышления для того чтобы выражать те или иные вещи в понятиях Rust. Но проблема не в закорючках, а все таки в необходимости по другому организовать работу с данными для того чтобы эффективно использовать ресурсы железа
"ручное управление ДОЛЖНО быть" Его сложно назвать действительно ручным (скорее полуавтоматическим), т.к. не нужно в явном виде расставлять free(..) в коде. Но управление таки должно быть если вы хотите добиться максимальной производительности от своего кода. ИМХО вы несколько неправильно воспринимаете Rust. Вы смотрите на него с со стороны какого нибудь высокоуровневого языка типа Python,Go,C#,etc. и поэтому он вам кажется переусложненным, т.к. Ваш язык прячет от вас все те детали которые тут торчат наружу. Вместо этого ИМХО надо на Rust смотреть со стороны того же C и видеть что, не уступая в точности управления памятью и ресурсами программам на С, Rust при этом дает вам возможности близкие к тем что есть в высокоуровневых языках. Т.е. надо его воспринимать не как недо-Python. а как следующее поколение С (не будем упоминать С++ чтоб не вызвать новый холивар от батхерта отдельных товарищей)
Атомарные операции происходят быстро, но тем не менее имеют определенный оверхед (например на синхронизацию кешей разных процессоров). Поэтому в том же Rust есть Rc (не потокобезопасный смарт пойнтер) и Arc (потокобезопасный). В том и прелесть что вы можете использовать ровно тот тип управления памятью который нужен для вашей задачи. И для 80-90% задач достаточно использовать обычные ссылки
Почему ОДИН? если вы используете неизменяемую ссылку то у вас может быть множество указателей на один и тот же участок памяти, а оверхеда все еще нет :)
Потому что использование обычных ссылок за которыми следит Borrow Checker не накладывает рантайм оверхед который есть у ARC. А также вообще не предполагает что ваш процессор поддерживает atomic операции. По сути раст ссылки это некий аналог смарт пойнтеров которые существуют на этапе компиляции, но в рантайме представляют собой просто сырые указатели
Это вы сами придумали? Можно ссылку на документацию которая утверждает что Borrowing это тот же самый ARC? ARC подразумевает некий рантайм оверхед на управление пойнтером чего нет в случае использования обычных ссылок.
Как раз преимущество Rust в том что если вам не нужны смарт пойнтеры то вам хватит и обычных ссылок за которыми следит Borrow Checker. Если вам не хватает стандартных ссылок то в стандартной библиотеке есть полный набор из смарт пойнтеров на все возможные ситуации
Сильно поддержку вопрос касательно нагрузки. О каких вообще цифрах входящих и выходящих событий идет речь? Хотя бы порядок чисел.
2 ReLU используется повсеместно (и уже не новая) как функция активации, потому что дает более быстрое обучение. Она не может служить заменой SoftMax. Вы что-то путаете
Решал похожую задачу. ИМХО можно было бы немножко улучшить систему если:
1) Строить базу используя более длинный эмбендинг (в моем случае 256 бит) и использовать расстояние Хэмминга для расчета похожести лиц.
2) Для поиска похожих эмбендингов можно использовать алгоритм Vantage Point Tree. Данный алгоритм имеет ряд преимуществ перед простым k-d tree по эффективности поиска на больших объемах данных
Из минусов такого решения — все также есть постепенная деградация дерева при вставке новых элементов (можно предпринять ряд шагов для того чтобы сильно замедлить деградацию и практически убрать необходимость перестраивать дерево, но эту часть я уже не могу раскрывать)
Поддержу предыдущего оратора, непонятно за что его заминусовали… Все эти сложные схемы с релиз бранчами, хотфиксами и прочими штуками реально нужны в 5-10% проектов. Во всех остальных прекрасно можно жить имея одну ветку мастер и фиче бранчи. В статье для начинающих на мой взгляд было бы лучше расписать именно такой тривиальный случай который подходит для несложных проектов (все равно начинающим девопсам не доверять в одиночку настраивать процесс для сложного проекта). А уже потом им надо учить и разбираться в каких случаях может быть оправдан более сложный подход.
Ваша картинка для привлечения внимания показывает излишне усложненную схему разработки. Использование такой схемы в 90% случаев приводит к проблемам и ошибкам. Поэтому рекомендовать ее для прод использования или ставить как КДПВ имхо не стоит.
Вы не правы. Вот например https://github.com/xacrimon/dashmap отличный пример как lock-free структура данных спокойно живет с гарантиями Rust. Реализовано это через внутренюю мутабельность и имея immutable ссылку на непосредственно словарь (обычно разделяемую через Arc) можно удобно обращаться к ней из многих потоков. Понятно что внутри реализации есть определенный процент магии атомик переменных и страшных вещей, но при этом внешний интерфейс простой и удобный для прикладного программиста
Тег это просто метка и постоянный указатель на коммит. За годы развития гита было множество вариантов их использовать. Наиболее популярный из тех что есть сейчас — это использовать теги для версионирования. Но при этом в самом гите на этот счет ничего не сказано и вы имеете все возможности использовать их так как вам удобно. Например в одном из наших workflow мы ставим несколько тегов на один коммит — один тег помечает комит как версию, а еще 2 тега на тот же коммит подписаны людьми ответственными за выпуск релиза и соответственно удостоверяют подписью их согласие на выпуск. Соответственно деплой prod окружения происходит при наличии 3-х тегов а не одного. Соответственно мы используем этот механизм так как это удобно нам. Поэтому я не понимаю почему вы считает что для хранения легаси веток их нельзя использовать только потому что Github не дает вам удобной UI для их просмотра
Чем мусорная закрытая ветка отличается от мусорного тега?
Ну это уже вопрос собственно к гитхабу и битбакету, если они не реализовали подобный функционал значит спрос на него небольшой. Это не проблемы гита как системы контроля версий как там гитхаб их отображает