"There's a lovely, empty, pink stool waiting for a lovely, empty, pink rump like yours" - помню эту фразу с отрочества. Кто не в курсе, это из "Larry...". Я английский язык по этой игрухе учил. ;)
К слову о подходах. На днях вышла бесплатная опенсорсная книга "FreeBSD Device Drivers - from first step to Kernel mastery" за авторством Edson Brandi (один из разработчиков FreeBSD). Книга в PDF формате содержит 4599 страниц - это для тех, кому важен сам процесс.
Книга, кстати, неплохая, но очень много воды, автор явно злоупотребил LLM-кой.
Well, new language (or new syntax) is always a problem. Devs don't like studying one more language, also there are tons of legacy code we depend on that will never be rewritten or even touched. In this regard Fil-C seems promising because it consumes already written code without modifications (mostly). Thanks anyway.
Yes, programs compiled with Fil-C said to be 4-times slower than with a regular compiler. That's a real drawback, but still faster than any Python or Java. And safe. :)
That's strange. Fil-C author says that his front-end is compatible with C++20 and most software can be compiled with Fil-C just find. From what I read, Fil-C is a kind of preprocessor for Clang/LLVM that inserts pointer checks (InvisiCaps) into intermediate representation of program (IR) during compile time. I liked the idea, but have not tried it yet. The problem with Fil-C for me is that it heavily depends on libmusl (a version of libc with pointer checks for Linux ABI), hence it's Linux-only. It will be difficult to port it to BSD or other OSes.
На существующем в РФ производстве можно изготавливать микропроцессоры с современной архитектурой RVA23 (RISC-V 64 bit) работающие на частотах 250-300 МГц. Что если взять эту технологию за опорную точку и переосмыслить всё написанное в статье. Не с точки зрения "тотального технологического суверенитета", а с точки зрения поворота в развитии цивилизации: остановиться, подумать, откатиться немного назад и проложить новый путь развития. Путь, где оптимизация и качество кода являются первостепенными факторами. Где нет необходимости в модных графических интерфейсай с кинетической прокруткой экрана (хотя они и возможны, но трата ресурсов на такое должно порицаться!). Где нет необходимости постоянно агрейдить ПО и железо, где Web браузер вмещается в 16МБ оперативной памяти, а FastEthernet и 2.4ГГц WiFi - достаточены для большинства задач бизнеса. В этой точке мы могли бы чувствовать себя комфортно и даже задавать тренд для дальнейшего развития.
И да. На мой взгляд нет никакой необходимости устраивать революцию. Новый подход может идти в параллель с существующими тенденциями.
Вы цифры-то посмотрели? Он таки грузит .so на двести метров, примерно своего же размера то есть.
Дело в том, что из всего того, что загружено, реально используется очень малая доля. Мне как-то попадалась статья на эту тему, где проводились исследования ряда популярных GUI приложений (Web-браузеры - тема отдельного разговора). В ней исследователи пришли к выводу, что в среднем, из каждой загруженной приложением библиотеки испольузется только 5% её кода, а всё остальное висит в памяти мертвым грузом. Это означает, что если выполнить Link-Time Optimization (-flto), то размер кода уменьшится в 20 раз! Иными словами, в один и тот же обьем памяти можно разместить до 20-ти приложений написанных и слинкованых таким образом.
Картину портят Web-браузеры и прочие приложения которые содержат в себе виртуальную машину и полную копию "мира" для этой ВМ. Также не способствует развитию идеи статической линковки с LTO вошедший в обиход способ распространения ПО в виде Flatpack, AppImage и Docker. Короче, если бы не мода на "удобство установки", то современный софт можно было бы конкретно ужать в размерах - в динамические библиотеки вынести только часто используемые системные функции (libc, libthr и т.д.), а всё остальное линковать статиком с -flto. Помимо экономии памяти было бы существенное снижение обьема гимороя вызванного поддержанием совместимости различных версий.
Ха! Так в чем поинт использовать .so, если приложения и так половину опенсорсного мира содержат внутри ? По факту получается, что разработчики давно уже всё статиком затянули во внутрь (AppImage, Flatpak - те же яйца). Какой толк от динамической линковки при таком раскладе ?
Жесть жосткая! Я считал, что Firefox - самая раздутая программа, но этот ваш Telegram бьёт все рекорды. Боюсь представить сколько памяти он пожирает при работе.
Есть возможность собрать с его с -flto ?
И какой самый толстый обьект внутри ELF-а ? Похоже там полноценная виртуальная машина со своей копией Ubuntu. :-)
Например надо инклуд вставить который не помнишь ни где лежит ни как назывется
Например, мы хотим найти где объявлена функция printf. Для этого воспользуемся командой grep вызвав её прямо из редактора vi со вставкой результата в редактируемый файл, жмем: :r! grep -r ’ printf(’ /usr/include
Удаляем лишнее.
Команды ! и r - это классика, их знает каждый пользователь редактора vi.
Ох ты-ж, какая древность всплыла. :)
"There's a lovely, empty, pink stool waiting for a lovely, empty, pink rump like yours" - помню эту фразу с отрочества. Кто не в курсе, это из "Larry...". Я английский язык по этой игрухе учил. ;)
Понятно, Linux от бразильской команды. На сайте gnu.org на них даже ссылка есть как на настоящий образец "Free Software". Будем изучать.
Весело у вас там.
Hyperbola это, простите, что ?
Где можно почитать про это ?
Ок, спасибо.
К слову о подходах. На днях вышла бесплатная опенсорсная книга "FreeBSD Device Drivers - from first step to Kernel mastery" за авторством Edson Brandi (один из разработчиков FreeBSD). Книга в PDF формате содержит 4599 страниц - это для тех, кому важен сам процесс.
Книга, кстати, неплохая, но очень много воды, автор явно злоупотребил LLM-кой.
Было и интересно узнать какую можно выжать максимальную тактовую вычислительного ядра на таком дизайне.
Почему использовали Gown EDA, а не опенсорсный тул на базе Yosys (OSS-CAD) ? Надо избавляться от проприетарщины хотя бы в академической среде.
Очень круто! Традиционный вопрос - какой Fmax получился у Вас на TangNano-9K ? Какой тулчейн для синтеза использовали ?
Well, new language (or new syntax) is always a problem. Devs don't like studying one more language, also there are tons of legacy code we depend on that will never be rewritten or even touched. In this regard Fil-C seems promising because it consumes already written code without modifications (mostly). Thanks anyway.
Yes, programs compiled with Fil-C said to be 4-times slower than with a regular compiler. That's a real drawback, but still faster than any Python or Java. And safe. :)
That's strange. Fil-C author says that his front-end is compatible with C++20 and most software can be compiled with Fil-C just find. From what I read, Fil-C is a kind of preprocessor for Clang/LLVM that inserts pointer checks (InvisiCaps) into intermediate representation of program (IR) during compile time. I liked the idea, but have not tried it yet. The problem with Fil-C for me is that it heavily depends on libmusl (a version of libc with pointer checks for Linux ABI), hence it's Linux-only. It will be difficult to port it to BSD or other OSes.
Предлагаю автору подумать в параллельную тему.
На существующем в РФ производстве можно изготавливать микропроцессоры с современной архитектурой RVA23 (RISC-V 64 bit) работающие на частотах 250-300 МГц. Что если взять эту технологию за опорную точку и переосмыслить всё написанное в статье. Не с точки зрения "тотального технологического суверенитета", а с точки зрения поворота в развитии цивилизации: остановиться, подумать, откатиться немного назад и проложить новый путь развития. Путь, где оптимизация и качество кода являются первостепенными факторами. Где нет необходимости в модных графических интерфейсай с кинетической прокруткой экрана (хотя они и возможны, но трата ресурсов на такое должно порицаться!). Где нет необходимости постоянно агрейдить ПО и железо, где Web браузер вмещается в 16МБ оперативной памяти, а FastEthernet и 2.4ГГц WiFi - достаточены для большинства задач бизнеса. В этой точке мы могли бы чувствовать себя комфортно и даже задавать тренд для дальнейшего развития.
И да. На мой взгляд нет никакой необходимости устраивать революцию. Новый подход может идти в параллель с существующими тенденциями.
Just curious, what's author's opinion on Fil-C ?
Дело в том, что из всего того, что загружено, реально используется очень малая доля. Мне как-то попадалась статья на эту тему, где проводились исследования ряда популярных GUI приложений (Web-браузеры - тема отдельного разговора). В ней исследователи пришли к выводу, что в среднем, из каждой загруженной приложением библиотеки испольузется только 5% её кода, а всё остальное висит в памяти мертвым грузом. Это означает, что если выполнить Link-Time Optimization (-flto), то размер кода уменьшится в 20 раз! Иными словами, в один и тот же обьем памяти можно разместить до 20-ти приложений написанных и слинкованых таким образом.
Картину портят Web-браузеры и прочие приложения которые содержат в себе виртуальную машину и полную копию "мира" для этой ВМ. Также не способствует развитию идеи статической линковки с LTO вошедший в обиход способ распространения ПО в виде Flatpack, AppImage и Docker. Короче, если бы не мода на "удобство установки", то современный софт можно было бы конкретно ужать в размерах - в динамические библиотеки вынести только часто используемые системные функции (libc, libthr и т.д.), а всё остальное линковать статиком с -flto. Помимо экономии памяти было бы существенное снижение обьема гимороя вызванного поддержанием совместимости различных версий.
Ха! Так в чем поинт использовать .so, если приложения и так половину опенсорсного мира содержат внутри ? По факту получается, что разработчики давно уже всё статиком затянули во внутрь (AppImage, Flatpak - те же яйца). Какой толк от динамической линковки при таком раскладе ?
Жесть жосткая! Я считал, что Firefox - самая раздутая программа, но этот ваш Telegram бьёт все рекорды. Боюсь представить сколько памяти он пожирает при работе.
Есть возможность собрать с его с
-flto?И какой самый толстый обьект внутри ELF-а ? Похоже там полноценная виртуальная машина со своей копией Ubuntu. :-)
А после
strip /usr/local/bin/Telegram?Покажите пожалуйста вывод
ldd /usr/local/bin/Telegramиreadelf -a /usr/local/bin/Telegram. Чего-то лишнего туда насовато.PS: У меня Firefox вместе со своим Gecko меньше занимает:
Например, мы хотим найти где объявлена функция printf. Для этого воспользуемся командой grep вызвав её прямо из редактора vi со вставкой результата в редактируемый файл, жмем:
:r! grep -r ’ printf(’ /usr/includeУдаляем лишнее.
Команды ! и r - это классика, их знает каждый пользователь редактора vi.
Я пишу код. Бывает, что очень много. LLM не использую. B c моей точки зрения написание кода это редактирование текста.