Собственно, сейчас при желании нет никаких проблем почитать устройство 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-теги — ну неудобно, но принципиально ничего не ограничивают.
Нехитрыми преобразованиями «ужасный» следующий код:
foo, err := DoSmth()
if err != nil {
return err
}
Превращается в совершенно «прекрасный»
var foo FooType
{
var err error
foo, err = DoSmth()
if err != nil {
return err
}
}
Я сам скорее согласен с автором и мне грустно видеть заложенную в Go идеологию. Но всё-таки у Go всё-таки имеется достаточный набор инструментов для решения примерно любой практической задачи.
Собственно, все большие игроки это уже сделали: Google давным-давно разрабатывает; Amazon (используется Anthropic); Microsoft вроде что-то делает; Meta заанонсили; OpenAI то ли дизайнит свои, то ли использует от гугла.
Подвох в том, что производство чипов по последним техпроцессам — дело дорогое, долгое и хорошо работает только в большом масштабе. А кроме чипов ещё нужны компиляторы/оптимизаторы под них и много разной обвязки. У отдельно взятых AI-стартапов нету сотни дата-центров и многих лет на создание уникальной инфры, поэтому подобным скорее занимаются именно облачные провайдеры, которые в подобном собаку съели.
Стоимость обучения определяется не себестоимостью, а балансом спроса и предложения. Аудитории могут вместить лишь столько студентов, а преподаватели — проводить лишь столько семинаров. Отсюда, повышается и стоимость, чтобы уменьшить число студентов до приемлемого. А учитывая, что есть кредит с господдержкой — спрос растет ещё выше.
Собственно, то же самое с баллами ЕГЭ — есть условные 100 бюджетных мест, из которых условные 99 заняты олимпиадниками без учёта ЕГЭ. И вот единственный студент с наибольшим баллом определяет проходной на бюджет.
Почему провайдеров-то? Провайдеры здесь сами заложники и ничего сделать не могут. Это все государственная структура (РКН).
CF, даже при всех своих умениях работы с трафиком, не может достоверно отличить самодеятельность провайдера от самодеятельности кого-то ещё.
Собственно, их заявление содержит только те факты, для которых у них есть понятные доказательства:
что-то происходит на уровне провайдеров, между пользователем и ближайшей точкой Cloudflare
это что-то одновременно происходит для всех пользователей, вне зависимости от провайдера
Доказательств вины РКН они получить не могут и не делают никаких неверифицируемых заявлений. Что, пожалуй, правильно.
Сделать ничего не могут или не хотят ссориться с российскими властями?
Скорее не могут — SNI формируется клиентом, а значит это он должен что-то делать, чтобы мимикрировать под незамедляемый трафик. Да и инъецированные пакеты приходят именно на сторону клиента.
Cloudflare тут может только, пользуясь своим масштабом, продавить в мир более защищенный сетевой стек, в который нельзя будет инъецировать пакеты сбоку и подсмотреть доменное имя. Но он это уже довольно успешно делает (ECH, QUIC) и это блокируется ещё проще. А всякие скрытые туннели типа VLESS примерно никогда не окажутся отлиты в граните стандартов и реализованы в браузерах.
Может, попробуют побороться за российский трафик
Собсно, тут Cloudflare делает всё что реально может — предоставляет обширнейшую статистику о наблюдаемом явлении благодаря внедрению и распространению NEL. Ещё мог бы со своей экспертизой и данными попробовать в суд подать на кого-нибудь, но, увы, Cloudflare не имеет никакого представителя в РФ.
btw, у Cloudflare уже давно есть такой бесплатный сервис как Cloudflare WARP: https://1.1.1.1 — утверждается, что он делает интернет быстрее и безопаснее.
Собственно, сейчас при желании нет никаких проблем почитать устройство 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-теги — ну неудобно, но принципиально ничего не ограничивают.
Да без проблем, на самом деле.
Нехитрыми преобразованиями «ужасный» следующий код:
Превращается в совершенно «прекрасный»
Я сам скорее согласен с автором и мне грустно видеть заложенную в Go идеологию. Но всё-таки у Go всё-таки имеется достаточный набор инструментов для решения примерно любой практической задачи.
Собственно, все большие игроки это уже сделали: Google давным-давно разрабатывает; Amazon (используется Anthropic); Microsoft вроде что-то делает; Meta заанонсили; OpenAI то ли дизайнит свои, то ли использует от гугла.
Подвох в том, что производство чипов по последним техпроцессам — дело дорогое, долгое и хорошо работает только в большом масштабе. А кроме чипов ещё нужны компиляторы/оптимизаторы под них и много разной обвязки. У отдельно взятых AI-стартапов нету сотни дата-центров и многих лет на создание уникальной инфры, поэтому подобным скорее занимаются именно облачные провайдеры, которые в подобном собаку съели.
Стоимость обучения определяется не себестоимостью, а балансом спроса и предложения. Аудитории могут вместить лишь столько студентов, а преподаватели — проводить лишь столько семинаров. Отсюда, повышается и стоимость, чтобы уменьшить число студентов до приемлемого. А учитывая, что есть кредит с господдержкой — спрос растет ещё выше.
Собственно, то же самое с баллами ЕГЭ — есть условные 100 бюджетных мест, из которых условные 99 заняты олимпиадниками без учёта ЕГЭ. И вот единственный студент с наибольшим баллом определяет проходной на бюджет.
CF, даже при всех своих умениях работы с трафиком, не может достоверно отличить самодеятельность провайдера от самодеятельности кого-то ещё.
Собственно, их заявление содержит только те факты, для которых у них есть понятные доказательства:
что-то происходит на уровне провайдеров, между пользователем и ближайшей точкой Cloudflare
это что-то одновременно происходит для всех пользователей, вне зависимости от провайдера
Доказательств вины РКН они получить не могут и не делают никаких неверифицируемых заявлений. Что, пожалуй, правильно.
Скорее не могут — SNI формируется клиентом, а значит это он должен что-то делать, чтобы мимикрировать под незамедляемый трафик. Да и инъецированные пакеты приходят именно на сторону клиента.
Cloudflare тут может только, пользуясь своим масштабом, продавить в мир более защищенный сетевой стек, в который нельзя будет инъецировать пакеты сбоку и подсмотреть доменное имя. Но он это уже довольно успешно делает (ECH, QUIC) и это блокируется ещё проще. А всякие скрытые туннели типа VLESS примерно никогда не окажутся отлиты в граните стандартов и реализованы в браузерах.
Собсно, тут Cloudflare делает всё что реально может — предоставляет обширнейшую статистику о наблюдаемом явлении благодаря внедрению и распространению NEL. Ещё мог бы со своей экспертизой и данными попробовать в суд подать на кого-нибудь, но, увы, Cloudflare не имеет никакого представителя в РФ.
btw, у Cloudflare уже давно есть такой бесплатный сервис как Cloudflare WARP: https://1.1.1.1 — утверждается, что он делает интернет быстрее и безопаснее.