cap83 LordMAD ........
LOL
Да, это следующая ступень развития... после ламеров. Без обид!
..............


--->

LordMAD
Я хочу сказать, что люди (?), которые не в состоянии разрабатывать компоненты - ламеры. Т.е. эти две стуненьки развития - соседние.


Где логика ?Логика прозрачная. Что не понятно?

ренегатКомпонентописание оно тоже, разное бывает.Это да.
ренегатКстате, а какие там такие компОненты с асмом? Я вот свои приеменяемые прошерстил, так только в FastMM/FastCode нашёл осмысленные варианты асма.Ну раз уж разговор пошел про Delphi, то 100% установленных у меня компонент используют вставки на asm'е: FastMM, EhLib, JCL, TB2k, TBX, VTV.

Целесообразность использования вставок на asm'е определяется не тем, сумел ли кто-нибудь релизовать нечто почти так же хорошо, только на чистом ЯВУ (возможно это и "красиво", но с практической точки зрения - достоинство сомнительное), а результатами замеров на целевых системах (та же старая-добрая команда asm'а RDTSC).

LordMADЛогика прозрачная. Что не понятно?Какое слово не понятно?

ренегатЭто как? Поясни.Какое слово не понятно?

ренегатЯ уже писал выше. Что не всякое ассмеблерное творчество имеет смысл и оптимально в целом.
Типовой пример - функция сравнения буферов и строк.

Опять же, лицезрея очередной велосипед (не самый оптимальный) во всех этих компОнентах, приходим
к вполне закономерному выводу. Что компонентописатели (даже именитые) - таки чего-то не догоняют
(не ламеры, но тем не менее).

Опять же, ЯВУ, не ЯВУ, всё упирается в те самые примитивы (которые может и были не сильно
оптимальны в каком Delphi3, и может быть даже не сильно оптимальны и сейчас (в Delphi10), но
суть велосипеда от этого - не меняется, что особенно актуально в силу особенностей отдельных
платформ/процессоров).

Так что приходим к выводу выше. Ассемблер - это удел разработчиков компиляторов (и приравненных
к ним низкоуровневых библиотечных средств).

Опять же - посмотри внимательно лишний на характер ассемблерных вставок даже в озвученных
выше компонентах (том-же JVCL).
Ты пытаешься доказать прописные истины о том, что целые системы писать на одном только asm'е не стоит, а нужно оптимизировать только часто используемые фрагменты кода ("компоненты", "примитивы" - называй как хочешь). Да, это так просто потому, что писать _все_ на asm'е обычно слишком дорого. С этим никто не спорит! Но если какой-то кусок кода используется достаточно часто (например, во многих программах или в цикле одной программы) - то "игра стоит свеч". Именно поэтому в библиотеках asm используется очень часто. В приведенном тобой примере с FastCode хорошо видно, что использование asm'а для оптимизации под разные процессоры дает хороший результат по сравнению с оптимизацией компилятором. Код из DB.pas простой и его просто сопровождать (не сложнее, чем аналогичный код на паскале), при этом он существенно лучше, чем аналогичный код на ЯВУ.

cap83Код из DB.pas не оптимальный ......Правда? Может ты имел в виду, что он не самый быстрый из всех возможных вариантов? Оптимальность подразумевает критерий. В данном случае критерий - соотношение "цена-качество". Писать на asm'е и писать самый быстрый код из всех возможных - это не одно и то же. Кстати, код из fastcode - не самый быстрый.