Покритикуйте, пожалуйста, код

Зачем асм? Читать это - боль и страдание, а оптимизации никакой не дает. Ну, по крайней мере я никакой оптимизации не увидел.

Зачем асм?

Затем что он дает выигрыш в высоконагруженных системах. Существует такое понятие «ассемблерная вставка». Наверное оно появилось потому что асм быстрее, не?

Читать это - боль и страдание

Это зависит от программиста. Читать С++ - это боль и страдание.

а оптимизации никакой не дает

Дядя, как думаешь, какой код будет более оптимизирован, который 1-в-1 повторяет то, что написал программист оперируя регистрами или который обернут в 20 слоев абстракции? По времени написания код на асме пишется лишь немногим дольше С.

Ну, по крайней мере я никакой оптимизации не увидел.

Код выше ест одну страницу памяти (4к), по факту ему было бы достаточно примерно 100 байт, остальное в регистрах, система выделяет минимальный объем в одну страницу.

Очень часто в языках нет инструмента оптимизации для конкретных операций (например С не умеет заливать память int'ами), что в ассемблере может быть исполнено в несколько инструкций. Компиляторы могут ловить такие паттерны, но не всегда.

Существует такое понятие «ассемблерная вставка». Наверное оно появилось потому что асм быстрее, не?

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

Короче говоря асм нужен, но писать на нем все и всегда это перебор.

Затем что он дает выигрыш в высоконагруженных системах.

Сомнительное утверждение. Ты уверен, что ты можешь написать код на Assembler который будет отрабатывать быстрее того, который порождают современные оптимизирующие компиляторы? В каждом компиляторе имеется огромная куча различных оптимизаций, охватить которую одному человеку просто невозможно, поскольку нужно быть специалистом во множестве направлений Computer Science и знать все хитрости целевой архитектуры.

Существует такое понятие «ассемблерная вставка». Наверное оно появилось потому что асм быстрее, не?

Так было раньше, когда компиляторы не умели достаточно хорошо оптимизировать некоторые моменты. Сегодня ассемблерная вставка это больше «подёргаем регистры процессора экзотической архитектуры, потому что я знаю, как сделать это более оптимально». Как пример – ассемблерные вставки в ffmpeg для того же ARM NEON.

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

Какой-то школьный высер

Норм критика

Ага. Вот, к примеру, кейс из какого-то доклада по C++ за авторством Полухина (того, который в комитете стандартизации сидит):

https://godbolt.org/z/nRy76E

int foo(unsigned int x) {
    return x % 2361 == 7;
}

foo:
        imul    edi, edi, 254678281
        xor     eax, eax
        sub     edi, 1782747967
        cmp     edi, 1819130
        setbe   al
        ret

Компилятор убрал всякие дорогие операции деления, заменив всё матан-магией:

https://github.com/gcc-mirror/gcc/blob/f37ffcc5675bb75a4835adcc1c87227a2a7041d9/gcc/expr.c#L11842-L11862

Сомнительно, что ассемблерщик сходу предложит подобное решение. И подобной магии там куча.

Тем временем в криптографии и мультимедиа без асма никуда.

Оптимально это запилить функцию на С. Запилить тесты и бенчи.

Затем попробовать написать на асме, тогда можно сравнить. Компиляторы молодцы, но написать на асме быстрее тоже возможно...

Конечно. Они ведь используют далеко не общеупотребимые инструкции, а всякие там специальные AES, AVX, NEON и т. д., где оптимизации самого компилятора не настолько навороченные и вручную оптимизированный код на Assembler’е от специалиста в этой области всё ещё оправдан. И скорее всего будет всегда оправдан.

Компиляторы молодцы, но написать на асме быстрее тоже возможно…

Конечно возможно. С этим никто не спорит. Но программы обычно не из одной функции состоят. А чтобы оптимизировать все функции своей программы максимально по быстродействию, нужно иметь огромный пласт самых различных фундаментальных знаний в разных областях. И этот пласт знаний от кучи людей уже содержит в себе оптимизирующий компилятор.

Вопрос лишь в том, а оправдано ли подобное? Нагружая свой код ассемблерными вставками теряется его портабельность. Потребуется перекомпилировать программу под какой-нибудь AArch64 или RISC-V и нужно будет делать вставку уже для этой архитектуры, обрамляя код уродливыми #ifdef’ами. Сможет ли программист на ассемблере, являющийся экспертом в x86_64, сходу сделать оптимальной ассемблерную вставку для другой архитектуры? Не слишком очевидно, верно? Как минимум ему потребуется потратить довольно много времени на изучение инструкций, регистров и т. д.

Наверное оно появилось потому что асм быстрее, не?

Далеко не только из-за этого. В качестве примера, в ARM есть инструкции эксклюзивного доступа к памяти. Как их использовать в Си без ассемблерных вставок?

выигрыш в высоконагруженных системах

О каких «высоконагруженных системах» идёт речь?

Самый распространенный случай высоконагруженной системы — веб, а его на ассемблерах никто не пишет. И причина тут очевидная: асм — не быстрее. Когда у тебя уже готов сервис на java/python/go и он работает, доспустим, медленно, сервис на асме не работает никак, потому, что его нет и не будет ещё полгода. А когда он будет, быстрее он всё равно не окажется, ибо требования уже поменялись.

веб, а его на ассемблерах никто не пишет

https://habr.com/ru/post/318916/

fasm обновился до версии 1.73.10 (комментарий)

Использовать int 0x80 в 64-бит смысла нет. Оно медленно работает и аргументы там принимаются 32-битные (т.е. системным вызовом read ты не сможешь например заполнить массив в памяти процесса, если этот массив по адресу, который в 32-битный регистр не влазит). Кое-какие системные вызовы через int 0x80 недоступны (посмотри в /usr/include/asm/unistd_32.h и /usr/include/asm/unistd_64.h). Кроме того, оно может не заработать если ядро собрано без поддержки 32-битных вызовов. В 64-битной ОС лучше использовать инструкцию sysenter. См. https://stackoverflow.com/questions/46087730/what-happens-if-you-use-the-32-b...

Кстати, даже в 32-битных ОС int 0x80 лучше не юзать т.к. есть способы быстрее

AsmBB забыл: https://board.asm32.info/

https://github.com/wqweto/AsmBB

Ага. Вот, к примеру, кейс из какого-то доклада по C++ за авторством Полухина (того, который в комитете стандартизации сидит)

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

Конкретно тот упомянутый момент: https://youtu.be/fT3OALUyuhs?t=588 - типа дали ассемблерщикам этот вот пример x % 2361 == 7 - во-первых нормальный ассемблерщик сначала скормит это компилятору, потом уже будет думать над задачей т.е. если компилятор все сделал оптимально и улучшить ничего нельзя - можно этот код и выдать. Я много всяких багрепортов в багзиллу GCC понаотправлял, взять например свежий пример https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92233

unsigned test_mult(unsigned a, unsigned b)
{
  if ((a == 0) || (b == 0))
  {
    return a*b; // here a*0 or 0*b or 0*0 - always 0
  }
  return 0;
}

So this function should always return 0 no matter what, but GCC generate comparisons and imul instruction, even with -O3

или есть не такие свежие https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80588 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91882, похожие проблемы я находил и в других компиляторах. Вот та лажа с умножением на 0 вообще никаким комиплятором не оптимизируется.

А ты не думаешь, что такие оптимизации должен программист делать, а не компилятор? Код не особо реалистичный, и тривиально оптимизируется человеком. Если в компилятор запихать еще кучу паттернов, то сложнее и медленнее он станет, а польза сомнительна.

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

Такая ситуация вполне реалистична если есть какая-то функция f1(a,b) в которой a и b как-то умножаются (возможно там какая-то сложная формула, не суть), которая инлайнится в некую другую функцию f2() и из контекста f2() можно понять что в функции f1(a,b) или аргумент a будет нулевым, или аргумент b нулевым, или оба

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

и да, если бы веб писали на ассемблере, то всё бы просто летало. и жрало бы в миллион раз меньше ресурсов. как пример - использую ассемблерный http-сервер rwasa. он намного быстрее nginx-а и жрёт на порядки меньше памяти и проца.

в вебе «высоконагруженность» создаёт говнокод

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

если бы веб писали на ассемблере, то

Никакого веба бы не было, сидели бы в 90-х.

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

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

всё было бы. ты не забывай, что интернеты придумали люди, которые писали ещё на сишечке и ассемблерах. а макаки сейчас просто заговнили и опопсили всё.

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

потому что понимает, как это будет работать на машине.

Я успокоился, когда долго и нудно соптимизированный под Nehalem код на Sandy Bridge стал работать медленней, чем из сишного компилятора. А поди ж ты, тот же самый x86.

и да, если бы веб писали на ассемблере, то всё бы просто летало. и жрало бы в миллион раз меньше ресурсов.

Потому что софта было бы в миллион раз меньше.

Современный ассемблер - это понимание микроархитектуры целевого процессора. Как писать на чём угодно, чтобы в очевидный bottleneck этой архитектуры не попадать. В подавляющем большинстве случаев это просто память и TLB, но бывают и забавные случаи, когда power budget палки в колёса вставляет.

Фичи дают нагрузку. А статичные странички из кеша, конечно, можно и миллионками в секунду отдавать.

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

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

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

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

Так макак много, а тех демиургов единицы были.

А сервер из примера ничего и не умеет на фоне nginx. Не говоря уже о том, что nginx есть под любую платформу в отличие от.

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

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

Я не про этот сервер говорил. И там в тестах никаких миллионов нет. В 100К на статистике я и на Cython могу и на Go, асм тут не нужен.

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

Надо кстати такое в метапрог добавить...

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

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

программирование - не удел масс. вот и всё. я постоянно это тут повторяю. не умеешь программировать - иди укладывать плитку.

Почему? По-моему мир хорошо устроился с программирующими массами, всем хорошо. Кроме тебя.

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

веб … - это детские игрушки

У тебя есть чудесный шанс раз и навсегда это пруфануть, надрав всех на HighloadCup.

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

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

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

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

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

Господа, срочный консилиум! Как думаете, недотрах или таки да?

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

у тебя? возможно. но кого это гребёт? сходи в поликлинику, там тебе помогут.

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

Какой-то школьный высер

Ёмко. Лорчну-ка.

а для меня полно челленджей и интересных задач

Занимаясь годами одним и тем же? Сомнительно.

там, где макакокод не встречается

Если сама такой не напишешь, то тебе и не встретится. У тебя будет ТЗ и единственное ограничение в виде докер-образа, который нужно залить на тестирование.

и я не поняла, как ты перешёл от макак к науке. вообще никакой корреляции

Я хотел сказать, что если бы люди из своего болотца никогда не выбирались, никакой науки не было бы и в помине.

в худшем

Впрочем, зато веб-макак бы не было.

нет, в худшем — всё было бы одновременно.