Идею нейроморфных чипов с деградирующими связями никто не озвучивал ? В статье был освещен момент связанный с тем, что у биологической нейронки нейропластичность со временем деградирует и переобучаться человеку с возрастом становится всё сложнее. Необходимо реализовать такое же поведение искусственных нейронов в самом кремнии как естественный механизм защиты и устаревания. Я где-то читал, что у мемристоров имеется ограниченное число перезаписей и с каждым разом их сложнее и сложнее перезаписывать. Вот на таких мемристорных струтурах и надо строить "позитронный мозг" для больших человекоподобных...
Ключевой недостаток заключается в слабости самой системы инструкции. Это не проблема изначальной концепции, а следствие конкретных решений, заложенных в архитектуру.
А можно по подробнее с этого места ? Какие конкретно технические решения в архитектуре RISC-V Вас не устраивают ? Прошу информацию подавать в сравнении с другими существующими техническими решениями.
"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. :-)
Идею нейроморфных чипов с деградирующими связями никто не озвучивал ? В статье был освещен момент связанный с тем, что у биологической нейронки нейропластичность со временем деградирует и переобучаться человеку с возрастом становится всё сложнее. Необходимо реализовать такое же поведение искусственных нейронов в самом кремнии как естественный механизм защиты и устаревания. Я где-то читал, что у мемристоров имеется ограниченное число перезаписей и с каждым разом их сложнее и сложнее перезаписывать. Вот на таких мемристорных струтурах и надо строить "позитронный мозг" для больших человекоподобных...
А можно по подробнее с этого места ? Какие конкретно технические решения в архитектуре RISC-V Вас не устраивают ? Прошу информацию подавать в сравнении с другими существующими техническими решениями.
Ох ты-ж, какая древность всплыла. :)
"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 меньше занимает: