Если вам интересно, что недавний закрытый и продвинутый курс глубокого обучения fast.ai сказал о проекте Google Swift для Tensorflow, этот пост может показаться вам интересным. Даже если вы посещали курс, вы, надеюсь, найдете здесь хороший обзор (со ссылками на курс, презентации и дополнительные материалы), что такое Swift для Tensorflow и почему он может быть актуальным.

Забудьте обо мне и философии и лучше взгляните на их официальные объявления Джереми Ховарда и Криса Леттнера (стремительный парень, а не переоцененный баскетболист).

Возможно, вы захотите начать с почему Google будет поддерживать swift для тензорного потока и почему fast.ai (вкратце, речь идет о производительности ускорителя, безопасности языковых типов и автозавершении кода, отслеживаемости всех уровней, развертывании кода исследовательского прототипа в рабочей среде) обнимет быстрых . Swift для тензорного потока должен позволять использовать все время, то есть вы изучаете (Swift - это просто, а записные книжки - проще!), Изучаете и кодируете, а затем отправляете в производство.

Теперь, что я могу дать вам в качестве прогулки по аргументам в классе + еще несколько ссылок.

Я привожу вам только один раздел, из моих собственных мыслей, почему я считаю этот проект интересным. Перейдите к следующему заголовку, если хотите углубиться в мысли о fast.ai и Google.

Изучение языков и создание искусственных языков на самом деле имеет давние традиции в философии и теории познания по уважительным причинам: мы хотим раздвинуть границы наших знаний и языков, также языки программирования являются важным фактором. Вы можете найти длинный список загадочных замечаний (например, Людвиг Витгенштейн: «Пределы моего языка означают пределы моего мира») о связи между языком и знаниями.

Конечно, они относятся к естественным или математическим языкам, появившимся в то время, но почему это должно быть иначе для языка программирования? Я думаю, что это не так, и варианты использования глубокого обучения, например Распознавание рака на компьютерной томографии или переваривание текста делают это более очевидным, чем раньше. Мы пытаемся раздвинуть границы наших знаний и языков программирования, чтобы дать нам возможность через облако использовать эти огромные ЦП, ЦП и TPU с такими языками программирования, чтобы делать именно это.

Представьте, что нам удастся собрать большие объемы экономически значимых данных, а затем мы попытаемся спрогнозировать экономические циклы. Может быть, мы сможем предсказать следующий финансовый кризис, может быть, мы получим «теорию», которая сделает безработицу понятной. Совершенно другая теория, нежели эти математически замаскированные экономические идеологии, использованные на политической арене. Представьте, что у нас есть какие-то большие нейронные сети со свёртками, повторениями и прочим ... и эта штука способна предсказывать вещи, которые мы пока не могли. Возможно, эту теорию трудно понять: в ней нет таких человеческих концепций, как труд, капитал, закон, классы и так далее. Скорее слоями и весами. Но это не невозможно понять - и если он предсказывает лучше, почему бы нам не использовать его и не попытаться понять это. В любом случае, почему мы должны ожидать, что что-то столь сложное, как экономика, будет человечески понятным с помощью простых концепций, красивых математических графиков и так далее. Что-то столь же беспорядочное и потенциально нюансированное, как нейронная сеть и большие объемы беспорядочных данных, могли бы быть намного лучше для прогнозирования такого уровня сложности. Это уже происходит, CNN лучше людей предсказывают, например рак легких по результатам сканирования легких.

Я мог бы придумать множество научно-фантастических примеров использования невероятных релевантных явлений - будь то изменение климата, болезни и так далее. В конце концов, придумывание новых языков - это действительно расширение границ того, что люди могут понять! Это очень старая тема для философов, и наличие отличных компьютерных языков на самом деле всего лишь одна, очень важная ветвь этой старой темы. Языки имеют значение, они не являются чем-то эфемерным, занудным (они тоже есть!) - так что продолжайте читать, потому что swift для тензорного потока - это улучшение и изобретение новой языковой парадигмы для языков программирования, которая позволит нам использовать эти кремниевые мозги. .

