За карьеру провел сотни собеседований и в разы больше просмотрел резюме. Могу подтвердить, что "вылизанный" проект чаще работает в минус, чем в плюс. У среднего соискателя в github'е несколько форков (в основном ради пары коммитов) и полтора пет-проекта, собранные на коленке. На этом фоне тщательно оформленный и прибранный проект смотрится слишком подозрительно. При внимательном изучении часто оказывается, что это артефакт прохождения какого-нибудь курса или практикума, в котором обещано портфолио. Т.е. никакой реальный опыт работы не подтверждает.
Когда уже на Хабре появится значок - нейростатья?.. Хотя бы для удобства чтения и восприятия. Пусть живут такие статьи, на здоровье, потому что минорная ценность все же есть, но легко отделять оригинальную авторскую мысль от очередного пересказа все же очень хотелось бы!
Возможно кому-то будет интересно послушать про то, почему литий так мало распространен во Вселенной и в чем его уникальность с точки зрения строения атомного ядра:
Основной посыл статьи неплохой, однако выводы на основе частных случаев смущают. Например:
Тимлид – это когда ты должен быть на связи 24/7. Суббота, воскресенье, утро 1 января – не важно
Нет, это просто-напросто неправда. Похоже вас в этом убедила пагубная среда или это ваша гиперответственность материализовалась. На самом деле бывает и даже очень распространена зрелая, спокойная и уверенная тимлидская работа.
История стара как мир наша индустрия. Подобное часто бывает с тимлидами-самоучками (или как сейчас называют first-time manager). Главное не опускать руки, ознакомиться с многочисленными похожими историями и научиться терраформировать окружение под себя, а не пытаться усидеть на всех стульях. И работа снова начнет приносить удовольствие ;)
Тут все очень просто: выпустили в режиме догоняющих, без киллер-фич, как следствие не взлетело, критмассы нет, молча похоронили. Индустрия AI сейчас меняет курс слишком быстро, что поделать...
язык становится востребованным, когда с его помощью удаётся реализовать что-то значимое - быстрее, надёжнее, проще или красивее, чем на других технологиях
Из этого кстати может возникнуть интересное обсуждение. Начну: Go - Kubernetes
В статье не хватает информации о потреблении ресурсов по сравнению с градиентным бустингом (который неплохо работает на CPU в отличие от нейросетевых моделей).
Дополнительным эффектом бессмертных объектов является отсутствие записи в счетчик ссылок, а значит, отсутствие необходимости обновлять кеши CPU, что отобразится в более эффективных паттернах работы с памятью для таких объектов.
В функцию Py_INCREF добавился if, причем обычно не выполняющийся (исходя из предположения, что большинство объектов не бессмертные). Навскидку бы сказал, что в этом основная причина деградации по скорости
Я хоть и не узнал ничего нового, но тем не менее статья видится очень полезной. Буду рекомендовать всем, кто на собеседованиях путает unicode, utf8, руны и т.д. Спасибо за систематизацию!
Я не решил так, а описал впечатление от прочтения. Дочитал, в конце стало непонятно какая судьба теперь у async/await, у threading, у multiprocessing, когда что использовать и т.д. И в бенчмарках нет однозначного фаворита. Я отчасти поэтому спросил про юзкейсы. Что происходит в идеальном сценарии развития языка и библиотек по задумке авторов субинтерпретаторов?
Какие в итоге юзкейсы для субинтерпретаторов? Подходят ли они, например, для обработки веб-сервера (по одному на каждый запрос)? Какое количество в рамках одного процесса считается адекватным числом?
Читается так, как будто пришлось все переписать, а профит точечный, все или хотя бы большинство проблем не полечились
Ответ на ваш вопрос белыми нитками шит. И не просто шит, а по краям у него кружевной кант. Общий вид довольно дик. Такие вопросы для нашего времени — настоящий бич
Потому что сначала трансформеры нужно было открыть, т.е. обнаружить эту успешно работающую на практике модель с помощью многих итераций проб и ошибок. И только потом стало возможным написать эффективную реализацию на C/C++, зная что нужно написать и имея готовые веса для проверки.
Python'овский ML-стек подходит для исследователей, так как даёт высокую скорость итераций и лёгкость экспериментирования. C/C++ же даёт скорость выполнения за счёт эффективной реализации конкретной модели.
Теперь вся фоновая работа регулируется и модерируется Google Play и RuStore
Можете чуть раскрыть этот момент? "RuStore" встречается за статью один раз, причем сразу в выводе. Читается так, как будто есть возможность как-то управлять фоновой работой приложений из другого приложения. Или у маркетплейса приложений какие-то специальные права для приложений, которые через него установили?
Отличный разбор!
За карьеру провел сотни собеседований и в разы больше просмотрел резюме. Могу подтвердить, что "вылизанный" проект чаще работает в минус, чем в плюс. У среднего соискателя в github'е несколько форков (в основном ради пары коммитов) и полтора пет-проекта, собранные на коленке. На этом фоне тщательно оформленный и прибранный проект смотрится слишком подозрительно. При внимательном изучении часто оказывается, что это артефакт прохождения какого-нибудь курса или практикума, в котором обещано портфолио. Т.е. никакой реальный опыт работы не подтверждает.
Когда уже на Хабре появится значок - нейростатья?.. Хотя бы для удобства чтения и восприятия. Пусть живут такие статьи, на здоровье, потому что минорная ценность все же есть, но легко отделять оригинальную авторскую мысль от очередного пересказа все же очень хотелось бы!
Статья нейросетевая, тут не о чем говорить.
Возможно кому-то будет интересно послушать про то, почему литий так мало распространен во Вселенной и в чем его уникальность с точки зрения строения атомного ядра:
https://youtu.be/3ra5KERCwOc?si=kvhNv531z4ogW01X
Основной посыл статьи неплохой, однако выводы на основе частных случаев смущают. Например:
Нет, это просто-напросто неправда. Похоже вас в этом убедила пагубная среда или это ваша гиперответственность материализовалась. На самом деле бывает и даже очень распространена зрелая, спокойная и уверенная тимлидская работа.
История стара как
мирнаша индустрия. Подобное часто бывает с тимлидами-самоучками (или как сейчас называют first-time manager). Главное не опускать руки, ознакомиться с многочисленными похожими историями и научиться терраформировать окружение под себя, а не пытаться усидеть на всех стульях. И работа снова начнет приносить удовольствие ;)Тут все очень просто: выпустили в режиме догоняющих, без киллер-фич, как следствие не взлетело, критмассы нет, молча похоронили. Индустрия AI сейчас меняет курс слишком быстро, что поделать...
Картинка в тему
Из этого кстати может возникнуть интересное обсуждение. Начну: Go - Kubernetes
В статье не хватает информации о потреблении ресурсов по сравнению с градиентным бустингом (который неплохо работает на CPU в отличие от нейросетевых моделей).
В функцию Py_INCREF добавился if, причем обычно не выполняющийся (исходя из предположения, что большинство объектов не бессмертные). Навскидку бы сказал, что в этом основная причина деградации по скорости
Я хоть и не узнал ничего нового, но тем не менее статья видится очень полезной. Буду рекомендовать всем, кто на собеседованиях путает unicode, utf8, руны и т.д. Спасибо за систематизацию!
Я не решил так, а описал впечатление от прочтения. Дочитал, в конце стало непонятно какая судьба теперь у async/await, у threading, у multiprocessing, когда что использовать и т.д. И в бенчмарках нет однозначного фаворита. Я отчасти поэтому спросил про юзкейсы. Что происходит в идеальном сценарии развития языка и библиотек по задумке авторов субинтерпретаторов?
Давно такое в ноде? Что-то не попадалось материалов по теме... Можете ссылочку дать?
Какие в итоге юзкейсы для субинтерпретаторов? Подходят ли они, например, для обработки веб-сервера (по одному на каждый запрос)? Какое количество в рамках одного процесса считается адекватным числом?
Читается так, как будто пришлось все переписать, а профит точечный, все или хотя бы большинство проблем не полечились
Классика!
Как и Твиттер, все логично 😅
(добрый юмор)
Понятно, т.е. регулируется не приложениями Google Play и RuStore, а процессами ревью приложений в этих магазинах.
Потому что сначала трансформеры нужно было открыть, т.е. обнаружить эту успешно работающую на практике модель с помощью многих итераций проб и ошибок. И только потом стало возможным написать эффективную реализацию на C/C++, зная что нужно написать и имея готовые веса для проверки.
Python'овский ML-стек подходит для исследователей, так как даёт высокую скорость итераций и лёгкость экспериментирования. C/C++ же даёт скорость выполнения за счёт эффективной реализации конкретной модели.
Можете чуть раскрыть этот момент? "RuStore" встречается за статью один раз, причем сразу в выводе. Читается так, как будто есть возможность как-то управлять фоновой работой приложений из другого приложения. Или у маркетплейса приложений какие-то специальные права для приложений, которые через него установили?
Либо я невнимательно прочитал, либо про Go в статье ничего нет. Хорошо бы поправить тэги
Показалось похоже на sqlc, о нём писали на Хабре. Есть ли значимые различия?