|
ASM нужен ли он сейчас?
#35018141
Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
|
|
|
|
|
LordMADТы пытаешься доказать прописные истины о том, что целые системы писать на одном только asm'е не стоит, а нужно оптимизировать только часто используемые фрагменты кода ("компоненты", "примитивы" - называй как хочешь).
Увы нет, ты невнимательно читаешь.
LordMADДа, это так просто потому, что писать _все_ на asm'е обычно слишком дорого. С этим никто не спорит! Но если какой-то кусок кода используется достаточно часто (например, во многих программах или в цикле одной программы) - то "игра стоит свеч". Именно поэтому в библиотеках asm используется очень часто. В приведенном тобой примере с FastCode хорошо видно, что использование asm'а для оптимизации под разные процессоры дает хороший результат по сравнению с оптимизацией компилятором. Код из DB.pas простой и его просто сопровождать (не сложнее, чем аналогичный код на паскале), при этом он существенно лучше, чем аналогичный код на ЯВУ.
Ты не понял. Я тебе показал то, что в DB.pas наличествует НЕ САМЫЙ ОПТИМАЛЬНЫЙ код, более
производительный вариант которого - присутсвует как раз в FastCode модулях. Не более того.
И пытался сказать то, что применение ассемблера "вразброс" в компонентах - плохая идея. Потому
что этот код - реально не сопровождается. Будучи написанным "как есть" в незапамятные времена -
он не будет переписан (аккурат до тех пор, пока КАРДИНАЛЬНО не сменится платформа, к примеру
переход с x86-32 на x64).
А то, что существует более оптимальный код сравнения буферов, разработчики DB.pas уже давно
и забыли (хотя это, по сути, исключительно библиотечная функция, которой не место в секции
implementation).
Т.е., по хорошему, весь ассемблерный код должен быть вообще вынесен в отдельный модуль,
и поддерживаться отдельно (как минимум, на предмет новых платформ/ревизий CPU).
Вот и всё.
|
|
|
