Кстати, интересный терминологический вопрос. Композиторы так называются, потому что они делают композицию из окон на экране. С другой стороны рисованием композиций занимаются художники...
Вы так говорите - будто композиторы это что-то плохое. Типа давайте, у нас изображение на экране будет зависеть от того как приложения быстро отрабатывают запрос на перерисовку окон (забыли уже "шлейфы" от окон в виндах или равномерно закрашенные прямоугольники в иксах, да?), заодно откажемся от аппаратного ускорения и будем делать блиттинг в софте, поимеем обратно проблемы с проигрыванием видео (забыли зеленые или розовые подложки в окнах видеоплееров, да?) и так далее...
То что большинство композиторов в линуксе заодно впихивает всякие свистоперделки вроде трехмерных эффектов больше говорит о вкусе их авторов и юзеров, нежели о самом подходе к композиции финального изображения на экране.
Ну это ж классический tradeoff между скоростью и потреблением памяти. Если памяти много - то реально можно смириться с тем что какие-то куски потом когда-нибудь освободятся. Зато не нужно подсчитывать ссылки, да. С другой стороны, в своей работе я редко вижу когда софт упирается в скорость процессора. Чаще - как раз в объем свободной памяти.
Это только если вы можете гарантировать что ваше "сообщение о том что операция завершена" никогда не выбросит исключение. В принципе, даже std::cout может бросить исключение если ему разрешить: cout.exceptions(iostate) .
В этому по сути фундаментальное различие - Rust дает сильно больше гарантий. Если ваш код уже скомпилировался, то вероятность того что в нем что-то неожиданно пойдет не так гораздо ниже чем в C++. С++ считает что программист не делает ошибок и что любая программа не содержит UB. Вот только я гарантирую что я найду UB в любом более-менее большом проекте на C++.
Так никто не говорит про /sys. Я скорее про общий подход с интерфейсами и их имплементацией через коллбеки в структурах. Там даже есть некоторый вариант наследования, когда в сабклассах переопределяется только часть коллбеков, например.
По моему такая система будет в разы более удобна для программистов.
Для программистов будет удобнее всего использовать unixtime. Все эти часы, минуты, дни недели и месяцы - от лукавого.
Заодно и на СИ перейти. Килосекунда - это типа минут 15. Вместо суток - 100 килосекунд. Вместо недели - мегасекунда. 50 мегасекунд - это год. Удобно! Людишки конечно первое время будут возмущаться что 100 килосекунд не синхронизированы с длиной суток, а Новый Год припадает на разные поры года, но потом привыкнут. Зато все просто и понятно.
Ну да, как тут правильно заметили подход автора ломает поддержку multi threading. Так что да, если отказаться от части фич, то можно сделать быстрее. Если забить на переносимость, например, то можно вообще поюзать mmap/MapViewOfFile и получить еще нефиговый прирост в скорости.
Зачем править сгенерированный нейросетью код руками, когда его должна править сама нейросеть же, после соответствующего исправляющего промта?
Исправить уже существующий код или написать новый с новым промтом?
Я вот просто беру классическую для меня проблему: есть ядро линукса. Есть новое устройство для которого надо написать драйвер. Чтобы драйвер органично и без костылей вошел в ядро надо несколько расширить ядерные интерфейсы. Если что - это нормально, в линуксе часто переделывают внутренние API.
Как мне заставить LLM сделать это? Весь код ядра очевидно не влезет в контекст. Дообучить LLM на конкретной версии кода и потом попросить сделать diff?
Или просто сказать "сделай мне новое ядро как старое, только с новым драйвером"?
Коптеры стали популярны относительно недавно (а не лет 50 назад) благодаря трем вещам: емким и легким аккумуляторам, силовой электронике, которая позволяет эффективно коммутировать адские токи и дешевым доступным MEMS датчикам.
Сделать же раму и намотать катушки в двигателе - действительно много ума не надо.
Порошковая покраска - это в принципе и есть напыление пластика. Типа - нанесли пластиковый порошок, засунули в печь, он там расплавился и равномерно покрыл деталь.
Вы как-то вообще упустили такую штуку как отображение файлов в память. А ведь это именно то что позволяет очень эффективно работать с содержимым файлов в любой современной OS. Например, исполняемые файлы не читаются с диска в память процесса. Они туда просто отображаются. А читаются они в тот самый страничный кеш. Точно этот же механизм используются для работы со свопом, кстати.
AFAIK, ничего оно не читает. Просто обращается к системному менеджеру аутентификации с запросом типа "а сколько времени прошло после последней успешной проверки юзера?"
Как раз в отличии от десктопов, мобильные приложения даже пукнуть не могут без разрешения от системы.
Кстати, интересный терминологический вопрос. Композиторы так называются, потому что они делают композицию из окон на экране. С другой стороны рисованием композиций занимаются художники...
Вы так говорите - будто композиторы это что-то плохое. Типа давайте, у нас изображение на экране будет зависеть от того как приложения быстро отрабатывают запрос на перерисовку окон (забыли уже "шлейфы" от окон в виндах или равномерно закрашенные прямоугольники в иксах, да?), заодно откажемся от аппаратного ускорения и будем делать блиттинг в софте, поимеем обратно проблемы с проигрыванием видео (забыли зеленые или розовые подложки в окнах видеоплееров, да?) и так далее...
То что большинство композиторов в линуксе заодно впихивает всякие свистоперделки вроде трехмерных эффектов больше говорит о вкусе их авторов и юзеров, нежели о самом подходе к композиции финального изображения на экране.
Ну это ж классический tradeoff между скоростью и потреблением памяти. Если памяти много - то реально можно смириться с тем что какие-то куски потом когда-нибудь освободятся. Зато не нужно подсчитывать ссылки, да. С другой стороны, в своей работе я редко вижу когда софт упирается в скорость процессора. Чаще - как раз в объем свободной памяти.
Это только если вы можете гарантировать что ваше "сообщение о том что операция завершена" никогда не выбросит исключение. В принципе, даже
std::coutможет бросить исключение если ему разрешить:cout.exceptions(iostate).В этому по сути фундаментальное различие - Rust дает сильно больше гарантий. Если ваш код уже скомпилировался, то вероятность того что в нем что-то неожиданно пойдет не так гораздо ниже чем в C++. С++ считает что программист не делает ошибок и что любая программа не содержит UB. Вот только я гарантирую что я найду UB в любом более-менее большом проекте на C++.
Это определенно было у Винджа в "Глубине в небе".
Так никто не говорит про
/sys. Я скорее про общий подход с интерфейсами и их имплементацией через коллбеки в структурах. Там даже есть некоторый вариант наследования, когда в сабклассах переопределяется только часть коллбеков, например.Для программистов будет удобнее всего использовать unixtime. Все эти часы, минуты, дни недели и месяцы - от лукавого.
Заодно и на СИ перейти. Килосекунда - это типа минут 15. Вместо суток - 100 килосекунд. Вместо недели - мегасекунда. 50 мегасекунд - это год. Удобно! Людишки конечно первое время будут возмущаться что 100 килосекунд не синхронизированы с длиной суток, а Новый Год припадает на разные поры года, но потом привыкнут. Зато все просто и понятно.
Или пролет исключений через границы библиотек, например.
Проблема 2038 года куда ближе и страшнее.
Ну да, как тут правильно заметили подход автора ломает поддержку multi threading. Так что да, если отказаться от части фич, то можно сделать быстрее. Если забить на переносимость, например, то можно вообще поюзать mmap/MapViewOfFile и получить еще нефиговый прирост в скорости.
Ага, вот бы например nginx удивился бы, узнав что не может читать файлы не из того потока, которых их открывал.
Идея хорошая, но я ни разу не видел чтобы это где-то поддерживалось. Вроде бы сам гугл так тоже не умеет.
Исправить уже существующий код или написать новый с новым промтом?
Я вот просто беру классическую для меня проблему: есть ядро линукса. Есть новое устройство для которого надо написать драйвер. Чтобы драйвер органично и без костылей вошел в ядро надо несколько расширить ядерные интерфейсы. Если что - это нормально, в линуксе часто переделывают внутренние API.
Как мне заставить LLM сделать это? Весь код ядра очевидно не влезет в контекст. Дообучить LLM на конкретной версии кода и потом попросить сделать diff?
Или просто сказать "сделай мне новое ядро как старое, только с новым драйвером"?
Генератор судов по правам человека.
Коптеры стали популярны относительно недавно (а не лет 50 назад) благодаря трем вещам: емким и легким аккумуляторам, силовой электронике, которая позволяет эффективно коммутировать адские токи и дешевым доступным MEMS датчикам.
Сделать же раму и намотать катушки в двигателе - действительно много ума не надо.
Порошковая покраска - это в принципе и есть напыление пластика. Типа - нанесли пластиковый порошок, засунули в печь, он там расплавился и равномерно покрыл деталь.
Вы как-то вообще упустили такую штуку как отображение файлов в память. А ведь это именно то что позволяет очень эффективно работать с содержимым файлов в любой современной OS. Например, исполняемые файлы не читаются с диска в память процесса. Они туда просто отображаются. А читаются они в тот самый страничный кеш. Точно этот же механизм используются для работы со свопом, кстати.
Чтобы не быть голословным: https://developer.android.com/training/sign-in/biometric-auth#no-explicit-user-action
AFAIK, ничего оно не читает. Просто обращается к системному менеджеру аутентификации с запросом типа "а сколько времени прошло после последней успешной проверки юзера?"
Как раз в отличии от десктопов, мобильные приложения даже пукнуть не могут без разрешения от системы.
Мне кажется что 3/4 комментирующих тоже прочитало заголовок и сразу пошло в комментарии.