Приквел

Этот продвинутый класс предназначен для восстановления фреймворка fast.ai pytorch с нуля. Следовательно, многие из вас также узнают о программной инженерии, такой как обратные вызовы. В этом классе много драгоценных камней - проверьте уроки 1–5 - мы сосредоточимся на уроках 6 и 7, посвященных быстрому.

Взгляните на записные книжки, и, кстати, даже если вы проверите уроки 1–5, вы можете проверить записные книжки на Python в быстрой версии. Сосредоточьтесь на автоматическом различении здесь и здесь, чтобы понять эти записные книжки. Возможно, вы захотите взглянуть на предыдущие числа, начинающиеся с 00… и 01… и т. Д. по внедрению matmul / dot product с помощью swift. А до этого, вероятно, если вы новичок в быстром обучении, как я, освежите свои знания в быстром темпе. Это весело, это просто: держу пари, если вы знаете python, этот код (слайд из fast.ai, часть 2) будет выглядеть настолько знакомым, что вы можете просто начать.

Может быть, вы все еще воспользуетесь простым быстрым учебником, таким как этот тур, или, скорее, возьмите учебное пособие из записной книжки, например, от swift for tensorflow team или fast.ai.

Ноутбуки Python являются стандартом, даже если вы исключите Python из уравнения. Использование google co-lab у меня сработало. Вначале возникали некоторые проблемы с обеспечением стабильной работы быстрого ядра, но все быстро улучшилось, когда над этим работала команда Google. Вероятно, когда вы прочтете это в будущем, совместная лаборатория для Swift будет довольно стабильной. Также обратите внимание, огромное преимущество использования быстрых ноутбуков заключается в том, что эти afaik будут обновлены, по крайней мере, некоторыми версиями s4tf. Вам также стоит заглянуть на форум fast.ai, в категорию harebrain и репозиторий. Harebrain - это открытая часть форума fast.ai, где сотрудничают команды google и fast.ai. Насколько я понимаю, fast.ai захочет переписать свой фреймворк на основе swift (не отказываясь от python и pytorch), общий вопрос, на который они пытаются ответить во время совместной работы, заключается в следующем:

Что, если бы высокоуровневый дизайн API мог повлиять на создание дифференцируемого языка программирования?

Вот и все. Что можно дифференцировать? Эта дифференцируемость, встроенная прямо в swift, является ключевым отличием от того, что вы получаете, например в питоне. Итак, если это ключевая теоретическая концепция, может быть полезно знать, что этот термин вообще означает. Оказывается, термин придуман Янном Ле Канном (один из действительно умных), так что лучше читать это! Ага, что ж - после этого - это ребрендинг Deep Learning. Нет проблем, просто пройдите всю 1-ю часть здесь и вы знаете, что это такое ;-)

Но прежде чем вы сами погрузитесь в записные книжки, просмотрите видео и воспользуйтесь моим руководством.

# switch2swift: почему?

Так хорошо. Может быть, отказаться от python - но почему быстро? Почему бы, например, не Юлия?

Достаточно интересно, что fast.ai, по-видимому, также проверял julia [ВСТАВИТЬ ССЫЛКУ: держу пари, я слышал, что Джереми упоминал об этом в каком-то классе, но не смог найти его обратно] в качестве альтернативы swift4tensorflow. Одна из причин, по которой следует использовать Swift, - это, безусловно, то, что Google будет настаивать на этом, хотя кажется, что есть много других причин, некоторые из которых мы обсудим. Сказав это, похоже, нет причин не иметь версию fast.ai в Джулии и [ВСТАВИТЬ ССЫЛКУ: то же самое здесь, не удалось найти эту ссылку] Джереми даже упоминает об этом.

