Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.237.15.145] |
|
Страницы: (5) [1] 2 3 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Прошу выбрать один из вариантов ответа.
Я лично активно использую и изучаю ассемблер. Этот язык даёт неограниченные возможности управления компьютером и позволяет писать эффективный и компактный код. А что думаете вы? |
Сообщ.
#2
,
|
|
|
schooler
В голосовании мне не хватает варианта: Редко, только для оптимизации "тяжелых участков" кода. |
Сообщ.
#3
,
|
|
|
Azopp
Я думаю тебе больше всего подойдет 3 вариант ответа, так как обычно (по личному опыту) это так и происходит. Может быть не очень часто. Но с целью оптимизации... |
Сообщ.
#4
,
|
|
|
Ответил (и пока единственный) "никогда". Был бы вариант "Никогда, даже для программирования железа" выбрал бы его.
|
Сообщ.
#5
,
|
|
|
Почти всегда Крайне редко использую, как каркас, Дельфи, Паскаль, Борланд Си и Ватком Си(весчь), но все равно, основной код оформлен на асме.
|
Сообщ.
#6
,
|
|
|
Я соврал и ответил
"Всегда, пишу программы только на чистом ассемблере" потомучто не умею вообще! Но удивлён когда продвинутые программисты выбирают что-то другое... Мну всегда духом болеет только за асм! А лучше может только быть машинный код... Но времена и нравы меняются и против этого уже трудно попереть |
Сообщ.
#7
,
|
|
|
Думаю, в настоящее время знания ассемблера действительно необходимы только для исследования "чужих" программ. С другой стороны, если есть опыт, куча готовых шаблонов и функций - то почему б и нет. Я использую ассемблер просто ради интереса.
Цитата semiono @ наверное, ты часто бываешь удивлен удивлён когда продвинутые программисты выбирают что-то другое... |
Сообщ.
#8
,
|
|
|
Полностью согласен с Azopp.
На ЯВУ можно (и нужно!) написать все то же самое, что и на ассемблере (за исключением оптимизации средствами MMX, SSE, etc.), но код быстрее пишется, легче отлаживается, проще сопровождается и модифицируется. PS. Нет, вру: вспомнил еще один вариант, где нужен ассемблер - добывание информации опроцессоре через CPUID. |
Сообщ.
#9
,
|
|
|
Цитата andriano @ На ЯВУ можно (и нужно!) написать все то же самое, что и на ассемблере (за исключением оптимизации средствами MMX, SSE, etc.), + FPU , т.к. ЯВУ-компиляторы неплохо оптимизируют целочисленные операции и, мягко говоря, неважно FPU. Видимо из-за сложностей работы со FPU-стеком явушные реализации грешат ненужными загрузками\выгрузками промежуточных FPU-вычислений в память и многочисленными обменами регистров fxch |
Сообщ.
#10
,
|
|
|
Цитата semiono @ Время - деньги Но заметь, что если профи выбирают Си и Дельфи, то любители нередко предпочитают ассемблер, некоторые на него переходят именно с ЯВУ. Думаю этот факт о многом говорит.Но удивлён когда продвинутые программисты выбирают что-то другое... Цитата quotter @ Тоже неплохой вариант. Зачастую проще "подглядеть" у других, чем лазить по многотонным докам, особенно с хорошим инструментарием Думаю, в настоящее время знания ассемблера действительно необходимы только для исследования "чужих" программ Цитата andriano @ Согласен только с первым, остальное - дело привычки и опыта. Когда постоянно практикуешся, то вырабатывается стиль, позволяющий значительно упрощать отладку и модификацию. Но это относится и к ЯВУ, правда там "адаптация" происходит быстрее.но код быстрее пишется, легче отлаживается, проще сопровождается и модифицируется Цитата andriano @ Вспомнить можно много чего, например мониторинг производительности, через регистры MSR и CESR Или возьми такую область, как дебаггеры. Только на асме возможно легко и просто кодить работу с отладочными регистрами. Только на асме можно сделать обработчики исключений процессора. Только на асме можно реализовать нормальное переключение задач. Да много чего невозможно на ЯВУ Просто расслабились все из-за винды, вот и думают, что виндозные дрова - это низкий уровень вспомнил еще один вариант, где нужен ассемблер - добывание информации опроцессоре через CPUID |
Сообщ.
#11
,
|
|
|
leo, еще раз: я признаю право на ассемблерную оптимизацию, но считаю, что в ней нуждается не более 10-20% программ, а в них, в свою очередь, не более 10-15% кода (т.е. доля ассемблерного кода - где-то 2%). В то же время компилляторы с ЯВУ, сециально предназначенных для обработки чисел с плавающей точкой (например, с Фортрана) делают достаточно "чистый" код. Ну а для универсального языка плавающая точка - как-то не слишком актуально.
-Added Цитата AndNot @ Согласен только с первым, остальное - дело привычки и опыта. Не могу согласиться. Объем кода принято выражать в количестве строк не только потому, что больше не в чем, но и потому, что реальная сложность отладки, сопровождения и модификации зависит именно от количества строк. Я на ЯВУ это количество при той же функциональности оказывается меньше. |
Сообщ.
#12
,
|
|
|
Цитата Azopp @ В голосовании мне не хватает варианта: Редко, только для оптимизации "тяжелых участков" кода. Ага, как раз для таких вещей и применяю. В основном оптимизация компактных вычислительных ядер с плавучкой - раз. И для минимизации времени выполнения и объема кода на встроенном микроконтроллерном железе (опять же - избранные куски) - два. |
Сообщ.
#13
,
|
|
|
Цитата andriano @ Общий объем кода, в проекте несущественнен, все равно проект делится на небольшие модули, которые отлаживаются раздельно, с пол пинка Может быть у нас с тобой разные подходы, но я предпочитаю дробить проект на множество мелких модулей(10-500 строк), нежели пихать все в кучу, как делают немало ЯВУшников, которые просто не умеют взять бумагу, карандаш, пиво, и продумать задачу в мельчайших деталях, тщательно разбивая ее на отдельные подзадачи. После подобной процедуры уже редко приходится пользоваться отладчиком, в основном допускаешь синтаксические ошибки, которые компилятор отлавливает. И расширяемость хорошая, поскольку модули получаются независимыми от других, типа ООП реальная сложность отладки, сопровождения и модификации зависит именно от количества строк Цитата andriano @ Могу разочаровать тебя - не всегда, более того не всегда код на ЯВУ получается нагляднее Особенно когда пытаются сделать на ЯВУ чисто ассемблерные задачи. Я на ЯВУ это количество при той же функциональности оказывается меньше |
Сообщ.
#14
,
|
|
|
Хе. Задумал я написать минимальную программу на C++, показывающую окно. Для этого, подумал я, нужно избавиться от CRT. Ога, пишем без глобальных объектов, без new/delete, на чистом WinAPI, указываем свою точку входа. Написал. Откомпилировал. Смотрю - тянет CRT. И тянет memset оттудава. Ага, подумал я:
#define ZeroMemory(ptr,size) memset(ptr,0,size) А в коде у меня только одна строчка может это вызывать: WNDCLASSEX classEx = {0}; Можно, конечно, занулить все поля вручную, но я решил, что ято не мой метод и надо писать своя "занулятор" =) Написал типа этого: void MyZeroMem(void *ptr,unsigned int size) { char *ch = ptr; for(i = 0 ; i < size; ++i) { *ch = 0; ch++; } } Вставил, скомпилил, смотрю, всё равно, собака, тянет =( Дизассемблировал, и что же я вижу??? На том месте, где должна вызываться моя функция, компилятор вставил memset(!!!!). Это он, собака, соптимизировал! Посмотрел, что я тут стабильно зануляю кусок памяти и решил, что memset работает быстрее (снимаю перед разработчиками оптимизатора шляпу). Вот тут то я и вспомнил, что компилятор никогда не меняет ассемблерные вставки... Это был чуть ли не единственный раз, когда я вспоминал ассемблер |
Сообщ.
#15
,
|
|
|
Цитата andriano @ Вспомнилось две игрухи, первая на Си, вторая на Паскале. Обе - шутеры, почти одинаковы (во втором спецэффекты более продвинутые). Но вторая на 70% состояла из асма. В результате - вторая работала более гладко, нежели первая, даже при вдвое большем разрешении экрана и большем количестве спецэффектов. Первая была - знаменитая Quake, а вот вторая - Chasm: Shadow The Rift А казалось бы, подумаешь ерунда, какой то там FPU. Ну а для универсального языка плавающая точка - как-то не слишком актуально |