Тут все очень просто: выпустили в режиме догоняющих, без киллер-фич, как следствие не взлетело, критмассы нет, молча похоронили. Индустрия AI сейчас меняет курс слишком быстро, что поделать...
язык становится востребованным, когда с его помощью удаётся реализовать что-то значимое - быстрее, надёжнее, проще или красивее, чем на других технологиях
Из этого кстати может возникнуть интересное обсуждение. Начну: Go - Kubernetes
В статье не хватает информации о потреблении ресурсов по сравнению с градиентным бустингом (который неплохо работает на CPU в отличие от нейросетевых моделей).
Дополнительным эффектом бессмертных объектов является отсутствие записи в счетчик ссылок, а значит, отсутствие необходимости обновлять кеши CPU, что отобразится в более эффективных паттернах работы с памятью для таких объектов.
В функцию Py_INCREF добавился if, причем обычно не выполняющийся (исходя из предположения, что большинство объектов не бессмертные). Навскидку бы сказал, что в этом основная причина деградации по скорости
Я хоть и не узнал ничего нового, но тем не менее статья видится очень полезной. Буду рекомендовать всем, кто на собеседованиях путает unicode, utf8, руны и т.д. Спасибо за систематизацию!
Я не решил так, а описал впечатление от прочтения. Дочитал, в конце стало непонятно какая судьба теперь у async/await, у threading, у multiprocessing, когда что использовать и т.д. И в бенчмарках нет однозначного фаворита. Я отчасти поэтому спросил про юзкейсы. Что происходит в идеальном сценарии развития языка и библиотек по задумке авторов субинтерпретаторов?
Какие в итоге юзкейсы для субинтерпретаторов? Подходят ли они, например, для обработки веб-сервера (по одному на каждый запрос)? Какое количество в рамках одного процесса считается адекватным числом?
Читается так, как будто пришлось все переписать, а профит точечный, все или хотя бы большинство проблем не полечились
Ответ на ваш вопрос белыми нитками шит. И не просто шит, а по краям у него кружевной кант. Общий вид довольно дик. Такие вопросы для нашего времени — настоящий бич
Потому что сначала трансформеры нужно было открыть, т.е. обнаружить эту успешно работающую на практике модель с помощью многих итераций проб и ошибок. И только потом стало возможным написать эффективную реализацию на C/C++, зная что нужно написать и имея готовые веса для проверки.
Python'овский ML-стек подходит для исследователей, так как даёт высокую скорость итераций и лёгкость экспериментирования. C/C++ же даёт скорость выполнения за счёт эффективной реализации конкретной модели.
Теперь вся фоновая работа регулируется и модерируется Google Play и RuStore
Можете чуть раскрыть этот момент? "RuStore" встречается за статью один раз, причем сразу в выводе. Читается так, как будто есть возможность как-то управлять фоновой работой приложений из другого приложения. Или у маркетплейса приложений какие-то специальные права для приложений, которые через него установили?
Хотел написать, что сама по себе Gemma3 очень понравилась, работает практически без нареканий, не путает языки, не теряется в ответах, хорошо помнит контекст. пока лучшая 14B модель которую я пробовал. Посмотрим что будет с 3n
Присоединяюсь, довольно приятно описана база. Можно использовать как обучение и для начинающих Go-разработчиков, и для новоприбывших из других языков/технологий.
Когда-то давно пришлось делать "склейку" из двух desktop-приложений: одно на C#, второе на Delphi. В каждом из них были реализованы определенные формочки, которые вызывали друг друга по бизнес-сценариям (посредством несложного обмена файликами). Создавалось впечатление, что это одно приложение, просто стиль окошек разный. Иногда вызовы формировали цепочки, например C# -> Delphi -> C# -> Delphi. Самая большая сложность была с модальностью - нужно было сделать так, чтобы модальное окно на одном языке перекрывало все окна на другом языке. Та еще задачка! Вдруг кому-то интересно поломать голову, поэтому спрячу решение за спойлер: помогла функция SetWindowLongW с параметром GWL_HWNDPARENT.
К чему это я: сложно это все, большая исследовательская работа проделана, за это респект! Стоило ли оно того или виртуальные среды действительно лучшее решение - вопрос.
Тут все очень просто: выпустили в режиме догоняющих, без киллер-фич, как следствие не взлетело, критмассы нет, молча похоронили. Индустрия 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, о нём писали на Хабре. Есть ли значимые различия?
Ага, тоже задавался вопросом, перечитал в поисках ответа и не нашел. Видимо эта часть упущена
Класс, она уже есть на Ollama: https://ollama.com/library/gemma3n
Хотел написать, что сама по себе Gemma3 очень понравилась, работает практически без нареканий, не путает языки, не теряется в ответах, хорошо помнит контекст. пока лучшая 14B модель которую я пробовал. Посмотрим что будет с 3n
Присоединяюсь, довольно приятно описана база. Можно использовать как обучение и для начинающих Go-разработчиков, и для новоприбывших из других языков/технологий.
Когда-то давно пришлось делать "склейку" из двух desktop-приложений: одно на C#, второе на Delphi. В каждом из них были реализованы определенные формочки, которые вызывали друг друга по бизнес-сценариям (посредством несложного обмена файликами). Создавалось впечатление, что это одно приложение, просто стиль окошек разный. Иногда вызовы формировали цепочки, например C# -> Delphi -> C# -> Delphi. Самая большая сложность была с модальностью - нужно было сделать так, чтобы модальное окно на одном языке перекрывало все окна на другом языке. Та еще задачка! Вдруг кому-то интересно поломать голову, поэтому спрячу решение за спойлер: помогла функция SetWindowLongW с параметром GWL_HWNDPARENT.
К чему это я: сложно это все, большая исследовательская работа проделана, за это респект! Стоило ли оно того или виртуальные среды действительно лучшее решение - вопрос.
Кстати тоже возник этот вопрос по ходу чтения статьи, возможно стоит в самом начале дать краткое определение.