Из моих скудных познаний: ассемблер — язык, использующий аббревиатуры, напоминающие англ. язык. Всё это транслируется в объектный код особыми программами-ассемблерами. Так зачем использовать ассемблер сейчас, когда есть куда более удобные языки высокого уровня?? Неужели только из-за быстродействия?! И это в эпоху пентиумов4?

Здравствуйте WarlockFX, Вы писали:

WFX>зачем использовать ассемблер сейчас, когда есть куда более удобные языки высокого уровня?? Неужели только из-за быстродействия?! И это в эпоху пентиумов4? :???:

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

Здравствуйте Павел Кузнецов, Вы писали:

ПК> <...> Твой вопрос некоторым образом напоминает мне вопрос: зачем хирургу скальпель, когда он может использовать намного более функциональный супер-пупер армейский нож? <...>

ПК>Во-первых, не все компиляторы поддерживают набор команд последних версий процессоров. Во-вторых, некоторые команды процессоров, даже при наличии поддержки компилятора, не отображаются на язык/библиотеку.

В-третьих ручная оптимизация критических к скорости исполнения участков кода может увеличить производительность в полтора-два раза. Да пусть даже на 10% — и то хорошо.

Здравствуйте Igor Trofimov, Вы писали:

ПК>>Во-первых, не все компиляторы поддерживают набор команд последних версий процессоров. Во-вторых, некоторые команды процессоров, даже при наличии поддержки компилятора, не отображаются на язык/библиотеку.

IT>В-третьих ручная оптимизация критических к скорости исполнения участков кода может увеличить производительность в полтора-два раза. Да пусть даже на 10% — и то хорошо.

Если математику переписать с обычных C на SSE-инструкции, то можно и раза в 3 скорость увеличить... Т.е. если раньше P4 решал цифродробительную задачу целую ночь, то после оптимизации будет справляться за 3 часа =))
Правда, частенько "наборам команд последних версий процессоров" соответствуют интринтики, но даже с им иногда асм предпочтительнее.

Здравствуйте WarlockFX, Вы писали:

WFX>Из моих скудных познаний: ассемблер — язык, использующий аббревиатуры, напоминающие англ. язык. Всё это транслируется в объектный код особыми программами-ассемблерами. Так зачем использовать ассемблер сейчас, когда есть куда более удобные языки высокого уровня?? Неужели только из-за быстродействия?! И это в эпоху пентиумов4?

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

Здравствуйте Aquila, Вы писали:

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

Здравствуйте WarlockFX, Вы писали:

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

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

Здравствуйте Igor Trofimov, Вы писали:

IT>В-третьих ручная оптимизация критических к скорости исполнения участков кода может увеличить производительность в полтора-два раза. Да пусть даже на 10% — и то хорошо.


С этим третьим аунктом надо быть очень осторожным. Ассемблера надо по возможности избегать, даже в time-ctritical задачах. Мне вообще до ассемблеров дела нет, я и так весь ifdef'ах. У меня целевые платформы на основе StrongARM, SH4, 486+. А использование ассемблера везде где только можно — есть зло. Некоторые программеры еще с собой носят самопальные библиотеки всяческих полезных функций на ассемблере. Поэтому сил на использование _T("") вместо "" уже не остается. Короче, я к тому, что 10% — это НИЧТО, ноль, пустое место! За эти 10% мы получаем непереносимый код, потребность в более квалифицированных программистах, кучу потенциальных ошибок и несколько самых настоящих. Например, софт для 200 мгц стронгарма (без сопроцессора!) прекрасно обходится без каких-либо ассемблерных вставок, хотя критических по времени задач много. Юзеры просто соглашаются с частичной потерей данных.

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

X>С этим третьим аунктом надо быть очень осторожным. Ассемблера надо по возможности избегать, даже в time-ctritical задачах.

Не уверен, что твео мнение разделяют разработчики, реализующие криптографические алгоритмы, обработку аудио/видео, realtime-3D и проч.

X>А использование ассемблера везде где только можно — есть зло.

Никто не говорит "везде, где можно".

