IT в России и мире в реалиях мирового кризиса

Цитата: DimonT от 12.01.2022 18:17:59зачастую "с гвоздём-десяткой в геометрическом  центре сиденья якобы для выработки правильной посадки")...

Тогда уж "соткой"
Насчёт же например возможности переписать программы под новые архитектуры, "промышленная археология" и в программировании существует наверняка. И когда я вижу в программе 2013 года внутреннее отображение имён в формате 8.3, то самым логичным для меня будет предположить, что люди писавшие эту программу давно мирно отошли в мир иной в окружении скорбящих внуков и правнуков. И никто уже не помнит, что и как там работает.

Цитата: Senya от 12.01.2022 18:28:45Тогда уж "соткой"

"
- Такой маленький, Бэрримор!?
-В диаметра, сэр!".
Тяжелый рабочий день был

Цитата: Senya от 12.01.2022 18:28:45. И когда я вижу в программе 2013 года внутреннее отображение имён в формате 8.3, то самым логичным для меня будет предположить, что люди писавшие эту программу давно мирно отошли в мир иной в окружении скорбящих внуков и правнуков. И никто уже не помнит, что и как там работает.

...или писано "пуганым мамонтом" по привычке. Я вот как юзверь от "8.3" в именах своих личных файлов отошёл только лет восемь назад -  а от "и никакой кириллицы" только два или три

мск – эхо – плющев
передается почти правительственная телеграмма о квч телеграме квч тчк
срочно примите инфо двтч к сожалению зпт ваши ожидания не оправдались вскл
правительство германии всё-таки намерено добиваться ограничения работы телеграма тчк грустный смайлик
срочно примите меры зпт публикуйте колонку dw в знак протеста вскл вскл вскл