Для Google вы можете найти длинную ветку здесь, почему они выбрали быстрые варианты. Пока что я могу сказать, что "конечный пользователь" (разработчик) все с нетерпением жду этого, потому что swift кажется действительно интересным и простым в использовании. И насколько хорошо иметь типы и правильные ошибки компиляции при работе с языком вместо того, чтобы находить эти вещи во время выполнения.

Дни Python (в глубоком обучении) сочтены

Джереми готовит почву в самом начале курса, чтобы подготовить людей к тому, что что-то случится с python. Он делает это с помощью программирования matmul / dot product на python и демонстрирует, насколько это невероятно медленнее. Теперь Python решает эту проблему, возвращаясь, например, к Pytorch, который, в свою очередь, использует библиотеки C под капотом, что дает множество проблем (по сути, то, что решит swift!)

Я не буду описывать различные шаги, которые проходит Джереми (поэлементные операции, трансляция, суммирование Эйнштейна…), чтобы удалить python, за исключением того, как это делают pytorch или einsum. Проверить записную книжку можно здесь:

Итог немного грустный:

«Чтобы сделать Python быстрее, нужно удалить Python»

Затем, в уроке 12, последнем перед 2 уроками fast.ai swift, Джереми берет его и говорит: Python мертв (1-я строка, 2-й столбец)!

На самом деле он только говорит: «Дни Python сочтены».

Но подумайте, сколько фантастической работы было вложено в экосистему глубокого обучения Python и сколько студентов и профессионалов выучили этот язык!

Для меня это было похоже на Смерть Неда Старка в Игре престолов - очень трудно принять! А кто в нашем случае Джоффри Баратеон?

Как и следовало ожидать, в момент отчаяния на сцену выходит спаситель (в лице стремительного изобретателя Криса Леттнера).

В коротких вопросах и ответах мне особенно понравилась мысль о том, что swift может помочь преодолеть барьер между «нормальным» и «глубоким обучением / дифференцируемым» программированием, чтобы интегрировать ваши модели в обычные приложения. Как вы знаете, один из способов увидеть глубокое обучение - это другой способ программирования, где мы показываем компьютерные примеры и позволяем ему / ему «выяснить» что-то вроде «теории или гипотезы (например, сверточной сети), что, например, кошка такая, что она может классифицировать, представляет ли картина кошку или нет. «Нормальное» программирование - это управление потоком, такое как if-then или циклы. Итак, не странно ли смешивать «дифференцируемое программирование» (подробнее об этом ниже) в ядре языка?

Нет! Не более чем «странно» смешивать функциональное и объектно-ориентированное программирование - очевидно, в любом случае быстро, поскольку принцип дизайна просто берет все полезные шаблоны и разумно их смешивает. Не существует догматического «чистого» функционального или объектно-ориентированного стиля программирования, следовательно, нет проблем, связанных с дифференцированным программированием. На самом деле, наоборот, смешивать это хорошо, поскольку разработчики могут использовать все преимущества различных подходов в своих приложениях.

Как Джереми приходит к драматическому выводу, что питон мертв? Опыт, я бы сказал, с такими же попытками, как pytorch с JIT-компилятором. Контекст этого утверждения - это описание архитектуры RNN / LSTM (которая здесь не имеет большого значения) и, как часть этого, того, как pytorch использует Just in Time Compiler, чтобы преобразовать python в C ++, а затем скомпилировать его. Перевод языков друг в друга (я думаю, можно согласиться с этим) не изящен (вообще) и, вероятно, указывает на скорее не идеальный дизайн в вашем языковом стеке. Джереми перечисляет это как одну из проблем, с которыми вы когда-нибудь столкнетесь с python в своем сообщении в блоге https://www.fast.ai/2019/03/06/fastai-swift/.

В конце концов, все, что написано на Python, должно иметь дело с одним или несколькими из следующего:… преобразование в какой-то другой язык (например, PyTorch с использованием TorchScript или TensorFlow с использованием XLA), что означает, что вы на самом деле не пишете в конечном целевом языке и должны иметь дело с несоответствием между языком, который, по вашему мнению, вы пишете, и фактическим языком, который действительно используется (по крайней мере, с теми же проблемами отладки и профилирования, что и при использовании библиотеки C).