X>Короче, я к тому, что 10% — это НИЧТО, ноль, пустое место!

Думаю, вышеперечисленные люди с тобой не согласятся... Представь, что один mp3-кодек будет на 10% быстрее второго при одинаковых остальных показателях. Это очень неплохой разрыв — 10%.

Здравствуйте Igor Trofimov, Вы писали:

X>>Ассемблера надо по возможности избегать, даже в time-ctritical задачах.

IT>Не уверен, что твео мнение разделяют разработчики, реализующие криптографические алгоритмы, обработку аудио/видео, realtime-3D и проч.

Я, конечно, не все "разработчики, реализующие криптографические алгоритмы, обработку аудио/видео, realtime-3D и проч.", но работаю в области, сильно завязанной на все вышеперечисленное. Куски кода, когда-то написанные на ассемблере, "мочим" при первой встрече при сопровождении старого кода. При написании нового по возможности избегаем. Т.е., если что-то удается написать без использования ассемблера, без существенной потери эффективности, пишем на C/C++.

IT>Представь, что один mp3-кодек будет на 10% быстрее второго при одинаковых остальных показателях. Это очень неплохой разрыв — 10%.

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

Ассемблер прекрасно вписывается в места, где нужно сделать что-нибудь, что невозможно сделать на C/C++: определить тип или вызвать специфическую команду процессора, что-нибудь "намутить" со стеком/вызовами в блоке защиты, написать шаблоны для кодогенератора и т.п. И, конечно, иногда соптимизировать "узкое" место, но только как последнее средство для этого, ибо <... читай подпись ...>

Здравствуйте Igor Trofimov, Вы писали:

X>>Короче, я к тому, что 10% — это НИЧТО, ноль, пустое место!

IT>Думаю, вышеперечисленные люди с тобой не согласятся... Представь, что один mp3-кодек будет на 10% быстрее второго при одинаковых остальных показателях. Это очень неплохой разрыв — 10%.

С точки зрения декодирования МП3: большинство американских пользователей все равно предпочитают пользоваться WMP. С точки зрения кодирования: создатели кодеков бьются над увеличением степени сжатия и реалистичности. Если я занимаюсь сжатием МП3 и плачу за кодек несколько сот баксов, то я запросто отдам еще стольник за более мощный процессор. На крайний случай поставлю рядом еще один компьютер 9или еще один процессор).

Это вопрос действительно философский, почти что как выход по goto из вложенных циклов.

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

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

ПК>Я, конечно, не все "разработчики, реализующие криптографические алгоритмы, обработку аудио/видео, realtime-3D и проч.", но работаю в области, сильно завязанной на все вышеперечисленное. Куски кода, когда-то написанные на ассемблере, "мочим" при первой встрече при сопровождении старого кода. При написании нового по возможности избегаем. Т.е., если что-то удается написать без использования ассемблера, без существенной потери эффективности, пишем на C/C++.

Именно о существенной потере и может идти речь. 10% — это так, мелочи... а как насчет 50%? Не удивлюсь, если после ручной оптимизации такого разрыва можно будет достичь. Есть например, замечательный пример, когда за счет использования команды adc можно добавить к числу c бит переноса от сложения a и b. Это применяется, например, в одном из алгоритмов рисования отрезка прямой. Т.е. на асме — две команды — add и adc. На C... покажи, как ты это сделаешь на C. Шикарный пример ручной оптимизации — алгоритм текстурирования из Quake — цикл развернут на 16 итераций таким образом, чтобы за одну неразвернутую итерацию происходило одно параллельно выполняющееся на FPU деление. Т.е. получается огромный эффект от параллелизма CPU/FPU. Т.е. фактически даром — 50% производительности.

Здравствуйте Xentrax, Вы писали:

X>Здравствуйте Igor Trofimov, Вы писали:

IT>>В-третьих ручная оптимизация критических к скорости исполнения участков кода может увеличить производительность в полтора-два раза. Да пусть даже на 10% — и то хорошо.

