Я стабильно 5-10 раз в год прохожу собесы, хотя и чувствую себя комфортно на своем месте работы. ТУПО ДЛЯ ТОГО, ЧТОБЫ ПОНИМАТЬ, ЧТО Я МОГУ ИХ ПРОЙТИ. И каждый раз замечаю, как отличается подготовка от реальных рабочих задач.
Да, конечно, давайте повернем матрицу и развернём строку, вчера это делал через rotate/revert. А всмысле это вам не подходит, если вы тут же в резюме просите знание numpy/LINQ?
Вы хотите System Design Твиттера - да давайте, тут только часа 2 надо для поверхностного разбора. А всмысле мы сейчас будем считать, сколько бит в теле запроса на список пользователей? Я бы просто привлёк техлида, чтобы такие вещи вместе посчитать - никто не делает System Design в соло. Сами же говорите про навыки делегирования в Резюме.
Нет, окей, я всё это подучу, стану супер-разработчиком/лидом в вакууме. Только ведь оно так противоречит и вашему резюме, и практике. Или вы переживаете, что все с проекта сбегут и останусь я один? Ну тогда я к вам не очень хочу.
При этом, отмечу, что собесы я прохожу и офферы получаю в 10-30% случаев - это реально. И не так страшен этот ваш LeetCode (немного лицемерю - сложные задачи правда страшно, но на реальных собесах их не встречал). Мне противно от послевкусия, что все проводят собесы так, как проводят конкуренты/рынок, а не так, как это было бы полезно и эффективно.
В своей команде на собесе 2 части - первая на Soft (соответствие культуре компании, коммуникации и тд), вторая на Hard(просто тестовое и потом 30 минут посмотреть, как человек умеет думать. Без задачек с LeetCode и тд). Вроде работает, на текучку не жалуемся.
Но в целом, хочу сказать, что собеседующих можно понять - всё это сложный процесс и не всегда понимаешь, а что мы делаем не так
6 лет назад был такой PlaidML - а-ля бэкенд для TF, позволяющий работать на GPU AMD. Он был поприветливее ROCm и прочих. Писал тогда статью про него - https://habr.com/ru/articles/420989/. Запускалось оно с пол-оборота, но производительность была раза в 2 ниже, чем на сравнимых по цене GPU от Nvidia. Не рассматривали его, оно сейчас живое? На гитхабе глянул их проект - вроде обновлялись год назад.
Отличные примеры с приложением к практике, спасибо! Очень напомнило книгу Непряхина "Я манипулирую тобой". Если еще не читали - попробуйте, вам точно понравится. Единственное, чего не хватило - разбора разных вариантов ухода от манипуляций. Есть несколько вариантов выхода - вскрытие, слом сценария, встречная манипуляция и тд. Они немного разный эффект имеют и к разным ситуациям применимы. Есть очень клёвые выходы через сломанный сценарий - очень люблю читать вариации на эту тему
Спасибо за статью! Со многим согласен, но по ощущению статья вышла однобокой - не хватает моментов про индивидуальность людей (психотипы, если угодно). Для одних людей нормально заглушать эмоции и переходить в рациональное русло, для других - это лишь ведёт к накоплению и последующему взрыву. Т.е. нельзя использовать общий подход к управлению эмоциями, закрывая глаза на индивидуальные особенности.
За референс могу привести "Как пасти котов" Рейнвотера, где открыто говорится, что индивидуальность очень важна и разным людям подходят разные методики
Рекомендую первые главы книги Константинова "Стратегическое Мышление", там наиболее понятный для меня набор видов мышления. С представленной здесь классификацией не совсем согласен (и не понял, на какой литературе она построена? Питер Сенге?). Процессное мышление - что-то вообще новое для меня.
Ощущение, что всё смешалось - кони, люди. Одни виды мышления судя по статье становятся навыками другого - странно для меня. Нужно определять, по какому признаку мы производим классификацию видов мышления. Это уже не к вашему комментарию, а к статье в целом
Статья для новичков, наверное, полезная. Но есть одна важная ошибка, которой не стоит их учить - pip install keras и дальше импорт из него. keras сейчас полностью мигрировал внутрь tf и правильно вызывать tf.keras и импорты слоёв делать тоже оттуда
Большое спасибо за статью, очень люблю эту тематику. Иногда полезно почитать такие общие статьи для повторения и актуализации информации в голове. Дополню насчет float32 -> float16. К сожалению, на практике после такой конвертации теряется довольно важная часть точности. Она может слабо выражаться в метриках, но иногда после такого сети непригодны для моментальной отправки в прод. Не рекламируюсь ни в коем случае, но вот в своей статье описывал, к чему это иногда ведет -https://habr.com/ru/post/558406/. Желательно даже при таком квантовании использовать Quantization Aware Training, который, благо, реализуется в 1 строчку в TF или PyTorch. Ну и насчет скорости работы - смотря что считать большим ускорением. У нас получилось около 2х к скорости обработки. Учитывая относительную простоту float32 -> float16 получается очень высокий КПД. А вот при квантовании float32 -> int8 нужно потратить довольно много усилий, чтобы это заработало с достаточной точностью. Знаю, что такое часто делают для мобилок в различных GANах и дифьюзерах, т.к. визуальный результат клиента удовлетворяет. А вот если стоит задача детекции, классификации и тд, где наша метрика точности более осязаема - возникают большие проблемы. Ну и тут сложнее с Quantization Aware Training - методики вроде как есть, но это уже не одна строчка и часто ломаются оптимизаторы. Если вы знакомы с хорошими методиками Quantization Aware Training для int8, то поделитесь. Я уже полгода не смотрел новых работ по этой теме
И насчет Pruning - там тоже есть 2 варианта: Post Training и During Training. Первый вариант на моей практике был не очень полезным, без потери точности получалось вырезать лишь малую часть. А вот второй вариант пока руки не дошли попробовать. Подскажите, может был опыт? Очень интересны практические результаты
Попробуйте добавить center_loss - он без перевода в сферические координаты. Должно дать значимый буст в точности работы. Всё таки метрик лернинг на чистом CE не совсем ту задачу решает. Линейное разделение не гарантирует скученность векторов
Мы решили экспериментировать дальше. Вытащили из обученной сети результирующие векторы по всем нашим изображениям, затем искали ближайшие векторы к картинке-запросу.
Правильно ли я понимаю, что вы взяли вектора с предпоследнего слоя классифицирующей сети? Использовали какие-то доп лоссы - sphere-loss или cosine-loss для компактного сбора векторов в гиперпространстве?
А вы везунчик! Я ни разу не получал в простом Colab что-то из T4/P100. Так или иначе, для Pro выделение мощных GPU в приоритете и происходит чаще(о чем написано в официальной документации). В любом случае, несколько коробит такая ситуация, когда скорость обучения твоей сети зависит от воли случая. А про 4vCPU не знал, спасибо за замечание!
Круто, что у тебя есть такой опыт. Думаю, радужность, моего отзыва следуют как раз из недостаточно сложной задачи и окружения. Единственной проблемой для меня стал неподдерживаемый SEPARABLECONV2D, который потратил сравнимо меньше моих нервов. Значит, есть причина ещё раз задуматься о применимости DataSphere для больших проектов
Про формат входных данных хорошее замечание, тоже наблюдали. Насчёт запуска Yolov3 - не знаю, в чем проблема. Мы на этой же версии Trt и yolov3 конвертится без проблем. Опять же, только если проблема в слое Upsample.
Спасибо за вопрос.
TensorRT для float16 inference использует Tensor cores. Да, тут важно говорить как ускорение для 1 потока в 2 раза за счет float16 вычислений, так и про увеличение пропускной способности памяти с особенностями вычислений в tensor cores.
Наш опыт такой — при работе в 1 потоке мы получаем ускорение 2х. Однако, если говорить про многопоточную обработку, то ситуация интереснее. Во float32 на TF мы можем обрабатывать параллельно 2.5 потока видео 30 fps. При переходе на float16 в TensorRT производительность вырастает до 8 потоков 30 fps. Т.е. фактически при полной утилизации tensor cores мы получили увеличение производительности в 3.2 раза — несколько меньше теоретически максимальной. Скорее всего, это связано с тем, что мы обрабатываем потоки с батчем = 1, чтобы не увеличивать latency прихода данных по каждому кадр.
Чекнул. Да, интересное решение, как-то упустил его из виду. Спасибо)
Задача — детектирование автомобилей в одной плоскости. За счёт отсутствия перекрытий и одного масштаба задача сильно упрощается и получается высокий mAp75
Я стабильно 5-10 раз в год прохожу собесы, хотя и чувствую себя комфортно на своем месте работы. ТУПО ДЛЯ ТОГО, ЧТОБЫ ПОНИМАТЬ, ЧТО Я МОГУ ИХ ПРОЙТИ. И каждый раз замечаю, как отличается подготовка от реальных рабочих задач.
Да, конечно, давайте повернем матрицу и развернём строку, вчера это делал через rotate/revert. А всмысле это вам не подходит, если вы тут же в резюме просите знание numpy/LINQ?
Вы хотите System Design Твиттера - да давайте, тут только часа 2 надо для поверхностного разбора. А всмысле мы сейчас будем считать, сколько бит в теле запроса на список пользователей? Я бы просто привлёк техлида, чтобы такие вещи вместе посчитать - никто не делает System Design в соло. Сами же говорите про навыки делегирования в Резюме.
Нет, окей, я всё это подучу, стану супер-разработчиком/лидом в вакууме. Только ведь оно так противоречит и вашему резюме, и практике. Или вы переживаете, что все с проекта сбегут и останусь я один? Ну тогда я к вам не очень хочу.
При этом, отмечу, что собесы я прохожу и офферы получаю в 10-30% случаев - это реально. И не так страшен этот ваш LeetCode (немного лицемерю - сложные задачи правда страшно, но на реальных собесах их не встречал). Мне противно от послевкусия, что все проводят собесы так, как проводят конкуренты/рынок, а не так, как это было бы полезно и эффективно.
В своей команде на собесе 2 части - первая на Soft (соответствие культуре компании, коммуникации и тд), вторая на Hard(просто тестовое и потом 30 минут посмотреть, как человек умеет думать. Без задачек с LeetCode и тд). Вроде работает, на текучку не жалуемся.
Но в целом, хочу сказать, что собеседующих можно понять - всё это сложный процесс и не всегда понимаешь, а что мы делаем не так
6 лет назад был такой PlaidML - а-ля бэкенд для TF, позволяющий работать на GPU AMD. Он был поприветливее ROCm и прочих. Писал тогда статью про него - https://habr.com/ru/articles/420989/.
Запускалось оно с пол-оборота, но производительность была раза в 2 ниже, чем на сравнимых по цене GPU от Nvidia. Не рассматривали его, оно сейчас живое? На гитхабе глянул их проект - вроде обновлялись год назад.
А почему не CLIP/DINO/Yolo-world? Для задачи "Определить всё" явно лучше. Ну и как бы получается one-stage. И учить не нужно - берем из коробки.
Отличные примеры с приложением к практике, спасибо! Очень напомнило книгу Непряхина "Я манипулирую тобой". Если еще не читали - попробуйте, вам точно понравится. Единственное, чего не хватило - разбора разных вариантов ухода от манипуляций. Есть несколько вариантов выхода - вскрытие, слом сценария, встречная манипуляция и тд. Они немного разный эффект имеют и к разным ситуациям применимы. Есть очень клёвые выходы через сломанный сценарий - очень люблю читать вариации на эту тему
Спасибо за статью! Со многим согласен, но по ощущению статья вышла однобокой - не хватает моментов про индивидуальность людей (психотипы, если угодно). Для одних людей нормально заглушать эмоции и переходить в рациональное русло, для других - это лишь ведёт к накоплению и последующему взрыву.
Т.е. нельзя использовать общий подход к управлению эмоциями, закрывая глаза на индивидуальные особенности.
За референс могу привести "Как пасти котов" Рейнвотера, где открыто говорится, что индивидуальность очень важна и разным людям подходят разные методики
Рекомендую первые главы книги Константинова "Стратегическое Мышление", там наиболее понятный для меня набор видов мышления. С представленной здесь классификацией не совсем согласен (и не понял, на какой литературе она построена? Питер Сенге?). Процессное мышление - что-то вообще новое для меня.
Ощущение, что всё смешалось - кони, люди. Одни виды мышления судя по статье становятся навыками другого - странно для меня. Нужно определять, по какому признаку мы производим классификацию видов мышления. Это уже не к вашему комментарию, а к статье в целом
Статья для новичков, наверное, полезная. Но есть одна важная ошибка, которой не стоит их учить - pip install keras и дальше импорт из него. keras сейчас полностью мигрировал внутрь tf и правильно вызывать tf.keras и импорты слоёв делать тоже оттуда
Большое спасибо за статью, очень люблю эту тематику. Иногда полезно почитать такие общие статьи для повторения и актуализации информации в голове.
Дополню насчет float32 -> float16. К сожалению, на практике после такой конвертации теряется довольно важная часть точности. Она может слабо выражаться в метриках, но иногда после такого сети непригодны для моментальной отправки в прод. Не рекламируюсь ни в коем случае, но вот в своей статье описывал, к чему это иногда ведет -https://habr.com/ru/post/558406/. Желательно даже при таком квантовании использовать Quantization Aware Training, который, благо, реализуется в 1 строчку в TF или PyTorch.
Ну и насчет скорости работы - смотря что считать большим ускорением. У нас получилось около 2х к скорости обработки. Учитывая относительную простоту float32 -> float16 получается очень высокий КПД.
А вот при квантовании float32 -> int8 нужно потратить довольно много усилий, чтобы это заработало с достаточной точностью. Знаю, что такое часто делают для мобилок в различных GANах и дифьюзерах, т.к. визуальный результат клиента удовлетворяет. А вот если стоит задача детекции, классификации и тд, где наша метрика точности более осязаема - возникают большие проблемы. Ну и тут сложнее с Quantization Aware Training - методики вроде как есть, но это уже не одна строчка и часто ломаются оптимизаторы. Если вы знакомы с хорошими методиками Quantization Aware Training для int8, то поделитесь. Я уже полгода не смотрел новых работ по этой теме
И насчет Pruning - там тоже есть 2 варианта: Post Training и During Training. Первый вариант на моей практике был не очень полезным, без потери точности получалось вырезать лишь малую часть. А вот второй вариант пока руки не дошли попробовать. Подскажите, может был опыт? Очень интересны практические результаты
Намного интереснее, как вы решайте задачу в крайних случаях - например в забитых автобусах?
Не пробовали вместо YOLOv5+CRAFT использовать одну WPOD-NET? Будет значительно быстрее и сразу отнормировано
Попробуйте добавить center_loss - он без перевода в сферические координаты. Должно дать значимый буст в точности работы. Всё таки метрик лернинг на чистом CE не совсем ту задачу решает. Линейное разделение не гарантирует скученность векторов
Правильно ли я понимаю, что вы взяли вектора с предпоследнего слоя классифицирующей сети? Использовали какие-то доп лоссы - sphere-loss или cosine-loss для компактного сбора векторов в гиперпространстве?
А вы везунчик! Я ни разу не получал в простом Colab что-то из T4/P100. Так или иначе, для Pro выделение мощных GPU в приоритете и происходит чаще(о чем написано в официальной документации). В любом случае, несколько коробит такая ситуация, когда скорость обучения твоей сети зависит от воли случая. А про 4vCPU не знал, спасибо за замечание!
Круто, что у тебя есть такой опыт. Думаю, радужность, моего отзыва следуют как раз из недостаточно сложной задачи и окружения. Единственной проблемой для меня стал неподдерживаемый SEPARABLECONV2D, который потратил сравнимо меньше моих нервов. Значит, есть причина ещё раз задуматься о применимости DataSphere для больших проектов
Про формат входных данных хорошее замечание, тоже наблюдали. Насчёт запуска Yolov3 - не знаю, в чем проблема. Мы на этой же версии Trt и yolov3 конвертится без проблем. Опять же, только если проблема в слое Upsample.
TensorRT для float16 inference использует Tensor cores. Да, тут важно говорить как ускорение для 1 потока в 2 раза за счет float16 вычислений, так и про увеличение пропускной способности памяти с особенностями вычислений в tensor cores.
Наш опыт такой — при работе в 1 потоке мы получаем ускорение 2х. Однако, если говорить про многопоточную обработку, то ситуация интереснее. Во float32 на TF мы можем обрабатывать параллельно 2.5 потока видео 30 fps. При переходе на float16 в TensorRT производительность вырастает до 8 потоков 30 fps. Т.е. фактически при полной утилизации tensor cores мы получили увеличение производительности в 3.2 раза — несколько меньше теоретически максимальной. Скорее всего, это связано с тем, что мы обрабатываем потоки с батчем = 1, чтобы не увеличивать latency прихода данных по каждому кадр.
Чекнул. Да, интересное решение, как-то упустил его из виду. Спасибо)
Задача — детектирование автомобилей в одной плоскости. За счёт отсутствия перекрытий и одного масштаба задача сильно упрощается и получается высокий mAp75
Здесь YOLOv3 описан как хороший вариант для бейзлайна по доступности и простоте)