Таким образом, аргумент заключается не в том, что «текущая JIT-версия pytorch имеет некоторые ошибки», а скорее в том, что этот подход является симптомом некоторых более глубоких недостатков в дизайне языка для его использования с глубоким обучением.

В первом быстром уроке Джереми уточняет, почему «питон должен уйти»

Python хорош ... но:

  • Медленно: загружает данные во внешние библиотеки C - см. урок 8!
  • Параллелизм: GIL расширяет возможности внешних библиотек C
  • Ускорители: больше возможностей для CUDA и т. д.

Опять же, это не проблемы, которые можно решить в следующем выпуске какой-либо новой библиотеки. Эти проблемы коренятся в дизайне и развитии языка. На прилагаемых слайдах Python описывается как

Python:

  • Атомы: код C, реализующий методы объекта Python
  • Состав: медленный интерпретатор, который интересным образом объединяет вызовы C

Помните об этих «атомах» питона (можно сказать: это довольно большие «молекулы»), когда ниже мы перейдем к swift, который имеет гораздо меньшие «атомы».

Проблемы с загрузкой Pytorch и Tensorflow

«Итак, это питон. Ладно, ничего хорошего, но именно поэтому у нас есть такие фреймворки, как pytorch и tensorflow - так что у нас все хорошо! »

Нееет! это еще не годится! Проверь это. Вкратце:

Когда дело доходит до скорости (не говоря уже о том, что вы не можете отлаживать эти фреймворки, потому что они имеют эти большие, недоступные «C-молекулы»), проблема заключается в накладных расходах, когда вы загружаете свои матричные вычисления в графический процессор.

«PyTorch похож на самолет: вы должны приложить немало усилий, чтобы оправдать время, потраченное на поездку в аэропорт, прохождение контроля безопасности, взлет, посадку…»

У Google, написавшего тензорный поток, есть много данных: для них, загружая свои огромные вычисления на такой корабль (см. Рисунок ниже), чтобы начать процесс, это нормально, а для «нормальных» людей - нет. Другими словами, если у вас есть рабочие нагрузки типа Google, эта модель подойдет. Однако для многих из них эта модель неосуществима.

«TensorFlow был разработан на основе идеи создания графа вызовов, а затем внесения в него значений»

И недавняя эволюция тензорного потока в сторону стремления придать ему вид пирога тоже не мешает.

"Желание" - это в основном синтаксический сахар. Чтобы сделать его по-настоящему полезным, нужно еще многое сделать. По состоянию на апрель 2019 года небольшое матричное умножение на графическом процессоре с использованием tf eager занимает 0,28 мс, что в 10 раз дольше, чем в PyTorch. ‘

Ключевой вывод: как перенести эти вычисления на GPU? MLIR, новая инфраструктура машинного обучения Google (которая, по сути, еще не существует), которая строится для поддержки swift для tenorflow, предназначена для решения этой проблемы.

Это часть инфраструктуры, @differentiable, которую мы кратко представим, будет использовать ее. Этого еще нет, но он решает проблему, имеющуюся в текущих концепциях.

Даже если не было капитального ремонта инфраструктуры Google для tenorflow, Swift может предложить несколько приятных вещей.

Swift - крутая штука

Почему Swift, почему не какой-нибудь другой скомпилированный язык, если python этого не делает? Оказывается, дизайн Swift очень помогает с производительностью. И LLVM работает (в основном) только на процессорах, в то время как «будущее», то есть LLVM, перенесет это на графические процессоры.

Дизайн Swifts - это предварительное требование к производительности, которую он может достичь. Swift переводится в промежуточное представление LLVM, и уже этот перевод включает множество оптимизаций. Крис Леттнер говорит о "бесконечно взломанном языке", причем очевидно, что он имеет в виду a.o.t. тот, у кого есть доступ как разработчик к примитивам языка