Недавно я рассказывала (https://t.me/MariaVl…arova/1518) о том, как Берлин закручивает гайки по поводу мессенджера Tеlegram. Напоминала ещё любителю поискать «зверства российского режима», не иностранному агенту, колумнисту Deutsche Welle (DW) и журналисту «Эха Москвы» Александру Плющеву о том, как он писал о судебных тяжбах с «Телегой» в России буквально следующее: «Российские власти уничтожают свободный интернет». А DW рассказывала о том, как обходить ограничения работы интернет-сервисов. 
Александр Плющев ответил (https://youtu.be/hgOlkzP4jBc?t=501) на выраженную мной надежду на то, что блокировка Telegram в Германии не состоится. Но, похоже, ошибся. А ведь подсказки были - травля и в результате прекращение спутникового вещания RT DE в Германии стали явным признаком введения в этой стране цензуры нового уровня. 
Александр, очень нужна Ваша колонка в DW о зверствах германского режима в отношении мессенджера. Вас точно власти Германии послушают – не зря же платили как интернет-эксперту (DW финансируется Правительством ФРГ). 
На днях Министр внутренних дел Нэнси Фезер в интервью газете Zeit прямо допустила блокировку мессенджера Telegram в стране в случае, если не будет найдено общеевропейское решение по соблюдению требований местного законодательства. А предписания немецких органов власти пока якобы действительно не выполняются. Высказанную угрозу усилил Министр юстиции ФРГ Марко Бушман, который в интервью Bild am Sonntag пригрозил Павлу Дурову многомиллионными штрафами.
Да, официальный Берлин публично объявил войну «Телеге». Иначе квалифицировать скоординированные интервью двух членов федерального правительства невозможно. 
Пора вводить хэштег, символизирующий откат Германии от демократических ценностей, – #ПриМеркельТакогоНеБыло.
Кстати, информация для Telegram:
«Бумажный самолётик» по-немецки – Papierflieger,  а «Цифровое сопротивление» – digitaler Widerstand

https://t.me/MariaVl…arova/1681

Цитата: mse от 12.01.2022 19:28:46От кириллицы до сих пор не отошёл. На днях нарвался что Минтовская родная папка "Документы" с какой-то программой конфликтнула.

Ну с впечатлениями от работы нортоновского Дискдоктора по русским папкам без загруженного руссификатора мало что сравнится.
А рекомендация "никакой кириллицы в путях" минимум для четверти тяжёлых игр актуальна.

Цитата: Senya от 12.01.2022 19:47:36Ну с впечатлениями от работы нортоновского Дискдоктора по русским папкам без загруженного руссификатора мало что сравнится.
А рекомендация "никакой кириллицы в путях" минимум для четверти тяжёлых игр актуальна.

Так и сейчас , хоть и юникод -  пофигу , всё равно нет нет , да и встретишь , что непонимейшен  кириллицу в путях . ... Я уже не обращаю внимания . Везде, где можно, стараюсь обходиться латиницей и старым , добрым 8.3 .

Цитата: DimonT от 12.01.2022 18:17:59Тут не важно  - торопятся чтоб релизнуться до конкурентов или к "закрытию года"/XY-летию Великой Октябрьской Социалистической Революции - всё равно без жесткого ТЗ и вазелина (положенного только при хорошем поведении) будут и "доделаем - когда-нибудь" и "работает - не трожь!". Блоки ППЗУ для ПМК с неисправленными ошибками в прогах но клепаемые  чуть не пятилетки - ведь были.
 А без "капитализма" - массово растут в основном  "лисапеды" (что "от Левши", что отраслевые - всё равно зачастую "с гвоздём-десяткой "соткой" в геометрическом  центре сиденья якобы для выработки правильной посадки")...

У нас разработчики ходят и просят дать доделать, привести хоть в какой-то порядок. Потом затрахиваются тонуть в собственном дерьме под названием "технический долг" и уходят. Приходят следующие... в виду отсутствия документации к лисапедам не сразу понимают, во что вляпались. А когда видят "лисапеды" (когда колеса, например, отвалятся. Ну или там гусеницы к утру надо вместо них приделать...), в ужасе пытаються что-то там переделать "нормально". Потом их берут в оборот начальство с очередным мегапрожектом, и круг замыкается. Результат: клиент жрет говно, мы делаем говно, и зарабатываем мы на этом тоже говно. Надеюсь так не везде. Пока еще надеюсь.

Цитата: Senya от 12.01.2022 19:47:36Ну с впечатлениями от работы нортоновского Дискдоктора по русским папкам без загруженного руссификатора мало что сравнится.
А рекомендация "никакой кириллицы в путях" минимум для четверти тяжёлых игр актуальна.

На самом деле она актуальна ввиду тупого здравого смысла. Пока поддержка альтернативных кодировок была "прибита сбоку" и добавляла сложности общей системе - лучше было без нее. Любая свистоперделка делает хуже. Даже "закон" какой-нибудь на эту тему наверняка есть.

Американская компания Apple зарегистрировала личный кабинет на сайте Роскомнадзора в рамках закона о «приземлении» иностранных IT-компаний, следует из информации на сайте ведомства.
В России с 1 января 2022 г. действует так называемый «закон о приземлении» иностранных компаний (№ 236-ФЗ), принятый в июле прошлого года. Он обязывает зарубежные интернет-компании, суточная аудитория которых превышает 500 000 пользователей, открыть в стране свои уполномоченные представительства. Помимо регистрации на сайте Роскомнадзора они должны разместить на своем сайте форму обратной связи с пользователями из РФ и установить рекомендованный ведомством счетчик посещаемости. Также они должны ограничивать доступ к информации, которая будет признана нарушающей российское законодательство.
Из информации на сайте Роскомнадзора следует, что Apple только зарегистрировала личный кабинет, но не разместила электронную форму и не учредила представительство или юрлицо в России.
За отказ от выполнения требований иностранным компаниям грозит в том числе запрет на распространение рекламы о себе и размещение российскими рекламодателями собственной рекламы на таких ресурсах, запрет на прием платежей от российских физических и юридических лиц, а также маркировка публикуемого в сети контента.

Цитата: бардак с идеями от 15.01.2022 09:21:55Американская компания Apple зарегистрировала личный кабинет на сайте Роскомнадзора в рамках закона о «приземлении» иностранных IT-компаний, следует из информации на сайте ведомства.

Ну вот . а либерашки орали .что огрызок из России уйдёт

Круглый стол «Российское ПО и цифровой суверенитет страны – как это связано?» в МИЦ "Известия"

На Хабре выложен отчет о тестировании инженерного образца Эльбрус-16С с предыдущим поколением и интеловским процем (Core i7-2600).

 Вкратце... Несмотря на технические проблемы с процем и не отлаженность компилятора, Эльбрус-16С показывает увеличение производительности на  33% чем у Эльбрус-8СВ. Но по некоторым задачам всё так же печально...
 А в Этой статье рассмотрено нюансы создания кода для Эльбрус-ов. Читается как хороший детектив.

Цитата: qurvax от 12.01.2022 17:54:36Неа. Корень зла - капитализм. Софт делаеться не для того, чтобы юзверю было хорошо, а для того, чтобы производителю срубить денег. И больше ни для чего.

Не софт для пользователя, а пользователь для софта.
Здесть классическое техническое противоречие. И решено оно чисто по ТРИЗ'овски, без компромиссов – в противоречиях, где есть техническая часть, компромисы не допускаются – выбирается одна сторона противоречия (в данном случае производитель софта важнее его потребителя, т.е. жопочасы работы программистов исключаются) абсолютируется, а проблемы второй стороны решаются по остаточному принципу. Если решаются, конечно.

Цитата: _taras_ от 29.01.2022 14:09:15А в Этой статье рассмотрено нюансы создания кода для Эльбрус-ов. Читается как хороший детектив.

Жить это как процессор общего назначения не будет.  Несколько лет назад я написал здесь, что единственное, что эльбрус будет хорошо крутить, так это аналог "шейдеров" на GLSL - маленькие блоки кода, без сайд эффектов, с линейным кодом, выполняемые многократно и независимо. 


Смотрим на содержимое внутреннего фора - вот это оно и есть. И все пляски в статье, дабы разложить это на широкие команды и задействовать параллельное вычисление в ее рамках. Отсюда борьба с условными и безусловными переходами, inline функций, независимые итерации и прочее.
Любой же реальный софт основан на вызове подпрограмм и ветвлении, то есть на переходе к тому или иному адресу.  Это базовый принцип построения софта - разбиение его на повторно используемые блоки инструкций и переход на них (от функций пользовательских библиотек и до системных вызов ядра ОС - это все адреса для перехода).  И да, заинлайнить системный вызов на этапе компиляции не получится, да и с библиотеками линковка обычно идет не статичная.

Отсюда "атомная" производительность на реальном ПО где дажмп на джампе сидит (но да, 16 ядер - это все-таки 16 ядер, оно быстрее чем. И это не потому, что код индусский - ОНО ВСЕ ТАКОЕ, построенное на передаче управления туда-сюда, иногда еще и в зависимости от действий пользователя.
Но это уже прогресс: в 22 году начали открываться детали и начали задаваться вопросы. И главный вопрос все тот же: способен ли МЦСТ в принципе сделать суперскаляр с конвейером и предсказанием переходов, чтобы непотребством из статьи занимался сам ЦПУ хотя бы на средненьком уровне набивая свою широкую команду?
------
Это не значит, что им нельзя пользоваться - эльбрус просто не то, чем его пытаются представить, вопя про аналговнонет и сравнивая со вполне бытовым i7. Был у PS3, в свое время, такой мега крутой и прогрессивный процессор Cell, в теории, а потом практика внесла свои коррективы.

Цитата: mrt789 от 05.02.2022 00:18:39Любой же реальный софт основан на вызове подпрограмм и ветвлении, то есть на переходе к тому или иному адресу.  Это базовый принцип построения софта - разбиение его на повторно используемые блоки инструкций и переход на них (от функций пользовательских библиотек и до системных вызов ядра ОС - это все адреса для перехода).  И да, заинлайнить системный вызов на этапе компиляции не получится, да и с библиотеками линковка обычно идет не статичная.

По первому выделению:
В отношении ветвления программы бывают очень разные. Где-то много циклов, как в вычислительных алгоритмах, и данные тут, в основном, с плавающей запятой, где-то циклов мало, зато куча условных переходов. И в каждом случае требуется разная стратегия оптимизации и параллелизации, если это возможно. Вряд ли в кремнии можно реализовать то, что можно реализовать на уровне компиляции – банально площади не хватит. Горизонт планирования у кремния крайне мал, а вот программист, что касается циклов, знает еще на этапе программирования, где у него что, как и сколько будет крутиться, даже в случае алгоритмов с выходом из цикла по результату, а не по счетчику. Просто необходимо дать ему возможность сообщать компилятору об этом. Если речь идет о C, то стандарт предусматривает механизм такого общения – прагмы (если речь идет об уровне процессора, то, например в случае x86_64, предусмотрены префиксы, которыми программист может влиять на предсказание вероятности переходов).
И еще – если передача параметров в процедуры идет мимо памяти, т.е через регистры, потерь на вызовы можно избежать, имея два кеша инструкций, инструкции по заполнению которых генерируются компилятором, а не кремнием.
А если еще предусмотреть совместную компиляцию как циклов, так и процедур, которые в них крутятся, то даже объявлять их встраиваемыми (inline) не потребуется – компилятор просто встроит код в тело наиболее оптимальным образом. Кремний этого не сможет никогда.
В идеале нужно использовать несколько специализированных процессоров, код на которые будет раскладывать компилятор.

По второму выделению:
С библиотеками в программах-числодробилках линковка обычно идет как раз статическая, что дает прирост в производительности иногда до 30%, а в ряде случаев и в разы (собственный опыт в отношении использования libm). Динамическая линковка катастрофически отнимает у программы память – даже если вы используете всего одну функцию из динамической библиотеки, динамический компоновщик отобразит в ваше адресное пространство всю библиотеку целиком – он не умеет "выдирать" только тот код, который нужен программе, поскольку ничего не знает об этом и нет механизмов об этом ему сообщить. А в случае статической  компоновки в вашем адресном пространстве окажется только та часть библиотеки, которая будет реально использоваться.

Цитата: adolfus от 08.02.2022 11:30:37По первому выделению:
1. В отношении ветвления....
2. С библиотеками в программах-числодробилках....

1. У кремния есть уникальная абсолютно недостижимая для компилятора особенность - он всегда видит текущее состояние в рантайме. Причем исключительно на своем уровня, где уже нет никаких делений, и где инструкции прикладного ПО ничем не отличаются от инструкций системного.
2. Я не спорю с числодробилками, это всегда пожалуйста. Но как был сказано "программирование начинается там, где заканчивается память" - любой ввод/ввыод (сетевой, файловой, пользовательский), это системный вызовы ядра, ты мимо них не прыгнешь. И ядро статически не слинкуешь со своим софтом (дядя Торвальдс проклянет), соответственно никакой компилятор не залезет внутрь "man 2 read/write/open", которые через цать прокладок приземляются на тот или иной произвольный драйвер. Это база, с махровых времен, когда выделилась ОС и произошло разделение на системное и прикладное ПО.

Цитата: mrt789 от 08.02.2022 19:18:121. У кремния есть уникальная абсолютно недостижимая для компилятора особенность - он всегда видит текущее состояние в рантайме.

Это так, однако видит он совсем немного и только то, что "уже случилось". Что случится, он не видит и надеется только на подсказку со стороны программиста, если он предоставляет программисту такую возможность (x86_64 таки представляет, но на уровне конкретного префиксирования инструкций, но не факт, что компилятор это может сделать сам без участия программиста).
Что касается предсказания "будущего", то у кремния все ветви равновероятны, и только программист и компилятор могут здесь что-то улучшить.
Например, если известно, что компилятор в случае 
if (!cc)
    ex1  // это прямо
else
    ex2  // а тут переход jсс ex2
пускает ex1 прямо, а ex2 через jсс (gcc), то программист может просто на уровне стандартного синтаксиса управлять поведением кремния. А если еще у копмпилятора будет прагма, которая управляет генерацией переходов, то никакой кремний никогда не сравнится с программистом (компилятором).

Цитата: mrt789 от 08.02.2022 19:18:12Но как был сказано "программирование начинается там, где заканчивается память" - любой ввод/ввыод (сетевой, файловой, пользовательский), это системный вызовы ядра, ты мимо них не прыгнешь. И ядро статически не слинкуешь со своим софтом.

Ввод/вывод – это отдельная пестня и вряд ли прикладной программист на что-то тут может влиять, даже если он работает на уровне системных вызовов. С другой стороны у нас есть неблокирующие вызовы на сей счет и даже мультипоточность.
Работа с данными, она выдвигает особые требования. Это та поляна где идет борьба между SQL и ISAM. Тот же оракле, когда подгреб BerkeleyDB, писал  в руководствах, что если схема статична, то использование SQL оправдано только для макетирования – софт с использование bdb будет производительнее в разы и вести себя более предсказуемо, поскольку управление такими ограниченными ресурсами, как память и пропускная способность сетей и каналов ввода/вывода ложатся полность на программиста, который всегда знает больше и детальнее, нежели SQL-компилятор. К сожалению, их клиентура словно в последний раз живет – кроме как быстро выпустить и срубить бабки, в том числе и на распиле, не заинтересована.

Цитата: adolfus от 08.02.2022 11:30:37По первому выделению:
В отношении ветвления программы бывают очень разные. Где-то много циклов, как в вычислительных алгоритмах, и данные тут, в основном, с плавающей запятой, где-то циклов мало, зато куча условных переходов. И .....

Дональд Кнут  "Искусство программирования", на сегодня уже 4 тома....
Гениальная книга, вроде об программировании как искусстве, но в итоге ведёт программирование в категорию высокотехнологичных инженерных дисциплин....

Цитата: adolfus от 08.02.2022 22:49:28Ввод/вывод – это отдельная пестня и вряд ли прикладной программист на что-то тут может влиять, даже если он работает на уровне системных вызовов. С другой стороны у нас есть неблокирующие вызовы на сей счет и даже мультипоточность.
Работа с данными, она выдвигает особые требования. Это та поляна где идет борьба между SQL и ISAM. Тот же оракле, когда подгреб BerkeleyDB, писал  в руководствах, что если схема статична, то использование SQL оправдано только для макетирования – софт с использование bdb будет производительнее в разы и вести себя более предсказуемо, поскольку управление такими ограниченными ресурсами, как память и пропускная способность сетей и каналов ввода/вывода ложатся полность на программиста, который всегда знает больше и детальнее, нежели SQL-компилятор. К сожалению, их клиентура словно в последний раз живет – кроме как быстро выпустить и срубить бабки, в том числе и на распиле, не заинтересована.

Извините эффективность порядка вложения циклов при SQL запросе определяется не столько схемой сколько статистикой распределения данных по находящимся в распоряжении индексам ( execution plan ) А статистика вещь сугубо динамическая изменяющаяся во времени - то что было оптимально месяц назад сегодня может стать уже по-другому в зависимости от накопленных за это время данных в базе. Программист не должен каждый месяц переделывать порядок циклов в запросе ( вообще говоря - во всех запросах ) если конечно ему больше нечем заняться

Цитата: adolfus от 08.02.2022 22:49:28Ввод/вывод – это отдельная пестня и вряд ли прикладной программист на что-то тут может влиять, даже если он работает на уровне системных вызовов.

И точно также ничего не может сделать никакой компилятор. Мир с точки зрения ЦПУ сводится к набору его регистров и шинам данных/адреса. Ничего больше для него не существует. Зато он видит все на живую и может химичить с исполнением инструкций, как угодно может химичить - для него они все едины. Пусть и на очень маленьком отрезке, зато постоянно.
Если же подняться на несколько уровней выше, то у того же МЦСТшного компилятора, при компиляции любого реального софта возникнут ситуации, которые он не может оптимизировать от слов никак и никогда - это системные вызовы (ядро не инлайнится, придется делать переход) и поведение зависящее от ввода/вывода (то есть от тех же системных вызовов), которое никак нельзя предсказать.  А ЦПУ на своем микроуровне будет пытаться химичить и здесь, с каким-то успехом.
Где-то чего-то компилятор оптимизирует, из того что увидит, но в целом результат всегда будет как у 486-переростка при прочих равных. Вот и вся ситуация с эльбрусом. Удваивание количество ядер и снижение техпроцесса здесь ничего принципиально не меняют, только помогают замести ситуацию под ковер.

----

Простыми словами: если во внутренний фор из статьи добавить банальный вывод в консоль, то широкой команде и аппаратным циклам придет пушной зверек, потому что это 100% системный вызов, который еще неизвестно чего будет делать и куда выводить. Сначала да, там будет printf, который можно заинлайнить, но дальше уже будет write.

"Бздынь!" - сказала пила.


И да, основная масса нечислодробильного софта ("все в памяти, в одном массиве") примерно этим же и занята - сеть, файлы, обслуживание пользователя.