Эти тексты тут уже были около месяца назад, с матами для экспрессии. Но, видимо, автора тогда за мат забанили, сейчас он заново постит уже смягченную версию. Так что причесывание, как можно видеть, идет. Я лично предыдущую версию прочитал с удовольствием.
У меня в детстве был картридж многоигровка на Денди, где игра по ощущениям выбиралась случайно после нажатия кнопки сброса. Причем одна из игр "выпадала" крайне редко: если уж она выпала - то все, надо играть в нее, иначе непонятно когда она еще раз выпадет. Не знаю как я до такого догадался будучи школьником, но я через некоторое время научился стабильно "выбирать" эту игру путем замыкания иголкой двух контактов (ножек микросхемы) прямо на плате картриджа. Понятия не имею как это работало, но смею предположить по данным из статьи, что там был счетчик номера текущей запущенной игры со сдохшим конденсатором, и после выключения питания он помнил номер последней запущенной игры крайне непродолжительное время. Нажатие кнопки сброса пальцем давало долгое время перезагрузки, а метод с иголкой давал настолько короткое, что счетчик не успевал все забыть.
Нет, принцип гачи - хоть какой-нибудь ненужный мусор, но за каждую попытку получишь гарантированно. Иначе формально это уже казино. Про вкусняшки уточнили выше, да.
Ну, изначально бизнес-модель гачи и не рассчитывалась на всех, только на самых упоротых коллекционеров. Закидываешь монетку в торговый автомат, получаешь гасяпон (гачапон) - шарик со случайной игрушкой внутри. Наверно, более подходящий аналог - Киндер-Сюрприз, только без шоколадного яйца вокруг. Нормальным людям 2-3 любых обычных игрушки хватит, а для коллекционеров туда закидывали еще особо редкие экземпляры. Впрочем да, акцент тут смещен именно на игрушку, а не на "вкусняшку".
Ну так это и есть гача (применительно к вкладышам): ты покупаешь жвачку не зная заранее какой там вкладыш. У Киндер-Сюрприза та же механика. Бустеры в коллекционных карточных играх тоже. Короче, физическая реализация лутбоксов.
Мне понравилось, как Теренс Тао в одном из интервью рассказывал на пальцах идею своей попытки опровержения, что можно из уравнений Навье-Стокса построить логические гейты и задать такие начальные параметры системы, чтобы получился этакий жидкостный компьютер. И потом он пытался построить робота из жидкостных вихрей, который строит свою уменьшенную копию, потом передает ей всю свою энергию, копия делает то же самое, но быстрее... и в итоге за конечное время вся энергия фокусируется в одной точке, что приводит к взрыву решения. Подробностей не знаю.
Я буквально неделю назад делал расчеты на 2000 GPU-часов на обычных видеокартах с проверками корректности (не совсем double check, когда каждая подзадача считается 2 раза, но близко к нему). Из ~2000 подзадач один раз словил расхождение. Условно говоря - если время расчета идет на месяцы, проверка на сбои вроде флипнутого рандомного бита обязательна. В идеале double check. К расчетам на обычных CPU это тоже относится.
У LLM в каждой конкретной версии размеры матриц вполне себе фиксированные, так что с этим проблем нет. Тензорные ядра тоже без дела не сидят. Штрассен же рекурсивный, сводит задачу к нескольким другим в 2 раза меньше, а для достаточно маленьких задач дальше на рекурсию слишком много ресурсов тратится, и быстрее в лоб (через тензорные ядра). Это как в сортировках на C++ и Java - они гибридные: как только в рекурсивной сортировке размер кусочка массива становится маленьким (скажем, до 10-16 элементов) - становится быстрее сортировать вставками, чем дальше делить рекурсивно пополам. В умножении матриц проблема скорее в том, что размер этого переходного маленького кусочка слишком большой для текущих размеров LLM.
У вас просто LLM (Little Language Models) слишком маленькие. Вот будут видеокарты на пару терабайт памяти - Штрассен будет быстрее.
А если серьезно - Штрассен вполне обгоняет умножение в лоб где-то на размерах матриц 1000 на 1000 на CPU в один поток. Но Штрассена проблематично распараллеливать на видеокартах, и видимо пока с этим никто особо не заморачивается - проще через тензорные ядра в лоб числа молотить.
Это в базовой куче. Если завести массив отслеживания позиций элементов в куче (в код кучи вносится модификация - при каждом свапе элементов этот массив корректируем) - то можно вполне быстро.
А это n-мерное пространство сейчас с нами в одной комнате?
Это математическая абстракция. Декарт в свое время придумал декартовы координаты как способ работы с алгебраическими уравнениями на геометрической плоскости. До Декарта вот этих осей абсцисс и ординат не было, и у точек координат тоже не было. Оказалось удобно. А потом понеслось... а если в уравнении переменных не 2, а 3? а если вообще n?
Лучше всего для психического здоровья работать с n-мерным пространством как с набором точек, у которых n координат. Представлять себе только 3-мерное пространство, про n-мерное думать "ну там наверно всё выглядит примерно аналогично".
Если герой этой статьи на Хабре нашел как запихать много сфер в n-мерное пространство, думаю, несложно будет адаптировать его находку к тому, чтобы запихать много "шапочек" на n-мерную сферу.
Ну как, 1 байт - это точка в 8-мерном пространстве, а именно вершина 8-мерного единичного гиперкуба. Машинное 32-битное слово aka int в C++ - точка в 32-мерном пространстве. Блоки бит корректировать эффективнее, чем каждый бит по-отдельности. Например, кодом Хэмминга.
Эти тексты тут уже были около месяца назад, с матами для экспрессии. Но, видимо, автора тогда за мат забанили, сейчас он заново постит уже смягченную версию. Так что причесывание, как можно видеть, идет. Я лично предыдущую версию прочитал с удовольствием.
У меня в детстве был картридж многоигровка на Денди, где игра по ощущениям выбиралась случайно после нажатия кнопки сброса. Причем одна из игр "выпадала" крайне редко: если уж она выпала - то все, надо играть в нее, иначе непонятно когда она еще раз выпадет. Не знаю как я до такого догадался будучи школьником, но я через некоторое время научился стабильно "выбирать" эту игру путем замыкания иголкой двух контактов (ножек микросхемы) прямо на плате картриджа. Понятия не имею как это работало, но смею предположить по данным из статьи, что там был счетчик номера текущей запущенной игры со сдохшим конденсатором, и после выключения питания он помнил номер последней запущенной игры крайне непродолжительное время. Нажатие кнопки сброса пальцем давало долгое время перезагрузки, а метод с иголкой давал настолько короткое, что счетчик не успевал все забыть.
Нет, принцип гачи - хоть какой-нибудь ненужный мусор, но за каждую попытку получишь гарантированно. Иначе формально это уже казино. Про вкусняшки уточнили выше, да.
Ну, изначально бизнес-модель гачи и не рассчитывалась на всех, только на самых упоротых коллекционеров. Закидываешь монетку в торговый автомат, получаешь гасяпон (гачапон) - шарик со случайной игрушкой внутри. Наверно, более подходящий аналог - Киндер-Сюрприз, только без шоколадного яйца вокруг. Нормальным людям 2-3 любых обычных игрушки хватит, а для коллекционеров туда закидывали еще особо редкие экземпляры. Впрочем да, акцент тут смещен именно на игрушку, а не на "вкусняшку".
Ну так это и есть гача (применительно к вкладышам): ты покупаешь жвачку не зная заранее какой там вкладыш. У Киндер-Сюрприза та же механика. Бустеры в коллекционных карточных играх тоже. Короче, физическая реализация лутбоксов.
Гача из 90-х - это жвачка Турбо со вкладышами и подобное, если ты хотел собрать все картинки.
У Тао не то чтобы с lean опыт есть, у него есть опыт решения задачи для частного случая.
Мне понравилось, как Теренс Тао в одном из интервью рассказывал на пальцах идею своей попытки опровержения, что можно из уравнений Навье-Стокса построить логические гейты и задать такие начальные параметры системы, чтобы получился этакий жидкостный компьютер. И потом он пытался построить робота из жидкостных вихрей, который строит свою уменьшенную копию, потом передает ей всю свою энергию, копия делает то же самое, но быстрее... и в итоге за конечное время вся энергия фокусируется в одной точке, что приводит к взрыву решения. Подробностей не знаю.
Я буквально неделю назад делал расчеты на 2000 GPU-часов на обычных видеокартах с проверками корректности (не совсем double check, когда каждая подзадача считается 2 раза, но близко к нему). Из ~2000 подзадач один раз словил расхождение. Условно говоря - если время расчета идет на месяцы, проверка на сбои вроде флипнутого рандомного бита обязательна. В идеале double check. К расчетам на обычных CPU это тоже относится.
Лучше книгу написать. В западном стиле: одна умная мысль и 300 страниц воды.
У LLM в каждой конкретной версии размеры матриц вполне себе фиксированные, так что с этим проблем нет. Тензорные ядра тоже без дела не сидят. Штрассен же рекурсивный, сводит задачу к нескольким другим в 2 раза меньше, а для достаточно маленьких задач дальше на рекурсию слишком много ресурсов тратится, и быстрее в лоб (через тензорные ядра). Это как в сортировках на C++ и Java - они гибридные: как только в рекурсивной сортировке размер кусочка массива становится маленьким (скажем, до 10-16 элементов) - становится быстрее сортировать вставками, чем дальше делить рекурсивно пополам. В умножении матриц проблема скорее в том, что размер этого переходного маленького кусочка слишком большой для текущих размеров LLM.
Хотя не, Штрассена и даже чего побыстрее для GPU и TPU можно написать так, чтобы он обгонял умножение в лоб.
Итого Штрассен на 20% быстрее, чем cuBLAS, на матрицах 20к на 20к (не вчитывался, если честно, что там в плане погрешностей и устойчивости).
У вас просто LLM (Little Language Models) слишком маленькие. Вот будут видеокарты на пару терабайт памяти - Штрассен будет быстрее.
А если серьезно - Штрассен вполне обгоняет умножение в лоб где-то на размерах матриц 1000 на 1000 на CPU в один поток. Но Штрассена проблематично распараллеливать на видеокартах, и видимо пока с этим никто особо не заморачивается - проще через тензорные ядра в лоб числа молотить.
Думаю, в видеоиграх нужно запретить проигрыши, поскольку это может быть обидным.
Это в базовой куче. Если завести массив отслеживания позиций элементов в куче (в код кучи вносится модификация - при каждом свапе элементов этот массив корректируем) - то можно вполне быстро.
Ох уж этот Геданкен.
Это математическая абстракция. Декарт в свое время придумал декартовы координаты как способ работы с алгебраическими уравнениями на геометрической плоскости. До Декарта вот этих осей абсцисс и ординат не было, и у точек координат тоже не было. Оказалось удобно. А потом понеслось... а если в уравнении переменных не 2, а 3? а если вообще n?
Лучше всего для психического здоровья работать с n-мерным пространством как с набором точек, у которых n координат. Представлять себе только 3-мерное пространство, про n-мерное думать "ну там наверно всё выглядит примерно аналогично".
Если я буду подробно все расписывать - получится статья на 20 экранов)
Вот я нашел другую статью с видео на 7 минут, в которой на пальцах поясняется суть: Контактное число шаров и сферические коды / Этюды // Математические этюды
Если герой этой статьи на Хабре нашел как запихать много сфер в n-мерное пространство, думаю, несложно будет адаптировать его находку к тому, чтобы запихать много "шапочек" на n-мерную сферу.
Придумано, и много, но уже отнюдь не для начинающих Maximum flow problem - Wikipedia
Ну как, 1 байт - это точка в 8-мерном пространстве, а именно вершина 8-мерного единичного гиперкуба. Машинное 32-битное слово aka int в C++ - точка в 32-мерном пространстве. Блоки бит корректировать эффективнее, чем каждый бит по-отдельности. Например, кодом Хэмминга.