Разрабатывать новое важно и нужно только в тех случаях, когда существующие инструменты вашу задачу не решают или решают её плохо.
Тот же MTProto, например, появился до того как gRPC стал популярен, поэтому его появление было довольно неизбежно — у разработчиков тг не имелось на руках эффективного бинарного протокола.
Но сейчас, например, телеграм всё никак не может дотащить звонки в веб-версию, поэтому что webrtc примерно никак не укладывается в их стек и их шифрование.
Владелец железа запускает у себя воркер — специальную виртуалку, которая изолирована с помощью Intel TDX.
tar с моделью монтируется с хоста в воркер, здесь воркер использует свой доверенный dm-verity, чтобы защитить архив от модификации. Хеш архива анонсируется в сеть.
Клиент использует хеш нужной ему модели, чтобы найти воркер в сети. Потом он верифицирует, что виртуалка действительно внутри Intel TDX и её содержимое не было скомпрометировано.
После аттестации между клиентом и воркером есть TLS-соединение, в котором они обмениваются задачей и результатом.
Воркер использует GPU, чтобы сделать вычисления. Здесь используется NVidia CC, чтобы воркер мог верифицировать, что у него реальная железная GPU, а не что-то фейковое. Клиент аттестацию GPU не проверяет, но он уже аттестовал виртуалку с воркером.
И ещё между клиентом и воркером есть прокси, которые обеспечивают всем участникам справедливые выплаты. Там какая-то жесть с смарт-контрактами, я уже не копал.
Итого: клиент находит подходящий воркер по хешу модели, он не может попросить кого-то выполнить нужную ему модель. Но сама модель на воркерах может быть совершенно любой, хоть проприетарной— клиентам виден только её хеш.
Как человек, однажды год фуллтайм работавший с другим "собственным бинарным протоколом, разработанном с нуля, с встроенным шифрованием и ещё что-то" (*), очень вас прошу — не надо. Я этим уже не занимаюсь, но продолжаю от коллег слышать только плохое и нисколько хорошего.
Мы живём в прекрасное время, когда уже существует https, умееющий в авторизацию по клиентскому сертификату. Уже есть http2 с долгими сессиями и server push. Наконец, уже есть grpc, который всё это красиво оборачивает. Сегодня примерно любая задача передачи данных между двумя акторами эффективно решается широко распространенными инструментами. Изобретать новые почти точно не стоит.
Собственно, сейчас при желании нет никаких проблем почитать устройство TString, ибо его тащат на гитхаб примерно все опенсорсгые проекты Яндекса (YT, YDB): тык
DeepMind занимался машинным обучением ещё до бума LLM, который сейчас все называют ИИ, и активно продолжает заниматься им и сейчас. Собственно, в этой статье никакой ИИ (LLM) никуда не суют, речи про AGI и близко не идёт, а вместо этого используют вполне привычное машинное обучение для того, чтобы аппроксимировать поведение диффуров и находить скрытые закономерности.
Из блога DeepMind
Our approach is based on the use of Physics-Informed Neural Networks (PINNs). Unlike conventional neural networks that learn from vast datasets, we trained our models to match equations which model the laws of physics. The network's output is constantly checked against what the physical equations expect, and it learns by minimizing its ‘residual’, the amount by which its solution fails to satisfy the equations.
Our use of PINNs goes beyond their typical role as general-purpose tools used for solving partial differential equations (PDEs). By embedding mathematical insights directly into the training, we were able to capture elusive solutions — such as unstable singularities — that have long-challenged conventional methods.
Но на сегодняшний день AI продает лучше чем Machine Learning, вот и суют куда попало.
Осциллограф может начать запись измеряемых данных по триггеру,
Справедливости ради, в ролике сделано наоборот — осциллограф завершает запись данных по триггеру.
Потому что если сигнал о начале записи будет подавать лазер, то этот сигнал дойдет немного позже света от того же самого лазера и никакой хорошей картинки не получится. Поэтому автор сделал обратную вещь — сигнал о завершении записи появляется одновременно с включением лазера и идёт к осциллографу через два мотка провода (200 метров), которые дают достаточно задержки, чтобы успеть заснять всю сцену.
Тут правильнее исходить не из стоимости, а из требований на время запуска новой площадки. Если нужно запустить сотню стоек за два дня, то нанять в 100 раз больше людей никак не выйдет — их банально нужно где-то найти, привезти в поле, обучить, обеспечить инструментами, да ещё и накормить где-то. А запуск нового ДЦ (или модуля) — событие всё-таки нечастое, и в нормальной жизни датацентра столько инженеров не нужно.
Если исходный проект большой и сложный или компания поменьше гугла, то выбора у них не будет.
Чтобы написать большой и сложный проект, вам нужно откуда-то в него вложить человекочасы. Поскольку никакая коммерческая компания в это вкладываться не будет, то фактически вам доступны только человекочасы бесплатных энтузиастов, либо какие-то ресурсы из некоммерческих фондов, которые зачем-то хотят написать непонятно кому нужное ПО.
Таким образом, в любом копилефт-проекте неоткуда взяться приличному объему человекочасов, и какой-нибудь гугл довольно быстро его перепишет под себя силами оплачиваемых фуллтайм-разработчиков.
В пайплайне обработке данных нужно сделать две вещи:
Сперва нужно сопоставить по времени данные с разных антенн, потому что они на разном расстоянии. Значит, уже какая-то нетривиальная обработка с FPGA должна быть где-то рядом с телескопом, ибо очень чувствительно к latency. Причем это всё должно быть примерно в одном месте с общим источником точного времени (атомные часы уже предусмотрели).
Затем нужно данные предобработать до какого-то разумного объема, который можно где-то хранить. Просто сырых данных с антенн выходит в районе 160Гбит/с, и это только на первой фазе проекта (если я правильно читаю слайды). Это на порядок больше, чем весь трафик в интернете и нткакой оптики куда-то далеко это тянуть не напасешься.
Всё зависит от масштаба. Если вы облачный провайдер и серверов у вас как на серверной фабрике, то в рамках одного ДЦ часто единицей отказа является целая стойка, потому что в ней уже есть один ToR-свитч, который является единой точкой отказа для всех серверов в этой стойке. Если туда добавить ещё и CXL-память, то по большому счету ничего не меняется (хотя вероятность отказа подрастет).
Новая libc может не заработать на новом ядре (потому что не хватает фич). Но старая libc заработает на новом ядре (потому что сисколлы из ядра не выпиливают).
Строго говоря, алгоритм довольно несложно доработать так, чтобы устаревшие элементы удалялись из куч в тот же момент, когда они вышли из окна. Но для этого потребуется заменить кучу на ваше любимое дерево поиска — тогда удаление станет возможно за O(log N) на каждый новый элемент, где N — размер окна. А реализация какого-нибудь КЧД это уже далековато от "несложно" =)
Однако же альтернативный вариант можно подглядеть здесь: https://stackoverflow.com/a/10696252 — там предлагается аналогичное решение, но с заменой кучи/дерева на список с пропусками, который обладает примерно теми же преимуществами и без необходимости реализовывать балансировку. Но в худшем случае он потребует O(N), что становится практически аналогично quicksort.
В целом, задача как ни крути сводится к поддержанию сортированного списка и быстрее чем O(log N) её решить в общем случае вряд ли выйдет. Учитывая что N (размер окна) довольно мало, то боюсь что любой выигрыш от сложных структур данных запросто будет нивелирован прямолинейностью quicksort.
Согласен, выразился слишком категорично. Какое-то апи есть, но со звездочкой. Из того что вживую втыкался:
Гугл фото (не диск!) закрыл доступ к всей библиотеке через API. Теперь можно видеть только то что было загружено тем же приложением, либо вручную выбирать до 2000 файлов и выдавать к ним доступ. В случае с Диском доступ не закрыли и API есть, но формально все те же самые механизмы уже реализованы и черт его знает что будет в будущем.
Яндекс.диск и его webdav, когда я его трогал, люто резал скорость до где-то 2МБ/с. Это неюзабельно, уж извините.
Про маил ру ничего не скажу, я акцию на 1ТБ пропустил =)
Собственно, примерно никакое файлооблако не даёт гарантий, что автоматизация с ним не сломается. А мне всё-таки хочется верить, что я свой бекап таки смогу просто взять и спокойно восстановить.
Для того чтобы шарить файлы — можно использовать примерно любой мессенджер, а при необходимости залить в примерно любой диск. Надежность при этом совершенно не важна, главное чтобы удобно было. Плюс у того же гугла/яндекса ещё и есть безлимит на фотографии (но со сжатием).
Если же для бекапов и сохранности — Backblaze B2 и AWS Deep Glacier. Первый умеренно дешёвый ($6/TB/mo), с хорошей репутацией и понятным ценообразованием. Второй при правильном использовании стоит сущие копейки (~$1/TB/mo), но восстановление обойдется долго и дорого и есть много подводных камней.
Типичный {гугл,яндекс,маил}.диск обычно имеют ужасные лимиты по скорости, полностью отсутствующее API и отсутствие каких-либо гарантий. Зато у них удобный интерфейс и возможность просто взять и поделиться. С ними я абсолютно уверен разве что в том, что в течении года по ссылке можно будет перейти и файлы через браузер скачать. Ну а большего мне и не надо.
Полноценные S3-подобные хранилища имеют немного более приятное ценообразование и вполне адекватные SLA (они хотя бы есть!). Но никаких красивых ссылок и удобства. Если мой домашний диск вдруг умрет, то почти точно я смогу восстановиться из Backblaze и никто меня в этот момент не забанит и скорость не ограничит. К восстановлению из Amazon, надеюсь, никогда не прибегну, но лишняя копия ещё никому не вредила.
Не надо два разных юзкейса смешивать и всё становится хорошо и приятно.
в конце области видимости или в момент последнего использования
Я всей душой люблю Rust. Но не могу не заметить, что определить «момент последнего использования» в большинстве языков с GC — приблизительно невозможно. Потому что файл может быть в структуре, структура оказалась на куче, а GC в one-shot утилите банально не запускается. И вот теперь close() буквально никогда не вызовется.
А заставлять программиста доказывать компилятору факты о поведении программы — занятие хоть и полезное, но уж больно трудоемкое.
Фактически, Вы можете предъявить только то, что в Go build target оформляется, как комментарий специального вида, и не имеет прямой поддержки в синтаксисе языка.
Если почитать статью по ссылке, то там подсвечивается более важная проблема кросс-компиляции — все условия выражены в терминах названия платформы, а не доступных фич этой платформы.
Во-первых, это не позволяет просто написать «если есть системный вызов pledge(), то используй его», а вместо этого надо перечислить все совместимые платформы вручную. Если вдруг этот список расширится, то нужно его руками менять.
Во-вторых, в Go невозможно скомпилировать под, условно, Linux 2.6. Можно только под какой-то абстрактный Linux с непонятным набором доступных фичей. Здесь можно вспомнить io-uring, который в части дистрибутивов был, а в части его убрали по соображениям безопасности.
А build-теги — ну неудобно, но принципиально ничего не ограничивают.
Разрабатывать новое важно и нужно только в тех случаях, когда существующие инструменты вашу задачу не решают или решают её плохо.
Тот же MTProto, например, появился до того как gRPC стал популярен, поэтому его появление было довольно неизбежно — у разработчиков тг не имелось на руках эффективного бинарного протокола.
Но сейчас, например, телеграм всё никак не может дотащить звонки в веб-версию, поэтому что webrtc примерно никак не укладывается в их стек и их шифрование.
Там такая цепочка:
Владелец железа запускает у себя воркер — специальную виртуалку, которая изолирована с помощью Intel TDX.
tar с моделью монтируется с хоста в воркер, здесь воркер использует свой доверенный dm-verity, чтобы защитить архив от модификации. Хеш архива анонсируется в сеть.
Клиент использует хеш нужной ему модели, чтобы найти воркер в сети. Потом он верифицирует, что виртуалка действительно внутри Intel TDX и её содержимое не было скомпрометировано.
После аттестации между клиентом и воркером есть TLS-соединение, в котором они обмениваются задачей и результатом.
Воркер использует GPU, чтобы сделать вычисления. Здесь используется NVidia CC, чтобы воркер мог верифицировать, что у него реальная железная GPU, а не что-то фейковое. Клиент аттестацию GPU не проверяет, но он уже аттестовал виртуалку с воркером.
И ещё между клиентом и воркером есть прокси, которые обеспечивают всем участникам справедливые выплаты. Там какая-то жесть с смарт-контрактами, я уже не копал.
Итого: клиент находит подходящий воркер по хешу модели, он не может попросить кого-то выполнить нужную ему модель. Но сама модель на воркерах может быть совершенно любой, хоть проприетарной— клиентам виден только её хеш.
Как человек, однажды год фуллтайм работавший с другим "собственным бинарным протоколом, разработанном с нуля, с встроенным шифрованием и ещё что-то" (*), очень вас прошу — не надо. Я этим уже не занимаюсь, но продолжаю от коллег слышать только плохое и нисколько хорошего.
Мы живём в прекрасное время, когда уже существует https, умееющий в авторизацию по клиентскому сертификату. Уже есть http2 с долгими сессиями и server push. Наконец, уже есть grpc, который всё это красиво оборачивает. Сегодня примерно любая задача передачи данных между двумя акторами эффективно решается широко распространенными инструментами. Изобретать новые почти точно не стоит.
(*) — тут подразумевается телеграм с его MTProto
А чем std::alloc не годится? Как-то же стандартный вектор всё-таки должен же быть реализован.
Собственно, сейчас при желании нет никаких проблем почитать устройство TString, ибо его тащат на гитхаб примерно все опенсорсгые проекты Яндекса (YT, YDB): тык
DeepMind занимался машинным обучением ещё до бума LLM, который сейчас все называют ИИ, и активно продолжает заниматься им и сейчас. Собственно, в этой статье никакой ИИ (LLM) никуда не суют, речи про AGI и близко не идёт, а вместо этого используют вполне привычное машинное обучение для того, чтобы аппроксимировать поведение диффуров и находить скрытые закономерности.
Из блога DeepMind
Our approach is based on the use of Physics-Informed Neural Networks (PINNs). Unlike conventional neural networks that learn from vast datasets, we trained our models to match equations which model the laws of physics. The network's output is constantly checked against what the physical equations expect, and it learns by minimizing its ‘residual’, the amount by which its solution fails to satisfy the equations.
Our use of PINNs goes beyond their typical role as general-purpose tools used for solving partial differential equations (PDEs). By embedding mathematical insights directly into the training, we were able to capture elusive solutions — such as unstable singularities — that have long-challenged conventional methods.
Но на сегодняшний день AI продает лучше чем Machine Learning, вот и суют куда попало.
Справедливости ради, в ролике сделано наоборот — осциллограф завершает запись данных по триггеру.
Потому что если сигнал о начале записи будет подавать лазер, то этот сигнал дойдет немного позже света от того же самого лазера и никакой хорошей картинки не получится. Поэтому автор сделал обратную вещь — сигнал о завершении записи появляется одновременно с включением лазера и идёт к осциллографу через два мотка провода (200 метров), которые дают достаточно задержки, чтобы успеть заснять всю сцену.
А вы точно не LLM?
Тут правильнее исходить не из стоимости, а из требований на время запуска новой площадки. Если нужно запустить сотню стоек за два дня, то нанять в 100 раз больше людей никак не выйдет — их банально нужно где-то найти, привезти в поле, обучить, обеспечить инструментами, да ещё и накормить где-то. А запуск нового ДЦ (или модуля) — событие всё-таки нечастое, и в нормальной жизни датацентра столько инженеров не нужно.
Чтобы написать большой и сложный проект, вам нужно откуда-то в него вложить человекочасы. Поскольку никакая коммерческая компания в это вкладываться не будет, то фактически вам доступны только человекочасы бесплатных энтузиастов, либо какие-то ресурсы из некоммерческих фондов, которые зачем-то хотят написать непонятно кому нужное ПО.
Таким образом, в любом копилефт-проекте неоткуда взяться приличному объему человекочасов, и какой-нибудь гугл довольно быстро его перепишет под себя силами оплачиваемых фуллтайм-разработчиков.
К своему стыду, я обсчитался с единицами измерения и должно быть ~170ТБит/с =(
Конкретно число 160Тбит/с сырых данных появляется в разных источниках, но сходу красивой ссылки я не нашел.
Картинка
Дальше там потоки данных ещё больше, но они уже внутри кластера, насколько я понимаю.
В пайплайне обработке данных нужно сделать две вещи:
Сперва нужно сопоставить по времени данные с разных антенн, потому что они на разном расстоянии. Значит, уже какая-то нетривиальная обработка с FPGA должна быть где-то рядом с телескопом, ибо очень чувствительно к latency. Причем это всё должно быть примерно в одном месте с общим источником точного времени (атомные часы уже предусмотрели).
Затем нужно данные предобработать до какого-то разумного объема, который можно где-то хранить. Просто сырых данных с антенн выходит в районе 160Гбит/с, и это только на первой фазе проекта (если я правильно читаю слайды). Это на порядок больше, чем весь трафик в интернете и нткакой оптики куда-то далеко это тянуть не напасешься.
Источник: https://indico.skatelescope.org/event/427/contributions/4238/attachments/3526/4655/Bolton_UCAM_Kernel_workshop_overview_Nov16.pdf — там в самом конце есть слайды с потоком данных
Всё зависит от масштаба. Если вы облачный провайдер и серверов у вас как на серверной фабрике, то в рамках одного ДЦ часто единицей отказа является целая стойка, потому что в ней уже есть один ToR-свитч, который является единой точкой отказа для всех серверов в этой стойке. Если туда добавить ещё и CXL-память, то по большому счету ничего не меняется (хотя вероятность отказа подрастет).
Новая libc может не заработать на новом ядре (потому что не хватает фич). Но старая libc заработает на новом ядре (потому что сисколлы из ядра не выпиливают).
А почему все сложные вычисления происходят именно на кольце, а не в приложении при синхронизации данных на смартфон?
Строго говоря, алгоритм довольно несложно доработать так, чтобы устаревшие элементы удалялись из куч в тот же момент, когда они вышли из окна. Но для этого потребуется заменить кучу на ваше любимое дерево поиска — тогда удаление станет возможно за O(log N) на каждый новый элемент, где N — размер окна. А реализация какого-нибудь КЧД это уже далековато от "несложно" =)
Однако же альтернативный вариант можно подглядеть здесь: https://stackoverflow.com/a/10696252 — там предлагается аналогичное решение, но с заменой кучи/дерева на список с пропусками, который обладает примерно теми же преимуществами и без необходимости реализовывать балансировку. Но в худшем случае он потребует O(N), что становится практически аналогично quicksort.
В целом, задача как ни крути сводится к поддержанию сортированного списка и быстрее чем O(log N) её решить в общем случае вряд ли выйдет. Учитывая что N (размер окна) довольно мало, то боюсь что любой выигрыш от сложных структур данных запросто будет нивелирован прямолинейностью quicksort.
Согласен, выразился слишком категорично. Какое-то апи есть, но со звездочкой. Из того что вживую втыкался:
Гугл фото (не диск!) закрыл доступ к всей библиотеке через API. Теперь можно видеть только то что было загружено тем же приложением, либо вручную выбирать до 2000 файлов и выдавать к ним доступ. В случае с Диском доступ не закрыли и API есть, но формально все те же самые механизмы уже реализованы и черт его знает что будет в будущем.
Яндекс.диск и его webdav, когда я его трогал, люто резал скорость до где-то 2МБ/с. Это неюзабельно, уж извините.
Про маил ру ничего не скажу, я акцию на 1ТБ пропустил =)
Собственно, примерно никакое файлооблако не даёт гарантий, что автоматизация с ним не сломается. А мне всё-таки хочется верить, что я свой бекап таки смогу просто взять и спокойно восстановить.
Для того чтобы шарить файлы — можно использовать примерно любой мессенджер, а при необходимости залить в примерно любой диск. Надежность при этом совершенно не важна, главное чтобы удобно было. Плюс у того же гугла/яндекса ещё и есть безлимит на фотографии (но со сжатием).
Если же для бекапов и сохранности — Backblaze B2 и AWS Deep Glacier. Первый умеренно дешёвый ($6/TB/mo), с хорошей репутацией и понятным ценообразованием. Второй при правильном использовании стоит сущие копейки (~$1/TB/mo), но восстановление обойдется долго и дорого и есть много подводных камней.
Типичный {гугл,яндекс,маил}.диск обычно имеют ужасные лимиты по скорости, полностью отсутствующее API и отсутствие каких-либо гарантий. Зато у них удобный интерфейс и возможность просто взять и поделиться. С ними я абсолютно уверен разве что в том, что в течении года по ссылке можно будет перейти и файлы через браузер скачать. Ну а большего мне и не надо.
Полноценные S3-подобные хранилища имеют немного более приятное ценообразование и вполне адекватные SLA (они хотя бы есть!). Но никаких красивых ссылок и удобства. Если мой домашний диск вдруг умрет, то почти точно я смогу восстановиться из Backblaze и никто меня в этот момент не забанит и скорость не ограничит. К восстановлению из Amazon, надеюсь, никогда не прибегну, но лишняя копия ещё никому не вредила.
Не надо два разных юзкейса смешивать и всё становится хорошо и приятно.
Я всей душой люблю Rust. Но не могу не заметить, что определить «момент последнего использования» в большинстве языков с GC — приблизительно невозможно. Потому что файл может быть в структуре, структура оказалась на куче, а GC в one-shot утилите банально не запускается. И вот теперь close() буквально никогда не вызовется.
А заставлять программиста доказывать компилятору факты о поведении программы — занятие хоть и полезное, но уж больно трудоемкое.
Если почитать статью по ссылке, то там подсвечивается более важная проблема кросс-компиляции — все условия выражены в терминах названия платформы, а не доступных фич этой платформы.
Во-первых, это не позволяет просто написать «если есть системный вызов pledge(), то используй его», а вместо этого надо перечислить все совместимые платформы вручную. Если вдруг этот список расширится, то нужно его руками менять.
Во-вторых, в Go невозможно скомпилировать под, условно, Linux 2.6. Можно только под какой-то абстрактный Linux с непонятным набором доступных фичей. Здесь можно вспомнить io-uring, который в части дистрибутивов был, а в части его убрали по соображениям безопасности.
А build-теги — ну неудобно, но принципиально ничего не ограничивают.