Забавные новости 0й-Ti :)

а если сбой произошёл на скоростной трассе???

Ты не учитываешь, что 2% потеряны на ЛАЙТ нагрузке а вероятность упасть, конечно, повышается - больше сжирается стек, больше сжирается куча + растут ошибки синхры. короче, не веришь - прогоняй стресс тесты и сам всё увидишь.. правда, держи в памяти, что твоя железка/комп может пострадать от таких нагрузок

Молодец - аплодирую, а теперь Вопрос в студию: Вот нафуя.. нафуя нужен ржака, если для приличного результата нужно превратить его в сиху???

как считаешь, ядро оси пишут по стандартам???

как выяснялось, Тебя понесло по бездорожью Ты, вообще, помнишь о чём речь-то шла?

 

Заглушили двигатель и останавливаемся накатом, всё хорошо.

Посмотрел первоисточник и, честно говоря, не нашёл упоминаний, что нагрузка - лайт.
Обыкновенный стресс-тест, разницы с сишным драйвером никакой. В одном тесте вариант на расте даже быстрее на микроскопическую долю процента.

Неа, программы устроены по-другому. От того, что функция вызывается не десять раз в секунду, а миллион, стек сильнее съедаться не будет. Аллокации будут чаще, но не больше (при условии равного количества потоков, которые всё это обрабатывают).
Что такое ошибки синхры, мне неведомо. Если кто-то ошибся и допустил гонку потоков, это просто баг, к стресс-тестам отношения не имеющий.
Если же потоки синхронизированы корректно, на стресс-тестах они не упадут никогда (только не приводи в пример RowHammer и Spectre).
Как, впрочем, и железо никак не сломается от нагрузки. Максимум, что может произойти, если плохое охлаждение, процессор или диск начнут троттлить, снижая частоту. Не велика беда, у меня под праймом с AVX2 процессор тоже упирается в тепловой лимит, ну дк современные процессоры даже водянками не остудишь.

Нет, потому что не существует стандартов на написание ядер. Как не существует и стандартов на написание софта в целом.

--- Сообщение объединено, 31 дек 2023 ---

Кстати, те бенчмарки вышли в 2022м. За год несколько раз подкручивали оптимизации - вполне возможно, что на актуальной версии раст или совсем сравняется с си, или даже превзойдёт его в большем количестве тестов - даже с учётом того, что и gcc подкручивали за год.
В любом случае, на одной чаше весов сахар современного языка, на другой - минус два процента производительности. Да за столько фич и пяти процентов не жалко.
Было бы десять - вот тогда уже можно спорить. Двадцать - уже много. Но два процента…
Тебе два соседних поколения gcc дадут такую разницу просто на оптимизациях компилятора.

 

угу, на скоростной трассе заглушить двиг - явное создание аварийной ситуации

три ссд - прям стресс тест

стек жрут чекеры + доп жор на куче. А синхра расползается, когда железка переходит в экстрим/аварийный режим работы и софтварных вариантов такое лечить нет, поэтому в ядрах осей добиваются максимальной скорости потоков - они гораздо лучше держат экстрим нагрузки. А в датацентрах и на сервачах делают физ разделение потоков/процессов + дублирование + бэкап точки.

оооооооопа... вот это поворот Rel мне прям любопытно, что тимлид скажет на такое.. хотя, понятно что

уже отвечал https://wasm.in/threads/godnota-na-rzhaku.34990/#post-440536

ЗЫ.. вернусь опосля нг

 

UbIvItS, тебя не смущает что они только времени с тобой спорят? К чему то существенному пришли за все время?

--- Сообщение объединено, 31 дек 2023 ---

Не смущает отсутствие конкретики с их стороны, их отсылки, на всякие мутные аргументы/терминологии?

--- Сообщение объединено, 31 дек 2023 ---

Есть много терминологии, из разных отраслей, единственное чего нет, так это простоты

 

Ну а какие варианты? Прошивка всё равно не может продолжать, если случилось что-то, к чему она не готова.
В случае явного отказа ты можешь их обработать резервной прошивкой. А если бажная прошивка продолжит работать - неизвестно, что может произойти. Может, ничего, а может, вклинит двигатель или откажут тормоза, или что-то ещё.

Разумеется, если ты готов к неожиданным данным, везде проверки, всё покрыто тестами на плохие значения, падать не обязательно, но и раст не обязывает падать, ты всегда можешь обработать ошибку явно (даже OutOfMemory, если юзаешь infallible).

Если что, у процессора вообще нет понятия загруженности. Он всегда что-то делает.
То, что ты видишь в диспетчере задач - это какой процент времени процессор выполнял код потоков, а не крутился в idle-цикле где-то в ядре, выполняя или halt, или что-то ещё, чтобы ввести себя в какое-нибудь C-state с низким энергопотреблением.
Если запустишь на процессоре какой-нибудь тест - он вместо idle, будет выполнять твой код. Для процессора никакой разницы: он будет сильнее греться, но не станет совершать ошибки.
Если по какой-то причине процессор всё же ошибся - таки да, что-то упадёт. Shit happens, такое бывает.
И никакая экономия на микросекундах здесь ничего не исправит - ты просто упадёшь. Но при разработке мы считаем процессор абсолютно надёжным, а значит, если процессор не сломан, синхронизация и вообще всё будет работать гарантированно корректно, независимо от нагрузки и её продолжительности.

Инструкция cmp, проверяющая диапазоны, не трогает память вообще. Ни одна проверка не выделяет динамическую память.

Вот смотри, с драйверами я познакомился где-то в 2015м. Сначала и долгое время писал их под винду, а примерно в 2019м начал писать их под линукс. И там, и там работал в основном с файловой системой, процессами и их памятью. Такой классический набор системщика.
Драйвера для железок не писал ни разу, но, несмотря на это, думаю, что плюс-минус неплохо представляю, как устроены эти два ядра.
Разумеется, постоянно приходится читать исходники или линуксового, или виндового ядер, а также доки по оным.
И со всем этим багажом - я уверен! - если бы существовал хотя бы намёк на некий стандарт, по которому они написаны, я бы о нём хотя бы слышал.
Есть принятые стили, есть гайдлайны и how-to, есть спецификации и их эталонные реализации (например, для сетевых протоколов), есть ограничения в некоторых функциях (например, IRQL для функций в винде или атомарность контекста в линуксе, когда ты не можешь ждать на примитивах синхронизации) - но нет стандартов.
Ни одного. Совсем.
А всё потому, что нельзя стандартизировать совершенно разные подходы к проектированию операционок. Не существует и не может существовать стандарта, который скажет «пишите так и никак больше».

--- Сообщение объединено, 31 дек 2023 ---

Интересно, если примеры кода с дизассемблером для тебя не конкретика - то что было бы достаточно убедительным?
На каком основании ты выбрал сторону в нашем с ним споре?

 

Такое ощущение что единственная твоя мотивация в этом сраче: стремление доминировать,
доказать свою значимость. Какую мысль ты хочешь до него донести? )

 

Для него только батники тащут, ты забыл штоле? Нужен батник, который все сделает.

Не ну есть там всякий SEI CERT, например. Проблема в том, что в реальности у каждой компании будет свой стандарт, который может быть плохо совместим с внешними от компании библиотеками, например, поэтому форсировать стандарт на уровне языка и всяких тулз, типа линтеров и форматтеров - куда лучше.

Да-да, конечно же речь шла вовсе не о том, где ты наделал в рейтузы на ровном месте. Вообще, про другое разговаривали.

--- Сообщение объединено, 31 дек 2023 ---

Посмотри на это с другой стороны. Вот есть у людей хобби участвовать в бесконечных спорах на форуме, но тут вдруг образовался ты, вставляя то тут, то там свои 5 копеек без какой-то дельной аргументации и без ничего, просто ради того, чтобы что-то написать. Ты хочешь поучаствовать в споре, но не обладаешь достаточными скиллами в риторике? Или хочешь показаться умнее всех остальных, но не знаешь как? Тебя сильно заботит, что другие упражняются в риторике, а ты не участвуешь?

 

"Участвовать" - это значит быть частью толпы. Это с каких пор, быть частью толпы - элитно ??

 

Опять ты про батники зачем-то раскудахтался. У тебя с ними какая-то проблема?
Мне вот они по кайфу, буду использовать их столько, сколько посчитаю нужным, до самого второго пришествия

 

классический подход: основной блок управления для штатного режима работы, обу вылетает - врубается запасной, запаска вылетает - переключается на ручной режим (водила сам должен переключать скорости и вовремя жать педальки сцепление/газ/тормоз).

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

опять сомнительное утв - проц не совершает ошибок лишь в штатном режиме работы и при этом само понятие «штатного режима работы» весьма вариативно =>> со временем проц выгорает, что сильно сужает допустимые пределы температур..

на новых ЖЕСТьанках с этим совсем бьАДА

ну-дык, во ржаке чекеры на все случаи ЖЕСТИ

лады, берём компиль сишки, пишем rofl at x; берём ржаку - пишем то же самое и коблу (кобол) сюда же =>> все эти замшелые яп-ы не понимают сией гениальной команды.. вот что за хз такое?????? сам же яп уже накладывает свой набор стандартов/ограничений на то, что пишешь; потом идут стандарты/ограничения оси, потом жестянка тоже впихуаривает свои ПЯТЬ КОПЕЕК + 2 КОПЕЙКИ ЗАКОНОВ ФИЗИКИ. если про си МЕЛОЧИ забыть, то да - стандартов нет

 

это автоматическая коробка в ручной режим должна уйти? это как?

это только если специально не маскируют

 

> лишь
Гм, «лишь» - это всё время жизни процессора. Если он начал ошибаться, его выбрасывают.
Поэтому нет смысла рассуждать о какой-то стойкости кода к аппаратным ошибкам - её просто нет.

Её и нельзя посчитать иначе, это просто условность.

Неа, неявных рантайм-проверок там мало - на выход за границы и проверки переполнений, вот наверно и всё.
Есть ещё явные проверки в std (например, проверки заимствований в RefCell или проверки на OOM в коллекциях) - но ни одной из них память не нужна.

Ты говорил выше о стандартах, подразумевая что-то конкретное. «Если прогу пишут по всем-всем стандартам» - вот я и спрашиваю, по каким?
В данном контексте слово «стандарт» предполагает некое высокое качество, мол, раз написано по стандартам, значит, с прогой всё хорошо и незачем её переписывать.
Но мы регулярно видим CVE и в ядрах, и в юзермпейсе.
Вот и вопрос: или стандарты не стандарты, или их злостно нарушают.
Вот и придумывают новые языки, чтобы кода меньше, а смысла больше. Да, ценой ЦЕЛЫХ ДВУХ процентов IOPS’ов!

Ну и да, альтернативы си (не обязательно даже раст, да хоть C++) - это не столько про безопасность, сколько про сахар и фичи.

 

это в эпоху то когда четыре девятки проф.сисадмины должны обеспечивать по простою? да бросьте, купите новый для новой ноды, и планомерно заменитее все ноды в кластере. Уже давно избыточности хоть залейся, что бы и в проце ошибки править и на всех стыках.

--- Сообщение объединено, 3 янв 2024 ---

есть, оно же не горит всё разом, а то у вас как то выходит как в анекдоте "иду по полю и вдруг неожиданно из-за угла выезжает танк"

 

Хм, а в каком виде? Ты же не знаешь, где выстрелит, если проц стал работать нестабильно.
Где-то в регистре или кэше на рандомной инструкции попортился битик - может он ни на что не влияет, а может сделает format C:
Софтверно ты никак к этому не подготовишься.

 

HoShiMin, битик? ок. требуется передать битик, тогда передаем пять 1 1 1 1 1 и получаем с ошибкой 1 1 1 0 1 . типа так? теперь принимаем решение, 1 или 0 нам передавали? похоже что передавали 1. Это и есть суть помехоустойчивых кодов.

В процессорах регулярно происходят ошибки, и регулярно правятся. бывают наверно случаи что ОТК не проходят какие-то экземпляры.

я к тому веду, что вы утрируете оба. каждый в свою сторону.

 

если сугубо автоматика, значит всё будет очень плохо.

для игрового пк, конечно, попрёт... хотя, нет - даже для гамеров фигово и даже очень: вот гамер, вложил в свой акк 20 000+ бакинских и ведёт очень важную миссию, а тута сбой проца.. порекомендуй такому гамеру как не попасть в такой просак (ведь, даже свежий проц/гпу могут такое)

нуууууууууууу.... нефигасе..... ладно, выключи комп и попробуй напечатать сюда пост - работа ж компа сплошная условность

и этого мало??????????? даже для проца на 3-5ггц такое очень жирно.. тута надо помнить, что кол-во переменных и частота их использования уж очень сильно меняют ландшафт

например, аптайм.

сахара и фич, кстати, толком нет.

