Почему? Я слышал, что он уже почти не используется

Стикер

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

Я имею ввиду учить, чтобы использовать на практике, а не просто потому что надо)

Там соглашения о вызовах проще

RISK/VLIW

когда ты учился читать в детстве, ты использовал букварь или словарь Даля?

С такой точки зрения лучше вообще с ДОС начинать

Даля

тогда можно ожидать еще большее недовольство

Ну так лучше быть последовательным

На практике скорей всего x86-64. Просто для обучения лучше arm или risc-v

Стикер

Очевидно, aarch64

Используется, потому что более совместим со старыми ПК, а ещё вес меньше на выходе. В настоящий момент лучше писать на 32-х битную систему, чем на 64-х битную. Минусов от этого практически никаких.

Регистров больше на х64 зато, писать удобнее если программа не состоит из чисто вызовов функций

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

🤔😳 Привет КТ315! Точно меньше? Наоборот же -> больше информации распихивать по регистрам - это хорошо

А что хорошего?

скорость доступа

Почему как можно меньше?

А где я писал "использовать меньше регистров, и больше памяти"? Я написал "использовать меньше регистров", я на x86 справляюсь и с EAX/EDX/ECX/EBX/ESI/EDI/EBP, даже не сохраняя их. Всё дело в продуманности алгоритма и его последовательности. Например, при обработке данных с файла - ты можешь, например, писать в тот же файл, и держать на дескриптор один регистр, а можешь в конце открыть файл ещё раз, либо писать в новый файл - и вот у тебя один свободный регистр. Скорость от этого особо не пострадает.

Стикер

Чтобы хеловорлд не раздуть до 1.5 гигов.

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

Не, ну скорость исполнения тоже не надо задвигать в дальний угол.

Тоже верно.

1,5 гига чего? статической памяти?😄

Экзешник

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

запакуй UPX'ом )

Ох как же после такого скорость исполнения упадёт))) атя-тя.

с чего она упадёт? он же распакуется и будет работать как и незапакованный

распакуется.

2 секунды распаковка 10 минут работы несущественно

Стикер

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

? что за бред

https://t.me/proasm/79017

ещё раз 2 секунды распаковки и 10 минут работы 10*60= 600секунд 2/600 = 0,3% времени работы вы ж сами говорите за алгоритмы, лучше улучшить алгоритм и получить +10% чем бодаться с 0.3% не так ли?

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

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

это лишь ответ был барону что он так печётся за 1,5 гиговые хеллоу ворлды ) а так-то зачем паковать, согласен

а вот какие алгоритмы ты уже писал?

сортировка пузырьком

не понял, что это

алгоритм сортировки )

Вещь, которую все новички пишут, но использовать на деле будут только лет через 10.

он тяжелый?

легкий