Ну собственно из последнего по transforming autoencoding: arxiv.org/abs/1505.01596
Хоть и построено на нелюбимых Хинтоном disastrous CNN, но результат все равно впечатляет.
Смею предположить, что сеть натренированная таким способом на приличном количестве материала сумела бы отличить диван. Хоть это и чистая спекуляция с моей стороны. =)
Динамическая типизация ведет к лишнему cache miss при доступе к данным. Не то, чтобы это сильно пугало для имплементации логики (cache miss виртуальной таблицы нас ведь не смущает), но при работе с гигабайтами данными может вполне ощутимое количество циклов съесть, потому как каждый мисс может стоить очень дорого.
Потратив достаточно большое количество времени на борьбу с фрагментацией в процессе работы в игровой индустрии, я бы порекомендовал вместо этого решения просто использовать TBB scalable allocator (https://www.threadingbuildingblocks.org/docs/help/tbb_userguide/Memory_Allocation.htm#tutorial_Memory_Allocation).
Эффективно борется с фрагментацией, масштабируется (100 потоков, постоянно выделяющие память, поставят msvcr120.dll:malloc на колени из-за мьютекса). При этом не нужно ничего менять в своем коде. =)
Для дебага я порекоммендовал бы остаться на дефолтном аллокаторе (диагностика leaks and overrun), прибегая к помощи Александреску и его small object allocator в особо запущеных случаях, когда хочется скорости даже в дебаге.
Это называется латентное семантическое пространство. А вектора, которые описывают слова в этом многомерном пространстве, называются в литературе word embeddings и имеют такие вот свойства, где близкие по семантике слова находятся рядом. У нас, конечно, все несколько сложнее — само семантическое пространство объединяет сразу все поддерживаемые языки («кот» и «cat» в нем находятся рядом), а языковые модели умеют отвечать на запрос о вероятности нахождения конкретного слова на конкретной позиции в конкретном предложении, что дает возможность строить иерархии отношений слов. Но в базе современных подходов к NLP лежат именно эти word embeddings.
Да, структура голоса достаточно хорошо отделяется от музыки. Но для хорошего результата, мне кажется нужно было бы сделать иначе — натренировать приличных размеров RNN на удаление голоса из музыки, вместо выделения голоса из музыки. Хотя тренировать пришлось бы несколько дольше, да и материал подсобрать было бы еще той задачей, если конечно нет друзей в приличной звукозаписывающей компании, которые могу дать плюс и минус отдельно.
Да, код местами жестко экспериментальный. Поддерживать два codebase, для CPU и GPU, тяжеловато, плюс мы активно используем MKL, поэтому выигрышь от GPU не такой гигантский. Решили пока, что второго codebase он не стоит.
В сети ~2.5М коеффициентов, соответственно ~5М операций (умножение + сложение) на каждый фрейм. С текущим окном это чуть больше 300М операций на секунду материала.
Нет, все автоматически произойдет, как только мы починим. Мы, к сожалению, замерджили на продакшин сервер неработающий код, на который запитан весь другой работающий код. Бывает… =(
У нас наблюдаются технические проблемы с нашим внутрисервисным RPC. Приношу извинения за недоступность сервиса — мы максимально быстро постараемся все починить.
https://github.com/tridemax/CART
Интересно было бы сравнить эффективность. =)
Там в разделе 5.5 трансформируют тестовые картинки.
Хоть и построено на нелюбимых Хинтоном
disastrousCNN, но результат все равно впечатляет.Смею предположить, что сеть натренированная таким способом на приличном количестве материала сумела бы отличить диван. Хоть это и чистая спекуляция с моей стороны. =)
Эффективно борется с фрагментацией, масштабируется (100 потоков, постоянно выделяющие память, поставят msvcr120.dll:malloc на колени из-за мьютекса). При этом не нужно ничего менять в своем коде. =)
Для дебага я порекоммендовал бы остаться на дефолтном аллокаторе (диагностика leaks and overrun), прибегая к помощи Александреску и его small object allocator в особо запущеных случаях, когда хочется скорости даже в дебаге.