Swift - это синтаксический сахар для LLVM!

  • Примитивные операции - это инструкции LLVM

Состав: структуры и классы:

  • String, Dictionary, а также Array, Int и Float - это структуры!

Обоснование: заставляет функции языка быть выразительными и мощными

  • Вы можете создавать такие же вещи, без преград

Это реальное отличие от Python, но также и от других языков, таких как C ++

  • Атомы: int, float, массивы C, указатели,…
  • Состав: Структуры и классы: std :: complex, std :: string, std :: vector,…

Фактически, вы можете быстро создать свой собственный тип данных Float.

Помните, что «атомы» Python в отношении глубокого обучения на самом деле являются кодом C. Очевидно, это мешает нам легко изменить этот слой или отладить его. Положительным моментом, конечно же, является производительность - но что, если бы мы могли использовать «бесконечно взламываемый стек swift llvm» и иметь квази-C-производительность?

По словам Джереми, в некоторых областях численного программирования мы уже можем достичь производительности уровня C с помощью Swift. Если вы хотите глубже погрузиться в Swift, особенно в отношении производительности, загляните в блог Джереми на тему Использование Swift для численных вычислений.

Интеграция с Python

Python используется десятилетиями, включает сложные библиотеки, такие как scikit или matplotlib. Так что безумие отказываться от этого - если только производительность не ужасна, и мы можем просто продолжать использовать библиотеки, которые нам нужны!

Итак, резюмируем: вы можете использовать python в своем быстром блокноте! Как такое возможно?

По сути, swift вызывает интерпретатор Python для выполнения импортированных библиотек Python, таких как numpy. Вопреки тому, что некоторые могут подумать, Python не лишен типов - у него есть только один тип: объект. Swift сопоставляет свои типы с этим, вы можете найти этот класс в быстром репозитории github.

Найдите пример блокнота здесь и пояснение здесь.

Вот и все: особо нечего сказать, но это, конечно, много! Может быть, небольшое зло «атаковать» питона, выбирая из него то, что полезно, пока Swift не перестроит все эти библиотеки и не оставит питон «мертвым» в пути. Если бы я был генеральным директором python, я бы немедленно ввел какой-нибудь быстрый блок, к счастью, мы находимся в мире с открытым исходным кодом!

C Интеграция

Думаю, нечего спорить в пользу интеграции с C! Лично я, откровенно говоря, не знал бы, какие библиотеки C мне следует использовать (и я думаю, что многие специалисты по данным тоже не знают). Джереми приводит openCV в качестве примера, так как написано так много быстрого кода C, что несомненно, что будут умные использования C. Найдите примеры Джереми по интеграции C здесь.

Действительно интересным для языковых фанатов является объяснение Криса Леттнера о том, как интеграция с C работает под капотом:

Лучший способ справиться с этим - написать полный компилятор C и использовать его в качестве библиотеки в компиляторе Swift… К сожалению, это сложно и на это уйдут годы. К счастью, мы это уже сделали

Пусть Clang и LLVM сделают тяжелую работу:

  • Анализируйте файлы заголовков, сохраняйте их в бинарных модулях, создавайте AST
  • Создание кода для всех странных функций семейства C

Как программист, используйте файл заголовка C, и вы получите сгенерированный быстрый интерфейс. Swift анализирует и переназначает концепции C в Swift, например двойной * превращается в UnsafeMutablePointer ‹Double›.

Я действительно думаю, что стоит на мгновение оценить, насколько на самом деле крутая и элегантная эта интеграция. На самом деле это интеграция на уровне промежуточного представления, поэтому, например, скорость по отношению к оборудованию - это совершенно незаметно, и для разработчика это также выглядит довольно гладко (как только вы перейдете к этим файлам заголовков C). Это не просто хак, объединяющий два языка вместе - проявите некоторое уважение ;-)

Быстрые протоколы

