Ровно год назад, армия Zомби-людоедоV пошла войной на соседей за то, что те смели жить своим умом и по своим правилам. Zомби-людоедам любая субъектность априори противна.

Год мы проклинали эту мразь всем честным миром за каждое новое пробитое дно, пока это все не замылилось. Год десентизации к видам трупов, к цифрам потерь, год привыкания к тому, что дегенеративным адептам русского мира желать быстрой и массовой смерти — это еще гуманно.

Но давайте все-таки о хорошем.

Год назад весь западный мир считал, что Украина сдастся за три дня. Сегодня, все еще недостаточно уверенно, но лидеры стран первого мира обещают — и дают — поддержку в борьбе до победного конца.

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

Год назад можно было играть в «ветряное экологическое чудо», сидя на русской газовой игле. Сейчас европейцам приходится думать о технологических прорывах, энергетическом суверенитете и all-of-the-above strategy.

Культурные войны отступили на шаг назад.
Несостоятельность Realpolitik и всяких там изоляционизмов-пацифизмов стала мейнстримно-очевидной.
Мрази коллективно показали свои злобно-туповатые ебала и мерзкую натуру.
Поляризация снизилась, солидарность возросла.
Ругать западные ценности стало, слава Б-гу, менее модно.

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

Оздоровление свободного мира оплачено кровью сотен тысяч украинцев. Если вы сейчас это читаете — задонатьте сегодня ЗСУ.

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

#prog #performancetrap

Что ж, подходит мой 14й день постов. Пропустил я два дня, и мне честно было просто тяжело публиковать каждый день. В итоге это вылилось в несколько осознаний:

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

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

Ну а вот вам интересный факт: если вы отключите L1/L2 префетчеры для кешей, то вероятно для своих серверных или жёстких по памяти процессов вы получите прирост производительности

https://www.reddit.com/r/pcmasterrace/comments/usoko0/disabling_hardware_prefetcher_l1_and_l2_led_to_a/

Почему? Потому что мы все больше упираемся в память, а префетчеры могут ошибаться и занимать вообще место для работы с памятью. Результаты будут скорее всего смешанными, то есть вероятно вы увидите прирост, но некоторые части кода сильно замедлятся. Особенно те, которые работают с большими кусками памяти.

В таких частях кода можно вставить software prefetching с помощью __builtin_prefetch. Вообще одна из интересных схем, которую можно попробовать -- если пропускной способности памяти хватает, то оставить prefetching, а если не хватает, то, наоборот, отключить. Скорее всего больше полезной работы будет выполнено, так как в среднем какие-то серверные процессы больше пытаются достать что-то из памяти, чем все остальное. Память не растет, чем больше вы позволите ей делать то, что нужно, тем кажется будет лучше.

Если вы работаете в HFT и у вас AMD машинки, я думаю, такую тему можно попробовать.

#prog #article

Windows и TerminateThread

Советую почитать замечательную статью: https://devblogs.microsoft.com/oldnewthing/20150814-00/?p=91811

tl;dr:
> Originally, there was no Terminate­Thread function. The original designers felt strongly that no such function should exist because there was no safe way to terminate a thread, and there’s no point having a function that cannot be called safely. But people screamed that they needed the Terminate­Thread function, even though it wasn’t safe, so the operating system designers caved and added the function because people demanded it. Of course, those people who insisted that they needed Terminate­Thread now regret having been given it.

Примерный перевод:
> Мы не хотели делать TerminateThread, потому что считали, что нельзя безопасно прибить поток. Но нас очень просили его реализовать. Поэтому мы все-таки добавили TerminateThread, но сделали его сломанным, чтобы пользователи жалели о том, что захотели такую функцию.

В сломанности TerminateThread убедиться несложно. Достаточно запустить простой код, который запускает много потоков и сразу же их убивает. Не знаю, как у вас (кто может проверить, отпишитесь в комментах), а у меня на Windows 7 этот код наглухо зависал на какой-то итерации, не добегая до конца. И это при том, что здесь нет никаких примитивов синхронизации, а только создание потока!

Что ж, судя по комментариям, многие мем не поняли. Давайте объясню.

Прежде всего: этот мем имеет смысл в контексте настольных ролевых игр. Каюсь, в контексте конкретно канала "Полено бехолдера", который целиком посвящён мемам по ним, это очевидно, но не в контексте Блог*а, который посвящён в основном программированию и антивоенной агитации.

