Это бессмысленный вопрос без контекста. Ну, какой вопрос — такой и ответ, вот вам пример:
void func(unsigned int a) {
unsigned int * p = &a;
printf("stack: %08X %08X %08X %08X\n", *(p-1), *(p), *(p+1), *(p+2));
}
Выведет на 32-битной платформе адрес возврата из функции, следующее за ним слово — аргумент a и ещё два слова с непонятно чем, использовавшиеся вызывающим кодом. Поскольку контекст вопроса непонятен, этим и ограничимся, ну а так вы можете дальше заняться интерпретацией этих данных по своему усмотрению. Отладчики (gdb), например, умеют даже строить из этих чисел обратный трейс вызовов.
Прошу не забывать: речь про реальный Си, а не про теоретизирования из стандартов или прочие религиозные убеждения. Разумеется, и асм вставки тут тоже можно использовать, если их поддерживает реальный компилятор.
А вот фиг. Microsoft попробовал — и не смог (да, я знаю, он расширял C++, не C, но тут принципиальных отличий нет).
Отличие в том что они хотели вставить привязку к платформе. Эти штуки не очень подходят для заимствования их в gcc, например.
, чем, свой, особый, диалект C или C++.
Так надо не диалект в явном виде а аккуратно небольшими порциями.
Я знаю только clang
Я тоже. Но это не доказательство.
Проще уж взять какой-нибудь Turbo C 2.0
Там ограничение по памяти, например. Да и вообще, по-моему не проще.
Поддрежку имещющегося софта вы не обеспечите
Надо только поддержку формата бинарников и нужные системные вызовы обеспечить. От ОС требуется только изолировать недоверенный софт в гарантированно изолированные среды (с чем и проблема в контексте имеющегося железа), при этом не повредив интерактивности (тут всё програмно решается).
Они сделали синоним с memcpy на memmove для старых программ, если вы ту же самую программу пересоберёте из исходников, получите те же проблемы.
С синонимом тоже проблемы. memcpy раньше был заполнителем памяти по шаблону, например memcpy(p+16, p, 1600) размножит первые 16 байт 100 раз, проблемы могли быть разве что с шаблоном меньше машинного слова. С новым вариантом кроме как ручной цикл ничего видимо нельзя сделать.
По сравнению с десктопной версией — стало намного медленнее.
Кнопки перехода к непрочитанному справа страницы были удобнее (ну и подгружались намного быстрее, но это общая проблема).
Не работает Ctrl+F по комментариям из начала статьи, потому что они не подгружены.
Проведён рефакторинг страниц для ускорения работы сайта. Думаю, пары кликов будет достаточно для того, чтобы оценить скорость работы.
Аналогично — всё стало только медленнее.
Полностью переработан трекер
Теперь он похож на какую-то муть из соцсетей, а хабр всё-таки технический ресурс — уместнее сделать удобным как было раньше.
Ну и предупреждение про "комментировать не чаще чем раз в день" раньше показывалось при кнопке "отправить", а теперь — при попытке что-то написать. Предупреждать заранее это конечно хорошо, но лучше бы не скрывать при этом форму ответа — а то черновик будущего коммента приходится писать в текстовом файле, если сутки ещё не прошли, а у меня есть время на придумываение ответа уже сейчас.
(коммент написан 25 июня, с тех пор больше не пробовал "мобильную" версию)
Нельзя так выразится. Разработку C осуществляют вполне конкретные люди.
"Разработка C" (речь не про компилятор, а про спецификацию языка, писаную ли не писаную) это обобщённое понятие по уже выше указанным причинам.
Если уточнять, есть комитет (вроде бы, один, но никто не мешает появиться равноценному второму), есть авторы gcc, clang, msvc, icc, pcc и ещё кучи менее известных компиляторов.
Любой, кто сделает свой компилятор и как-то окажется популярным — станет влиять на то, что понимается под "Си". Как минимум тем, что есть компилятор Си с его кастомными фичами, как максимум тем что его кастомные фичи будут позаимствованы другими компиляторами (например, gcc) и/или попадут в очередную версию стандарта от комитета.
Если же кто-то сделает альтернативный питон, то в лучшем случае его запомнят как "альтернативный питон от такого-то автора", а вообще скорее всего ему придётся придумывать другое название.
Мне. Я не хочу каждые 2-3 года переписывать свой код только потому, что саботажники захотели всё “типа ускорить”.
Ну, компилятор K&R C написать и поддерживать весьма легко (без оптимизатора, но кажется его наличия нет в задаче). А весь остальной свой код можно будет писать на K&R C и таким образом не переписывать. Как идея?
не сможете запускать никаких программ, кроме тех, что напишите сами.
Такая ОС будет бесполезна, разумеется поддержка имеющегося софта нужна. Ну и js с веба в том числе. Но это оффтоп.
Так вот: у режимов -O0 или -O1 нет никакой спецификаци
Да, формально нету. Я просто предполагаю что неформальная спецификация -O0 будет и дальше такой же. Возможно, зря. Время покажет, но пока что проблем это не создало, а кто-то тратит силы на изучение других языков по теоретическим причинам. Хотя нет, один раз помню сломали memcpy — вместо последовательного копирования от меньших к большим адресам вставили туда какие-то оптимизации. Хотя это не про компилятор а про библиотеку. Ну, я не считаю что трата времени на выявление этой проблемы больше, чем трата времени на другой язык.
Да собственно уже кой-какие трюки в clang -O0 не работают.
Ну, clang мне никогда не нравился, я ещё раньше где-то писал коммент о том как они навязывают свои спорные вкусы (и где-то — неотключаемо опциями) использующим его программистам. Но это проблемы clang-а а не проблемы Си.
А потому что речь шла, внезапно, о программе на C,
Тогда непонятно откуда там отсылка к C++. Видимо, то сообщение писал кто-то кто совсем не в теме и думает что C++ это новая версия C.
Но это не значит, что нет никакой разницы между языком, поддерживаемым одним программистом, Rust'ом, C или, скажем, Python'ом.
Rust — язык одной компании
Python — язык одного программиста с соавторами, плавно превращается в язык одного сообщества
C — общественное достояние, если можно так выразиться
Разница, разумеется, есть. На мой личный взгляд — в пользу C.
поддержка того кода, который был написан 30 с лишним лет назад без каких-либо модификаций.
Зато был модифицирован "компилятор". Такое можно с любым языком провернуть. И повторюсь, нет никакой проблемы организовать сейчас компиляцию K&R C кода полувековой давности на современном железе. Но кому это нужно?
Приходится искать что-нибудь, что разработали другие.
Rust имеет немалые шансы загнуться вместе с Мозиллой. В отлиие от C, который, с принятыми мерами предосторожности (не использовать экзотический синтаксис и предупредить не включать агрессивные оптимизации) скорее всего и через 50 лет скомпилируется успешно и правильно без модификаций.
А всё остальное, что в современных процессорах бывает — неспецифицированное поведение.
В условиях, когда кроме моей программы никто с компом не взаимодействует — возможно там нет ничего страшного, но я просто вспомнил своё аналогичное желание иметь всё под контролем при наличии злонамеренного агента где-то либо непривилегированного на компе, либо в сети — и понял что, даже если я напишу себе идеальную ОС и рабочую среду без единой уязвимости — безнадёжно упрусь в проблемы ширпотребного железа.
Нет, не хватает. Если бы хватало — вам не нужно было бы рассусоливать про -O0 и gcc 4.4.
Большинство тупо ставит -O2 и не парится. И логическую адекватность своего кода проверять не пытаются. До дефектов компилятора им дела тем более нет. Я, разумеется, эту ситуацию не одобряю, но надо признать, что такой факт имеется. И именно для этого большинства обычно всё и делается. Но я не пойму ваше упорное нежелание признавать gcc -O0 или gcc -O1 как способ компиляции, постоянно ссылаетесь на проблемы -O2 только и обобщаете их на "весь язык".
Пример компил/тора ну, скажем, с поддержкой RISC-V и без всей этой мути на тему pointer provenance — в студию
Есть же языки для которых совместимость — важнее скорости.
Ну, тут соглашусь, в Си приоритет скорее в пользу скорости. И хотя на нём можно писать совместимый софт, но на ряде других языков это будет заметно проще. Опять же, кому что больше нужно и нравится.
If you believe pointers are mere addresses, you are not writing C++; you are writing the C of K&R, which is a dead language
Ну так речь не про C++. Про C++ соглашусь — там указатели (идеологически) это не просто адреса. Хотя технически это и адреса. А вот почему противопоставили ему именно K&R C — не знаю.
В конце-концов ведь у нас проблема ведь не в том, что компилятор плох, а в том, что язык превратили в непотребство.
Ну нет. Есть язык например C89, он и через 1000 лет будет таким же как сейчас. А вот поддержка его современными компиляторами может и сломаться (хотя я не думаю что его в обозримое время захотят выкидывать, всё-таки это единственный всем понятный эталон из семейства Си-языков).
А вот против идеологии "C89 или более поздний стандарт, ещё не опубликованный неким комитетом" я категорически возражаю. Потому, что не признаю ни за каким комитетом приоритетное право приватизировать этот язык и самоназываться его руководящей/направляющей силой. Бывают другие ситуации, когда язык является от начала до конца продуктом конкретной организации или даже человека - там за ними можно признать такое право, а тут нет.
Так что, фразы "Си превратили" смысла не имеют, потому что Си сам по себе это не что-то строго конкретное и никогда им не был. Вам могут не нравится конкретные его редакции/реализации/вариации, надо указывать какие.
То есть чинить нужно в первую очередь язык, а уже потом компилятор.
Учитывая сказанное выше, чинить можно либо какую-то из спецификаций (как изданную комитетом, так и изданную авторами компилятора) либо какой-то из компиляторов.
Если документация не описывает как писать на некоем языке и вам явно заявляют, что даже если вы всё будете делать всё, как описано в документации, то гарантий вам всё равно никто никаких не даст… то как на этом языке вообще хоть что-нибудь написать-то?
Согласен, есть такая проблема, боль всех математиков. Они хотят детерминированное и идеально строгое описание, а работать (если выйти за пределы теоретической математики) приходится с приблизительными и негарантированными утверждениями. Где-то эта проблема острее, где-то меньше. Но люди как-то научились жить с этим. Даже логически идеальный компилятор ничего не гарантирует, ведь он запускается на неидеальном процессоре, и программы им скомпилированные тоже запускаются на неидеальном процессоре. Найдёте альтернативу современным процам, без недокументированного поведения (ну, хотя бы почти), с производительностью хотя бы того же порядка, и по схожей цене? Всё дело в том, сколько сил вы готовы вложить в избавление от неожиданного поведения. Повторюсь, большинству хватает уровня документированности и предсказуемости имеющихся компиляторов, а 100% идеал всё равно невозможен.
Корректная программа на C должна либо собираться всеми компиляторами во всех режимах, либо, если она не собирается, разработчики должны приниматься её (или, скорее, краткие выжимки из неё) в качестве багрепорта и править компилятор.
Учитывая сказанное в начале этого коммента: надо уточнить, на какой вариации языка эта программа корректная. И компилировать только теми компиляторами, у которых заявлена поддержка именно этой вариации. Потом уже делать выводы. Да, судя по всему заявленная поддержка C99 у современных компиляторов с -O2 сломана, но это частный случай, и не повод делать максимально общий вывод.
Можно, наверное, написать программу на подмножестве C (например если в программе завести ровно один массив целых чисет и весь алгоритм реализовать на нём, то мало какой компилятор сможет с этим что-либо сделать), но какой смысл?
Не всё так плохо, подмножество можно расширить по чуть урезанного C89.
Проще на другой язык, тогда уже, перейти.
Ну, это кому как, личные предпочтения.
так, чтобы его можно было гарантированно скомпилировать и запустить через 30-40 лет. Где-то в районе 2050го-2060го года, то бишь. Используя акутальные компиляторы и железо для того года.
Тут ни Rust, ни любой другой современный язык гарантий не даст. Никто не знает, какое там будет "актуальное железо" через 40 лет, будет ли оно вообще идеологически совместимо с текущим. Может там везде квантовые компьютеры будут и другая парадигма программирования, ну а старый софт - в эмуляторе запустится, да, вместе с gcc 4.2 для его компиляции. Если же кардинальных перемен не случится, то думаю приведённый выше пример будет и там работать.
Да, ту самую версию из 1983го года. Да, без изменений.
Ну это совсем другое. Кроме того, компилятор для K&R C тоже никто не мешает сделать, кому он только нужен будет кроме как для компиляции древностей?
По поводу аналогии с гвоздями: гвозди обычно покупаются, а разработку компилятора обычно никто не покупает.
Если я у кого-то закажу разработать мне компилятор под мои требования (и не важно, стандарт это или нет, главное что я их чётко пропишу), оплачу (разумеется, большую сумму), а мне потом выдадут какую-то самодеятельность вида "я так вижу" - то на нерадивого исполнителя можно и в суд подать с возвратом предоплаты и компенсацией убытков от потраченного впустую времени ожидания.
Если компилятор есть уже готовый, и продаются лицензии на него - я могу рыночными методами (куплю/не куплю, постановка условий) попытаться повлиять на ход его разработки в нужную сторону. Но если я, как клиент, не буду особо значим для поставщика (например, 99.9% покупателей это не нужно и есть задачи важнее) - мои пожелания закономерно проигнорируют, а делать будут то, что нужно большинству. Подозреваю, что большинству как раз плевать на такие мелочи, проявляющиеся раз в 100 человеко-лет усреднённой разработки - ведь в куче софта авторы плюют даже на пачки варнингов, выдаваемых компилятором на их код.
Если же компилятор готовый и бесплатный, то рычагов влияния на его разработку, кроме как поучаствовать самому (и не фиксить что-то одно, а делать больше, чтобы проекту было невыгодно вас прогонять при разногласиях), вообще практически нет. Как крайний случай - писать полностью своё с нуля, там вам никто не помешает, но сил придётся потратить очень много. Как почти крайний - форкнуть gcc, хотя я не уверен что это проще.
Повторюсь, речь тут идёт не про соответвие стандарту, а про разногласия по поводу того, как должен работать компилятор. Апелляции к стандарту - это лишь один из аргументов, и не более того. Стандарт в Си традиционно был скорее подведением итогов разработки по факту, чем руководством к действию.
Если на C (и C++) нельзя написать корректную программу (а с подходом “нам закон не писан, мы можем творить с вашим кодом всё, что левая пятка пожелает” это, очевидно, невозможно),
Ну, оно не до конца документировано, это да. Кроме того, в компиляторах бывают просто баги. Но всё же, для подавляющего большинства программ особенности компилятора - далеко не на первом месте проблема, особенно с -O0. У кучи популярного софта тупо лезут пачки варнингов при компиляции и авторов это не беспокоит.
Бесполезно. Как мне было объяснено среди саботажников достигнут консенсус: они не собираются соблюдать стандарт и не собираются поддерживать обратную совместимость (кроме поддержки бенчмарков, это святое).
Это неверно. Способы корректно скомпилировать C89 код существуют. Насчёт C99 и C11 точно не знаю, мне как то они в полной реализации не нужны, но думаю тоже существуют (-O0). Если же вам нужно, чтобы один и тот же компилятор с одним и тем же набором флагов корректно компилировал и C89 и C11, да при этом ещё и топовые оптимизации проводил - ну, видимо такого нет. Но это требование намного более сильное, чем просто "написать корректную программу на Си". А переход на другой язык вообще никак не влияет на поддержку новых стандартов Си компиляторами.
В этой ситуации ничего не остаётся, кроме как переходить на другой язык.
Как я уже тут много раз писал Rust кажется подходящим кандидатом.
Подходящий вс же будет тот, который лучше способствует решению поставленной задачи. А вы задачу (утилитарную, а не идеологическую) не сформулировали. Где-то может и Rust лучше. Лично мне для системных и прикладных, но критичных к производительности задач лучший кандидат - Си (кроме тех ныне редких мест где ассемблер), по совокупности причин. Теоретические проблемы с UB я обхожу как описано выше, в итоге ни разу, кроме специальных тестовых примеров, с ними не сталкивался. С артефактом компилирования сталкивался ровно один раз: gcc оптимизировал выражение strlen(x)*k с нулевым k, выкинув вызов strlen, в результате чего прога не падала при x==NULL и стала падать только спустя несколько лет при переходе на более новый компилятор, ну это уже не теоретическая проблема а явный пропущеный баг был. Какая там оптимизация стояла не помню.
Корректная программа должна выдвать всегда один и тот же результат, независимо от оптимизации.
Хорошо, значит -O2 и -fno-strict-* влияют на язык. Но только в плане сужения области его определения. Некоторые программы корректные для -O0 но некорректные для -O2, если же они корректны для обоих случаев то дадут одинаковый результат. А должны, не должны - ну, влияют, таков факт.
А давайте компилятор не будет решать за меня, как мне писать программы?
Компилятор ничего и не решал. Компилятор просто не поддерживает некоторые вещи в -O2, и это были мои советы как обойти проблему, заодно, возможно, попутно улучшив скорость работы и качество кода самого по себе.
Если программа соотвествует стандарту, то она должна работать корректно, если не соотвествует — объясните какое именно правило она нарушает.
С учётом вышеобсуждённого, вполне допускаю, что область применимости -O2 уже, чем стандарт. Но тут никаких выходов, кроме как смириться, не вижу. Тем более что сам я с этим не сталкивался ни разу.
Ссылка на пункт стандарта, где так написано — или заканчиваем дискуссию, извините.
Что написано? Что realloc может быть медленным? Это не пункт стандарта, это реальность. Если realloc действительно сдвинет указатель, ему скорее всего понадобится копировать все байты со старого места на новое, а это трата времени. Если заботитесь о скорости работы софта, желательно сокращать количество таких действий - например делать realloc инкрементами по 30%-100% от прошлого объёма, а не по одному элементу увеличивающегося массива.
так разработчики компиляторов очень-очень любят прикрываться стандартом
так, внезапно, оказывается, что соблюдать его необязательно.
Нет уж. Извините. Либо крестик, либо трусы.
Я, если что, нигде не высказывал одобрения всему этому, так что не надо меня ставить на их сторону и на этом основании нападать. Я только указал свои соображения по поводу того, как жить в имеющейся ситуации (разумеется, ваше право их учесть или не учесть). Ругаться с разработчиками компиляторов считаю нецелесообразным, они тоже мне ничем не обязаны, могу выбрать наиболее подходящий из имеющихся либо попробовать написать свой.
давайте тогда объясняйте с какого перепугу вы считаете, что проверка if (x + 1 < x) должна быть выкинута без аппеляции к стандарту.
Ну тут могу предположить, что ответ будет такой: мы вам дали опцию чтобы выкидывать такие проверки, а включать или не включать её - на ваш выбор. Опция по дефолту включена в -O2, потому что нам показалось это уместным, но мы ни в коем случае вас не заставляем, и можно сделать и -O2 без неё, если дописать -fno-strict-overflow.
Вы уж меня извините, но ни -O2, ни даже-fno-strict-aliasing на язык влиять не должны. По крайней мере так утверждают разработчики компиляторов.
Не особо понятное утверждение. На язык они и не влияют. Влияют на конвертацию языка в машинный код. Ну и, в частности, не видел подобных утверждений (как в цитате) от разработчиков компиляторов.
Да, Си с -O2 и Си с -O0/-O1 можно считать существенно разными режимами компиляции, что бы там кто ни говорил. Предсказуемая построчная конвертация (причём - в обе стороны) C <-> ASM - это именно про -O0/-O1 (хотя кажется этот самый известный режим нигде не стандартизирован, но по факту он есть во всех компиляторах). -O2/-O3 это неидеальная эмуляция логики обычного Си, работающая в некоторых стандартизированных рамках, за пределами которых начинается UB.
Если, например, у тебя структура имеет внутри себя указатели и она была “передвинута”,
Ну примерно такое и предполагал. Если до этого дошло, то и правда придётся проверять. Но если посмотреть глобальнее, то это ведь вопрос общей идеологии работы кода. А точно ли структуру нужно организовывать с указателями внутри? Ведь есть альтернатива, и не одна, и заранее утверждать что тупо указатели будут быстрейшим вариантом - нельзя. А точно ли именно тут нужен realloc (если вообще нужен)? А может, лучше оптимизировать код так, чтобы realloc вызывался реже, и когда он уж вызвался, переписывание указателей было незначительной погрешностью к затраченному времени? Да, скорее всего при этом потратится чуточку больше памяти (а может и нет), но зато скорость вырастет (при любой логике компилятора), потому что realloc сам по себе накладен.
Не поможет. Этот код с realloc полностью соотвествует C89.
Ну, тут тогда уступаю и соглашаюсь.
Вариант “используйте -O1” на долгосроке работать, увы, не будет: сейчас просто все бенчмарки гоняются с -O2/-O3
Ну, как я писал - с моим кодом почему-то -O1 и -O2 почти всегда одинаковые, а -O3 иногда чуть отличается, причём заранее неизвестно в какую сторону. Может быть, потому что я не пытаюсь грузить всеми оптимизациями компилятор, а пишу так, чтобы лишних действий и в исходнике было по-минимуму? Всякие отладочные ветки, которые на самом деле не должны выполняться, можно отключать препроцессором (например assert так и работает) а не оптимизатором. Не-отладочные ветки, которые на самом деле никогда не выполняются - это проблема и запутанного исходника, а не только оптимизаций. Бенчмарки числодробилок пусть и будут на максимальном (из полезных) уровне оптимизации, но realloc'ам "на авось" там не место. А в прикладной логике супер-оптимизации не нужны.
Нехорошо так делать, все аргументы указаны, кроме -O2. У меня, пока я не прочёл комменты ниже и не открыл ссылку, было впечатление что там дефолтное, т.е. -O0.
Ну да, с -O2 он не ассемблер, поэтому не надо пихать его везде, где не требуется жёсткая оптимизация. Ну или хотя бы делать -O2 -fno-strict-aliasing -fno-strict-overflow (большинство проблем -O2 именно в этих двух флагах). Ну а те куски кода, где забота о производительности по-максимуму отдана компилятору - тщательно проверять на соответствие формальному стандарту.
Кстати, экспериментируя с уровнями оптимизации (gcc) для своего кода, заметил: между -O0 и -O1 разница большая почти всегда (до полутора а может где-то и двух раз), а вот -O1, -O2 и -O3 всё примерно одно и то же. Иногда -O3 чуть лучше остальных (на какие-нить 10%), иногда даже почему-то чуть медленнее. Это всё для меня ещё один аргумент не использовать -O2 и выше без острой нужды, а если и использовать - то, во-первых, удостоверившись, что он действительно именно тут даст прирост, а во-вторых тщательно проверяя код на формальные придирки.
Касательно realloc() - почему-то ни разу не было ситуации, что надо проверять изменился ли указатель. По-моему лучше писать код, не зависящий от этого. Понятное дело, подобная проверка может появиться как попытка программиста что-то оптимизировать (иначе можно всегда делать вид что указатель изменился), но видимо надо писать так, чтобы realloc() и код вокруг него не становился узким местом.
Максимальная вероятность проведения успешного дня среди разработчиков достигала 99%, причем в этом случае встречи проводились не чаще одного раза в день или их вообще не было
в день
Я удивлён, что измеряется количество именно "в день". Разумнее было бы измерять "в неделю", причём числа больше 5 — это вообще по-моему за гранью разума и не предмет рассмотрения всерьёз, а адекватное — 1-2.
Лучший экземпляр — 1023 мВтч, худший — 925 мВтч. Разница 9.5%. Девять с половиной процентов, Карл!
Как будто это важно. Разброс в цене между двумя магазинами может быть больше.
Это означает, что когда тестируется по одному экземпляру батареек и делается вывод, что батарейка бренда «А» на 5% лучше батарейки бренда «Б» всё зависит от попавшегося экземпляра.
А 5% тем более не важны.
По названию статьи я подумал что там разброс в 2 раза неожиданно обнаружился, а то и больше.
Если речь шла про устройства хранения информации, то тут про них речь и идёт, всё верно.
Хотя конечно технология хранения другая и даже ещё не реализованная как я понял.
Или реь шла именно про устройства с магнитным вращающимся диском и магнитными головками?
В зависимости от методологии расчёта, хранение данных в собственных дата-центрах Internet Archive обходятся в 2−5 раз дешевле, чем в облаке.
но
Есть подозрение, что рано или поздно наступит момент, когда сложность поддержания своей инфраструктуры превысит некий порог — и библиотека откажется от собственных дата-центров.
Вы уж определитесь. Чем больше проект, тем наоборот выгоднее его хостить на своих серверах.
Печально, а я её как хорошую организацию воспринимал.
Проект Debian
Надеюсь примут правильное решение, хотя печально что они вообще начали этот бред обсуждать.
Остальные то из списка особого доверия и так не вызывали.
Я если что не фанат Столлмана и даже скорее предпочту BSD-лицензию его GPL, но в праве на публичное выражение и популяризацию своих идеалов, в том числе с помощью организации, созданной им же и для как раз этих целей, ему точно нельзя отказывать.
Если же окажется, что дело и правда не в его СПО-политике (но прикрываясь чем-то другим), а в тех надуманных обвинениях непонятно в чём, то "обвинители" вообще предстают какими-то умственно отсталыми, странно как они смогли работать в ИТ-компаниях.
Эм. Самый очевидный и простой способ распознавания асимметричного пинга — это вовсе не таймстампы, а трассировка. Так как асимметричный пинг, как верно замечено в статье, обычно является следствием асимметричного маршрута — достаточно изучить маршрут (и пинги до всех его узлов) чтобы всё понять.
Если же маршрут симметричный, или по какой-то причине его невозможно исследовать, то всё может оказаться не так радужно, как думает автор. Если время на серверах синхронизируется через тот же канал с ассиметричным пингом — то ничего из этого не получится. В таком случае (не имея доп. каналов связи) невозможно (строго невозможно) отличить симметричный пинг 50+50 и правильное время "там" от пинга 70(туда)+30(обратно) и отстающего на 20мс времени "там".
Кубики сами по себе конечно не стоит есть в больших количествах, но вроде никто так и не делает. Хотя бы потому, что они повредят уже пищеварительную систему недостатком воды. А если их разбавить/запивать — сахар уже получается не чистый (но и сахарную воду просто так тоже мало кто пьёт). Дальше уже надо выяснять, в какой именно форме (сахароза, глюкоза, фруктоза), в каком количестве и с какими именно сопровождающими веществами его употреблять наиболее желательно (с учётом состояния здоровья принимающего). Тут уже вопрос переходит в количественную плоскость, а не в качественную ("сахар это плохо") как некоторые пытаются представить.
Да, вероятно в составе вкусных природных его источников сахар наиболее благоприятен для организма, потому что организм за миллионы лет приспособился именно из этих источников его получать. Но не всегда есть возможность питаться исключительно свежесорванными с дерева фруктами (по множеству разных причин), поэтому можно рассмотреть и другие варианты.
Чтобы не было нарушений, надо поддерживать нормальную физическую активость. Что с сахаром, что без (но вообще, в таких условиях сахар весьма полезен). Ну а если круглосуточно находиться на диване (ночью — спать, днём — за компом), то да, всё и так плохо, а тут ещё задачу по утилизации ненужной энергии подкидывают.
Они (алгоритмы гос шифрования) и так давно open source (и вобщем-то по самым пессимистическим оценкам на качественную и быструю реализацию именно алгоритма у компетентного программиста уйдёт никак не больше месяца, а скорее всего и меньше недели — считайте бюджет).
Осталось только интегрировать их в официальные версии open source клиентского и серверного софта. Это задача чуть посложнее (и не только программистам но и бюрократам), но тоже, в масштабах государства, копеечная. Проблема исключительно в том что сейчас эту задачу рассматривают не как что-то нужное стране, а как способ получить финансирование всяким мутным конторам.
Это бессмысленный вопрос без контекста. Ну, какой вопрос — такой и ответ, вот вам пример:
Выведет на 32-битной платформе адрес возврата из функции, следующее за ним слово — аргумент
aи ещё два слова с непонятно чем, использовавшиеся вызывающим кодом. Поскольку контекст вопроса непонятен, этим и ограничимся, ну а так вы можете дальше заняться интерпретацией этих данных по своему усмотрению. Отладчики (gdb), например, умеют даже строить из этих чисел обратный трейс вызовов.Прошу не забывать: речь про реальный Си, а не про теоретизирования из стандартов или прочие религиозные убеждения. Разумеется, и асм вставки тут тоже можно использовать, если их поддерживает реальный компилятор.
Отличие в том что они хотели вставить привязку к платформе. Эти штуки не очень подходят для заимствования их в gcc, например.
Так надо не диалект в явном виде а аккуратно небольшими порциями.
Я тоже. Но это не доказательство.
Там ограничение по памяти, например. Да и вообще, по-моему не проще.
Надо только поддержку формата бинарников и нужные системные вызовы обеспечить. От ОС требуется только изолировать недоверенный софт в гарантированно изолированные среды (с чем и проблема в контексте имеющегося железа), при этом не повредив интерактивности (тут всё програмно решается).
С синонимом тоже проблемы. memcpy раньше был заполнителем памяти по шаблону, например
memcpy(p+16, p, 1600)размножит первые 16 байт 100 раз, проблемы могли быть разве что с шаблоном меньше машинного слова. С новым вариантом кроме как ручной цикл ничего видимо нельзя сделать.По сравнению с десктопной версией — стало намного медленнее.
Кнопки перехода к непрочитанному справа страницы были удобнее (ну и подгружались намного быстрее, но это общая проблема).
Не работает Ctrl+F по комментариям из начала статьи, потому что они не подгружены.
Аналогично — всё стало только медленнее.
Теперь он похож на какую-то муть из соцсетей, а хабр всё-таки технический ресурс — уместнее сделать удобным как было раньше.
Ну и предупреждение про "комментировать не чаще чем раз в день" раньше показывалось при кнопке "отправить", а теперь — при попытке что-то написать. Предупреждать заранее это конечно хорошо, но лучше бы не скрывать при этом форму ответа — а то черновик будущего коммента приходится писать в текстовом файле, если сутки ещё не прошли, а у меня есть время на придумываение ответа уже сейчас.
(коммент написан 25 июня, с тех пор больше не пробовал "мобильную" версию)
"Разработка C" (речь не про компилятор, а про спецификацию языка, писаную ли не писаную) это обобщённое понятие по уже выше указанным причинам.
Если уточнять, есть комитет (вроде бы, один, но никто не мешает появиться равноценному второму), есть авторы gcc, clang, msvc, icc, pcc и ещё кучи менее известных компиляторов.
Любой, кто сделает свой компилятор и как-то окажется популярным — станет влиять на то, что понимается под "Си". Как минимум тем, что есть компилятор Си с его кастомными фичами, как максимум тем что его кастомные фичи будут позаимствованы другими компиляторами (например, gcc) и/или попадут в очередную версию стандарта от комитета.
Если же кто-то сделает альтернативный питон, то в лучшем случае его запомнят как "альтернативный питон от такого-то автора", а вообще скорее всего ему придётся придумывать другое название.
Ну, компилятор K&R C написать и поддерживать весьма легко (без оптимизатора, но кажется его наличия нет в задаче). А весь остальной свой код можно будет писать на K&R C и таким образом не переписывать. Как идея?
Такая ОС будет бесполезна, разумеется поддержка имеющегося софта нужна. Ну и js с веба в том числе. Но это оффтоп.
Да, формально нету. Я просто предполагаю что неформальная спецификация -O0 будет и дальше такой же. Возможно, зря. Время покажет, но пока что проблем это не создало, а кто-то тратит силы на изучение других языков по теоретическим причинам. Хотя нет, один раз помню сломали memcpy — вместо последовательного копирования от меньших к большим адресам вставили туда какие-то оптимизации. Хотя это не про компилятор а про библиотеку. Ну, я не считаю что трата времени на выявление этой проблемы больше, чем трата времени на другой язык.
Ну, clang мне никогда не нравился, я ещё раньше где-то писал коммент о том как они навязывают свои спорные вкусы (и где-то — неотключаемо опциями) использующим его программистам. Но это проблемы clang-а а не проблемы Си.
Тогда непонятно откуда там отсылка к C++. Видимо, то сообщение писал кто-то кто совсем не в теме и думает что C++ это новая версия C.
Rust — язык одной компании
Python — язык одного программиста с соавторами, плавно превращается в язык одного сообщества
C — общественное достояние, если можно так выразиться
Разница, разумеется, есть. На мой личный взгляд — в пользу C.
Зато был модифицирован "компилятор". Такое можно с любым языком провернуть. И повторюсь, нет никакой проблемы организовать сейчас компиляцию K&R C кода полувековой давности на современном железе. Но кому это нужно?
Rust имеет немалые шансы загнуться вместе с Мозиллой. В отлиие от C, который, с принятыми мерами предосторожности (не использовать экзотический синтаксис и предупредить не включать агрессивные оптимизации) скорее всего и через 50 лет скомпилируется успешно и правильно без модификаций.
В условиях, когда кроме моей программы никто с компом не взаимодействует — возможно там нет ничего страшного, но я просто вспомнил своё аналогичное желание иметь всё под контролем при наличии злонамеренного агента где-то либо непривилегированного на компе, либо в сети — и понял что, даже если я напишу себе идеальную ОС и рабочую среду без единой уязвимости — безнадёжно упрусь в проблемы ширпотребного железа.
Большинство тупо ставит -O2 и не парится. И логическую адекватность своего кода проверять не пытаются. До дефектов компилятора им дела тем более нет. Я, разумеется, эту ситуацию не одобряю, но надо признать, что такой факт имеется. И именно для этого большинства обычно всё и делается. Но я не пойму ваше упорное нежелание признавать
gcc -O0илиgcc -O1как способ компиляции, постоянно ссылаетесь на проблемы -O2 только и обобщаете их на "весь язык".Не в курсе. Но быстро нашлось такое: https://github.com/riscv/riscv-gnu-toolchain Там нету режима
-O0?Ну, тут соглашусь, в Си приоритет скорее в пользу скорости. И хотя на нём можно писать совместимый софт, но на ряде других языков это будет заметно проще. Опять же, кому что больше нужно и нравится.
Ну так речь не про C++. Про C++ соглашусь — там указатели (идеологически) это не просто адреса. Хотя технически это и адреса. А вот почему противопоставили ему именно K&R C — не знаю.
Ну нет. Есть язык например C89, он и через 1000 лет будет таким же как сейчас. А вот поддержка его современными компиляторами может и сломаться (хотя я не думаю что его в обозримое время захотят выкидывать, всё-таки это единственный всем понятный эталон из семейства Си-языков).
А вот против идеологии "C89 или более поздний стандарт, ещё не опубликованный неким комитетом" я категорически возражаю. Потому, что не признаю ни за каким комитетом приоритетное право приватизировать этот язык и самоназываться его руководящей/направляющей силой. Бывают другие ситуации, когда язык является от начала до конца продуктом конкретной организации или даже человека - там за ними можно признать такое право, а тут нет.
Так что, фразы "Си превратили" смысла не имеют, потому что Си сам по себе это не что-то строго конкретное и никогда им не был. Вам могут не нравится конкретные его редакции/реализации/вариации, надо указывать какие.
Учитывая сказанное выше, чинить можно либо какую-то из спецификаций (как изданную комитетом, так и изданную авторами компилятора) либо какой-то из компиляторов.
Согласен, есть такая проблема, боль всех математиков. Они хотят детерминированное и идеально строгое описание, а работать (если выйти за пределы теоретической математики) приходится с приблизительными и негарантированными утверждениями. Где-то эта проблема острее, где-то меньше. Но люди как-то научились жить с этим. Даже логически идеальный компилятор ничего не гарантирует, ведь он запускается на неидеальном процессоре, и программы им скомпилированные тоже запускаются на неидеальном процессоре. Найдёте альтернативу современным процам, без недокументированного поведения (ну, хотя бы почти), с производительностью хотя бы того же порядка, и по схожей цене? Всё дело в том, сколько сил вы готовы вложить в избавление от неожиданного поведения. Повторюсь, большинству хватает уровня документированности и предсказуемости имеющихся компиляторов, а 100% идеал всё равно невозможен.
Учитывая сказанное в начале этого коммента: надо уточнить, на какой вариации языка эта программа корректная. И компилировать только теми компиляторами, у которых заявлена поддержка именно этой вариации. Потом уже делать выводы. Да, судя по всему заявленная поддержка C99 у современных компиляторов с -O2 сломана, но это частный случай, и не повод делать максимально общий вывод.
Не всё так плохо, подмножество можно расширить по чуть урезанного C89.
Ну, это кому как, личные предпочтения.
Тут ни Rust, ни любой другой современный язык гарантий не даст. Никто не знает, какое там будет "актуальное железо" через 40 лет, будет ли оно вообще идеологически совместимо с текущим. Может там везде квантовые компьютеры будут и другая парадигма программирования, ну а старый софт - в эмуляторе запустится, да, вместе с gcc 4.2 для его компиляции. Если же кардинальных перемен не случится, то думаю приведённый выше пример будет и там работать.
Ну это совсем другое. Кроме того, компилятор для K&R C тоже никто не мешает сделать, кому он только нужен будет кроме как для компиляции древностей?
По поводу аналогии с гвоздями: гвозди обычно покупаются, а разработку компилятора обычно никто не покупает.
Если я у кого-то закажу разработать мне компилятор под мои требования (и не важно, стандарт это или нет, главное что я их чётко пропишу), оплачу (разумеется, большую сумму), а мне потом выдадут какую-то самодеятельность вида "я так вижу" - то на нерадивого исполнителя можно и в суд подать с возвратом предоплаты и компенсацией убытков от потраченного впустую времени ожидания.
Если компилятор есть уже готовый, и продаются лицензии на него - я могу рыночными методами (куплю/не куплю, постановка условий) попытаться повлиять на ход его разработки в нужную сторону. Но если я, как клиент, не буду особо значим для поставщика (например, 99.9% покупателей это не нужно и есть задачи важнее) - мои пожелания закономерно проигнорируют, а делать будут то, что нужно большинству. Подозреваю, что большинству как раз плевать на такие мелочи, проявляющиеся раз в 100 человеко-лет усреднённой разработки - ведь в куче софта авторы плюют даже на пачки варнингов, выдаваемых компилятором на их код.
Если же компилятор готовый и бесплатный, то рычагов влияния на его разработку, кроме как поучаствовать самому (и не фиксить что-то одно, а делать больше, чтобы проекту было невыгодно вас прогонять при разногласиях), вообще практически нет. Как крайний случай - писать полностью своё с нуля, там вам никто не помешает, но сил придётся потратить очень много. Как почти крайний - форкнуть gcc, хотя я не уверен что это проще.
Повторюсь, речь тут идёт не про соответвие стандарту, а про разногласия по поводу того, как должен работать компилятор. Апелляции к стандарту - это лишь один из аргументов, и не более того. Стандарт в Си традиционно был скорее подведением итогов разработки по факту, чем руководством к действию.
Ну, оно не до конца документировано, это да. Кроме того, в компиляторах бывают просто баги. Но всё же, для подавляющего большинства программ особенности компилятора - далеко не на первом месте проблема, особенно с -O0. У кучи популярного софта тупо лезут пачки варнингов при компиляции и авторов это не беспокоит.
Это неверно. Способы корректно скомпилировать C89 код существуют. Насчёт C99 и C11 точно не знаю, мне как то они в полной реализации не нужны, но думаю тоже существуют (-O0). Если же вам нужно, чтобы один и тот же компилятор с одним и тем же набором флагов корректно компилировал и C89 и C11, да при этом ещё и топовые оптимизации проводил - ну, видимо такого нет. Но это требование намного более сильное, чем просто "написать корректную программу на Си". А переход на другой язык вообще никак не влияет на поддержку новых стандартов Си компиляторами.
Подходящий вс же будет тот, который лучше способствует решению поставленной задачи. А вы задачу (утилитарную, а не идеологическую) не сформулировали. Где-то может и Rust лучше. Лично мне для системных и прикладных, но критичных к производительности задач лучший кандидат - Си (кроме тех ныне редких мест где ассемблер), по совокупности причин. Теоретические проблемы с UB я обхожу как описано выше, в итоге ни разу, кроме специальных тестовых примеров, с ними не сталкивался. С артефактом компилирования сталкивался ровно один раз: gcc оптимизировал выражение strlen(x)*k с нулевым k, выкинув вызов strlen, в результате чего прога не падала при x==NULL и стала падать только спустя несколько лет при переходе на более новый компилятор, ну это уже не теоретическая проблема а явный пропущеный баг был. Какая там оптимизация стояла не помню.
Хорошо, значит -O2 и -fno-strict-* влияют на язык. Но только в плане сужения области его определения. Некоторые программы корректные для -O0 но некорректные для -O2, если же они корректны для обоих случаев то дадут одинаковый результат. А должны, не должны - ну, влияют, таков факт.
Компилятор ничего и не решал. Компилятор просто не поддерживает некоторые вещи в -O2, и это были мои советы как обойти проблему, заодно, возможно, попутно улучшив скорость работы и качество кода самого по себе.
С учётом вышеобсуждённого, вполне допускаю, что область применимости -O2 уже, чем стандарт. Но тут никаких выходов, кроме как смириться, не вижу. Тем более что сам я с этим не сталкивался ни разу.
Что написано? Что realloc может быть медленным? Это не пункт стандарта, это реальность. Если realloc действительно сдвинет указатель, ему скорее всего понадобится копировать все байты со старого места на новое, а это трата времени. Если заботитесь о скорости работы софта, желательно сокращать количество таких действий - например делать realloc инкрементами по 30%-100% от прошлого объёма, а не по одному элементу увеличивающегося массива.
Я, если что, нигде не высказывал одобрения всему этому, так что не надо меня ставить на их сторону и на этом основании нападать. Я только указал свои соображения по поводу того, как жить в имеющейся ситуации (разумеется, ваше право их учесть или не учесть). Ругаться с разработчиками компиляторов считаю нецелесообразным, они тоже мне ничем не обязаны, могу выбрать наиболее подходящий из имеющихся либо попробовать написать свой.
Ну тут могу предположить, что ответ будет такой: мы вам дали опцию чтобы выкидывать такие проверки, а включать или не включать её - на ваш выбор. Опция по дефолту включена в -O2, потому что нам показалось это уместным, но мы ни в коем случае вас не заставляем, и можно сделать и -O2 без неё, если дописать -fno-strict-overflow.
Не особо понятное утверждение. На язык они и не влияют. Влияют на конвертацию языка в машинный код. Ну и, в частности, не видел подобных утверждений (как в цитате) от разработчиков компиляторов.
Да, Си с -O2 и Си с -O0/-O1 можно считать существенно разными режимами компиляции, что бы там кто ни говорил. Предсказуемая построчная конвертация (причём - в обе стороны) C <-> ASM - это именно про -O0/-O1 (хотя кажется этот самый известный режим нигде не стандартизирован, но по факту он есть во всех компиляторах). -O2/-O3 это неидеальная эмуляция логики обычного Си, работающая в некоторых стандартизированных рамках, за пределами которых начинается UB.
Ну примерно такое и предполагал. Если до этого дошло, то и правда придётся проверять. Но если посмотреть глобальнее, то это ведь вопрос общей идеологии работы кода. А точно ли структуру нужно организовывать с указателями внутри? Ведь есть альтернатива, и не одна, и заранее утверждать что тупо указатели будут быстрейшим вариантом - нельзя. А точно ли именно тут нужен realloc (если вообще нужен)? А может, лучше оптимизировать код так, чтобы realloc вызывался реже, и когда он уж вызвался, переписывание указателей было незначительной погрешностью к затраченному времени? Да, скорее всего при этом потратится чуточку больше памяти (а может и нет), но зато скорость вырастет (при любой логике компилятора), потому что realloc сам по себе накладен.
Ну, тут тогда уступаю и соглашаюсь.
Ну, как я писал - с моим кодом почему-то -O1 и -O2 почти всегда одинаковые, а -O3 иногда чуть отличается, причём заранее неизвестно в какую сторону. Может быть, потому что я не пытаюсь грузить всеми оптимизациями компилятор, а пишу так, чтобы лишних действий и в исходнике было по-минимуму? Всякие отладочные ветки, которые на самом деле не должны выполняться, можно отключать препроцессором (например assert так и работает) а не оптимизатором. Не-отладочные ветки, которые на самом деле никогда не выполняются - это проблема и запутанного исходника, а не только оптимизаций. Бенчмарки числодробилок пусть и будут на максимальном (из полезных) уровне оптимизации, но realloc'ам "на авось" там не место. А в прикладной логике супер-оптимизации не нужны.
Нехорошо так делать, все аргументы указаны, кроме
-O2. У меня, пока я не прочёл комменты ниже и не открыл ссылку, было впечатление что там дефолтное, т.е.-O0.Ну да, с
-O2он не ассемблер, поэтому не надо пихать его везде, где не требуется жёсткая оптимизация. Ну или хотя бы делать-O2 -fno-strict-aliasing -fno-strict-overflow(большинство проблем -O2 именно в этих двух флагах). Ну а те куски кода, где забота о производительности по-максимуму отдана компилятору - тщательно проверять на соответствие формальному стандарту.Кстати, экспериментируя с уровнями оптимизации (gcc) для своего кода, заметил: между
-O0и-O1разница большая почти всегда (до полутора а может где-то и двух раз), а вот-O1,-O2и-O3всё примерно одно и то же. Иногда-O3чуть лучше остальных (на какие-нить 10%), иногда даже почему-то чуть медленнее. Это всё для меня ещё один аргумент не использовать-O2и выше без острой нужды, а если и использовать - то, во-первых, удостоверившись, что он действительно именно тут даст прирост, а во-вторых тщательно проверяя код на формальные придирки.Касательно
realloc()- почему-то ни разу не было ситуации, что надо проверять изменился ли указатель. По-моему лучше писать код, не зависящий от этого. Понятное дело, подобная проверка может появиться как попытка программиста что-то оптимизировать (иначе можно всегда делать вид что указатель изменился), но видимо надо писать так, чтобыrealloc()и код вокруг него не становился узким местом.Я удивлён, что измеряется количество именно "в день". Разумнее было бы измерять "в неделю", причём числа больше 5 — это вообще по-моему за гранью разума и не предмет рассмотрения всерьёз, а адекватное — 1-2.
Как будто это важно. Разброс в цене между двумя магазинами может быть больше.
А 5% тем более не важны.
По названию статьи я подумал что там разброс в 2 раза неожиданно обнаружился, а то и больше.
Если речь шла про устройства хранения информации, то тут про них речь и идёт, всё верно.
Хотя конечно технология хранения другая и даже ещё не реализованная как я понял.
Или реь шла именно про устройства с магнитным вращающимся диском и магнитными головками?
Тогда постройте свой новый в регионе с дешёвым электричеством.
но
Вы уж определитесь. Чем больше проект, тем наоборот выгоднее его хостить на своих серверах.
Печально, а я её как хорошую организацию воспринимал.
Надеюсь примут правильное решение, хотя печально что они вообще начали этот бред обсуждать.
Остальные то из списка особого доверия и так не вызывали.
Я если что не фанат Столлмана и даже скорее предпочту BSD-лицензию его GPL, но в праве на публичное выражение и популяризацию своих идеалов, в том числе с помощью организации, созданной им же и для как раз этих целей, ему точно нельзя отказывать.
Если же окажется, что дело и правда не в его СПО-политике (но прикрываясь чем-то другим), а в тех надуманных обвинениях непонятно в чём, то "обвинители" вообще предстают какими-то умственно отсталыми, странно как они смогли работать в ИТ-компаниях.
Эм. Самый очевидный и простой способ распознавания асимметричного пинга — это вовсе не таймстампы, а трассировка. Так как асимметричный пинг, как верно замечено в статье, обычно является следствием асимметричного маршрута — достаточно изучить маршрут (и пинги до всех его узлов) чтобы всё понять.
Если же маршрут симметричный, или по какой-то причине его невозможно исследовать, то всё может оказаться не так радужно, как думает автор. Если время на серверах синхронизируется через тот же канал с ассиметричным пингом — то ничего из этого не получится. В таком случае (не имея доп. каналов связи) невозможно (строго невозможно) отличить симметричный пинг 50+50 и правильное время "там" от пинга 70(туда)+30(обратно) и отстающего на 20мс времени "там".
alexxz
В большинстве случаев можно обойтись анализом аномалий в пингах к узлам прямого маршрута. Ещё можно TTL эхо-ответов учитывать, но и это редко нужно.
А, я наверно недооценил оговорку
Кубики сами по себе конечно не стоит есть в больших количествах, но вроде никто так и не делает. Хотя бы потому, что они повредят уже пищеварительную систему недостатком воды. А если их разбавить/запивать — сахар уже получается не чистый (но и сахарную воду просто так тоже мало кто пьёт). Дальше уже надо выяснять, в какой именно форме (сахароза, глюкоза, фруктоза), в каком количестве и с какими именно сопровождающими веществами его употреблять наиболее желательно (с учётом состояния здоровья принимающего). Тут уже вопрос переходит в количественную плоскость, а не в качественную ("сахар это плохо") как некоторые пытаются представить.
Да, вероятно в составе вкусных природных его источников сахар наиболее благоприятен для организма, потому что организм за миллионы лет приспособился именно из этих источников его получать. Но не всегда есть возможность питаться исключительно свежесорванными с дерева фруктами (по множеству разных причин), поэтому можно рассмотреть и другие варианты.
Чтобы не было нарушений, надо поддерживать нормальную физическую активость. Что с сахаром, что без (но вообще, в таких условиях сахар весьма полезен). Ну а если круглосуточно находиться на диване (ночью — спать, днём — за компом), то да, всё и так плохо, а тут ещё задачу по утилизации ненужной энергии подкидывают.
Они (алгоритмы гос шифрования) и так давно open source (и вобщем-то по самым пессимистическим оценкам на качественную и быструю реализацию именно алгоритма у компетентного программиста уйдёт никак не больше месяца, а скорее всего и меньше недели — считайте бюджет).
Осталось только интегрировать их в официальные версии open source клиентского и серверного софта. Это задача чуть посложнее (и не только программистам но и бюрократам), но тоже, в масштабах государства, копеечная. Проблема исключительно в том что сейчас эту задачу рассматривают не как что-то нужное стране, а как способ получить финансирование всяким мутным конторам.