Тут решающим является не бюджетность, а именно год выпуска. Даже в самых дешманских, но современных ноутбуках аппаратное ускорение декодирования (и даже кодирования) будет присутствовать.
Ну там не только функционал встреч, но и офис. Короче, комплексное бизнес-решение.
Вот проблемы, с которыми я сталкивался:
Очень тяжёлый и прожорливый клиент, который понемногу ест CPU, даже сидя в трее, а это минус автономное время работы для ноута. И ладно бы у него был какой-то функционал, но нет — это просто браузер. Вот прямо сейчас вышел из Teams, а он заглючил, остался висеть и начал жрать 100% cpu. Почему? А хз.
Принципиальное нежелание Microsoft, чтобы люди пользовались браузером вместо родного клиента. В какой-то момент мне даже User Agent пришлось менять, потому что веб-версия соглашалась работать только через Edge. Upd: сейчас проверил, через Firefox уже нормально работает.
Очень долгое время загрузки как самого Teams, так и веб-офиса. В разы медленее, чем Google Meet и Google Drive.
Большие задержки в приходе оповещений для мобильной версии Teams. Например, я могу прочитать сообщение только через неделю. Для переписки гораздо более удобен Telegram или обычная электронная почта.
Zoom не может шарить окна, открытые на другом дисплее через Xephyr, браузер — может.
На самом деле, пункт 2 — это вообще киллер-фича линукса. У меня 4K монитор, и собеседникам очень не нравится, когда я его шарю целиком (им слишком мелко). Вместо этого я создаю виртуальный экран размера порядка 1024х768 и запускаю всё внутри него.
Тут дело не в PyTorch, а в том, что новые видеокарты не поддерживаются старыми версиями CUDA. Старую версию PyTorch вполне можно скомпилировать с поддержкой новой версии CUDA, и всё будет прекрасно работать.
NVIDIA GeForce RTX 3080 Ti with CUDA capability sm_86 is not compatible with the current PyTorch installation.
The current PyTorch install supports CUDA capabilities sm_37 sm_50 sm_60 sm_70.
NVIDIA GeForce RTX 3080 Ti with CUDA capability sm_86 is not compatible with the current PyTorch installation.
The current PyTorch install supports CUDA capabilities sm_37 sm_50 sm_60 sm_70.
Старые версии PyTorch и CUDA не могут работать с новой видеокартой и драйвером.
Статистические бинарники однозначно будут меньше места занимать, если следовать принципу "you only pay for what you use". Компилятор просто выкинет неиспользуемый код, чего не скажешь о Python, где либы приходится таскать с собой целиком.
По инструкции через конду всё хорошо установилось, вот только накачало 20 гигов файлов и не смогло запуститься на видеокарте (слишком старые версии пакетов в requirements.txt).
Плюнул и решил попробовать запустить напрямую, просто устанавливая нужные пакеты по мере вываливания ошибок, либо удаляя импорты, если они не нужны для инференса. Десять минут, десяток мегабайт на отсутствующие пакеты — и всё работает в лучшем виде.
До Python никто не писал настолько масштабных проектов, и эти проблемы попросту не вылезали.
Главная проблема Python — отвратительная ситуация с обратной совместимостью. Причём как в самом языке, так и в библиотеках. Поэтому программисты зачастую не заморачиваются и фиксируют версии всех зависимостей так, на всякий случай.
Да, virtualenv и conda решают проблему с зависимостями, но приводят к другим проблемам:
Дичайшее раздувание размера проекта. В случае ML-проектов это порядка 3-5 гигов на каждый проект.
Сложность с одновременным использованием нескольких проектов. Нельзя обойтись по-простому парой импортов.
Старые зависимости могут просто пропасть.
Невозможность запустить проект из-за несовместимости старых библиотек с операционной системой (тут поможет docker) или железом (тут docker уже не поможет).
Например, старая версия pytorch тянет за собой старую версию CUDA, а старая CUDA не совместима с новой видеокартой. При этом с более новыми версиями библиотек проект не запускается, причём проблема не в основной части проекта (инференс), а в какой-то там вспомогательной обвязке, которую можно было безжалостно вырезать.
Версионирование зависимостей — это зло, которое неизбежно будет приводить к раздуванию кода. А самое весёлое — это когда вам надо скрестить несколько проектов, каждый со своим уникальным набором зависимостей.
Вот уж чего не хватает C#, так это реализации IEquatable<> для enum.
Вместо этого приходится использовать костыль в виде EqualityComparer<>.Default.Equals (который, кстати, инлайнится, что не так уж и плохо).
Всё работает, просто по славной линуксовой традиции нужно применять напильник, например, поменять строчку в конфигурационном файле.
Строчка появляется, если нажать на Launch Meeting, а потом нажать отмену.
Тут решающим является не бюджетность, а именно год выпуска. Даже в самых дешманских, но современных ноутбуках аппаратное ускорение декодирования (и даже кодирования) будет присутствовать.
Ну там не только функционал встреч, но и офис. Короче, комплексное бизнес-решение.
Вот проблемы, с которыми я сталкивался:
Очень тяжёлый и прожорливый клиент, который понемногу ест CPU, даже сидя в трее, а это минус автономное время работы для ноута. И ладно бы у него был какой-то функционал, но нет — это просто браузер. Вот прямо сейчас вышел из Teams, а он заглючил, остался висеть и начал жрать 100% cpu. Почему? А хз.
Принципиальное нежелание Microsoft, чтобы люди пользовались браузером вместо родного клиента. В какой-то момент мне даже User Agent пришлось менять, потому что веб-версия соглашалась работать только через Edge. Upd: сейчас проверил, через Firefox уже нормально работает.
Очень долгое время загрузки как самого Teams, так и веб-офиса. В разы медленее, чем Google Meet и Google Drive.
Большие задержки в приходе оповещений для мобильной версии Teams. Например, я могу прочитать сообщение только через неделю. Для переписки гораздо более удобен Telegram или обычная электронная почта.
Teams — редкостная гадость в плане юзабилити, продавить её реально можно только админресурсом.
Угу:
На самом деле, пункт 2 — это вообще киллер-фича линукса. У меня 4K монитор, и собеседникам очень не нравится, когда я его шарю целиком (им слишком мелко). Вместо этого я создаю виртуальный экран размера порядка 1024х768 и запускаю всё внутри него.
Хм, не знал об этом. Он же очень настойчиво требует запустить клиент.
А ещё лучше Zoom — Google Meet, ибо работает из браузера.
Для Zoom же нужен клиент, который в Linux ещё и отображается криво.
Тут дело не в PyTorch, а в том, что новые видеокарты не поддерживаются старыми версиями CUDA. Старую версию PyTorch вполне можно скомпилировать с поддержкой новой версии CUDA, и всё будет прекрасно работать.
Да, так и есть. Есть ещё промежуточный вариант: написать код на C++, оформить в виде либы и цеплять его из Python.
Ага. А через год будет так:
Это нисколько не поможет от ошибок вида:
Старые версии PyTorch и CUDA не могут работать с новой видеокартой и драйвером.
Статистические бинарники однозначно будут меньше места занимать, если следовать принципу "you only pay for what you use". Компилятор просто выкинет неиспользуемый код, чего не скажешь о Python, где либы приходится таскать с собой целиком.
Ну вот только что решил попробовать вот это:
https://github.com/saic-mdal/lama
По инструкции через конду всё хорошо установилось, вот только накачало 20 гигов файлов и не смогло запуститься на видеокарте (слишком старые версии пакетов в requirements.txt).
Плюнул и решил попробовать запустить напрямую, просто устанавливая нужные пакеты по мере вываливания ошибок, либо удаляя импорты, если они не нужны для инференса. Десять минут, десяток мегабайт на отсутствующие пакеты — и всё работает в лучшем виде.
До Python никто не писал настолько масштабных проектов, и эти проблемы попросту не вылезали.
Главная проблема Python — отвратительная ситуация с обратной совместимостью. Причём как в самом языке, так и в библиотеках. Поэтому программисты зачастую не заморачиваются и фиксируют версии всех зависимостей так, на всякий случай.
Да, virtualenv и conda решают проблему с зависимостями, но приводят к другим проблемам:
Дичайшее раздувание размера проекта. В случае ML-проектов это порядка 3-5 гигов на каждый проект.
Сложность с одновременным использованием нескольких проектов. Нельзя обойтись по-простому парой импортов.
Старые зависимости могут просто пропасть.
Невозможность запустить проект из-за несовместимости старых библиотек с операционной системой (тут поможет docker) или железом (тут docker уже не поможет).
Например, старая версия pytorch тянет за собой старую версию CUDA, а старая CUDA не совместима с новой видеокартой. При этом с более новыми версиями библиотек проект не запускается, причём проблема не в основной части проекта (инференс), а в какой-то там вспомогательной обвязке, которую можно было безжалостно вырезать.
Версионирование зависимостей — это зло, которое неизбежно будет приводить к раздуванию кода. А самое весёлое — это когда вам надо скрестить несколько проектов, каждый со своим уникальным набором зависимостей.
Вот уж чего не хватает C#, так это реализации
IEquatable<>для enum.Вместо этого приходится использовать костыль в виде
EqualityComparer<>.Default.Equals(который, кстати, инлайнится, что не так уж и плохо).Насчёт пункта 4: скоро в C# завезут file-local types:
https://github.com/dotnet/csharplang/issues/6011
Ну-ну. А без физических нагрузок будет дряблое тело и skinny fat.