Книга Swift дает хорошее представление о принципах проектирования языка. Одно очевидное преимущество по сравнению с python (я просто воспринимаю это как данность, это преимущество) заключается в том, что swift компилируется, поэтому как разработчик вы обнаруживаете ошибки на раннем этапе написания кода. Скомпилированные языки, как правило, имеют лучшие сообщения об ошибках и лучшие IDE, поскольку они могут использовать аналитические возможности компилятора.

Один из принципов дизайна, который мне больше всего нравится, заключается в том, что swift старается быть не странным, заимствуя идеи из других языков, но последовательно объединяя их. Следовательно, swift может показаться вам знакомым (это было для меня, когда я начинал, и я не использовал его раньше), потому что, вероятно, вы знаете какую-то версию концепций, которые он использует из других языков, например интерфейсы из Java, или вы могли видеть это, например Патч Python обезьяны (посмотрите забавное объяснение имени здесь!).

Эй, может быть, вы просто слушаете Swift Founder с точки зрения его философии, а не получаете это от меня!

Давайте рассмотрим одну особенность: в Swift есть что-то намного более безопасное и принципиальное, чем исправление обезьяны python. Протоколы Swift, которые также намного мощнее, потому что вы можете легко добавлять методы ко всем типам, которые имеют определенный набор поведения.

Проверь это:

Здесь мы расширяем isOdd для работы со всем, что является целым числом. Итак, я не знаю, что видел это раньше, например. на Java или других языках. Но это только я, и даже если какой-то язык уже такой: swift не претендует на то, чтобы всегда вводить новшества. Опять же, не берите это у меня - надеюсь, я обратил на это ваше внимание - пусть эксперты говорят:

Если вас интересует пример использования fast.ai, проверьте Использование Джереми для API блока данных с программированием, ориентированным на протокол. Здесь Джереми использует возможности интеграции Swift с C и быстрые протоколы для воссоздания fast.ai Datablock API в сочетании с вышеупомянутой интеграцией OpenCV C. Опять же, нет смысла повторять здесь все детали: посмотрите объяснения в видео.

@ Различный

Посмотрите Крис об этой« дифференцируемой идее», это большая идея, и идея состоит в том, чтобы базовый механизм глубокого обучения стал основной функцией языка. Автоматическая дифференциация зависит от инфраструктуры компилятора, некоторые объяснения см. В разделе S4tf u под капотом ниже. Проект s4tf дает больше теоретических объяснений этой концепции, некоторые более свежие слайды можно найти в Swift_for_Tensorflow.pd f »

Интересно видеть, что это исследование датируется полвеками, и Крис Леттнер где-то упоминает, что они заимствуют эти идеи из Фортрана (в той же степени, что и в инновациях! '' Просто выберите правильные существующие идеи, смешайте их, и вы на полпути. до гения, см. Сатоши Накамото!). Как и в случае с нейронными сетями, мы стоим на плечах гигантов. Я исключаю, что эта часть будет «движущейся целью», пока Google меняет свою инфраструктуру в сторону MLIR, поэтому ознакомьтесь с этими ссылками и ссылками на MLIR ниже и немного погуглите, когда прочтете это

Здесь мы сосредоточимся на блокноте и уроке, который ссылается на этот блокнот fast.ai. В записной книжке показано, как человек из мира pytorch может использовать swift, а затем показывает, где это можно сделать лучше. Найдите раздел, где Крис (swift: структура и значения / функциональный способ) делает это лучше, чем Джереми (python: классы и ссылки / способ с отслеживанием состояния) здесь. Вам, вероятно, стоит пройти через это несколько раз, по крайней мере, мне пришлось, и мне это понравилось.

На самом деле есть две вещи, которые быстрый способ самодифференцирования делает иначе, чем метод «наивного парня-питона, обучающегося быстро». Один касается семантики значений и ссылок, второй - о функциональном способе программирования, который позволяет компилятору лучше оптимизировать и обобщать.

Начнем с Быстрая семантика значений:

Семантика значения:

  • переменные обозначают (или «означают») его значение
  • так работает математика
  • Структуры Swift работают с семантикой значений

