Assembler. С чего начать?

akorop	# 8 лет, 7 месяцев назад
Темы: 111 Сообщения: 1755 Участник с: 29 февраля 2012	anode akorop Непереносимость кода может вообще не быть недостатком. В таких случаях надо приводить примеры. Хочется услышать о достоинствах непереносимости кода. Вы плохо умеете читать? Я не говорил о достоинствах. А не быть недостатком это может, например, в уникальном изделии с ограниченным сроком службы. anode Все ваши "настоящие недостатки" являются следствием другой причины: отсутствие необходимой квалификации у программиста. То есть Вы предлагаете в список недостатков добавить ещё один: 5. Более высокие требования к квалификации программиста. Согласен. Теоретики, блин...

# 8 лет, 7 месяцев назад

Сообщения: 1755

Участник с: 29 февраля 2012

anode
akorop
Непереносимость кода может вообще не быть недостатком.
В таких случаях надо приводить примеры. Хочется услышать о достоинствах непереносимости кода.

Вы плохо умеете читать? Я не говорил о достоинствах. А не быть недостатком это может, например, в уникальном изделии с ограниченным сроком службы.

anode
Все ваши "настоящие недостатки" являются следствием другой причины: отсутствие необходимой квалификации у программиста.

То есть Вы предлагаете в список недостатков добавить ещё один: 5. Более высокие требования к квалификации программиста. Согласен.

Теоретики, блин...

Rarog	# 8 лет, 7 месяцев назад
Темы: 10 Сообщения: 188 Участник с: 22 января 2013	akorop Притом быстродействие снижается раза в три всего по сравнению с C. Ну и в результате чего тогда снижается быстродействие, если не из-за "обверток" интерпретатора? P.S. В три раза, всего навсего....

Natrio	# 8 лет, 7 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	akorop, вы настолько упорны в отстаивании ваших радикальных убеждений вида "Ассемблер – ЗЛО", что хватаетесь за самые сомнительные доводы вместо доказательств, при этом требуете доказательств от оппонентов :) На что вы рассчитывали утверждая, что LAME без использования MMX/SSE догоняет сам себя с MMX/SSE? Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора? Когда я несколько лет назад устанавливал дистрибутивы, где LAME был собран БЕЗ ассемблера, а потом пересобирал его с ассемблером, производительность кодека на тогдашних процессорах возрастала примерно в два раза. С тех пор LAME не сильно изменился, он вообще довольно старинный кодек, как и формат MP3. Неужели вы верите, что столько ассемблерного кода в нём было написано для красоты, когда в нём уже был обычный код не хуже? Ваш пример показывает только то, что при выключенном ассемблере (кстати, его выключение в LAME не требует пересборки), была использована внешняя математика, в которой со времён создания LAME ТОЖЕ появились ассемблерные процедуры, задействующие векторные инструкции процессора. А теперь отложим в сторону старый добрый LAME, и возьмём куда более современный x264. Вы ведь его не тестили, да? ~~Раз пошла такая пьянка,~~ давайте затестим. Берём небольшенький ролик, и перекодируем его утилитой ffmpeg, сначала с нормальной сборкой x264: $ time ffmpeg -i test.mkv -map 0:0 -vcodec libx264 -crf 20 /tmp/test.mkv ... [libx264 @ 0x87256c0] using cpu capabilities: MMX2 SSE2 Cache64 ... real 2m4.971s user 3m50.037s sys 0m2.873s а потом ставим пересборку x264 с опцией --disable-asm , и кодируем тот же файлик ещё раз: $ time ffmpeg -i test.mkv -map 0:0 -vcodec libx264 -crf 20 /tmp/test.mkv ... [libx264 @ 0x91ca6c0] using cpu capabilities: none! ... real 7m17.103s user 12m52.890s sys 0m5.100s Итого, ассемблерные вставки в x264 дают, оказывается, при кодировании данного ролика с данными параметрами на данном процессоре ускорение в три раза. (Я думал, будет меньше:)

Natrio

# 8 лет, 7 месяцев назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

akorop, вы настолько упорны в отстаивании ваших радикальных убеждений вида "Ассемблер – ЗЛО", что хватаетесь за самые сомнительные доводы вместо доказательств, при этом требуете доказательств от оппонентов :)

На что вы рассчитывали утверждая, что LAME без использования MMX/SSE догоняет сам себя с MMX/SSE? Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора?

Когда я несколько лет назад устанавливал дистрибутивы, где LAME был собран БЕЗ ассемблера, а потом пересобирал его с ассемблером, производительность кодека на тогдашних процессорах возрастала примерно в два раза. С тех пор LAME не сильно изменился, он вообще довольно старинный кодек, как и формат MP3. Неужели вы верите, что столько ассемблерного кода в нём было написано для красоты, когда в нём уже был обычный код не хуже? Ваш пример показывает только то, что при выключенном ассемблере (кстати, его выключение в LAME не требует пересборки), была использована внешняя математика, в которой со времён создания LAME ТОЖЕ появились ассемблерные процедуры, задействующие векторные инструкции процессора.

