Есть идеи как улучшить?

Напиши программу на C, посмотри во что её собирает компилятор с -O3, сделай выводы.

У меня есть на си, думаешь это самый лучший вариант?

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

Перепиши на x86_64.

можно ли сделать какие нибудь улучшения

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

Зачем? Всё равно же на x86_64 она запускается.

В 32-битном режиме.

В 32-битном режиме.

Ну да. Зато работает на i386 и x86_64.

Перепиши на x86_64.

А я понел, это был совет как улучшить.

Перестать писать бессмысленные комментарии вроде add eax, edx ; прибавить к eax edx

Я думаю, можно бы было для данной задачи заюзать какие-нибудь расширения типа MMX, SSE* и подобные.

Вот. Зачем обрабатывать по символу, когда можно кусать по строке.

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

Совсем нет. Читаю modern x86 assembly language programming, примеры оттуда процентов на 20-30 быстрее чем код gcc7.1 с -O3. А в части примеров когда компилятор не додумывается что можно использовать SIMD, то разница десятикратная. В части примеров можно переписать C код, чтобы он лучше оптимизировался, но далеко не всегда. Так что это сказки про современные компиляторы. Как минимум нужно знать ассемблер чтобы понимать где можно применять SIMD, тогда можно инспектировать выбранные функции, чтобы посмотреть догадался ли компилятор об этом или нет, и если нет то переписать код/написать эту функцию на ассемблере.

Перестать писать бессмысленные комментарии вроде add eax, edx ; прибавить к eax edx

А так нормально то написано? Ничего лишнего? Или можно ещё сократить? Или есть команды, которые лучше подойдут?

Почему не amd64? Почему не AT&T синтаксис?

Почему не AT&T синтаксис?

Ну я пробывал gas использовать, мне конечно нравиться at&t синтаксис, но intel тоже нравиться. Тем более у at&t большой долг накопился. Intel тоже хороший синтаксис.

Почему не amd64?

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

Вносите царя.

Прежде всего, convert_char отвратительна. Работает только для ASCII, ничего, кроме 0, не проверяется. Используй что-либо другое.

Читай Кнута.

• есть инфа, что loop на современных процессорах работает заметно медленнее, чем просто dec ecx и jnz cycle.
• есть movzx, позволяющий не занулять регистр перед заполнением какой-то его части.

• or al, al ; сравнить
  

  для этого обычно используют test
• dec поддерживает работу с памятью, так что не нужно выгружать значение в регистр и потом записывать обратно

• xor ecx, ecx ; обнулить
mov ebx, 0 ; код выхода
  

  Выбрал бы один стиль и придерживался его.

А ещё в 2017 есть yasm, который чуть более фичаст, нежели nasm, и обладает нормальной поддержкой x86_64.

xor ecx, ecx ; обнулить mov ebx, 0 ; код выхода

Выбрал бы один стиль и придерживался его.

А ну да забыл. Тем более xor ecx, ecx быстрее этого варианта mov ebx, 0, потому как во второй варианте нужно работать с памятью, а это много времени занимает.

есть инфа, что loop на современных процессорах работает заметно медленнее, чем просто dec ecx и jnz cycle.

Откуда такая информация?

Нет описания зачем это нужно.

Нет описания зачем это нужно.

Нет описания чего?

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

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

Функция перевода из строки в число я взял из книги, там есть перевод и шестнадцатеричного числа и отрицательного числа.

Вот обсуждение этого явления и его причин, первоисточником же является, видимо, один из optimization guide-ов

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

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

Вот обсуждение этого явления и его причин, первоисточником же является, видимо, один из optimization guide-ов

Интересно да, что такая тема заводилась?

Ну я пробывал

Розенталя попробуй :)

Нет, не умнее

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80588

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68027

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71343

После call convert_char для sub al,'0' упал и умер. Выше абсолютно правильно посоветовали - посмотреть, как это сделает gcc.

Код топикстартера неэффективен, комментировать даже лень

Код топикстартера неэффективен, комментировать даже лень

Плохо что код на вас так повлиял, и как это код так смог лень на вас наложить?

Плохо то, что ты занимаешься засиранием лора своими глупыми вопросами, facepalm.jpg

Между прочим, вот те ссылки на gcc bugzilla, это все мои багрепорты

Плохо то, что ты занимаешься засиранием лора своими глупыми вопросами, facepalm.jpg

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

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

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

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

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

call для однострочника. Две стэковых операции на один примитивный sub. Это вообще ни в какие ворота.

Так мои вопросы почему-то намного умнее твоих оказываются.

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

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

И особенно быстрый парсинг целочисленных значений (комментарий) — этот код я сам в свое время сочинил. Ты б для начала написал код на Си, откомпилировал бы его, и потом подумал бы, а как его вообще можно улучшить с т.з. ассемблера.

http://l.wzm.me/_nezumi/optimize.htm читай тут

Семь китов оптимизации или Жизненный цикл оптимизации

Две стэковых операции на один примитивный sub.

А да, работа со стеком медленнее чем работа с глобальными переменными. Тогда можно без convert_char.

http://l.wzm.me/_nezumi/optimize.htm читай тут Семь китов оптимизации или Жизненный цикл оптимизации

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

Ты эту информацию отлично смог бы сам нагулить, а не создавать бессмысленные треды на ЛОРе

Ты эту информацию отлично смог бы сам нагулить, а не создавать бессмысленные треды на ЛОРе

Спасибо за принятие участие в моей сингулярности.

Што?

Не в этом суть: на одну быструю команду ты имеешь аж два обращения к стэку - на call и ret. И это только начало.

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

Например даже вот mov eax, 4 пример. Можно сделать быстрее, тоже самое, только быстрее, потому что не обращается к памяти.

xor eax, eax
times 4 inc al

С чего ты взял, что mov константы в регистр обращается к памяти? Константа просто кодируется в опкоде и поэтому его размер может получиться больше, чем какой-нибудь xor, однако это может в ряде случаев даже оказаться полезным (выравнивание инструкций, например).

С чего ты взял, что mov константы в регистр обращается к памяти?

Я в книжке прочитал. Там написан вариант с xor и inc, который в ряде случаешь будет быстрее ( смотря сколько inc ). Ты можешь у кого нибудь узнать, кто в этом разбирается, интересно было бы послушать. Но в книге же на станут врать.

Станут. Точнее, книга может попросту устареть и/или автор может ошибаться

http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimizati...

Страница 160 в pdf файле:

GENERAL OPTIMIZATION GUIDELINES
3.5.1.1 Use of the INC and DEC Instructions
The INC and DEC instructions modify only a subset of the bits in the flag register. This creates a dependence on all previous writes of the flag register. This is especially problematic when these instructions are on the critical path because they are used to change an address for a load on which many other instructions depend.

Assembly/Compiler Coding Rule 33. (M impact, H generality)
INC and DEC instructions should be replaced with ADD or SUB instructions, because ADD and SUB overwrite all flags, whereas INC and DEC do not, therefore creating false dependencies on earlier instructions that set the flags.

С чего ты взял, что mov константы в регистр обращается к памяти?

Но ты же не можешь скопировать число в переменную. mov [str], 0. Потому что из памяти в память нельзя, копировать из памяти можно только с помощью регистров. А если это так, то ноль в этом случае трактуется как копирование из памяти. mov eax, 0.

Я вот думал как заменить команду умножения, и вот, можешь сказать, это лучше этого imul ebx, ecx умножения?

  xor edx, edx
  mov edx, ebx
  shl ebx, 3
  shl edx, 1
  add ebx, edx