в тучные годы так и делали, а сейчас есть риск тупо вылететь из бюджета - мы возвращаемся во времена, когда на одном ссаном серваче висело от инет веба до локального принтера

 

Не знаю, происходят и правятся ли там ошибки на самом деле, но софт их не видит. Мы же говорим о случаях, когда ошибка дошла до софта.

Если он купил бракованный проц - идёт в магазин и меняет по гарантии. Если гарантия кончилась - можно поднять напряжение или снизить частоты. Или отключить проблемное ядро в биосе.
Если же намекаешь на то, как сделать, чтобы на сломанном процессоре ничего не упало - то никак.
Хочешь в этом убедиться - зайди в биос, подними частоту мегагерц на 300 и попробуй во что-нибудь поиграть. Проверишь на практике готовность игр (да и вообще операционки) к аппаратным ошибкам.

Вот четыре цикла, которые нагружают процессор по-разному:

Код (ASM):

1.  
2. Loop1:
3.     jmp Loop1
4.  
5. Loop2:
6.     pause
7.     jmp Loop2
8.  
9. Loop3:
10.     mov rcx, rax
11.     add rax, rcx
12.     sub rax, rcx
13.     jmp Loop3
14.  
15. Loop4:
16.     cvtsi2ss xmm0, rax
17.     shufps xmm0, xmm0, 0
18.     addps xmm0, xmm0
19.     mulps xmm0, xmm0
20.     jmp Loop4
21.  

Для всех диспетчер покажет 100% - даже на цикле с pause.
Причём, на основе метрик даже не от процессора, а от планировщика, который сам и уводит процессор в C-state.

Ну вот мы увидели разницу в 2%.

Аптайм с языком не связан.

Да, не считая сахар и фичи, сахара и фич там нет.

 

HoShiMin, ну в ddr ecc это что? таких ошибок везде много и много мест где отсекается. Редкая ошибка железа наверно может докатиться до софта, но тогда просто можно софтом организовать лишнюю верификацию и лишние повторные запросы. Гипотетически, есть ситуации, где действительно необходимо от одного битика вешать зависимость потока исполнения. jnz условно. Но такие ситуации редкость, где прям действительно нужна RTOS и оффигенно скоростной код в принятии решения. Но там и пишут его не тяп-ляп и в продакшн. Там верифицировать код и тестовые прогоны могут гонять годами. Короче, изначально спор из натягивании совы на глобус. В кардиостимуляторах херня, а уж казалось бы, должно быть высокопрофессиональными людьми создано. В большинстве случаев куча усилий, но если глубоко копнуть, то не нужных усилий по "борьбе за совершенство и надежность".

просто даже если взять, если кубик докер контейнеры поднимает и закрывает исходя из нагрузки на приложение, то ну о чем тут говорить за какие-то биты. всё давно относительно стабильно и так. Да и ЛЛВМ всякие eBPF , в натив всё меньше нужды у людей. А раз так то и движуха в раст несущественна. А если уж прям ситуация того требует, то соберутся с духом и прям в асме напишут. А какие там тогда типы?

--- Сообщение объединено, 3 янв 2024 ---

я вообще спорить не готов, у меня с компетенциями не алё, и это не кокетство. Есть узкие темы, есть кругозор, да. Но хватает мозгов понять, что в мире есть колокол и хвосты распределения. Ситации разные. Смысла спорить как по мне - нет.

 

Да, ECC может скорректировать один бит в оперативке, но если ошибается сам процессор - ты никак это не исправишь.
За примерами далеко ходить не надо: немножко разгоняем процессор и начинаем ловить падения/зависания/синие экраны в рандомных местах.
И как это ловить? Например, пишешь mov rax, 123, а у тебя вылетает #UD, потому что что-то сломалось в декодере.
И более того, нельзя к этому подготовиться: какими бы проверками ты ни обложил код, вылететь может в самих этих проверках.
Поэтому мы всегда полагаемся на то, что процессор работает правильно и не ошибается. А если ошибается - это уже не наша зона ответственности.

 

ну гипотетически стэктрэйс может прикапывать материнка, и при падении в прерывание, заполнять регистры предыдущим устойчивым состоянием, как на практике - хз.

Приложение опирается на ось, ось на железо, но железо железу рознь. Кто-то не переживет смерть видеокарты, но подозреваю, если бы захотели, извернулись бы.