Мы тут подняли вопрос о гравитации в центре Земли. Привет, Фиолетовая коробка. По факту если посчитать, какая гравитация в центре планеты, то в общем смысле мы получаем 0. Это легко рассчитать. Взять листочек и ручку, и нарисовать схему. Разве что, нужно не забыть, что традиционная формула из закона тяготения относится к внешней точки, а не внутренней. А тут нужна только внутренняя масса. Потому мы подставим массу Земного шара через его объем. И после некоторых мучений и сокращения радиуса из знаменателя, подтвердим, что получили ноль. Но что это значит? Это значит, что именно в точном центре Земли и правда нулевая гравитация. Но только в самой точке, потому что стоит немного сместиться относительно неё и появится притяжение к центру. Причём, внутри тоже массы будут тянуть в разные стороны. И тут появляется мысль о том, что структура там какая-то волшебная или странный пузырь невесомости. Наверное можно представить себе вариант, где такой пузырь есть, но в случае Земли всё интереснее - внутренние слои давят на центр. И в центральной точке совершенно бешенное и равномерное давление. Потому мы не получим разных феноменальных эффектов типа пустой полости в центре планеты или что-то такое. Плотность и состояние вещества будут обусловлены давлением. Короче если лень читать - гравитация в центре Земли и правда ноль. Именно в самом центре. Но это ничего не меняет из-за феноменального давления. ⚠️  Дебри.Физика #стримы

Недавно для себя открыл, что приём из CUDA C Best Practices работает и на чипах Apple Ядро GPU держит сразу несколько SIMD-групп, и когда одна группа ждёт данные из памяти, ядро выполняет инструкции другой. Можно подумать, что чем больше групп на ядре, тем лучше, однако все группы делят между собой регистры и shared memory ядра, поэтому если групп становится слишком много, регистры перестают помещаться на ядре, и данные уходят в кэш. Этот трафик мешает кернелу загружать собственные данные, из-за чего ядро замедляется. Собственно, [приём] для CUDA заключается в том, что можно выделить кернелу shared memory больше, чем ему нужно - это приведет к уменьшению числа групп, и, как следствие, данные перестанут вытесняться. До M3 на чипах Apple число групп ограничивали регистры, каждая группа сразу получала их под самый тяжёлый участок кернела. С M3 регистры выделяются по ходу работы, групп на ядро влезает больше, и чтобы их данные не вытесняли друг друга из кэша, Apple добавила блок, который называет occupancy manager (далее планировщик). На M3 и M4 он снижает число групп, когда из L1, общего для регистров, shared memory и кэша буферов, начинают вытесняться данные. Но этот планировщик работает криво, потому что не снижает число групп, когда через L1 идут данные регистров. На умножении матрицы сразу на несколько токенов он держит 26-27 SIMD-групп на ядро, хотя быстрее всего кернел работает при 8-14. Такое умножение нужно для MTP, где модель набрасывает несколько следующих токенов и проверяет их за один проход. Metal не даёт задать число групп вручную, но приём для CUDA можно заставить работать и здесь. Shared memory в Metal (threadgroup memory) выделяется сразу на одну или несколько SIMD-групп, и новые группы ядро не запускает, пока для их памяти нет места, поэтому лишняя память уменьшает число групп. Чтобы компилятор её не выкинул, в кернел добавляется запись в эту память, которая никогда не выполняется. Лучшее число групп у разных матриц разное, в той же Qwen3.8 на 4 токенах умножение 5120×17408 быстрее всего при 10 группах, 17408×5120 при 24, а от типа квантования лучшее число меняется от 6 до 24. Я пытался вывести формулу по числу регистров, байтам на вес, объёму вычислений на байт и прочим переменным, но не вышло. По лучшей составной формуле кернел в среднем на 5-7% медленнее, чем с оптимумом, найденным перебором. К тому же на той же матрице при 16 группах трафика регистров уже нет, а умножение всё равно по скорости такое же, как и без ограничения (413 мкс против 418), и лучшее время в 349 мкс получается только при 10 группах. Что тормозит кернел между 16 и 10 группами, я так и не понял. Возможно, размер регистрового файла и другие константы чипа помогли бы разобраться, но Apple их не публикует. Поэтому для тестов в llama.cpp число групп подбирает тюнер, который в первые проходы генерации пробует для каждой матрицы вариант без лишней shared memory и несколько её объёмов от 2 до 32 КБ и оставляет самый быстрый, на это уходит около 2 секунд работы GPU. На первой картинке время прохода четырёх моделей в llama.cpp без тюнера и с ним. У Qwen3.8-27B в Q4_K_M проход на 4 токена сокращается со 133 до 113 мс, на 5 со 177 до 127 мс, а у той же модели в Q6_K выигрыш доходит до 38% (на 1-3 токенах llama.cpp работает другим кернелом, которому ограничение не помогает, а на 6 выигрыш почти пропадает, там кернел считает токены двумя частями по 3). На второй картинке то же умножение матрицы 5120×17408 в MLX. В f32 ограничение числа групп ускоряет его на 4 токенах с 374 до 288 мкс, правда в bf16, в котором MLX считает модели, выигрыш сильно меньше. Видимо, в bf16 кернелу нужно меньше регистров

🟢Парень с Claude Code и Codex нашёл возможную планету в данных NASA, где её годами никто не замечал. Павел Рабцевич заметил, что звезда TIC 4206066 немного тускнеет каждые 3,18 дня, и нашёл тот же сигнал в наблюдениях за 2018, 2020 и 2025 годы. Это может быть планета, проходящая перед звездой. По словам автора, он проверил каталоги и результаты автоматического поиска: ранее этот кандидат нигде не фигурировал. То есть телескоп записал сигнал, но предполагаемую планету в нём ещё не распознали. Тред. И история уже дошла до настоящих наблюдений: команда TESS одобрила его заявку на дополнительные измерения, что подтверждается официальным списком программы. В ноябре проверят, повторятся ли затмения в заранее предсказанное время🌚 Молодец, Павел 👍 P.S. Где-то астрологи уже выясняют, почему именно эта планета мешала нам жить все эти годы😡