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

Чем телеком принципиально отличается от веба? Там нужно молотить херову тучу пакетов и тут нужно молотить херову тучу пакетов.

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

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

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

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

А хаскелевский warp ещё быстрее:

https://github.com/snoyberg/posa-chapter/blob/master/warp.md#performance-of-warp

будут потери, что неприемлемо

А что в вебе потери — это приемлемо?

В вебе нет требований, чтобы сайт работал при полной загрузке сетевой карты

А в телекоме есть? То-то чувак в соседней теме ищет роутер который не режет скорость.

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

А что в вебе потери — это приемлемо?

Так в вебе вместо потерь медленно открывающиеся страницы. В перспективе это тоже потери, но не так критично.

А в телекоме есть? То-то чувак в соседней теме ищет роутер который не режет скорость.

Внезапно. У меня и HP и Cisco скорость не режут... где тема?

По факту критерий обычно один — оптимизация производства (на получение прибыли).

Именно так. Если магистральный коммутатор будет вместо заявленных 10 Гбит пропускать только 8, то будут как минимум репутационные потери, а как максимум возвраты по гарантии. А если на сайт вместо 1000 одновременных сессий может зайти только 800, то это заметно гораздо меньше. Поэтому для веба «херак-херак и в продакшен», а для телекома приходится гарантировать производительность.

Если разбирать сам код, там хватает неоптимальных моментов. Вот взять например https://github.com/codemeow/freelancer/blob/master/freelancer.asm#L154

    .p_loop:
        xor     edx,        edx
        mov     ebx,        10
        idiv    ebx
        add     edx,        30h
        push    rdx
        inc     ecx
        cmp     eax,        0
        jnz     .p_loop

    .p_print:
        pop     rax
        mov     [v_loop_i], eax
        p_s     v_loop_i,   1
        loop    .p_print 

Тут делается перевод в десятичную систему счисления, точнее в ascii цифры и выводится потом через вызов макроса p_s который вызывает p_str... Ну во-первых тут xor edx, edx на каждой итерации цикла смысла делать нет, у тебя инструкция idiv в любом случае там переписывает. Во-вторых, инструкцию idiv (которой ты получаешь остаток от деления на 10 чтоб выцепить десятичный разряд) для оптимизации можно заменить инструкцией умножения, как это обычно делают компиляторы. Т.е. если GCC с флагом -O3 попросить это собрать: https://godbolt.org/z/j862j_

unsigned test(unsigned a)
{
  return a%10;
}

test:
        mov     eax, edi
        mov     edx, 3435973837
        imul    rax, rdx
        shr     rax, 35
        lea     edx, [rax+rax*4]
        mov     eax, edi
        add     edx, edx
        sub     eax, edx
        ret

Еще у тебя зачем-то на каждую выводимую цифру по одному вызову sys_write идет, это неоптимально, лучше одним большим вызовом все вывести чтоб не дергать ядро на каждый чих. А еще у тебя там цикл построен через инструкцию loop что тоже неоптимально, современные процессоры ее медленно исполняют https://stackoverflow.com/questions/35742570/why-is-the-loop-instruction-slow...

Ну и вот эти вот места

    push    rax
    push    rbx
    push    rcx
    push    rdx
...
    pop     rdi
    pop     rbx
    pop     rcx
    pop     rdx

вместо потерь медленно открывающиеся страницы

Страницы медленно открываются -> пользователей раздражает -> они сваливают к конкурентам -> потери.

но не так критично

А в телекоме что, железка устраивает ядерный взрыв? Нет, внезапно там та же самая схема — хреновую железку перестают покупать.

У меня

Ну лiл же. Не ожидал от тебя аргументов такого уровня. Разочарован.

Страницы медленно открываются -> пользователей раздражает -> они сваливают к конкурентам -> потери.

Не всегда. GMail тормозит, Facebook тормозит. Пользователи не уходят.

Ну лiл же. Не ожидал от тебя аргументов такого уровня. Разочарован.

Да я серьёзно. Единственный раз, когда видел, чтобы не проходила полная пропускная способность — на 8-портов D-Link'е. Вот мне и интересно, где и как такое наблюдается.

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

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

Прекрасно там всё.

А яйцеголовым нечего делать за пределами лов-левела

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

Нет.

асм быстрее, не?

Не. Например, у gcc -O0 -S в выхлопе тоже асм, и он медленный.

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

Процессоры работают не так, как «написал программист». Кабздец, и ты ещё на асме что-то там пишешь? Я такой говноасм в школе писал, и он нифига не оптимизированный.