Эталонная семантика:

  • переменная обозначает местоположение
  • это то, чему нас заставляли учиться, обычно когда это нас кусает
  • Классы Swift работают со справочной семантикой

Если вы используете семантику ссылок с быстрыми классами, есть вероятность, что ваш тензор будет изменен другими частями кода, имеющими эту ссылку. Типичный способ смягчить это - клонировать тензоры в какой-то момент вручную, что является медленным и дорогостоящим, если вы это делаете, а если вы его пропустили, вам трудно отлаживать ошибки. Swift, однако, имеет встроенный механизм Копировать при записи, который по сути копирует структуру для вас, когда это необходимо, но только тогда (чтобы его память была эффективной). Здесь есть более подробная информация, например, вокруг таких ключевых слов, как in-out (для параметров функции) и let (неизменяемые константы) против var (изменяемые переменные), дополнительную информацию можно найти здесь.

Для нашего контекста нижняя строка такова:

Не используйте класс:

Используйте структуры:

Чтобы понять механизм задней опоры, упомянутый в видео, вы должны знать, что такое правило цепочки. Если у вас есть время, пройдите эту математическую работу или найдите что-нибудь подобное. Что я не рекомендую: смотреть видео о обратном распространении с графикой, где срабатывают некоторые нейроны - я нашел эту метафору и иллюстрацию более запутанной, чем один раз пройтись по математике (и я не математик!), Потому что это градиентное исчисление на самом деле вещи, которые вы можете вспомнить из школы.

Второй ингредиент - это отсутствие двойного вычисления функций в прямом пути. Важной частью является Chainer Pattern, который по существу позволит вам избежать пересчета тензоров, потому что это может быть довольно затратно, поэтому нам действительно нужно оптимизировать. Увеличьте масштаб Сравнение Джереми различных стилей программирования для достижения этой цели.

Обратите внимание, что swift на самом деле выполняет это автоматическое различие за вас с помощью тега @differentiable, и вы можете делать это с типами данных, такими как Double или Float, а не только с тензорами, как в Pytorch, которые дифференцируемы, то есть непрерывны. Итак, целое число не дифференцируемо.

Я оставляю вас в покое! Найдите еще одну лаконичную записную книжку для этого здесь.

S4tf Под капотом

Теперь я разрежу лед. Ну, я бывал там раньше, потому что эти вещи для меня тоже довольно новы. Но Compiler Infra - тем более, и MLIR - это движущаяся цель, которую очень мало на этой планете еще понимают. Поэтому я дам несколько упрощений и много ссылок (где, надеюсь, все будет обновлено) и своего рода настрой, чтобы понять это.

Если вы используете s4tf сейчас (июнь 2019 г.), вы действительно можете использовать (отказ от ответственности: насколько я понимаю) TF Eager под поверхностью. Это нормально для всех ваших прототипов и быстрой разработки. Затем в течение следующего года (может быть, дольше) Google следует изменить инфраструктуру, и (теоретически) вы должны просто извлекать выгоду из прироста производительности, ничего не делая. Если вы исследователь или инженер, вы можете пойти дальше и скрестить пальцы, Google наверстает упущенное! Это кажется небольшой идеей от fast.ai, чтобы начать сейчас, когда преимущества еще не видны, а затем получить выгоду, когда Google выполнит свое обещание.

Вот план, представленный в курсе в мае 2019 года.

Опять же, по состоянию на апрель 2019 года это приблизительное планирование, и вы можете проверить этот сайт на наличие новостей, когда прочтете этот пост.

Давайте избавимся от XLA: он находится в промежуточном состоянии, существующий компилятор. Здесь нечего сказать, кроме того, что это текущий тензорный поток, и он не должен быть долгосрочной целью. Вспомните приведенную выше цитату Джереми об использовании других языков, на которых вы пишете свой код:

