Мне вот кажется, что вы в попытке доказать что я неправ постоянно прыгаете с темы на тему.
Давайте сначала, вот ваш тезис:
Линукс своим зоопарком убунтуклонов делает малорентабельным серьёзную разработку коммерческих программ для него...
Я это предложение читаю как: "Разработка под линукс малорентабельная, потому что там зооопарк убунтоклонов".
Я же просто говорю, что проблем клонов преувеличена, особенно при наличии flatpak и AppImage. Да специализированное ПО для работы с медиа (+ игры), жёстко садящееся на дрова определённой ОС, делать не под винду точно малорентабельно. Но не сильно требованое к дровам ПО вполне можно портировать. И речь здесь не столько о буржёях, сколько о РФ софте, особенно в текущих реалиях.
Да это наздоровье. Запустить софт, запиленный для другого дистра, - задача подвластная даже не работнику компании выпускающей тот самый софт. Да это не бесплатно по времени, но подходы есть.
Так а при чём здесь зоопарк? Нет возможности поставить винду, всегда можно поставить пользователю Ubuntu/Kubuntu и чисто под него заточить софт. Все остальные проблемы типа желания использовать astralinux решаются через создание flatpak/appimage для полученных ubuntu приложений
На картинке выше — зарплата, которую требует председатель Firefox, в сравнении с ежегодными потерями пользователей, и НЕТ... График не преувеличен и не приблизителен.
Всё верно, он просто показывает две никак не коррелирующие величины, каждая из которых имеет свою собственную ось Y. Но при этом пытается делать вид, что в этом есть какое-то тайное знание.
Не взлетит. Дело в том, что в отличие от аукциона, работу потом надо работать и рабочий день и его комфортность в разных компаниях может быть сильно разной и вообще быть не связана с ЗП. И опытные кандидаты и опытные интервьюеры из числе будущих коллег пытаются на хорошем собеседовании эти моменты прояснить. А HR о них вообще ничего не знает.
Слушайте, это великолепно. Нашёл для себя лучшее доказательство того, что Си++ не для меня. А можете сделать такое по всем языкам, которые вы поддерживаете?
Никаких специальных языковых конструкций нам не надо! Ни раньше, ни сейчас. Мы сейчас используем LLVM в его каноническом виде. Все, что позволяет LLVM, то доступно и нам. Требование к компилятору, в части упорядочивания команд только одно: команда выдающая результат должна стоять раньше, чем команды потребляющие этот результат. И это не противоречит фон-нейману! Разница в том, что это требование не связано с очередностью исполнения, как у фон-неймана, а связано с идентификацией команд. Т.е. инструмент один, а использование его различно.
ОК. Но ведь как я понимаю выбор конечного алгоритма всё-равно влияет. Ведь можно условно взять более жирный по коду алгоритм, в котором больше образуется параллельных мест при выполнении и он лучше загрузит ваши мультиклетки, но скорее всего он также лучше загрузит и superscalar и VLIW. Другой вопрос, что superscalar, что VLIW имеют низкий предел параллелизма в 4-8 и в 25 инструкций в параллель соответственно, а у вас он может быть существенно выше. Всё верно описал?
Спасибо за подробное описание, для меня лично это всё-равно подвид dataflow, который может содержать радикально разные подходы, но вам видимо виднее.
Давайте уточним некоторые вопросы:
Подход Бабаяна к dataflow требует специальные языковые конструкции, спец. компилятор, запущенный рантайм компилятора для оптимизации "управляющего воздействия" на лету и конечно спец. железа. Я читал ваши статьи, вы когда-то утверждали что вам не требуется чтобы компилятор как-то по особенному упорядочивал команды. Соответственно я полагаю что вам не требуют и спец. языковые конструкции. Это до сих пор так?
Что у вас происходит, если все клетки не получили всех необходимых данных по широковещательной рассылке и находятся все одновременно в состоянии ожидания?
Но ведь это по сути всё-равно подвид dataflow архитектуры. Ведь насколько я понимаю суть dataflow - это что данные диктуют порядок действий, а всё остальное - специфика устройства каждой конкретной архитектуры.
Ну то есть в dataflow вершины явно друг другу рассылают данные, а в мультиклете вместо вершин дуги и они напрямую друг с другом не связаны, а обмениваются информацией через специальную таблицу через которую "ожидают" готовности всех необходимых входных данных?
Подскажите, является ли мультиклеточная архитектура неким подобием реализации идей Бабаяна (Data-flow architechture) в части параллельности: https://arccn.ru/media/babayan_video/
Или это альтернативный взгляд на ту же проблему с совсем другой реализацией?
Современные контроллеры умеют заряжать быстро и нормально. Если вы подключите телефон к более мощной зарядке предназначенной для быстрого заряда вы в среднем чаще столкнётесь с ситуацией, что батарея будет заряжаться быстрее, хотя и в контролируемом производителе ключе. Но тем не менее циклы аккума в этом случае деградировать будут быстрее. Понятно что на каких-то моделях это вообще не будет проявляться, а на каких-то будет.
Всё-таки штатная зарядка она чаще не "быстрая" и бережнее.
Всё-таки в айфонах скорее стоят батареи в среднем на 3 Ач и меньше и в обычном режиме заряда требуется около 12 Вт. И то в режиме умного заряда батареи ток заряда после 80% ёмкости резко снижается.
Кроме того батарея потерявшая даже 20% ёмкости, а это происходит в среднем за год, начинает чудить на морозе, если она не 100% заряжена, что бывает часто. Поэтому в широтах, где бывает нормальная зима, я бы к батареи относился максимально бережно.
Лично для себя всё-таки вижу, что производитель не дурак и лучше всегда использовать или штатную зарядку или зарядку слабее штатной.
Мне вот кажется, что вы в попытке доказать что я неправ постоянно прыгаете с темы на тему.
Давайте сначала, вот ваш тезис:
Я это предложение читаю как: "Разработка под линукс малорентабельная, потому что там зооопарк убунтоклонов".
Я же просто говорю, что проблем клонов преувеличена, особенно при наличии flatpak и AppImage. Да специализированное ПО для работы с медиа (+ игры), жёстко садящееся на дрова определённой ОС, делать не под винду точно малорентабельно. Но не сильно требованое к дровам ПО вполне можно портировать. И речь здесь не столько о буржёях, сколько о РФ софте, особенно в текущих реалиях.
Да это наздоровье. Запустить софт, запиленный для другого дистра, - задача подвластная даже не работнику компании выпускающей тот самый софт. Да это не бесплатно по времени, но подходы есть.
Так а при чём здесь зоопарк? Нет возможности поставить винду, всегда можно поставить пользователю Ubuntu/Kubuntu и чисто под него заточить софт. Все остальные проблемы типа желания использовать astralinux решаются через создание flatpak/appimage для полученных ubuntu приложений
Осталось только ссылку на статистику привести и тогда пазл сложится.
Всё верно, он просто показывает две никак не коррелирующие величины, каждая из которых имеет свою собственную ось Y. Но при этом пытается делать вид, что в этом есть какое-то тайное знание.
Не взлетит. Дело в том, что в отличие от аукциона, работу потом надо работать и рабочий день и его комфортность в разных компаниях может быть сильно разной и вообще быть не связана с ЗП. И опытные кандидаты и опытные интервьюеры из числе будущих коллег пытаются на хорошем собеседовании эти моменты прояснить. А HR о них вообще ничего не знает.
Давно пора сделать платную подписку и перестать финансово зависеть от корпоратов.
Кажется что проще хранить пароли в заметках на телефоне, которые синхронизировать с облаком.
А вставлять через такие приложения: https://gadgetstouse.com/blog/2021/10/01/copy-paste-text-from-android-to-pc-or-vice-versa/
Слушайте, это великолепно. Нашёл для себя лучшее доказательство того, что Си++ не для меня. А можете сделать такое по всем языкам, которые вы поддерживаете?
Да и на собеседованиях можно юзать.
Я использую и то и то, не чувствую себя ущербным.
ОК. Но ведь как я понимаю выбор конечного алгоритма всё-равно влияет. Ведь можно условно взять более жирный по коду алгоритм, в котором больше образуется параллельных мест при выполнении и он лучше загрузит ваши мультиклетки, но скорее всего он также лучше загрузит и superscalar и VLIW. Другой вопрос, что superscalar, что VLIW имеют низкий предел параллелизма в 4-8 и в 25 инструкций в параллель соответственно, а у вас он может быть существенно выше. Всё верно описал?
И да, может ли ваш процессор быть универсальным в теории? Т.е. нет ли для этого каких-то тяжёлых препятствий?
Спасибо за подробное описание, для меня лично это всё-равно подвид dataflow, который может содержать радикально разные подходы, но вам видимо виднее.
Давайте уточним некоторые вопросы:
Подход Бабаяна к dataflow требует специальные языковые конструкции, спец. компилятор, запущенный рантайм компилятора для оптимизации "управляющего воздействия" на лету и конечно спец. железа. Я читал ваши статьи, вы когда-то утверждали что вам не требуется чтобы компилятор как-то по особенному упорядочивал команды. Соответственно я полагаю что вам не требуют и спец. языковые конструкции. Это до сих пор так?
Что у вас происходит, если все клетки не получили всех необходимых данных по широковещательной рассылке и находятся все одновременно в состоянии ожидания?
Но ведь это по сути всё-равно подвид dataflow архитектуры. Ведь насколько я понимаю суть dataflow - это что данные диктуют порядок действий, а всё остальное - специфика устройства каждой конкретной архитектуры.
Ну то есть в dataflow вершины явно друг другу рассылают данные, а в мультиклете вместо вершин дуги и они напрямую друг с другом не связаны, а обмениваются информацией через специальную таблицу через которую "ожидают" готовности всех необходимых входных данных?
Честно говоря не понимаю, прочитал ваш Whitepaper, прочитал https://en.wikipedia.org/wiki/Dataflow и не нашёл радикальных отличий. Может быть вы https://en.wikipedia.org/wiki/Flow-based_programming ?
Подскажите, является ли мультиклеточная архитектура неким подобием реализации идей Бабаяна (Data-flow architechture) в части параллельности: https://arccn.ru/media/babayan_video/
Или это альтернативный взгляд на ту же проблему с совсем другой реализацией?
В Айфонах можно включить умную зарядку, которая очень щадящим образом заряжает от 80% до 100%
Современные контроллеры умеют заряжать быстро и нормально. Если вы подключите телефон к более мощной зарядке предназначенной для быстрого заряда вы в среднем чаще столкнётесь с ситуацией, что батарея будет заряжаться быстрее, хотя и в контролируемом производителе ключе. Но тем не менее циклы аккума в этом случае деградировать будут быстрее. Понятно что на каких-то моделях это вообще не будет проявляться, а на каких-то будет.
Всё-таки штатная зарядка она чаще не "быстрая" и бережнее.
В целом с вами согласен, но...
Всё-таки в айфонах скорее стоят батареи в среднем на 3 Ач и меньше и в обычном режиме заряда требуется около 12 Вт. И то в режиме умного заряда батареи ток заряда после 80% ёмкости резко снижается.
Кроме того батарея потерявшая даже 20% ёмкости, а это происходит в среднем за год, начинает чудить на морозе, если она не 100% заряжена, что бывает часто. Поэтому в широтах, где бывает нормальная зима, я бы к батареи относился максимально бережно.
Лично для себя всё-таки вижу, что производитель не дурак и лучше всегда использовать или штатную зарядку или зарядку слабее штатной.