Здравствуйте Aquila, Вы писали:
А>>>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы? VD>>А что MMX и SSE компиляторам не доступны?
A>Например?
Intel С++ 5-6
Думаю, что через год-два и Шарповский будет кое-что поддерживать.
Здравствуйте VladD2, Вы писали:
А>>>>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы?VD>>>А что MMX и SSE компиляторам не доступны? A>>Например? VD>Intel С++ 5-6
Это все? Небогатый выбор. Тем не менее на то, что он все-таки имеется, там где требуется хорошая оптимизация, пишут на ассемблере. Впрочем, на ассемблере можно писать и когда оптимизация не требуется, благо язык не слишком сложный.
VD>Думаю, что через год-два и Шарповский будет кое-что поддерживать.
А зачем ему? Он же под VM генерит. VM, по идее, должна отвечать за генерацию реального кода.
Здравствуйте Aquila, Вы писали:
A>Это все? Небогатый выбор. Тем не менее на то, что он все-таки имеется, там где требуется хорошая оптимизация, пишут на ассемблере. Впрочем, на ассемблере можно писать и когда оптимизация не требуется, благо язык не слишком сложный.
VD>>Думаю, что через год-два и Шарповский будет кое-что поддерживать.
A>А зачем ему? Он же под VM генерит. VM, по идее, должна отвечать за генерацию реального кода.
Оптимизацию алгоритмов будет делаться помпиляторм Шарпа и других языков. Ну, а оптимизацию под процессор безусловно должен делать JIT. Я же рассматривал эти вещи совместно. Т.е. с точи зрения использования MMX и т.п. конечно нужно развивать не "компилятор с языка", а JIT.
Здравствуйте Аноним, Вы писали:
А>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы?
100-200% — это уже совсем не 10%. Кроме того, речь идет о продукте, о котором нельзя сказать: "пользователь может подождать чуть подольше" (работа не-лету), "пускай купит машину помощнее" (и так уже мощная) и "через год выйдет пентиум 10 и все будет тип-топ" (продукт нужен немедленно).
Но и тут наверное лучше не самому писать на ассемблере, а попробовать использовать интеловские библиотеки...
Здравствуйте VladD2, Вы писали:
A>>Это все? Небогатый выбор. Тем не менее на то, что он все-таки имеется, там где требуется хорошая оптимизация, пишут на ассемблере. Впрочем, на ассемблере можно писать и когда оптимизация не требуется, благо язык не слишком сложный. VD>
Всяко попроще, чем C# .
VD>>>Думаю, что через год-два и Шарповский будет кое-что поддерживать. A>>А зачем ему? Он же под VM генерит. VM, по идее, должна отвечать за генерацию реального кода. VD>Оптимизацию алгоритмов будет делаться помпиляторм Шарпа и других языков.
IlAsm
VD>Ну, а оптимизацию под процессор безусловно должен делать JIT. Я же рассматривал эти вещи совместно. Т.е. с точи зрения использования MMX и т.п. конечно нужно развивать не "компилятор с языка", а JIT.
Здравствуйте Xentrax, Вы писали:
X>Здравствуйте Edmond, Вы писали:
E>>Но как правило этот переносимый код -- действительно независимые от среды задачи!!!
X>Как оказалось, Win32 можно перенести куда угодно. Даже на устройства с 4 — 8 мегами памяти, не говоря уже о современных 64-128 с флешками по 512 мб
??? Например???
E>>Гм..., боюсь, что время "восторгов" для меня прошло.... E>>Да и какое-то странное у вас представление: ломать, переключать....
X>Просто я не понимаю, почему многие используют ассемблер там, где он не нужен. Я считаю, что только потому, что нравится.
Такая трактовка действительно есть....
Однажды встала задача заменить системный диалог открытия файла. Я, всегда ратующий за code reusability (а потому с отвтращением приступивший к выполнению очередной блажи руководства), решил поискать что-нибудь в инете. В нескольких вариантах я нашел ассемблерные вставки. И эти реализации отправилиcь в /dev/nul. Но я прекрасно понимаю авторов: им было "по приколу". До сих пор многие программисты даже не знают про юникод,
Бедненькие
Конечно, елси так подходить к прогарммированию, то про переносимость можно забыть.
А что переносимоть????
Недавно был разговор об переносе асма с платформы на платформу....
И это не так уж невозможно....
X> X>А еще я вот сейчас сижу и думаю, что будут делать дорогие наши любители ассемблерных вставок после прехода на архитектуру IA-64? Лично я просто нажму Ctrl-Shift-B.
Что делать? Выход есть....
Вы мне скажите что будут делать программисты, есил тенденция полёта ЯВУ в верх не смениться.....
Здравствуйте Xentrax, Вы писали:
X>До сих пор многие программисты даже не знают про юникод,
Проблема в том, что про юникод не "знает" Win98 (в которой нет большинства ****W функций), а совместимость с этой операционкой зачастую гораздо более важна, чем с WinCE .
X>А еще я вот сейчас сижу и думаю, что будут делать дорогие наши любители ассемблерных вставок после прехода на архитектуру IA-64? Лично я просто нажму Ctrl-Shift-B.
Здравствуйте Aquila, Вы писали:
A>>>Это все? Небогатый выбор. Тем не менее на то, что он все-таки имеется, там где требуется хорошая оптимизация, пишут на ассемблере. Впрочем, на ассемблере можно писать и когда оптимизация не требуется, благо язык не слишком сложный. VD>>
A>Всяко попроще, чем C# .
Это точно. Не нужно переменные описывать лишние и заморачиваться отступами. Хотя есть несознательные ассемблерщики которые навязывают этот дикий ситль! И ты не поверишь... есть те которые используют табуляцию или 2-4 пробела на отступ!!! Зачем так усложнять жизнь?!
A>Интересно, получится ли это у Микрософта?
Меня волнует другой вопрос... не заведет ли к этому моменту MS себе новую игрушку?!
X>>Как оказалось, Win32 можно перенести куда угодно. Даже на устройства с 4 — 8 мегами памяти, не говоря уже о современных 64-128 с флешками по 512 мб
E>??? Например???
Да полно таких, ключевой слово — Windows CE. Наша фирма даже свою разрабатывает.Внутренняя флешка на 64 мб и отсек для дополлнительной флешки. Памяти пока ставят всего 32 мега, но железка пока сырая, и думаю, скоро будут савить 64 (у нас в фирме очень хреновые программисты софта, поэтому в 18 мегов свободной оперативки уже не влезаем).
E> До сих пор многие программисты даже не знают про юникод,
E>Бедненькие
Ага, еще как. Особенно когда им предлагают выпустить японскую версию
E>Конечно, елси так подходить к прогарммированию, то про переносимость можно забыть.
E>А что переносимоть????
Переносимость — это когда код не требует серьезной переделки, чтобы работаьт где-то еще.
E>Недавно был разговор об переносе асма с платформы на платформу....
Это экономически не обосновано, как мне кажется. Заниматься такой фигней .
X>> X>>А еще я вот сейчас сижу и думаю, что будут делать дорогие наши любители ассемблерных вставок после прехода на архитектуру IA-64? Лично я просто нажму Ctrl-Shift-B.
E>Что делать? Выход есть....
Какой выход? Насколько я понимаю, 32 разрядный код будет исполнятся на ИА-64 медленно. Или есть какие-то умные конвертеры из машинного кода из х486+ в ИА-64?
E>Вы мне скажите что будут делать программисты, есил тенденция полёта ЯВУ в верх не смениться.....
Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами. Но до этого еще относительно далеко. Пока можно развлекаться ловлей суперхитрых багов.
Здравствуйте VladD2, Вы писали:
VD>А что MMX и SSE компиляторам не доступны?
Насчет MMX и SSE — не знаю. Но я еще не видел компилятора, который перебор массива целых в цикле превращал в конструкцию :
LOCK REPNE SCASD
А более быстрого варианта решения задачи прямого перебора массива в памяти я ешшо не встречал
Хотя, возможно, есть еще более наворочаные инструкции процессоров из SSE/SSE2 — я с ними не особо знаком, но и там будет аналог данного алгоритма, а не что-то другое, так что увы других вариантов нет.
Дело в том, что разработчик, имеющий представление о данных, всегда может соптимизировать код (иногда — ТОЛЬКО с применением ассемблера) так, чтобы он работал быстрее, чем то, что нагенерит самый наворочаный компилятор ЯВУ. Увы, но это — так.
Как и многие высказавшиеся я считаю, что ассемблер — это один из последних шагов оптимизации, зато после него уже нет вариантов, да и сомнений в скорости не остается.
Еще одно важное преимущество ассемблера — достаточно малый исполняемый код. Программа, которая будет целиком (и правильно) написана на ассемблере — совсем маленькая программа.
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте Edmond, Вы писали:
E>А что переносимоть???? E>Недавно был разговор об переносе асма с платформы на платформу.... E>И это не так уж невозможно....
Да... все, наверное хоть слышали про замечательные компутеры Yamaha и Spectrum??? (ну и прочие из семейства Z80, туда же, по-моему относилась Amiga).
Так вот. Данные компьютеры (а вернее — процессор) на 100% совместимы с Intel 8086 на уровне машинного кода. так что вот
некоторая специфика, конечно есть, конкретику приводить сечас не буду, но сам факт — на лицо.
Люди писали на Yamaha достаточно приятные программки на ассемблере и балдели от их маленького размера и высокого быстродействия.
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте Hacker_Delphi, Вы писали:
HD>Да... все, наверное хоть слышали про замечательные компутеры Yamaha и Spectrum??? (ну и прочие из семейства Z80, туда же, по-моему относилась Amiga).
Амига к z80 никаким боком не относится. Совершенно иная система — в Amiga стоят процы от Motorola (680x0, 603e, 604e, etc), которые несовместимы с Intel.
HD>Так вот. Данные компьютеры (а вернее — процессор) на 100% совместимы с Intel 8086 на уровне машинного кода. так что вот
Неправда твоя Z80 совместим только с i8080.
Re[10]: зчем нужен ассемблер??
От:
Аноним
Дата:
28.10.02 07:25
Оценка:
Здравствуйте Hacker_Delphi, Вы писали:
HD>Да... все, наверное хоть слышали про замечательные компутеры Yamaha и Spectrum??? (ну и прочие из семейства Z80, туда же, по-моему относилась Amiga). HD>Так вот. Данные компьютеры (а вернее — процессор) на 100% совместимы с Intel 8086 на уровне машинного кода. так что вот
Ткнул пальцем в небо. И промахнулся...
Несовместим Zilog Z80 с Intel 8086/88, нет. А вот с Intel 8080 — совместим (на 100% — сверху вниз).
HD>некоторая специфика, конечно есть, конкретику приводить сечас не буду, но сам факт — на лицо. HD>Люди писали на Yamaha достаточно приятные программки на ассемблере и балдели от их маленького размера и высокого быстродействия.
E>>Недавно был разговор об переносе асма с платформы на платформу.... X>Это экономически не обосновано, как мне кажется.
Экономика не имеет значения в контексте исходной темы. Впрочем, многие аргументы данного треда не имеют никакого значения.
X>Заниматься такой фигней .
А WinCe не фигня?
X>Какой выход? Насколько я понимаю, 32 разрядный код будет исполнятся на ИА-64 медленно. Или есть какие-то умные конвертеры из машинного кода из х486+ в ИА-64?
А зачем конвертировать? Более того, зачем писать под IA-64? С другой стороны, если надо написать, то почему бы это не сделать? В чем проблема?
X>Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами.
Здравствуйте Aquila, Вы писали:
X>>Заниматься такой фигней .
A>А WinCe не фигня?
Еще какая. Компетентное мнение
X>>Какой выход? Насколько я понимаю, 32 разрядный код будет исполнятся на ИА-64 медленно. Или есть какие-то умные конвертеры из машинного кода из х486+ в ИА-64?
A>А зачем конвертировать? Более того, зачем писать под IA-64? С другой стороны, если надо написать, то почему бы это не сделать? В чем проблема?
Я просто к тому, что код написанный на на бейсике, джаве шарпе, паскале, плюсах заработает под ИА-64 без особых переделок. А ассемблерный 32-разрядный код — нет. Поэтому, если писать что-то долгосрочное, то наверное не стоит эмулировать замыкания в С++ :
ну и так далее, недавно тут пробегало, все видели...
Такой код под ИА-64 работаь не будет, Это при том, что единственная оправданная цель применения ассемблера — многократное повышение скорости выполнения здесь не достигается.
X>>Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами.
A>Больше на Дельфи похоже.
Здравствуйте Xentrax, Вы писали:
A>>А зачем конвертировать? Более того, зачем писать под IA-64? С другой стороны, если надо написать, то почему бы это не сделать? В чем проблема? X>Я просто к тому, что код написанный на на бейсике, джаве шарпе, паскале, плюсах заработает под ИА-64 без особых переделок. А ассемблерный 32-разрядный код — нет. Поэтому, если писать что-то долгосрочное, то наверное не стоит эмулировать замыкания в С++ : X>class CStdThunk{ X> BYTE m_mov; // mov ecx, %pThis X> DWORD m_this; // X> BYTE m_jmp; // jmp func X> DWORD m_relproc; // relative jmp X>ну и так далее, недавно тут пробегало, все видели...
Наверное, не стоит. Если используется C++, то почему бы на нем и не писать?
X>Такой код под ИА-64 работаь не будет, Это при том, что единственная оправданная цель применения ассемблера —
многократное повышение скорости выполнения
Это не единственная оправданная цель применения ассемблера.
X>>>Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами. A>>Больше на Дельфи похоже. X>Я всеми руками за.
Здравствуйте Hacker_Delphi, Вы писали:
HD>Здравствуйте Edmond, Вы писали:
E>>А что переносимоть???? E>>Недавно был разговор об переносе асма с платформы на платформу.... E>>И это не так уж невозможно....
HD>Да... все, наверное хоть слышали про замечательные компутеры Yamaha и Spectrum??? (ну и прочие из семейства Z80, туда же, по-моему относилась Amiga). HD>Так вот. Данные компьютеры (а вернее — процессор) на 100% совместимы с Intel 8086 на уровне машинного кода. так что вот
Да? Ямаха говорите
Не знал.... Для меня Ямаха, это не плохие проффессиональные синтезаторы....
.