TensorFlow, использующий XLA ... означает, что вы на самом деле пишете не на конечном целевом языке, и вам нужно иметь дело с несоответствием между языком, который, как вы думаете, вы пишете, и фактическим языком, который действительно используется ...

Другими словами, XLA будет промежуточным состоянием, заменяющим текущий активный режим TF (и помните выше, что этот активный режим TF, очевидно, также не является хорошим долгосрочным решением).

LLVM - это посредническое представительство.

При генерации промежуточного кода он также выполняет множество оптимизаций кода.

  • Постоянное сворачивание
  • Устранение мертвого кода
  • Встраивание
  • Арифметическое упрощение
  • Подъем петли

И да, мне пришлось поискать петлю подъема. Не стесняйтесь гуглить, если заблудились ;-)

Можно сказать больше о LLVM, цель MLIR, по-видимому, состоит в том, чтобы переделать LLVM с учетом извлеченных уроков и подготовить MLIR для автоматической дифференциации и ускорителей, таких как GPU и TPU, которые также создает Google.

Посмотрите Интервью с Крисом, чтобы получить общее объяснение и дополнительную информацию о MLIR здесь.

В чем основная проблема с вышеописанным @differentiable? Я понимаю проблему простым языком:

(1) нам нужно извлечь график для обратной опоры (это правило цепочки выше), который мы можем загрузить в графический процессор или TPU.

(2) для «обычных» вычислений (следовательно, обычные потоки управления, которые вы пишете на Python или

swift) мы используем процессоры, а для численных вычислений нам нужны графические процессоры!

У нас возникает вопрос, как мы переводим программу на Python или Swift в код компилятора, чтобы они запускались в правильном порядке на правильном устройстве и правильно объединялись. Это возможно, потому что компиляторы могут действительно проверять код, видеть, «где срабатывает дифференцируемая часть», а затем преобразовывать его в аппаратное обеспечение и согласовывать с «нормальным кодом».

Сравните это с этой статьей. Предположение или цель, которую мы здесь преследуем, заключается в том, что swift должен предлагать разработчику унифицированный уровень интерфейса, взятый из приведенной выше статьи.

вы пишете обычный императивный код Swift вместо обычного Tensor API. Вы можете использовать (или строить) произвольные абстракции высокого уровня без снижения производительности, если вы придерживаетесь статической стороны Swift: кортежи, структуры, функции, неэкранирующие замыкания, дженерики и тому подобное. Если вы смешиваете тензорные операции с кодом хоста, компилятор будет генерировать копии туда и обратно. Точно так же вы можете использовать классы, экзистенциалы и другие функции динамического языка, но они будут вызывать копии на / с хоста. Когда происходит неявная копия тензорных данных, компилятор напомнит вам об этом предупреждением компилятора.

Как уже было сказано, MLIR - это движущаяся цель, и я, конечно, не претендую на то, чтобы полностью ее понять. Так что позвольте мне просто дать вам еще два замечания от Джереми и Криса, чтобы остановиться на них.

Тензорные понимания: около минуты 13.50 здесь Джереми сравнивает глубокое обучение с оптимизатором базы данных: «» Вы говорите базе данных с помощью SQL, что вы хотите, а не о том, как этого добиться, мы сделаем то же самое с глубоким обучением.

И меня заинтриговало это замечание Криса Леттнера:

«По сути, Tensorflow - это компилятор. Он берет модели, а затем заставляет их быстро работать на оборудовании ... у него есть интерфейс, оптимизатор и много бэкендов ... если вы посмотрите на него с особой точки зрения, это компилятор

Итак, я все еще ломаю голову над обоими ;-)

Суть для меня в том, что мы интегрируем новый способ написания программ прямо в сердце языка - точно так же, как мы также смешиваем объектно-ориентированное и функциональное программирование. Единственное отличие: @differentiable требует множества методов компилятора и инфраструктуры, чтобы сделать это из ядра языка. MLIR в значительной степени «просто», чтобы это произошло.

Спасибо

Эти уроки бесплатные, потрясающие, и за это спасибо fast.ai и google.