А теперь отложим в сторону старый добрый LAME, и возьмём куда более современный x264. Вы ведь его не тестили, да? ~~Раз пошла такая пьянка,~~ давайте затестим. Берём небольшенький ролик, и перекодируем его утилитой ffmpeg, сначала с нормальной сборкой x264:

$ time ffmpeg -i test.mkv -map 0:0 -vcodec libx264 -crf 20 /tmp/test.mkv
...
[libx264 @ 0x87256c0] using cpu capabilities: MMX2 SSE2 Cache64
...
real    2m4.971s
user    3m50.037s
sys     0m2.873s

а потом ставим пересборку x264 с опцией --disable-asm , и кодируем тот же файлик ещё раз:

$ time ffmpeg -i test.mkv -map 0:0 -vcodec libx264 -crf 20 /tmp/test.mkv
...
[libx264 @ 0x91ca6c0] using cpu capabilities: none!
...
real    7m17.103s
user    12m52.890s
sys     0m5.100s

Итого, ассемблерные вставки в x264 дают, оказывается, при кодировании данного ролика с данными параметрами на данном процессоре ускорение в три раза. (Я думал, будет меньше:)

maisvendoo	# 8 лет, 7 месяцев назад
Темы: 68 Сообщения: 1142 Участник с: 10 октября 2012	Natrio Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора? Очевидно, что никакой оптимизирующий компилятор не в состоянии выжать максимум возможностей из конкретной железяки Об оптимизации в компиляторах Довольно любопытно. Самой вкусное - вывод: Современные методики оптимизации носят довольно противоречивый характер. С одной стороны они улучшают код, с другой - страдают непредсказуемыми побочными эффектами. Natrio ассемблерные вставки ммм, с недавних пор у меня именно к вставкам сложное отношение. Хотя в ряде случаев я и ошибался по их поводу. Да пребудет с нами Сила...! CPU Intel Core i9 10900-KF/RAM DDR4 128 Gb/NVidia GForce GTX 1080 Ti Turbo 11Gb/SSD M2 512 Gb/HDD Seagate SATA3 2 Tb/HDD Toshiba 3Tb/HDD Toshiba 6Tb http://rusrailsim.org

maisvendoo

# 8 лет, 7 месяцев назад

Темы: 68

Сообщения: 1142

Участник с: 10 октября 2012

Natrio
Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора?

Очевидно, что никакой оптимизирующий компилятор не в состоянии выжать максимум возможностей из конкретной железяки

Об оптимизации в компиляторах
Довольно любопытно. Самой вкусное - вывод:

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

Natrio
ассемблерные вставки

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

Да пребудет с нами Сила...!
CPU Intel Core i9 10900-KF/RAM DDR4 128 Gb/NVidia GForce GTX 1080 Ti Turbo 11Gb/SSD M2 512 Gb/HDD Seagate SATA3 2 Tb/HDD Toshiba 3Tb/HDD Toshiba 6Tb
http://rusrailsim.org

Natrio	# 8 лет, 7 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	maisvendoo ммм, с недавних пор у меня именно к вставкам сложное отношение Виноват, исправил. Я не имел в виду конкретно инлайн.

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	akorop А сколько будет стоить падение такой программы? Или задержка внедрения новой фичи? Вот уж где ассемблером и не пахнет, я думаю, так это в подобных областях. Интересно было бы узнать реальное положение, а не имхами мериться. Да, конечно, гугл заниматься такой ерундой, как переписывание своих сервисов на ассемблере, не будет. Слишком мелко и специфично. Ко всему прочему и цена поддержки возрастает. Там поступают по принципу переиспользования технологий. Оптимизацией занимаются совсем другие команды. Взять хотя бы релиз нового языка go от гугл. Т.е. разрабатывается инструмент, где и происходят оптимизации под платформу. А потом этот инструмент используется для разработки более высокоуровневых сервисов. Или фейсбук с его HHVM: PHP -> байт-код с JIT. А что есть есть JIT, как не оптимизация с привязкой к архитектуре? akorop Во-вторых, в серьёзном производстве замена программы подразумевает такую кучу затрат Это каких? Никто не говорит, про полное переписывание на ассемблере. Оптимизируются критические места на месте затыка, прогоняются авто-тесты, чтобы не было косяков. Что-то мне подсказывает, что взять другой контроллер подребует больших затрат. Хороший вариант: берем более быстрый микроконтроллер той-же серии, совместимый по пинам, +1$ предположим. На серии в 10к единиц имеем +10к $. Плохой вариант: другой, не совместимый по пинам и разводке, контроллер -> перепроектирование платы, создание опытного обзазца, тестирование, возможно, переписывание и тестирование прошивки... Конечно, если железо с самого начала было выбрано неудачно - тут уж никакая оптимизация не поможет. akorop Если уж на то пошло, то программа для современного x86 процессора - это фактически байт-код, только интерпретируется он не программно, а аппаратно. Я уже, кажется, раньше писал про микрокод. Как бы он не менялся, но xor rax, rax бедет всегда быстрее mov rax, 0. akorop Единственное осмысленное использование ассемблера - это крохотные вставки в программе на ЯВУ. И цель этих вставок - не повышение вычислительной эффективности самой вставки, а реализация чего-то такого, что в языке выразить нечем. Спорно. Пример с x264 вам уже приводили. А полагаться на оптимизацию компилятора как на серебряную пулю тоже не стоит. Он не идеален, его тоже люди пишут. akorop А что касается спроса, то я погуглил маленько, и первые же ссылки (например, тут и тут) показали, вполне ожидаемо, что спроса на ассемблер-программистов нет вообще. ...это примерно как готовиться в космонавты. А кто про спрос говорил? Тут к гадалке не ходи, востребованость таких спецов минимальна. Но потому они и ценятся. Ведь кто-то должен быть космонавтом, правда? Не всем же по земле ползать :) naszar Ну вот, опять к желтой прессе отсылают.. Зачем про мыша плохо говоришь?