одну страницу памяти (4к

Производительность не измеряется килобайтами.

Как их использовать в Си без ассемблерных вставок?

__builtin_govno(x)

Не обращай внимание. У многих тут при слове асм включается методичка насчет оптимизации и затрат. При чем, сам асм они ни шарят.

При асме топят за С. При с/с++ - за раст. Стильно, модно, молодёжно.

У меня под столом голая сишечка, без ассемблера, упирается в 100-гигабитную сеть на цифре 2.2 млн IOPS (Мелланокс больше не может). Процы простаивают, AMD Naples/Rome.

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

Чего конкретно ускоряли-то? Хэши/суммы какие-то считать? Сишный код общего назначения ассемблером ускорять - так себе занятие.

первый hello world на nasm'е

Лучше бы Объясните сишную магию asm вставкой заменили, чтоле. Хоть польза бы была.

Жёсткое реальное время против мягкого.

В Линуксе нет жёсткого рилтайма, увы и ах.

В телекоме, если время обработки пакета больше времени между приходом пакетов, будут потери, что неприемлемо.

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

Веб-морду на МК с eth на чём лепить будешь? Сишечка без вариантов.

Подозреваю что кодеки. Практически единственное что до сих пор имеет смысл ускорять асмом.

Хотя какие нахрен кодеки в серверной части...

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

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

Очень рекомендую почитать дизасм кода, который генерирует любой хороший C компилятор со включенной оптимизацией. А он таки заметно лучше, чем это: https://github.com/codemeow/freelancer/blob/master/freelancer.asm

С не умеет заливать память int'ами

Си прекрасно заливает память интами - банальный цикл делает это с максимальной достижимой для системы скоростью.

Лучше бы Объясните сишную магию asm вставкой заменили, чтоле. Хоть польза бы была.

Этот движок не только на x86_64 собирается ведь.

Этот... не только на x86_64 собирается

То есть, пользы не будет? Так считаешь?

То есть, пользы не будет? Так считаешь?

https://godbolt.org/z/3Red6X

https://godbolt.org/z/3Red6X

А если в test цикл впихнуть от -50 до 300 и суммировать результат? Или опять какая то оптимизация встрянет?

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

https://godbolt.org/z/C1-l_w

Да, точнее так.

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

Какой Function телекома? И какие характеристики (приблизительно)? Боюсь, что на 6к-10к сессий - это год твоих зарплат на покупку мейнфрейма. На БД для хранения правил для этих сессий уйдёт больше в разы, если это Oracle.

У тебя почти в каждом посте фигурирует слово «говно» в этом треде.

А через пост ода себе самой. Где посмотреть кто ты есть?

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

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

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

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

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

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

я системный программист. тут на ЛОРе когда-то были мои посты в jobs. продвинутый юзер ищет за минуту. ну да ладно уж, для непродвинутых: https://www.linkedin.com/in/yana-kireyonok-b5219682/ (только не говорите, что линкедин в роисье не работает).

Я вот читаю весь этот спор (или как это правильно назвать?) и не очень понимаю смысл. О чем вы вообще спорите?

По поводу вручную написанного человеком ассемблера vs сгенерированного компилятором из кода на Си - да, есть ситуации, когда что-то надо писать руками на асме т.к. компилятор не справляется, и нет никакого способа используя языковые конструкции Си заставить компилятор нагенерировать качественный машинный код. Есть и другие ситуации, когда человек просто не сможет некоторые оптимизации сделать своим человеческим мозгом. Взять например минимизацию булевых функций для большого числа аргументов или оптимизации циклов через полиэдральные модели (см. https://en.wikipedia.org/wiki/Polytope_model https://xeno-by.livejournal.com/28122.html). В общем есть такие моменты с оптимизацией, которые человеческий мозг просто не сможет осилить за разумное время, а процессор с запущенным на нем алгоритмом оптимизации вполне может.

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

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

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

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

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

О чем вы вообще спорите?

У неё сезонное обострение, к декабрю отпустит.

Расскажите ей, что она королева программирования и она сама свалит.

Я это видел. Я и другое видел, а поэтому у меня не стакается:

я вообще не интересуюсь социалочками

Но в youtube регулярно постим видосики с концертов, а раньше и ЖЖ был. Так, что там дальше...

у меня нет макак среди коллег

• Вакансия на сайте: Бэкенд-разработчик PHP (senior)

И ещё одна с недоязычком:

• Senior cистемный программист C/C++ - Python

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

а раньше и ЖЖ был

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

Вакансия на сайте: Бэкенд-разработчик PHP (senior)

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

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

Всё проще: лизинг твоих серверов заканчивается через год, а на следующих серверах твоя оптимизация нахрен не нужна будет.

Или соседний отдел CUDA к решению задачи прикрутил.

Или, наконец-то, разрешили GCC 3.3 в продакшене на современную версию проапгрейдить.

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

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

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

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

и да, про TCP/IP-стек. в ядре почему-то основная его тяжёлая часть, криптография, на ассемблере написана. разработчики не знали, что у вас пацталом процы простаивают. и написали зачем-то криптографию на ассемблере.

Пример основной тяжёлой части в TCP/IP-стеке, недавно пофикшенной: IO-path в драйвере сетевухи и IP-стеке не вмешался в L1i. Чувак добавил чутка кода, худо-бедно классифицирующего пакеты, собирающий их в списки и спускающего этот список в IP-стек. L1i вдруг стал горячим, IO полетели бодрее.

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

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

Или вот какая замечательная портянка: https://elixir.bootlin.com/linux/latest/source/arch/x86/lib/copy_user_64.S Знал ли автор, что на Netburst она работает хорошо, на Core значительно хуже, а примерно так с Nehalem вообще хуже банального rep movsb, который даже самый стрёмный gcc сгенерирует?

Новые фичи процов в компиляторах появляются задолго до появления этих процов на полках

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

Авторам этих ассемблерных портянок заранее знать, какая хрень лучше именно на этом процессоре работает, невозможно.

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

Пример основной тяжёлой части в TCP/IP-стеке, недавно пофикшенной: IO-path в драйвере сетевухи и IP-стеке не вмешался в L1i. Чувак добавил чутка кода, худо-бедно классифицирующего пакеты, собирающий их в списки и спускающего этот список в IP-стек. L1i вдруг стал горячим, IO полетели бодрее.

Ты выучил пару базвордов и продолжаешь нести чушь в надежде запугать кого-то этими базвордами?

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

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

Или вот какая замечательная портянка: https://elixir.bootlin.com/linux/latest/source/arch/x86/lib/copy_user_64.S Знал ли автор, что на Netburst она работает хорошо, на Core значительно хуже,

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

а примерно так с Nehalem вообще хуже банального rep movsb

Опять эти ретрансляция неведомой херни слышанной в интернете. Я тебя открою тайну, но никаких rep movsb нету. К тому же, с чего вдруг он банальный? Ты о нём услышал лишь потому, что интел впилил руками эту портянку в процессор. Правда она всё равно сливает той самой портянке выше.

Всё что ты где-то слышал связано лишь с тем, что movq - это уже давно не предельная ширина. Хотя я вроде вас уже макал в дерьмо на этом примере, но вы ничему не учитесь.

А самое смешное даже не это. Уже сколько лет прошло, но деградация не останавливается. Как тогда ты услышал при мытье полов про l1i - так и продолжаешь повторять эту чушь.

Для тех кто не понял. Данный эсперт услышав про l1i решил, что анролл ненужен и теперь его триггерит на этом. А решил он потому, что прочитал рекламку от интела(причём какую именно он показать не смог).

В целом мотивацию подобных экспертов можно понять. Нужно как-то оправдывать свою неспособность и незнания. Поддержание подобных мифов позволяет бездарность разводить обывателя на бабки.

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

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

Типа? Что там за жопа такая? Если про то, что не понять сходу, куда барьер тыкать, так это микроархитектуры современные такие. Даже авторы этих микроархитектур не понимают, смотри на известные секьюрные баги в процах за последние пару лет.

помнится, где-то в крипте (в смысле, в библиотеках криптовалют) я видела самодельную ассемблерную портянку для криптографии.

Ну и что?

Для тех кто не понял. Данный эсперт услышав про l1i решил, что анролл ненужен и теперь его триггерит на этом. А решил он потому, что прочитал рекламку от интела(причём какую именно он показать не смог).

Ты мне скажи, тот анролл по ссылке - грамотный?

Ты мне скажи, тот анролл по ссылке - грамотный?

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

По поводу самого анролла. В достаточно адекватно. Засирать все регистры уже давно ненужно. Тут даже есть подъём начала путей наверх. Это уровень как минимум выше среднего.

Самое интересное тут то, что именно нехалем помножил на ноль твои последние возможные потуги в адрес анролла. Ведь раньше не имело смысл экономить и можно почти выкинуть анрол в связи со свободными портами для lea/dec, но в интел завезли smt и методичка сломалась. Уберёшь анрол - засрёшь соседний поток. Хотя для засирания даже не обязательно что-то занимать.

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