Наверное, он говорил про storage0. С одной стороны -- фрагментация плохо, с другой стороны -- в целом, пофиг, старый забитый сервер уже будет выведен из аплоада, скорее всего.
Мб проще было не заморачиваться с тем, чтобы убеждаться, что на старый файл нет нескольких ссылок на самом сайте. Есть нюансы с репостами и подобным.
Но тут я в большей степени сужу косвенно, напрямую от "старичков" послушал бы истории об этом периоде.
Видео сейчас живёт в хранилище "Одноклассников", а не "ВКонтакте". Насколько я понимаю, оно на чанки нарезается, и не хранится целиком как один файл, подробнее не расскажу. Можно гуглить про него по названию "one blob storage" / "one cold storage", есть статьи и выступления про него.
CDN там тоже живёт по-своему. В целом, начало файла кэшировать звучит разумно, но какая именно там политика кэширования -- хз. Ставлю на то, что дело в CDN.
Тут вопрос бизнес-логик. По-хорошему, конечно, нужно подчищать такие файлы, но из-за каких-то соображений решили, что нужно сам файл сохранять... Вдруг кто-то в блог вставил ссылку, например. Может, ещё какие-то неизвестные мне причины есть.
Точно по запросу в поддержку можно добиться удаления фоток.
Наружу отдавать интерфейс для удаления -- это рискованно, и нужно тащить проверку прав и всего такого в хранилище. Внутри (для наших сервисов), конечно, такой интерфейс есть, ровно так он и выглядит :)
Думаю, да, опрелённое ускорение можно получить за счёт raw-сокетов. Но тут нужно было обрабатывать именно UDP-пакеты из пользовательского приложения, т.е. у нас не было цели оптимизировать само приложение.
На хосте — обычный арч, на плате — тюнили заказчики, подробностей не знаю.
Я думаю, interrupt coalescing для сетевой карточки может помочь, если приходит много пакетов «разом» (а тут отправляющий хост шлёт их по одному и ждёт ответа), в других случаях это не должно значительно помогать. Или всё-таки помогает за счёт чего-то?
В Mesa действительно есть хорошая поддержка аппаратного ускорения, но она не работает с аппаратурой напрямую, для её использования нужен слой DRM, который и взаимодействует с GPU (и которого у нас пока что нет). Если сконфигурить Mesa с драйвером swrast, она будет, грубо говоря, рисовать картинку в оперативной памяти, без задействования DRM, этот вариант и используется на данный момент.
Реализовать аналог DRM из Linux достаточно сложно, работаем над этим. В данный момент делается драйвер для Vivante GPU на i.MX6. Получить простую анимацию уже получилось, а вот "подружить" драйвер с Mesa не выходит. Там достаточно много подводных камней, когда закончим м.б. накатаю статью по этой теме.
Можно, это видно на скринах в статье. Графика отрисовывается с помощью Mesa, Mesa реализует OpenGL API.
так сложно использовать
Так же, как и обычно — пишете программу, используя OpenGL API, и компилируете.
Станет понятнее, если прочитать статью чуть дальше первого предложения. Непосредственному использованию самого OpenGL тут посвящено несколько предложений и два листинга кода по 20 строк.
Странно, но KVM тут не помогает. Ещё страннее, что в исходниках qemu сама инструкция (stmxcsr) упоминается и кажется, что и программно всё должно работать. Но что-то идёт не так. Проверил только что — на хосте инструкция исполняется без проблем.
Чтобы избегать ситуаций, подобных следующей: min(foo++, bar)
С дополнительными переменными foo будет инкрементирована один раз, а без них — дважды.
Ещё есть более экзотический пример (возможно, надуманный, но всё же возможный), когда может нарушиться согласованность. Если передавать в качестве аргумента разыменованный указатель, после сравнения аргументов может произойти переключение контекста, изменяющее содержимое соответствующего участка памяти. В таком случае макрос может вернуть значение, которого ему не передавали.
Спасибо за замечание!
В исходниках используется именно безопасный вариант, но в статье тоже не помешает исправить. Ссылка на коммит
Да, тут перепутаны знаки «больше» и «меньше», но позже это было исправлено :)
Наверное, он говорил про storage0. С одной стороны -- фрагментация плохо, с другой стороны -- в целом, пофиг, старый забитый сервер уже будет выведен из аплоада, скорее всего.
Мб проще было не заморачиваться с тем, чтобы убеждаться, что на старый файл нет нескольких ссылок на самом сайте. Есть нюансы с репостами и подобным.
Но тут я в большей степени сужу косвенно, напрямую от "старичков" послушал бы истории об этом периоде.
Видео сейчас живёт в хранилище "Одноклассников", а не "ВКонтакте". Насколько я понимаю, оно на чанки нарезается, и не хранится целиком как один файл, подробнее не расскажу. Можно гуглить про него по названию "one blob storage" / "one cold storage", есть статьи и выступления про него.
CDN там тоже живёт по-своему. В целом, начало файла кэшировать звучит разумно, но какая именно там политика кэширования -- хз. Ставлю на то, что дело в CDN.
Тут вопрос бизнес-логик. По-хорошему, конечно, нужно подчищать такие файлы, но из-за каких-то соображений решили, что нужно сам файл сохранять... Вдруг кто-то в блог вставил ссылку, например. Может, ещё какие-то неизвестные мне причины есть.
Точно по запросу в поддержку можно добиться удаления фоток.
Наружу отдавать интерфейс для удаления -- это рискованно, и нужно тащить проверку прав и всего такого в хранилище. Внутри (для наших сервисов), конечно, такой интерфейс есть, ровно так он и выглядит :)
Я думаю, interrupt coalescing для сетевой карточки может помочь, если приходит много пакетов «разом» (а тут отправляющий хост шлёт их по одному и ждёт ответа), в других случаях это не должно значительно помогать. Или всё-таки помогает за счёт чего-то?
В QEMU, как я понял, можно подсунуть ATF, но мы этого не делаем :)
На ARM для NEON у нас такое есть, а на x86 — нет.
В Mesa действительно есть хорошая поддержка аппаратного ускорения, но она не работает с аппаратурой напрямую, для её использования нужен слой DRM, который и взаимодействует с GPU (и которого у нас пока что нет). Если сконфигурить Mesa с драйвером
swrast, она будет, грубо говоря, рисовать картинку в оперативной памяти, без задействования DRM, этот вариант и используется на данный момент.Реализовать аналог DRM из Linux достаточно сложно, работаем над этим. В данный момент делается драйвер для Vivante GPU на i.MX6. Получить простую анимацию уже получилось, а вот "подружить" драйвер с Mesa не выходит. Там достаточно много подводных камней, когда закончим м.б. накатаю статью по этой теме.
Можно, это видно на скринах в статье. Графика отрисовывается с помощью Mesa, Mesa реализует OpenGL API.
Так же, как и обычно — пишете программу, используя OpenGL API, и компилируете.
Станет понятнее, если прочитать статью чуть дальше первого предложения. Непосредственному использованию самого OpenGL тут посвящено несколько предложений и два листинга кода по 20 строк.
Странно, но KVM тут не помогает. Ещё страннее, что в исходниках qemu сама инструкция (
stmxcsr) упоминается и кажется, что и программно всё должно работать. Но что-то идёт не так. Проверил только что — на хосте инструкция исполняется без проблем.Затрудняюсь сказать, что именно идёт не так.
Дело не в третьей переменной, а именно в
-O0. С-O1будет как в примере в статье.Если посмотреть дизассемблер, с оптимизацией
p == qпредподсчитывается как 0.Без оптимизации делается честный cmp.
Без оптимизации результат другой.
> gcc main.c
> ./a.out
0x7ffd9dad19fc 0x7ffd9dad19fc 1
> gcc main.c -O1
> ./a.out
0x7ffe4b876ebc 0x7ffe4b876ebc 0
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
min(foo++, bar)С дополнительными переменными
fooбудет инкрементирована один раз, а без них — дважды.Ещё есть более экзотический пример (возможно, надуманный, но всё же возможный), когда может нарушиться согласованность. Если передавать в качестве аргумента разыменованный указатель, после сравнения аргументов может произойти переключение контекста, изменяющее содержимое соответствующего участка памяти. В таком случае макрос может вернуть значение, которого ему не передавали.
В исходниках используется именно безопасный вариант, но в статье тоже не помешает исправить.
Ссылка на коммит
Да, тут перепутаны знаки «больше» и «меньше», но позже это было исправлено :)