X>
X>С этим третьим аунктом надо быть очень осторожным. Ассемблера надо по возможности избегать, даже в time-ctritical задачах. Мне вообще до ассемблеров дела нет, я и так весь ifdef'ах. У меня целевые платформы на основе StrongARM, SH4, 486+. А использование ассемблера везде где только можно — есть зло. Некоторые программеры еще с собой носят самопальные библиотеки всяческих полезных функций на ассемблере. Поэтому сил на использование _T("") вместо "" уже не остается. Короче, я к тому, что 10% — это НИЧТО, ноль, пустое место! За эти 10% мы получаем непереносимый код, потребность в более квалифицированных программистах, кучу потенциальных ошибок и несколько самых настоящих. Например, софт для 200 мгц стронгарма (без сопроцессора!) прекрасно обходится без каких-либо ассемблерных вставок, хотя критических по времени задач много. Юзеры просто соглашаются с частичной потерей данных.

X>А вот первые два пункта имеют место быть: к сожалению, бывают случаи, когда асм нужен. Например, когда нет компилятора Визуал Бейсика под какой-нибудь новый процессор. Или когда ну очень надо использовать какую-нибудь новомодную SSE инструкцию.


Не смешите меня "переносимым кодом"....
Я тут вижу все об оптимизации говорят...
А да что мне та оптимизация....


Если бы в разработке алгоритмов меня удовлетворял С/С++, я б и не смотрел на асм...
Но не удовлетворяет...
А вот почему ... это уже другая сказка

Здравствуйте Edmond, Вы писали:



E>Не смешите меня "переносимым кодом"....

Я не смешу, у нас реальзно без каких либо модификаций работает под Windows CE и Win32 куча кода, написанного умным человеком еще для Psion. Один и тот же код собирается для нескольких процессоров. Есть конечно некоторые особенности, связанные с глюками в SDK и сыростью некоторых платформ, но их очень мало.

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

Здравствуйте Xentrax, Вы писали:

X>Здравствуйте Edmond, Вы писали:

X>

E>>Не смешите меня "переносимым кодом"....

X>Я не смешу, у нас реальзно без каких либо модификаций работает под Windows CE и Win32 куча кода, написанного умным человеком еще для Psion. Один и тот же код собирается для нескольких процессоров. Есть конечно некоторые особенности, связанные с глюками в SDK и сыростью некоторых платформ, но их очень мало.

Да кто ж этого против

Но как правило этот переносимый код -- действительно независимые от среды задачи!!!

X>Для меня переносимость — не пустой звук. Поэтому к ассемблеру отношуть крайне отрицательно,



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

Гм..., боюсь, что время "восторгов" для меня прошло....
Да и какое-то странное у вас представление: ломать, переключать....

Здравствуйте Edmond, Вы писали:

E>Но как правило этот переносимый код -- действительно независимые от среды задачи!!!

Как оказалось, Win32 можно перенести куда угодно. Даже на устройства с 4 — 8 мегами памяти, не говоря уже о современных 64-128 с флешками по 512 мб

E>Гм..., боюсь, что время "восторгов" для меня прошло....
E>Да и какое-то странное у вас представление: ломать, переключать....

Просто я не понимаю, почему многие используют ассемблер там, где он не нужен. Я считаю, что только потому, что нравится. Однажды встала задача заменить системный диалог открытия файла. Я, всегда ратующий за code reusability (а потому с отвтращением приступивший к выполнению очередной блажи руководства), решил поискать что-нибудь в инете. В нескольких вариантах я нашел ассемблерные вставки. И эти реализации отправилиcь в /dev/nul. Но я прекрасно понимаю авторов: им было "по приколу". До сих пор многие программисты даже не знают про юникод, Конечно, елси так подходить к прогарммированию, то про переносимость можно забыть.


А еще я вот сейчас сижу и думаю, что будут делать дорогие наши любители ассемблерных вставок после прехода на архитектуру IA-64? Лично я просто нажму Ctrl-Shift-B.

Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы?

Здравствуйте <Аноним>, Вы писали:

А>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы?

А что MMX и SSE компиляторам не доступны?

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте <Аноним>, Вы писали:

А>>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы?
VD>А что MMX и SSE компиляторам не доступны?

Например?