farwayer

# 8 лет, 7 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

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

Да, конечно, гугл заниматься такой ерундой, как переписывание своих сервисов на ассемблере, не будет. Слишком мелко и специфично. Ко всему прочему и цена поддержки возрастает. Там поступают по принципу переиспользования технологий. Оптимизацией занимаются совсем другие команды. Взять хотя бы релиз нового языка go от гугл. Т.е. разрабатывается инструмент, где и происходят оптимизации под платформу. А потом этот инструмент используется для разработки более высокоуровневых сервисов. Или фейсбук с его HHVM: PHP -> байт-код с JIT. А что есть есть JIT, как не оптимизация с привязкой к архитектуре?

akorop
Во-вторых, в серьёзном производстве замена программы подразумевает такую кучу затрат

Это каких? Никто не говорит, про полное переписывание на ассемблере. Оптимизируются критические места на месте затыка, прогоняются авто-тесты, чтобы не было косяков. Что-то мне подсказывает, что взять другой контроллер подребует больших затрат.
Хороший вариант: берем более быстрый микроконтроллер той-же серии, совместимый по пинам, +1$ предположим. На серии в 10к единиц имеем +10к $.
Плохой вариант: другой, не совместимый по пинам и разводке, контроллер -> перепроектирование платы, создание опытного обзазца, тестирование, возможно, переписывание и тестирование прошивки...
Конечно, если железо с самого начала было выбрано неудачно - тут уж никакая оптимизация не поможет.

akorop
Если уж на то пошло, то программа для современного x86 процессора - это фактически байт-код, только интерпретируется он не программно, а аппаратно.

Я уже, кажется, раньше писал про микрокод. Как бы он не менялся, но xor rax, rax бедет всегда быстрее mov rax, 0.

akorop
Единственное осмысленное использование ассемблера - это крохотные вставки в программе на ЯВУ. И цель этих вставок - не повышение вычислительной эффективности самой вставки, а реализация чего-то такого, что в языке выразить нечем.

Спорно. Пример с x264 вам уже приводили. А полагаться на оптимизацию компилятора как на серебряную пулю тоже не стоит. Он не идеален, его тоже люди пишут.

akorop
А что касается спроса, то я погуглил маленько, и первые же ссылки (например, тут и тут) показали, вполне ожидаемо, что спроса на ассемблер-программистов нет вообще. ...это примерно как готовиться в космонавты.

А кто про спрос говорил? Тут к гадалке не ходи, востребованость таких спецов минимальна. Но потому они и ценятся. Ведь кто-то должен быть космонавтом, правда? Не всем же по земле ползать :)

naszar
Ну вот, опять к желтой прессе отсылают..

Зачем про мыша плохо говоришь?

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Natrio Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора? Вот, кстати, забыл про это написать. Если ты не будешь знать, во что компилятор преобразует твой код, ты в жизнь не напишешь код, который свернется в SIMD. А то, блин, дожили до времени, когда C/C++ программер не знает, что такое стек и почему нужно проверять длину входящих данных. Ассемблер нужно знать, не для того, чтобы на нем писать. Это очень редко бывает необходимо. Знать нужно, чтобы более эффективно и безопасно писать на том же самом C/C++.

farwayer

# 8 лет, 7 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

Natrio
Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора?

Вот, кстати, забыл про это написать. Если ты не будешь знать, во что компилятор преобразует твой код, ты в жизнь не напишешь код, который свернется в SIMD. А то, блин, дожили до времени, когда C/C++ программер не знает, что такое стек и почему нужно проверять длину входящих данных.

Ассемблер нужно знать, не для того, чтобы на нем писать. Это очень редко бывает необходимо. Знать нужно, чтобы более эффективно и безопасно писать на том же самом C/C++.

nafanja	# 8 лет, 7 месяцев назад
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	оффтоп да, сегодняшние коммерческие программисты напишут кода на пару строк, а бабла хотят как будто бы все с нуля на асеме написали. печалька. Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 8 лет, 7 месяцев назад

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

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

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	RAMZAY слышал о трёх атрибутах "хакеров":с++ , ассемблер,линукс. А про цвет носков там ничего не было? :)))

Aivar	# 8 лет, 7 месяцев назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	Тенденция: чем мощнее железо, тем выше уровень языка программирования, тем ленивее программист. Припоминаю конторы, которые под заказ писали только на Turbo Pascal'е.