произошёл скачок в производительности — CGI-скрипт упирался в 5–10 запросов в секунду, а FastCGI на момент создания уже выдавал десятки и сотни
Сейчас не так всё страшно.
Недавно столкнулся с необходимостью перенести свой сервис под apache2+cgi. Тестовый ендпоинд, который соединяется с БД и выполняет запрос "SELECT 1" показал 3000 RPS. Для сравнения, на том же железе с кастомным сервером и наличии пула соединений с БД было 30000 RPS на аналогичном ендпоинте.
Но если учесть, что реальные запросы "немного" сложнее, то оверхед из-за перезапуска cgi процесса не так уж сильно влияет.
Дерево можно впоследствии оптимизировать. Более того, если приглядеться к правилам вычислений над дуальным числами, то вы увидите те же правила, что и при дифференцировании, т.е. будут проведены аналогичные вычисления. Я даже как-то игрался, сделал аналитический вывод производной с применением дуальных чисел. Конечное выражение дичайшее получается, изобилует конструкциями x-x и x+0. Даже при наивном построении дерева это легко будет сократить, а с дуальными числами такие выражения вычисляются полностью.
Ещё с дуальными числами существенно сложнее работать в случае функций многих переменных, посмотрите упомянутый уже ceres. И с оптимизацией в случае многих переменных кратно хуже. То, что можно было бы "вынести за скобку" в случае дерева, в дуальных числах будет вычислено для каждой из переменных.
А так, это очень удобный и быстрый в реализации подход , когда вашу целевую функцию возможно шаблонизировать и передать в аргументах не только double, но и dual<double>. Я бы использовал только при прототипировании.
Мы у себя в ПО пришли к выводу, что намного эффективнее, с точки зрения вычислений, производить автодифференцирование крупными блоками, объединенными логически. Например, оператор сразу вычисляет значение многомерного полинома, или умножение на матрицу, коэффициенты которых нам нужно найти в процессе оптимизации, вместо разбиения на элементарные операции. С одной стороны, нам приходится явно писать код и для forward, backward и для вычисления производных. С другой стороны, в ручном режиме возможно сразу учесть, какие производные равны нулю, и учесть это для оптимизации вычислений.
Если вы просто усредните, то вы уберёте шумы, но не повысите разрешение изображения.
Эти формы известны только в момент "до прилунения", а что в ними в момент падения стало никто не знает. Более того, для звёзд эта форма является точкой, и хорошо математически описывается и просчитывается. А для произвольной формы - увы.
Для получения изображения поверхности Луны нас интересует именно оптическое угловое разрешение. Интерферометрия изображение поверхности не даст. Угловое разрешение в радианах: θ =1.22λ/D (λ - длина волны, D - диаметр апертуры). Для зеркала VLT диаметром 8.2 метра и зелёного света 550нм получим 0.017". При этом, по википедии у него разрешение с адаптивной оптикой 0.05", немного не дотянули до дифракционного предела.
З.Ы. Посмотрел, действительно, по цене небольшой квартиры сейчас можно купить телескоп с апертурой 400мм, что в теории даст разрешение 0.3", а как по факту никто не знает.
На пальцах: Диаметр Луны = 3 474 км; Угловой размер Луны = 31' (это 1860"); Разрешение лучших наземных телескопов около 1"; Разрешение телескопа Джеймс Уэбб около 0.1".
Делим одно на другое, получаем что для наземных телескопов линейное разрешение будет около 2 км, и около 200 м для Джеймса Уэбба. При этом обратите внимание, что наземные телескопы по размеру апертуры больше Уэбба, т.е. они сильно не дотягивают до физического предела.
В теории можно сделать много плохих снимков, из из большого массива построить один хороший.
Для звёзд это делают. Но там главное допущение, что звезда это точечный источник. Т.е. известно какую "форму" надо восстановить. Плюс в атмосфере лазером "зажигают" искусственную звезду для калибровки.
Кто-нибудь из хабражителей знает сервис, аналогичный JLCPCB в России? Я как-то хотел резку металла на ЧПУ заказать для DIY, но так и не нашёл, кто готов одиночное изделие вырезать.
Парадокса пока нет. Ещё нет ни одной системы, созданной одним человеком с применением ИИ, сопоставимой по масштабам тем системам, которые созданы "человеческими" коллективами, пусть и с гигантским оверхедом на коммуникации. Зато в противовес вашему случаю есть примеры создания одним человеком сложнейшего ПО, в том числе ОС, да и не одной. Именно одним человеком без ИИ. И как раз это обусловлено отсутствием лишних коммуникаций. Конечно, хочется надеяться, что тут ИИ сильно поможет таким людям. Но пока ИИ не готов к созданию сложного ПО. Лично мне, проще сразу написать код, чем на естественном языке описывать то, что я хочу от программы, хотя с удовольствием отдаю в ИИ рутинные задачи, или предварительные исследования.
Спасибо! Относительно недавно тоже делал коммуникации, но не в обучении, а моделировании. Интересно, куда тема движется, хотел ваши видео посмотреть, на VK плейлист есть, но пустой. На YouTube всё на месте. В MPI почему-то тоже до сих пор нет возможности агрегации в разных типах. Хотя довольно часто в моделировании встречается кейс что-то посчитать во float, а потом со всех нод в double собрать.
Вот так запускаю:
Я использую qwen-3.6-a35-b3 с весами в bf16, зацикливаний ни разу не заметил.
Ждём на huggingface)
Есть такой инструмент Doxygen, с ним не сравнивали?
У нас был не скрипт, а приложение, написанное на c++.
Сейчас не так всё страшно.
Недавно столкнулся с необходимостью перенести свой сервис под apache2+cgi. Тестовый ендпоинд, который соединяется с БД и выполняет запрос "SELECT 1" показал 3000 RPS. Для сравнения, на том же железе с кастомным сервером и наличии пула соединений с БД было 30000 RPS на аналогичном ендпоинте.
Но если учесть, что реальные запросы "немного" сложнее, то оверхед из-за перезапуска cgi процесса не так уж сильно влияет.
Где они все?
Дерево можно впоследствии оптимизировать. Более того, если приглядеться к правилам вычислений над дуальным числами, то вы увидите те же правила, что и при дифференцировании, т.е. будут проведены аналогичные вычисления. Я даже как-то игрался, сделал аналитический вывод производной с применением дуальных чисел. Конечное выражение дичайшее получается, изобилует конструкциями
x-xиx+0. Даже при наивном построении дерева это легко будет сократить, а с дуальными числами такие выражения вычисляются полностью.Ещё с дуальными числами существенно сложнее работать в случае функций многих переменных, посмотрите упомянутый уже ceres. И с оптимизацией в случае многих переменных кратно хуже. То, что можно было бы "вынести за скобку" в случае дерева, в дуальных числах будет вычислено для каждой из переменных.
А так, это очень удобный и быстрый в реализации подход , когда вашу целевую функцию возможно шаблонизировать и передать в аргументах не только
double, но иdual<double>. Я бы использовал только при прототипировании.Мы у себя в ПО пришли к выводу, что намного эффективнее, с точки зрения вычислений, производить автодифференцирование крупными блоками, объединенными логически. Например, оператор сразу вычисляет значение многомерного полинома, или умножение на матрицу, коэффициенты которых нам нужно найти в процессе оптимизации, вместо разбиения на элементарные операции. С одной стороны, нам приходится явно писать код и для forward, backward и для вычисления производных. С другой стороны, в ручном режиме возможно сразу учесть, какие производные равны нулю, и учесть это для оптимизации вычислений.
Если вы просто усредните, то вы уберёте шумы, но не повысите разрешение изображения.
Эти формы известны только в момент "до прилунения", а что в ними в момент падения стало никто не знает. Более того, для звёзд эта форма является точкой, и хорошо математически описывается и просчитывается. А для произвольной формы - увы.
Для получения изображения поверхности Луны нас интересует именно оптическое угловое разрешение. Интерферометрия изображение поверхности не даст.
Угловое разрешение в радианах: θ =1.22λ/D (λ - длина волны, D - диаметр апертуры).
Для зеркала VLT диаметром 8.2 метра и зелёного света 550нм получим 0.017".
При этом, по википедии у него разрешение с адаптивной оптикой 0.05", немного не дотянули до дифракционного предела.
З.Ы. Посмотрел, действительно, по цене небольшой квартиры сейчас можно купить телескоп с апертурой 400мм, что в теории даст разрешение 0.3", а как по факту никто не знает.
На пальцах:
Диаметр Луны = 3 474 км;
Угловой размер Луны = 31' (это 1860");
Разрешение лучших наземных телескопов около 1";
Разрешение телескопа Джеймс Уэбб около 0.1".
Делим одно на другое, получаем что для наземных телескопов линейное разрешение будет около 2 км, и около 200 м для Джеймса Уэбба. При этом обратите внимание, что наземные телескопы по размеру апертуры больше Уэбба, т.е. они сильно не дотягивают до физического предела.
Для звёзд это делают. Но там главное допущение, что звезда это точечный источник. Т.е. известно какую "форму" надо восстановить. Плюс в атмосфере лазером "зажигают" искусственную звезду для калибровки.
Да, только четверостишие из этой статьи.
Попробовал озвучить ваше стихотворение. Интересно, похоже?
https://suno.com/s/k2MqCiXurI37dfkW
В голове, а компьютер нужен только для того, что бы результат записать.
Кто-нибудь из хабражителей знает сервис, аналогичный JLCPCB в России? Я как-то хотел резку металла на ЧПУ заказать для DIY, но так и не нашёл, кто готов одиночное изделие вырезать.
Парадокса пока нет. Ещё нет ни одной системы, созданной одним человеком с применением ИИ, сопоставимой по масштабам тем системам, которые созданы "человеческими" коллективами, пусть и с гигантским оверхедом на коммуникации.
Зато в противовес вашему случаю есть примеры создания одним человеком сложнейшего ПО, в том числе ОС, да и не одной. Именно одним человеком без ИИ. И как раз это обусловлено отсутствием лишних коммуникаций.
Конечно, хочется надеяться, что тут ИИ сильно поможет таким людям. Но пока ИИ не готов к созданию сложного ПО.
Лично мне, проще сразу написать код, чем на естественном языке описывать то, что я хочу от программы, хотя с удовольствием отдаю в ИИ рутинные задачи, или предварительные исследования.
Интересно, на одноимённом языке они у себя не пишут совсем? Или это другое?
Промышленное решение на Ollama, это как-то не серьёзно. Поставили бы vLLM, она лучше масштабируемая.
Спасибо!
Относительно недавно тоже делал коммуникации, но не в обучении, а моделировании. Интересно, куда тема движется, хотел ваши видео посмотреть, на VK плейлист есть, но пустой. На YouTube всё на месте.
В MPI почему-то тоже до сих пор нет возможности агрегации в разных типах. Хотя довольно часто в моделировании встречается кейс что-то посчитать во float, а потом со всех нод в double собрать.