Аббревиатура TPK в контексте tabletop RPG (TRPG) означает "total party kill" — ситуация в игре, приводящая к смерти всех персонажей игроков. Иногда такое бывает из-за простой неудачи, иногда — из-за несбалансированной битвы, когда партия встречается с противником значительно превосходящей силы. Но иногда такое бывает из-за того, что GM (game master, ведущий, человек, который ведёт игру) становится сильно недоволен тем, как ведут себя игроки. И тут мы плавно переходим к следующему пункту.

Также в контексте TRPG есть ставшая мемом фраза "rocks fall, everyone dies". Эта фраза, хоть и может описывать буквально события в игре, является общим описанием для всех ситуаций, когда мастер становится недоволен игрой и устраивает намеренный TPK путём мастерского произвола.

Так что что мы видим на картинке? Камень с надписью TPK. И этот камень может быть использован GM для того, чтобы претворить в жизнь названную на камне ситуацию наиболее мемным способом. Дополнительные очки — за то, что надпись изначально наверняка означала нечто совсем иное.

Как-то так.

Опять эта белая дрянь падает с неба

Я не настолько сумасшедший, чтобы ходить на работу

#prog #rust #article

winnow = toml_edit + combine + nom

Или зачем мейнтенер toml_edit форкнул nom.

#prog #article

Use of Formal Methods at Amazon Web Services (pdf)

Папир, на минуточку, от 2014 года. При этом довольно короткий и не обременённый формальностями, так что советую прочитать его целиком, а не только выбранные мною выдержки.

We have found that testing the code is inadequate as a method to find subtle errors in design, as the number of reachable states of the code is astronomical.

<...>

In industry, formal methods have a reputation of requiring a huge amount of training and effort to verify a tiny piece of relatively straightforward code, so the return on investment is only justified in safety-critical domains such as medical systems and avionics. Our experience with TLA+ has shown that perception to be quite wrong. So far we have used TLA+ on 10 large complex real-world systems. In every case TLA+ has added significant value, either finding subtle bugs that we are sure we would not have found by other means, or giving us enough understanding and confidence to make aggressive performance optimizations without sacrificing correctness.

<...>

Engineers naturally focus on designing the ‘happy case’ for a system, i.e. the processing path in which no errors occur. This is understandable, as the happy case is by far the most common case. That code path must solve the customer’s problem, perform well, make efficient use of resources, and scale with the business; these are all significant challenges in their own right. Once the design for the happy case is done, the engineer then tries to think of “what might go wrong?”, based on personal experience and that of colleagues and reviewers. <...> Almost always, the engineer stops well short of handling ‘extremely rare’ combinations of events, as there are too many such scenarios to imagine. <...> In contrast, when using formal specification we begin by precisely stating “what needs to go right?” <...> We have found this rigorous “what needs to go right?” approach to be significantly less error prone than the ad hoc “what might go wrong?” approach.

<...>

T.R. learned TLA+ and wrote a detailed specification of these components in a couple of weeks. <...> This time the model checker found a bug that could lead to losing data if a particular sequence of failures and recovery steps was interleaved with other processing. This was a very subtle bug; the shortest error trace exhibiting the bug contained 35 high level steps. The improbability of such compound events is not a defense against such bugs; historically, AWS has observed many combinations of events at least as complicated as those that could trigger this bug. The bug had passed unnoticed through extensive design reviews, code reviews, and testing, and T.R. is convinced that we would not have found it by doing more work in those conventional areas.

<...>

B.M.’s first spec was for an algorithm that had a known subtle bug. The bug had passed unnoticed through multiple design reviews and code reviews, and had only surfaced after months of testing [выделение моё]. B.M. spent two weeks learning TLA+ and writing the spec. Using this spec, the TLC model checker found the bug in a few seconds [выделение моё]. The team had already designed and reviewed a fix for this bug, so B.M. changed the spec to include the proposed fix. The model checker found that the problem still occurred, but via a different execution trace. A stronger fix was proposed, and the model checker verified the second fix.

<...>

While our results are very encouraging, some important caveats remain. Formal methods deal with models of systems, not the systems themselves, so the adage applies; “All models are wrong, some are useful.” The designer must ensure that the model captures the significant aspects of the real system. Achieving this is a difficult skill, the acquisition of which requires thoughtful practice.

#life #article

Writing Is Magic, или почему в принципе стоит писать. Речь, впрочем, идёт не о художественной литературе, а скорее о утилитарных текстах.

#rust #meme