Есть подозрение что репозиторий выдирали из основной кодовой базы и не тестировали.
Отсутствует requirements.txt на который есть отсылки в Readme
Скрипт test.py без бубнов не запускается, т.к. в tools/inference.py есть невалидный импорт (from .stylematte import StyleMatte - при этом модуль stylematte отсутствует)
При смене чекпоинта с best_ffhqh512.pth на iharmony512.pth валятся ошибки про несовпадение размеров:
size mismatch for encoder.1.0.weight: copying a param with shape torch.Size([32, 16, 3, 3]) from checkpoint, the shape in current model is torch.Size([64, 16, 3, 3]).
size mismatch for encoder.1.0.bias: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([64]).
...
Написал бы об этом всем в issues, но вы их прикрыли.
Например собственный публичный датасет для маттирования на пару тысяч уникальный масок. Или какое-то новшество в архитектуре (да чтобы еще и на Comp1K соту выбить).
А то GuidedFilter так-то уже давно известная и точно не самая крутая в плане качества штука для апсемплинга.
А не подскажите ли как произвести вывод функции ошибки если хочется считать дисперсию в задаче классификации по аналогии с формулой (20) из предыдущей части? (ну или хотя бы где об этом почитать)
Из интересных наработок пожалуй только наш аналог IncludeComponent. С одной стороны можно было бы... С другой выкладывать без документации и тестов не хочется, а сил на них пока не хватает.
Вы упускаете, что несмотря на простоту дебага "динамического графа", статический при этом все же быстрее (параллельность выполнения неблокирующих друг друга веток).
Статический граф можно оптимизировать https://www.tensorflow.org/guide/graph_optimization // Например, сюда относится оптимизация NHWC -> NCHW при тренировке на GPU ибо так быстрее считается. В Pytorch такое порядок каналов идет по умолчанию, а TF приходится думать "конвертировать или нет" / "будет быстрее считаться или нет"
TF v2 не отказался от статического графа. В этом и прикол, что когда нужно подебажить можно скомпилировать модель с run_eagerly=True, а когда нужна производительность с False
Не являюсь большим знатоком в PyTorch, но кажется он подает данные в модель подготавливая их в многопроцессном режиме. Для адекватного сравнения я бы ожидал увидеть подачу в TF данных через tf.data.Dataset с prefetch-ем который использует плюсовый бекенд и многопоточность и с с генерацией ранодомных данных через tf.random.* а не конвертацией из numpy. Ну и как бы желательно делать model.train с указанием количества эпох, а не train_on_batch
Также для полноты картины хотелось бы чтобы при тестировании в TF был включен XLA (по ощущениям ускоряет тренировку больших моделей процентов на 10-15, в частности заменяет BatchNorm на fused-реализацию) и замерялись 2-я и последующие эпохи (на 1й TF делает оптимизации), а сами эпохи длились хотя бы минут по 5.
>>Кажется, не существует датасетов с эталонной разметкой с текстами из соцсетей
Хотя бы на подкорпусе тайги, который выложен в Universal Dependencies
>>Понятно, что будет плохо. «Правила в Razdel оптимизированы для аккуратно написанных текстов с правильной пунктуацией»
Разумеется понятно. Но было бы здорово понимать что считать вариантом «б».
Современные Ryzen (конкретно 3900x) рвут по всем тестам старые Threadripper-ы (1920x). Материнки b450 стоят значительно дешевле.
А продать в будущем десктопный комплект будет сильно проще.
Да, 2- а не 4-канальная память.
Если суммарное количество видеокарт 1-2-3, то других «за» в сторону Threadripper-а нет.
SSD в вашей сборке ИМХО дороговат (маркетинг). Самый дешевый того же объема будет не сильно уступать.
Думаю неточность идет от функции ошибки.
Конкретно вот в этом примере на TF www.tensorflow.org/tutorials/representation/word2vec создаются 2 embedding-матрицы: одна непосредственно для слов (то что потом будем использовать на инференсе), вторая — для Noise Contrastive Loss (ее для инференса не используем).
Есть еще 1 прикол w2v, который мало кто видит.
В оригинальной статье в CBOW используется сложение контекстных векторов. А по факту через месяц после публикации кто-то додумался использовать среднее. Спросили у Миколова — он подтвердил, что доли процента добавляет.
И в результате в gensim используется mean.
У Вас упал процент ошибок «не загружен счетчик».
Есть подозрение что даже с загруженным локально счетчиком не получится отправить данные в метрику (например, злой adblock+++ блокирует ip-адрес). Было бы интересно проверить.
Есть подозрение что репозиторий выдирали из основной кодовой базы и не тестировали.
Отсутствует requirements.txt на который есть отсылки в Readme
Скрипт test.py без бубнов не запускается, т.к. в tools/inference.py есть невалидный импорт (from .stylematte import StyleMatte - при этом модуль stylematte отсутствует)
При смене чекпоинта с best_ffhqh512.pth на iharmony512.pth валятся ошибки про несовпадение размеров:
Написал бы об этом всем в issues, но вы их прикрыли.
Вы пишите про ESB как про конкретный продукт, хотя это целый класс систем. Расскажете какую конкретно Вы внедрили?
Эх, хотелось бы что-то крутое увидеть...
Например собственный публичный датасет для маттирования на пару тысяч уникальный масок. Или какое-то новшество в архитектуре (да чтобы еще и на Comp1K соту выбить).
А то GuidedFilter так-то уже давно известная и точно не самая крутая в плане качества штука для апсемплинга.
А не подскажите ли как произвести вывод функции ошибки если хочется считать дисперсию в задаче классификации по аналогии с формулой (20) из предыдущей части? (ну или хотя бы где об этом почитать)
Из интересных наработок пожалуй только наш аналог IncludeComponent. С одной стороны можно было бы... С другой выкладывать без документации и тестов не хочется, а сил на них пока не хватает.
???
Второй как раз про него
Поправил, спасибо
Было бы здорово если бы при тестировании на реальных задачах вы осветили:
а) Как эти алгоритмы ведут себя с LSTM (например в языковых моделях)
б) Как эти алгоритмы ведут себя с большими батчами (2K ... 65K) - есть ли профит от LAMB-подобных оптимизаторов
Такие типы задач в бенчмарках делают крайне редко, к сожалению.
Позволю высказать критику вашего теста.
Вы упускаете, что несмотря на простоту дебага "динамического графа", статический при этом все же быстрее (параллельность выполнения неблокирующих друг друга веток).
Статический граф можно оптимизировать https://www.tensorflow.org/guide/graph_optimization // Например, сюда относится оптимизация NHWC -> NCHW при тренировке на GPU ибо так быстрее считается. В Pytorch такое порядок каналов идет по умолчанию, а TF приходится думать "конвертировать или нет" / "будет быстрее считаться или нет"
TF v2 не отказался от статического графа. В этом и прикол, что когда нужно подебажить можно скомпилировать модель с run_eagerly=True, а когда нужна производительность с False
Не являюсь большим знатоком в PyTorch, но кажется он подает данные в модель подготавливая их в многопроцессном режиме. Для адекватного сравнения я бы ожидал увидеть подачу в TF данных через tf.data.Dataset с prefetch-ем который использует плюсовый бекенд и многопоточность и с с генерацией ранодомных данных через tf.random.* а не конвертацией из numpy. Ну и как бы желательно делать model.train с указанием количества эпох, а не train_on_batch
Также для полноты картины хотелось бы чтобы при тестировании в TF был включен XLA (по ощущениям ускоряет тренировку больших моделей процентов на 10-15, в частности заменяет BatchNorm на fused-реализацию) и замерялись 2-я и последующие эпохи (на 1й TF делает оптимизации), а сами эпохи длились хотя бы минут по 5.
Хотя бы на подкорпусе тайги, который выложен в Universal Dependencies
>>Понятно, что будет плохо. «Правила в Razdel оптимизированы для аккуратно написанных текстов с правильной пунктуацией»
Разумеется понятно. Но было бы здорово понимать что считать вариантом «б».
А продать в будущем десктопный комплект будет сильно проще.
Да, 2- а не 4-канальная память.
Если суммарное количество видеокарт 1-2-3, то других «за» в сторону Threadripper-а нет.
SSD в вашей сборке ИМХО дороговат (маркетинг). Самый дешевый того же объема будет не сильно уступать.
Конкретно вот в этом примере на TF www.tensorflow.org/tutorials/representation/word2vec создаются 2 embedding-матрицы: одна непосредственно для слов (то что потом будем использовать на инференсе), вторая — для Noise Contrastive Loss (ее для инференса не используем).
Есть еще 1 прикол w2v, который мало кто видит.
В оригинальной статье в CBOW используется сложение контекстных векторов. А по факту через месяц после публикации кто-то додумался использовать среднее. Спросили у Миколова — он подтвердил, что доли процента добавляет.
И в результате в gensim используется mean.
Озвучьте пожалуйста, что за книги (у Чалдини читал только «Психология влияния»)
Есть подозрение что даже с загруженным локально счетчиком не получится отправить данные в метрику (например, злой adblock+++ блокирует ip-адрес). Было бы интересно проверить.
Расскажите как, если не сложно.