Так что я бы не сказал, что она не подробная. Опять же, подозреваю, что статья писалась не для такого как я, кто итак знает. Отдельно отмечу, что как показалось странным при такой подробности полное отсутствие упоминания о linear matrix inequalities.
Предположу, что исходный список вопросов вам задали не для того, чтобы вы ответили на них в комментарии, а для того, чтобы дать вам понять, что этого явно не хватает в статье.
ИМХО. У вас хорошая техническая статья, но не понятно о чем она и для кого. Вроде как статья про метод Ляпунова, но 2 трети статьи -- это вы пошли в случайном направлении и начали в подробностях разбирать вещи, которые вполне живут самостоятельной жизнью. Например фундамент математической оптимизации тоже выражается через анализ Ляпунова, но подробный рассказ о том как это выражается -- это не детальное погружение в тематику, а плохая струтурированность и отличный способ окончательно запутать читателя.
Сейчас нейросети считают синусы миллиардами операций
это как?
Вроде как хорошая статья, но не про то, как Интел считал синусы быстрее всех, а как автор это реверс инженирил. Вот же отличная статья на хабре на ту же тему и в 10 раз короче
Да, это я что-то затупил, тот же шафл перемешивает внутри 128-битного блока. Но в целом проблема с примером, который я привёл, остается -- сделать сдвиг кратно 8 бит можно одной инструкцией, но произвольный почему-то нет, приходится извращаться.
Касательно исходного вопроса по произвольному перекладыванию: судя по всему в AVX-512 shuffle тоже не умеет перекладывать между 128-битными блоками, но это умеет делать семейство инструкций permute -- ожидаемо они работают чуть медленее.
А ещё у AVX512 гораздо более удобный shuffle, который может переносить любые байты в любое место
Сколько не искал так и ни нашел ни одну инструкцию, которая умеет перемещать данные между двумя 64-битными компонентами, не то что 128. Например чтобы посчитать маску (1 << L) - 1 с L>64 пришлось
Сам AVX-512 сейчас не везде есть, но вообще это в большей степени для демонстрации концепта, я специально в качестве первичного примера брал операцию, которая итак есть.
Ключевой вопрос -- есть ли под этой идеей фундамент. Меня вот очень сильно смущает описание автора
Не все задачи можно расшарить между пользователями; важно, чтобы задача умела параллелиться. СЮРПРИЗ! Задачи для ИИ отлично параллелятся, собственно, поэтому они так хорошо выполняются на GPU
ибо если вы не видите разницу между распараллеливанием задач внутри одного гпу, между несколькими гпу в одной стойке и между гпу разных пользователей сети ... (тут должно быть какое-то саркастично-ехидное завершение, но я не придумал)
Другое дело, что последние лет 8 активно ведется ресерч по децентрализованному обучению, одна сторона этой монеты -- это federated learning, основная цель которого изоляция чувствительных данных, другая -- альтернатива централизованному параллелизму. К сожалению лучший proof of concept, что я видел -- вот эта репа от facebook (tl;dr там децентрализованный GossipDataParallel, который по идее из коробки заменяет torch.nn.parallel.DistributedDataParallel). К сожалению как мы все видим принципиальных прорывов связанных с этим нет.
А литкод убрал убрал дисперсию в замерах? Если нет, то на время работы особого смысла нет смотреть. Раньше точно было такое, что посылка одного и того же решения могла дать "beats 100%", а могла и "beats 30%"
Напомню наши ценности из начала статьи: Адаптация, Ценность, Команда. Если вы выкидываете хотя бы один из ритуалов, то забудьте об Адаптации. Никаких улучшений со временем не будет.
Прочитать популярную книжку, прийти на работу и "сейчас я вам всем объясню как правильно" не выглядит как адаптивность, больше похоже на один из худших методов организации работы.
Я работаю в R&D и пожалуй могу сказать, что моя специализация -- научные вычисления. Результат моей работы не часто можно увидеть и пощупать, особенно если хочется увидеть разницу разницей продукта сейчас и месяц назад. Оригинальную книгу по скраму не читал (не горжусь этим, просто привожу для контекста), но считаю, что работаю по скраму, мой выбор основан на прошлом опыте и своем личном и коллег по цеху, что лучше со спринтами, чем без. Мои спринты длятся 2 недели, именно такая длительность основана на обратной связи, а не потому что так советуют в книгах.
Для меня скрам -- это не только про адаптивность, но наверно даже в большей степени про то, что грамотная организация работы значительно улучшает производительность.
Как и string::find, вот только любая реализация string::find может опираться на то, что сравниваемым типом будет один из нескольких известных с известной максимальной длиной, а ranges::search -- нет
Не знаю, что по вашему мнению я путаю, попробую переформулировать. Если искомая строка <= 32 байт и нам доступны 256-битные регистры, то скорее всего любая реализация КМП будет медленнее линейного прохода с линейным сравнением, потому что компилятор свернёт всё линейное сравнение в одну SIMD инструкцию. Компилятор скорее всего сделает подобное и с сравнениями в КМП, но у него все равно в этом сценарии будет больше сравнений, которые еще и непоследовательны по доступу к памяти, что сделает его неэффективным.
И да, сворачивание в одну SIMD инструкцию сравнения целого слова является например причиной неэффективности того же КМП в большинстве случаев, но вы же ни слова об этом в статье не сказали!
Мой посыл в том, что вы предлагаете использовать ranges::search, который работает с произвольным типом вместо нативного string::find с фиксированным типом (ну или по крайней мере мы знаем, что это от 1 до 4 байт если говорим о wchar), и если где-то ожидать сворачивание в одну SIMD инструкцию типа cmpeq, то как раз скорее от find.
Вроде как важа задача довольно известная, но к сожалению не самая простая. Беглый поиск "Circle packing" выдаёт например https://github.com/elmotec/circlify
Во время ковида был у меня забавный случай. Все супермаркеты использовали квадратную разметку для соблюдения дистанции в 1,5м (только у Призмы я обнаружил на кассах разметку, соответствующую хексагональному замощению), написал на все контакстные почты известных мне супермаркетов с предложением хотя бы сделать как в Призме. Написал заодно и Роберту Лангу с просьбой дать первичную консультацию по задаче об упаковке. Оветили Роберт и менеджер из Призмы, ото всех остальных ничего.
Есть мнение, что все формулы/теоремы, названные в честь известных математиков, изобретены далеко не ими, например с Гауссом подобная история. Забавно, что конкретно по тематике статьи есть обратный пример: известно, что первые варианты БПФ придумал именно он.
В английской википедии есть следующие статьи
https://en.wikipedia.org/wiki/Lyapunov_stability
https://en.wikipedia.org/wiki/Lyapunov_equation
https://en.wikipedia.org/wiki/Lyapunov_function
https://en.wikipedia.org/wiki/QR_decomposition
https://en.wikipedia.org/wiki/QR_algorithm
https://en.wikipedia.org/wiki/Schur_decomposition
https://en.wikipedia.org/wiki/Proportional–integral–derivative_controller
https://en.wikipedia.org/wiki/Bartels–Stewart_algorithm
Так что я бы не сказал, что она не подробная. Опять же, подозреваю, что статья писалась не для такого как я, кто итак знает. Отдельно отмечу, что как показалось странным при такой подробности полное отсутствие упоминания о linear matrix inequalities.
Предположу, что исходный список вопросов вам задали не для того, чтобы вы ответили на них в комментарии, а для того, чтобы дать вам понять, что этого явно не хватает в статье.
ИМХО. У вас хорошая техническая статья, но не понятно о чем она и для кого. Вроде как статья про метод Ляпунова, но 2 трети статьи -- это вы пошли в случайном направлении и начали в подробностях разбирать вещи, которые вполне живут самостоятельной жизнью. Например фундамент математической оптимизации тоже выражается через анализ Ляпунова, но подробный рассказ о том как это выражается -- это не детальное погружение в тематику, а плохая струтурированность и отличный способ окончательно запутать читателя.
Видимо потому что перевод
Разборы на русском (ютуб, перевод):
https://www.youtube.com/watch?v=eQlSvfUuQNs
https://www.youtube.com/watch?v=qO-HpEgmd6U&t=10s
Статьи (хабр, оригинал)
https://habr.com/ru/articles/196374/
https://habr.com/ru/articles/837706/
https://habr.com/ru/articles/269991/
Моя мини заметка
https://t.me/a_zachem_eto_nuzhno/29
это как?
Вроде как хорошая статья, но не про то, как Интел считал синусы быстрее всех, а как автор это реверс инженирил. Вот же отличная статья на хабре на ту же тему и в 10 раз короче
https://habr.com/ru/articles/798991/
Да, это я что-то затупил, тот же шафл перемешивает внутри 128-битного блока. Но в целом проблема с примером, который я привёл, остается -- сделать сдвиг кратно 8 бит можно одной инструкцией, но произвольный почему-то нет, приходится извращаться.
Касательно исходного вопроса по произвольному перекладыванию: судя по всему в AVX-512 shuffle тоже не умеет перекладывать между 128-битными блоками, но это умеет делать семейство инструкций permute -- ожидаемо они работают чуть медленее.
Сколько не искал так и ни нашел ни одну инструкцию, которая умеет перемещать данные между двумя 64-битными компонентами, не то что 128. Например чтобы посчитать маску (1 << L) - 1 с L>64 пришлось
Вот так выкручиваться
Сам AVX-512 сейчас не везде есть, но вообще это в большей степени для демонстрации концепта, я специально в качестве первичного примера брал операцию, которая итак есть.
Ключевой вопрос -- есть ли под этой идеей фундамент. Меня вот очень сильно смущает описание автора
ибо если вы не видите разницу между распараллеливанием задач внутри одного гпу, между несколькими гпу в одной стойке и между гпу разных пользователей сети ... (тут должно быть какое-то саркастично-ехидное завершение, но я не придумал)
Другое дело, что последние лет 8 активно ведется ресерч по децентрализованному обучению, одна сторона этой монеты -- это federated learning, основная цель которого изоляция чувствительных данных, другая -- альтернатива централизованному параллелизму. К сожалению лучший proof of concept, что я видел -- вот эта репа от facebook (tl;dr там децентрализованный GossipDataParallel, который по идее из коробки заменяет torch.nn.parallel.DistributedDataParallel). К сожалению как мы все видим принципиальных прорывов связанных с этим нет.
Не увидел в статье, а вам же синтезатор речи начитывает текст в ускоренном темпе (по сравнению с обычной человеческой речью)? С какой если не секрет?
А литкод убрал убрал дисперсию в замерах? Если нет, то на время работы особого смысла нет смотреть. Раньше точно было такое, что посылка одного и того же решения могла дать "beats 100%", а могла и "beats 30%"
Прочитать популярную книжку, прийти на работу и "сейчас я вам всем объясню как правильно" не выглядит как адаптивность, больше похоже на один из худших методов организации работы.
Я работаю в R&D и пожалуй могу сказать, что моя специализация -- научные вычисления. Результат моей работы не часто можно увидеть и пощупать, особенно если хочется увидеть разницу разницей продукта сейчас и месяц назад. Оригинальную книгу по скраму не читал (не горжусь этим, просто привожу для контекста), но считаю, что работаю по скраму, мой выбор основан на прошлом опыте и своем личном и коллег по цеху, что лучше со спринтами, чем без. Мои спринты длятся 2 недели, именно такая длительность основана на обратной связи, а не потому что так советуют в книгах.
Для меня скрам -- это не только про адаптивность, но наверно даже в большей степени про то, что грамотная организация работы значительно улучшает производительность.
Как и string::find, вот только любая реализация string::find может опираться на то, что сравниваемым типом будет один из нескольких известных с известной максимальной длиной, а ranges::search -- нет
Не знаю, что по вашему мнению я путаю, попробую переформулировать. Если искомая строка <= 32 байт и нам доступны 256-битные регистры, то скорее всего любая реализация КМП будет медленнее линейного прохода с линейным сравнением, потому что компилятор свернёт всё линейное сравнение в одну SIMD инструкцию. Компилятор скорее всего сделает подобное и с сравнениями в КМП, но у него все равно в этом сценарии будет больше сравнений, которые еще и непоследовательны по доступу к памяти, что сделает его неэффективным.
И да, сворачивание в одну SIMD инструкцию сравнения целого слова является например причиной неэффективности того же КМП в большинстве случаев, но вы же ни слова об этом в статье не сказали!
Мой посыл в том, что вы предлагаете использовать ranges::search, который работает с произвольным типом вместо нативного string::find с фиксированным типом (ну или по крайней мере мы знаем, что это от 1 до 4 байт если говорим о wchar), и если где-то ожидать сворачивание в одну SIMD инструкцию типа cmpeq, то как раз скорее от find.
Ѣ, нет слов
https://quick-bench.com/q/_KCURn2wkxN1KcQvtSP-GbcxJmE
UPD. Допустил глупую ошибку, добавил benchmark::DoNotOptimize, ситуация не поменялась
https://quick-bench.com/q/bddW24xhG8EPtsfBI-RGdyac8M8
Вроде как важа задача довольно известная, но к сожалению не самая простая. Беглый поиск "Circle packing" выдаёт например https://github.com/elmotec/circlify
Есть такой математик Роберт Ланг, который произвёл в 90х годах революцию в оригами придумав схему построения crease pattern из фигурки из спичек с помощью задачи упаковки кругов.
https://langorigami.com/article/treemaker/
https://dl.acm.org/doi/pdf/10.1145/237218.237249
Пример его работы
https://langorigami.com/artworks/
Во время ковида был у меня забавный случай. Все супермаркеты использовали квадратную разметку для соблюдения дистанции в 1,5м (только у Призмы я обнаружил на кассах разметку, соответствующую хексагональному замощению), написал на все контакстные почты известных мне супермаркетов с предложением хотя бы сделать как в Призме. Написал заодно и Роберту Лангу с просьбой дать первичную консультацию по задаче об упаковке. Оветили Роберт и менеджер из Призмы, ото всех остальных ничего.
Есть например октонионы, но кажется, что практическая их польза заметно меньше кватернионов.
Есть мнение, что все формулы/теоремы, названные в честь известных математиков, изобретены далеко не ими, например с Гауссом подобная история. Забавно, что конкретно по тематике статьи есть обратный пример: известно, что первые варианты БПФ придумал именно он.