- 1
- 2
fld qword ptr [d]
call @ROUND-
Assembler / Говнокод #2172
+240.1
Это творчество дельфийского компилятора на тему i := round(d);
Он делает вызов функции ради одной пустяковой команды, что очень влияет на скорость.Запостил:
TarasB,
24 Ноября 2009
Follow us!
предложи в inline переделать
паскаль не люблю, дельфи тоже
си рулит!!!
Вот у меня есть прога, работающая с логическими функциями, там используется полно логических операций & | ~.
И на дельфи это будет длинная строка типа (a and b) or c, тем более, там нет разницы между операциями над битами и над логическими значениями, что приводит к путанице или необходимости везде писать <>0.
разработка п.о. состоит из множества фаз, в которую входит далеко не одна фаза тестирования
более того, если о баге составили репорт, сомневаюсь, что борланд это не пофиксит
ты идиот во второй раз, потому как не понимаешь нихрена между компиляторома, языками и их реализациями
да, и не забудь, что компиляторы ща намного умнее оптимизируют нежели ты... си, си++, асм... :-!
подписываюсь, всегда тошнило
Дельфа тут, если что, седьмая, старая. Про новые версии не знаю, в них это исправили, кстати? А то бесит делать ассемблерные вставки при работе с вещественными числами.
Хотя я соглашусь, что это изврат. ;)
nop - один
Возможно, они специально так делают, когда надо именно джва байта забить чтобы не нагружать декодер джвумя нопами.
Угу. Кстати я посмотрел как сейчас конпеляторы делают -- а они юзают длинную форму nop, которую префиксами и режимом адресации можно подогнать почти под любой размер.
Возможно в делфи пытались поддержать какие-то древние процы, где этой формы не было. В интеловской доке не написано, когда эта инструкция появилась, к сожалению. А в gcc опытным путём не получается границу найти, он для 32-битного кода всякие xchg да lea ебашит вместо длинных nop'ов.
Вика пишет, что опкод 0x90. При этом в Long mode (x64) он превращается в ``xchg eax, eax``, который still has no effect Ж)
Я о том, что 0x90 в long mode не совсем nop, хотя и без эффекта.
0x0F 0x1F это как раз чтобы два байта забить?
У него аргументы есть, так что там от 2 до 15 где-то. По крайней мере я сейчас вижу как gcc собрал 11 байтную форму.
З.Ы. Пишут, что только в 2006 году задокументировали. Хотя работало задолго до этого.
А по 32 бывает?
Я не знаю, никогда не оптимизировал на таком уровне... Но вроде кусками по 16 читает. И если ты начал с середины куска, то за этот такт ты набросишь гораздо меньше инструкций на конвейер, чем если бы ты начал с начала.
Сколько вообще в комптютере места проебывается из за этих выравниваний: и в оперативке, и вон в секции кода.
Ну эти инструкции то хоть бесплатны? Модуль выполнения поймет, что они не нужны, и не будет их выполнять?
Или их прямо декодер превратит в пустоту?
ROUNDINT
Вроде так. В вершине стека сопроцессора лежит результат.
fld qword ptr [d]
frndint
именно поэтому MSVC сначала выставляет округление по дефолту, но есть оптимизация, позволяющая отключить это
Просто на Дельфях не надо писать приложения, которые чувствительны к тому, как округляются даблы: call-ом или inline.
А если лень писать на C или на голом ассемблере, полагаю, нет и смысла беситься из-за ассемблерных вставок.
Написать свою INLINE функцию, состоящую из одной ассемблерной вставки, на Дельфях уже можно. А макросы - это зло. Точнее, зло для криворуких.
Простой пример:
#macro mul(a,b) a*b
...
int i = mul(2+3,4); // i==14, а не 20, как хотелось бы.
Сначала никто никому ничего не должен, а потом фигня получается.
А потом писать тупые отмазки "ну не надо на дельфях писать приложения, в которых важна скорость"? Ну да, это проще, чем написать компилятор нормально.
И я, вообще-то, не про те макросы, которые задают пользователи, забывая обрамлять их скобками, а про стандартные. Чтоб ты знал, функции типа odd - макросы.
А инлайны в виде машинных кодов тоже наизусть предлагаешь учить?
А ставить фреймворк ради новых версий - ну, нафиг, у меня комп древний.
:)
А так можно и в Pascal?
В дельфях уже можно писать inline-функции (см. это слово в Help, в семерке не уверен, в 2005-х - точно). В учебниках по плюсам авторы часто подчеркивают, что не надо городить макроопределения там, где можно реализовать inline-функцию: контроль типов, обход описанной мной выше ситуации, и т.д. Посему Тарасу и было скромно намякнуто: напиши inline с asm-вставкой, и будет тебе макрос.
Наследия округлятелей как функций сохранились с тех бородатых времен, когда у компилятора был флажок про 87-й сопр - "эмулировать или использовать его инструкции". Флажок цинично подставлял разные точки входа. Флажка в помине нет - точки входа остались. Потому что в учебном языке скорость округления дабла не роляет. Потому что в учебном языке никому не надо исправлять давно отлаженную и работающую функцию. Потому что не надо писать критичные к скорости выполнения приложения на учебных языках. Если шибко хочется считать развитую арифметику - надо брать библиотеку, написанную разработчиком конкретного процессора, и линковать ея.
Аминь.
Во-вторых, из-за такой вот ерунды и кричат всякие, что мол, Паскаль - язык для учеников, ничего серьёзного на нём написать нельзя, ну и прочая фигня.
И я всегда крайне негативно отношусь к ухудшениям, которые сделаны не для упрощения или удешевления, а просто тупо по лени разработчика.
- Ты Дельфи украл, или купил?
- Ты преподаешь, или учишься [, или умный шопесец]?
- Ты профессионал, или энтузиаст [, или ты написал компилятор лучше]?
А так - да. Относись.
2. Ни то, ни то [ну ты в натуре умного корчишь, я смотрю].
3. Энтузиаст [ололо, сперва добейся].
printf("%d",Round(0.5));
Не надо путать макросы и подставляемый компилятором код. Этим разные программы занимаются. Максимум - разные части одной многофункциональной программы. Препроцессирование и компиляция не есть единое и однообразное.
Скорее интринсиками.
Очень интересно также узнать, что думают товарищи о коде, выдаваемом M$ компиляторами Сей? По молодости дизассемблировал проги - в те времена БорландПаскалевский вариант был намного чище...
И? Оттого, что выбор способа будет внутри вызываемой функции, а не будет прямо подставляться в код - код станет быстрее? Стабильнее?
> Про то, что в новых процах CALL'ы оптимизированы запределно, слышали?
Конечно. Дайте денег, я куплю новый проц.
> И? Оттого, что выбор способа будет внутри вызываемой функции,
> а не будет прямо подставляться в код - код станет быстрее? Стабильнее?
Предположение насчёт выбора способа было первым, что пришло в голову. Пока мы не видим кода этой функции, ничего нельзя сказать точно. Но, развивая тему, Intel рекомендует разработчикам Сишных компиляторов использовать нехилый такой кусок кода. Потому что ANSI C предполагает другой способ округления нежели тот, который по умолчанию даёт FPU. Здесь случай не этот, но факт в том, что не всё так просто.
Станет ли код быстрее - не исключено, об этом позже. Стабильнее - вполне возможно. С этим знаком каждый, кто когда-либо работал над хоть сколько-нибудь сложными проектами на асме (да и не только), знает, что вынести кусок кода в отдельную функцию (особенно, если код не относится к логике программы, а является вспомогательным) - это мощный приём для повышения читабельности программы и, соответственно, её стабильности. Этакий аналог инкапсуляции в процедурном программировании. Здесь читаемость не столь важна, но... Основы программирования: если есть повторяющийся логически самодостаточный кусок кода - его можно вынести в отдельную функцию. А если он большой - то и нужно: программа меньше будет без особых потерь в быстродействии.
Дешёвая ирония. Смотрим настольную книгу №1 для программиста: "Intel® Architecture Optimization. Reference Manual". Раздел "Static Prediction":
> • Predict unconditional branches to be taken.
Что такое call - объяснять надо? Ладно, напомню. Это сложная инструкция, которой эквивалентно помещение в стек адрес возврата и безусловный переход. Что-то типа (псевдокодом):
push EIP
jmp ProcAddress
Читаем дальше:
> ... the call will be predicted as taken by the static prediction algorithm.
> Additionally, Pentium II and Pentium III processors have a return stack
> buffer (RSB) that can predict return addresses for procedures that are called
> from different locations in succession. This increases the benefit of
> unrolling loops containing function calls. It also mitigates the need to put
> certain procedures in-line since the return penalty portion of the procedure
> call overhead is reduced.
Это по оптимизации CALL'ов: если кратко, то нагрузка от них незначительна, поэтому нет особого смысла инлайнить некоторые процедуры. В частности, те, которые достаточно крупны или обособленны.
> A floating-point store must wait an extra cycle for its floating-point
> operand. After an fld, an fst must wait one clock.
Дальше идёт пример:
> fld meml ; 1 fld takes 1 clock
> ; 2 fst waits, schedule something here
> fst mem2 ; 3,4 fst takes 2 clocks
А перед этим пунктом сказано:
> Many of the floating-point instructions have a latency greater than one cycle
> but, because of the out-of-order nature of Pentium II and Pentium III
> processors, stalls will not necessarily occur on an instruction or μop basis.
> However, if an instruction has a very long latency such as an fdiv, then
> scheduling can improve the throughput of the overall application. The
> following sections discuss scheduling issues and offer good tips for any
> IA-based processor.
Так что CALL будет выполняться параллельно с FLD. И если там нет жёсткого использования стека (почти не сомневаюсь), то быстродействие не упадёт. А если там есть дополнительные операции - то как раз ускорит даже. Опять же, нельзя ничего сказать, пока не увидим кода функции.
Вспомним, кстати, что Delphi создавался не одним человеком, поэтому не исключено, что пока один писал стандартный процедурки (коих немало), другой писал сам компилятор, а потом они объединяли усилия. Не поленился, сдул пыль с Delphi 7, посмотрел System.pas. Реализовано как "Procedures and functions that need compiler magic". Реализация более чем корректна: по соглашению вызова FP-параметр передаётся в стеке, 8-байтовое целое возвращается в паре EDX:EAX. Для совместимости со старыми процессорами оставлено FWAIT. С точки зрения проектирования системы вполне адекватно.
А вообще, на одном очень известном интернет-портале, где собираются программисты со всего СНГ для обмена опытом, первый же ответ в такую тему звучал бы как "Сам попробуй напиши, а потом наезжай". Не сочтите за грубость, но именно это напрашивается, когда такая мелочёвка выдаётся за вселенскую тупость всемирно известного разработчика. Тем более когда для избавления от этой якобы тупости пришлось бы возложить на компилятор не только приведение типов, удаление неиспользуемых кода и данных, а также оптимизацию, но и написание целых процедур.
Если Вы используете округление в огромном цикле, где скорость критически важна - у Вас проблемы в проектировании и Вы рано взялись за написание кода. Если у Вас жизненно важен каждый такт (хм, интересно, бомбу запускаете?) - тогда почему Вы пишете на Delphi? Не пишете, но боитесь, что кто-нибудь напишет? Не бойтесь, те, кто не умеет выбрать подходящий инструмент для написания приложения, работают рядовыми программистами и к таким проектам не допускаются. Можете спать спокойно, найденная Вами ОСОБЕННОСТЬ никому не навредит.
rsdn что ли?
гадость какая)
Да, я имел в виду подставляемый код. Нахера подставлять вызов функции, когда можно сразу подставить код?
> это мощный приём для повышения читабельности программы и, соответственно, её стабильности
Нахрена нужна читабельность машинного кода, генерируемого компилятором?!
> Это по оптимизации CALL'ов: если кратко, то нагрузка от них незначительна, поэтому нет особого смысла инлайнить некоторые процедуры.
Я проверял скорость, разница очень велика.
> Вообще, по правде сказать, не понимаю, зачем выбрасывать сюда код, сгенерированный автоматически?
Это сайт такой, понимаешь. Говнокод называется. Сюда выкладывается говняный код. Например, типа этого.
> "Сам попробуй напиши, а потом наезжай"
Я сам написал ассемблерную вставку, заменяющую эту функцию, что значительно ускорило программу. Этого хватит?
> Если Вы используете округление в огромном цикле, где скорость критически важна
Нет, я уже перешёл на фиксированную запятую 16:16.
> Если у Вас жизненно важен каждый такт (хм, интересно, бомбу запускаете?) - тогда почему Вы пишете на Delphi?
А почему нельзя? Потому что Дельфа для этого не предназначена? А почему? Не из-за языка, а из-за того, что компилятор лажает. Так? Вот я и привёл пример такой лажи. Ещё ко мне вопросы есть? Нет. Всё, свободны.
> Да, я имел в виду подставляемый код. Нахера подставлять вызов
> функции, когда можно сразу подставить код?
Читаем 4 поста, где, среди прочих, указывается особенность проектирования системы программирования, а также необходимость разделения труда программистов, работающих над созданием этой самой среды. Подстановка функций в место вызова имеет обратную сторону: при использовании этого приёма в БОЛЬШИХ проектах как раз получается говнокод, потому что размеры программы начинают расти быстрее, чем падает производительность.
> > это мощный приём для повышения читабельности программы и, соответственно, её стабильности
> Нахрена нужна читабельность машинного кода, генерируемого компилятором?!
Ответьте для себя на вопрос, сколько из написанного мной Вы прочитали, а потом подумайте, стоит ли вырывать из контекста отдельные фразы, если Вы хотите доказать свою правоту или хотя бы прийти к усреднённой истине, а не просто похвастаться "Я читал дизасм-листинг Delphi-проги"? Не зря меня знакомые отговаривали от пустой траты времени на объяснение азов :(
Конкретно здесь фишка не в читабельности, а в генерации стабильного кода, лишённого ненужных заависимостей и соответствующего общепринятым стандартам, а также упрощении внутренней реализации компилятора, что не менее важно при разработке сложного программного продукта и допустимо, если это не влияет на качество результирующего продукта, либо влияет в исключительных случаях, которые не затрагивают области применения этого продукта.
> > незначительна, поэтому нет особого смысла инлайнить
> > некоторые процедуры.
> Я проверял скорость, разница очень велика.
Я проверял скорость, разница очень велика в пользу процедурного подхода. Если проверяете - указывайте аппаратное и программное обеспечение, а также приводите текст программы. Иначе мы много натестируем. Потрудитесь также найти указанный мною официальный документ и убедиться в том, что я это беру не из воздуха. Возможно, также, что Ваша ирония иронией не была и у Вас действительно старый-добрый i8086. Либо в Вашем тесте зашкалила синтетика (см. упоминание про проектирование приложения). Для сравнения, кстати, напишите аналогичную программу на Си и скомпилируйте ANSI C-совместимым компилятором. У них реализация округления понавороченней будет.
> > Вообще, по правде сказать, не понимаю, зачем
> > выбрасывать сюда код, сгенерированный
> > автоматически?
> Это сайт такой, понимаешь. Говнокод называется.
> Сюда выкладывается говняный код. Например,
> типа этого.
Эм-м-м, да будет Вам известно, что г&$но-с, оно имеет животное происхождение, т.е. должно исходить от животного. В случае с кодом таковым является представитель вида Homo Sapiens. А не компилятор.
Опять читаю прописные истины, но всё же... Продукт компиляции - это автоматически генерируемый поток информации, причём генерируемый по определённому алгоритму, решающему задачу компиляции в ОБЩЕМ виде. Не путайте наконец компилятор и ассемблер, если на то пошло. В данном случае решение разработчиков Delphi абсолютно оправданно и не противоречит здравому смыслу.
А с Вашей стороны, если Вы претендуете на звание специалиста, было бы логичнее выложить не сгенерированный код, а тот код, который обеспечивает такую генерацию. И в формате обсуждения, потому что там специалисты покруче нас с Вами вместе взятых.
> Я сам написал ассемблерную вставку, заменяющую
> эту функцию, что значительно ускорило программу.
> Этого хватит?
И речь в этом случае идёт не о написании эквивалентного кода, а о написании компилятора, который будет лишён этого недостатка и не уступит рассматриваемому по другим пунктам. Пока что в Ваших сообщениях читается отсутствие опыта работы над действительно большими проектами. Увы!.. А макроса в Вашем исполнении я так и не увидел. И не надо сейчас про оговорки: если Вы берётесь "обгаживать" большой проект, разработанный высококвалифицированными программистами - будьте добры соответствовать их уровню хотя бы частично и не путаться в БАЗОВЫХ понятиях. Как можно спорить о качестве компилятора, если Вы его не отличаете от препроцессора?
> > Если Вы используете округление в огромном цикле, где скорость критически важна
> Нет, я уже перешёл на фиксированную запятую 16:16.
Рад, что в Вашей программе это возможно. В критичных по скорости выполнения приложениях бОльшая часть работы выполняется ДО (!) непосредственного использования результатов. Редкий случай, когда округление нужно здесь и сейчас и многократно и выполнить его заранее нельзя, никогда не использует ЯВУ (языки высокого уровня). Ваша ирония опять выглядит глупо.
> > (хм, интересно, бомбу запускаете?) - тогда
> > почему Вы пишете на Delphi?
> А почему нельзя? Потому что Дельфа для
> этого не предназначена? А почему? Не из-за
> языка, а из-за того, что компилятор лажает.
> Так? Вот я и привёл пример такой лажи.
> Ещё ко мне вопросы есть? Нет. Всё, свободны.
Как здорово: сказал и закрыл тему. Молодец. Хохочем всей конторой. И хотя Вы абсолютно не настроены, насколько я вижу, адекватно воспринимать контраргументы и цель была в очередной раз выпендриться (это видно по заезженным клише, которые Вы активно используете), я попытаюсь ответить на Ваши вопросы. Хоть ответы и очевидны.
Delphi действительно не предназначена для разработки высокоскоростных приложений, как и наши любимые C++, Java, всё семейство .NET-ориентированных языков и т.п. И программы такой критичности пишут именно на ассемблере. По той же причине, по которой Вы едите суп ложкой, а не экскаваторным ковшом (я надеюсь!) и запиваете из кружки/стакана, а не напёрстка. Потому что есть инструменты, предназначенные для разработки прикладного ПО, которое большую часть времени ожидает действий пользователя и не выполняет критичных по скорости операций. И есть обратный случай, когда надо всё писать вручную, потому что никакой автоматизированный комплекс программ этого лучше программиста почти наверняка не сделает. Выбор адекватного инструмента - это отличительная особенность хорошего программиста от говнокодера. Человека от обезьяны наконец!.. И если Вы собрались написать операционную систему целиком на Delphi - это Ваше право, но место в лечебном заведении предоставляется в порядке живой очереди. Как и в случае написания, скажем, AutoCAD'а или OrCAD'а на чистом ассемблере, без FASM'овских макросов и т.п. удобств.
По-прежему остаётся ощущение, что Вы вините именно язык. Ваше право, но Вы не правы. На DelphiMaster.ru, например, Вас бы очень быстро и абсолютно корректно спустили с небес на землю все, включая обитающих там сишников, джавовцев и даже железячников. С точки зрения, например, синтаксиса Паскаль, лежащий в основе Delphi, куда более продуманный.
Вы можете сюда выкидывать сколь угодно произвольные свои изыскания, но давайте Вы не будете прикидываться, что в других компиляторах мало ляпов. Я уже далеко не первый и не второй год в этом варюсь и на своём веку дизассемблировал немало программ, самых разных. Есть действительно достойные звания говнокода места, а не подобные сомнительные изыскания.
Я прочитал всё, но на всё ответить не в состоянии, поскольку у меня нет приступа словесного поноса.
> а в генерации стабильного кода, лишённого ненужных заависимостей
Код, в который тупо вставлены 3 команды (fld, fistp, fwait), тоже не содержит никаких лишних зависимостей, но работает в разы быстрее, чем код, вызывающий функцию которая делает те же команды.
> Возможно, также, что Ваша ирония иронией не была и у Вас действительно старый-добрый i8086.
Селерон, 600 МГц. Мне убиться? Ничего, что большинство используемых нынче ЭВМ (если брать не только персоналки) примерно того же уровня?
> Delphi действительно не предназначена для разработки высокоскоростных приложений
Мне нужна не высокая скорость, а всего лишь приемлемая. И чтобы компилятор не делал таких элементарных ошибок. Кстати, почему вот такие конструкции, как odd() или Length(), таки ещё со времён турбо поцкаля всё-таки сделаны макросами? Значит, дело не в "разделении труда", которое вы непонятно зачем приплели.
> что большинство используемых нынче
> ЭВМ (если брать не только персоналки)
> примерно того же уровня?
Ну, во-первых, нынче используются даже в школах компьютеры помощнее, не в упрёк Вам будет сказано. Во-вторых - чуть дальше.
> Мне нужна не высокая скорость, а всего лишь приемлемая.
> И чтобы компилятор не делал таких элементарных ошибок.
Значит, всё-таки программисты Borland тупее Вас. Позвольте Ваш автограф?
> Кстати, почему вот такие конструкции, как odd() или Length(),
> таки ещё со времён турбо поцкаля всё-таки сделаны макросами?
Odd() в сущности вообще почти ничего не делает, т.к. для целочисленных типов её значение равно самому числу, а для перечисляемых - они при компиляции рассматриваются как константы с последовательными целыми значениями, т.е. тоже никаких преобразований не надо. И Odd() используется лишь для того, чтобы в языке со строгой типизацией выполнить приведение типов. Length() - это просто взятие однобайтового значения по вполне определённому ещё на этапе компиляции адресу. И тоже никаких приведений. Odd() фактически вычисляется ещё при компиляции (м.б. только за исключением редких случаев, когда сложное сочетание типов используется), а Length() - это просто byte ptr [...]. Операция присваивания сложнее, чем Odd() и Length(). Странно, что Вы расковыряли программу в Round()'ом и поленились посмотреть, как реализованы более часто используемые вещи.
> Значит, дело не в "разделении труда", которое вы непонятно зачем приплели.
Посмотрите исходник System.pas, найдите там реализацию этой и ещё некоторых других функций. Вы правда думаете, что это пакости ради так сделано? Или по тупости? Я рядом со свечкой не стоял, но налицо ситуация, когда разработчика самого компилятора избавили от необходимости делать то, что тот делать не обязан.
Уууу... И кто тут некомпетентен?
Кстати, раунд тоже почти ничего не делает - всего-то загрузить кучку байт в сопроцессор и выгрузить обратно.
> > т.к. для целочисленных типов её значение равно
> > самому числу
> Уууу... И кто тут некомпетентен?
Да, недосмотрел... Odd(), а не Ord(). В случае с Odd() ситуация иная, но не менее очевидная: при реализации функцией булевское значение придётся передавать в AX, а потом снаружи это AX проверять на равенство нулю. Тогда как намного проще просто сделать то, что делает вышеупомянутый Turbo Pascal: сдвиг вправо и дальнейшее использование CF. Возврат флагов соглашением stdcall не предполагается.
> Кстати, раунд тоже почти ничего не делает -
> всего-то загрузить кучку байт в сопроцессор
> и выгрузить обратно.
Вы сами задали эту тему в контексте Turbo Pascal'я. А там, если помните, есть директива, которая позволяет включать и отключать программную эмуляцию сопроцессора. В Delphi этот аргумент отпадает, но все остальные остаются актуальными.
Во-вторых, в дельфе даже этого не нужно.
Там немаленькая подстановка получится, если делать эмуляцию, совместимую с IEEE 754. А несовместимую нельзя, потому что тогда возникнут проблемы с совместимостью с другими приложениями.
> Во-вторых, в дельфе даже этого не нужно.
Как я уже писал, в Дельфе этот аргумент отпадает, остаётся вопрос проектирования компилятора с его упрощением.
Содержимое функции ROUND совместимо со всей иеее754 и занимает 6 строчек, большая часть из которых делает извлечения регистров из стека.
Кстати, round(const) таки компилируется сразу в результат, то есть попытки думать в направлении не плодить лишние вызовы были, но потом о них забыли.
> иеее754 и занимает 6 строчек, большая часть из
> которых делает извлечения регистров из стека.
Подстановка, если помните, относилась к эмуляции сопроцессора. Для совместимости с IEEE 754 нужно реализовать обработку случаев, когда операнд - обычное число, бесконечность и NaN. Плюс, если число не Extended, то ещё перевод в этот формат, т.е. поддержка денормализрованных операндов. В январе как раз довелось писать частичную эмуляцию: далеко не 6 строк.
> Кстати, round(const) таки компилируется сразу в результат,
> то есть попытки думать в направлении не плодить лишние
> вызовы были, но потом о них забыли.
Ничего общего. Все компиляторы и ассемблеры выражения, которые можно вычислить на стадии компиляции, вычисляют их и подставляют результаты, а не вычисление выражений. Все, кроме, м.б. учебных, написанных студентами в качестве лабы или курсача (есть такие задания). Эти операции выполняются компилятором, поэтому ни о каких вызовах там речи идти не может.
Эту обработку умеет делать сопроцессор. Все они заложены в команду fld.
> Ничего общего.
Ха, тогда почему round(const) заменяется, а вот sin(const) - нет?
И ещё. Почему такую нетривиальную операцию, как abs() компилятор преобразует в набор команд, а не в вызов функции? Значит, в этом направлении были мысли? Но до конца их не довели, за что и получили пост на говнокоде.
Нетривиальная операция ABS() нетривиальной не является: изменение единственного бита, причём независимо от того, какой FP-формат используется. А для целых - вообще готовая единственная инструкция. Там перегонка в/из память(-и) занимает больше времени, чем собственно операция.
Функции Sin(), Cos() и им подобные вычисляются через ряды, т.е. циклом. Как Вы понимаете, при разработке этих компиляторов я не стоял со свечкой рядом, но встраивать подсчёт этих вещей во время компиляции, по-видимому, означало как раз усложнение компилятора. Ну не могли Borland'овские разработчики в ущерб себе отказываться от реализации этой возможности, если бы она упрощала им работу. Не было среди них мазохистов. Можете поискать кого-нибудь и спросить.
Я не на экзамене, ты не профессор.
> И речь в этом случае идёт не о написании эквивалентного кода, а о написании компилятора, который будет лишён этого недостатка и не уступит рассматриваемому по другим пунктам
Та ты що? Мне надо "сперва добиться" и стать Филипом Каном?
> По-прежему остаётся ощущение, что Вы вините именно язык.
Нет, я виню именно компилятор. Не надо обвинять меня в несуществующих грехах.
Я смотрю, вы правила демагога используете вовсю. В том числе и чисто местное правило - любой код оправдывать якобы читаемостью и якобы тем, что на современных процессорах именно такой код более эффективен.
И по поводу всяких абстракций и аналогий типа
> Эм-м-м, да будет Вам известно, что г&$но-с, оно имеет животное происхождение
> но место в лечебном заведении предоставляется в порядке живой очереди
итд. Графоманы нынче не в почёте. Я честно прочитал ВЕСЬ этот поток сознания, но большую часть мог бы и не читать.
На 33% верно. Но вообще-то за слова принято отвечать, особенно если они задевают чьи-либо честь и достоинство. В данном случае - Borland'овских разработчиков. Без жёсткой аргументации можно и под УК попасть, там есть такая статья. Другое дело, что до подобных выпадов им дела нет - и слава Богу!.. А вот на брудершафт мы с Вами не пили пока ещё, будьте добры соблюдать элементарные нормы приличия.
> Та ты що? Мне надо "сперва добиться" и стать Филипом Каном?
Как будет выглядеть человек, который всю свою жизнь рисует портреты прохожих и попытается сказать, что картины, скажем, Пикассо - убожество? Если Вы не знакомы в достаточной степени с предметной областью - м.б. стоит быть осторожнее в высказываниях? Или сейчас так принято?
> Я смотрю, вы правила демагога используете вовсю.
Да ну? Я пока что приводил вполне конкретные ссылки на конкретные ОФИЦИАЛЬНЫЕ источники, даже с названиями разделов. Уж извините, что страниц не указал, но они время от времени перевыпускаются - и номера страниц могут отличаться. А Вы ограничиваетесь лишь обвинениями непонятно кого и упрёками в мой адрес. Чем не демагогия?
Золотое правило демагога: вырви из контекста и неси на шесте как флаг. Читаемость - это из общих рассуждений. Найдите в себе силы прокрутить страницу вверх и увидеть, что в следующем же предложении я написал: "Случай здесь не этот, но...". В сущности это было короткое вступление перед тем, как перейти к одному из правил надёжного программирования. Я про модульность, разбиение программы на логически самостоятельные участки.
> и якобы тем, что на современных процессорах
> именно такой код более эффективен.
Я привёл Вам цитаты из конкретного документа. Всё сказанное справедливо для процессоров начиная с Pentium II и III. Ткните меня носом в то место, где я сказал, что мы получим гарантированный выигрыш в скорости? Основная идея красной нитью: если падение и будет, то несущественное по сравнению с падениями производительности от выбора алгоритма и т.п.
Знаете, на будущее... Вы ведь не просто выложили кусок кода, но и сопроводили его вызывающим комментарием, а также неоднократно крайне нелестно отозвались о людях, уровень которых выше Вашего хотя бы потому, что Вы на сайте о говнокоде, а они во всемирно известной конторе. Это сначала привлекает внимание, а потом разрушает все сомнения насчёт Вашего опыта и подготовки. Не повторяйте больше этих ошибок - и общение со старшими коллегами будет идти Вам на пользу.
Опережая Ваши сообщения... Не стоит пытаться доказывать мне, что Вы супер-программист. Разницу между макросом и подстановкой Вы так и не ощущаете, даже после того, как Вам указали на это. Особенностей языка Вы, судя по упоминанию Ord() и Length() тоже не знаете, или по крайней мере не владеете этой базовой информацией свободно. Опытный человек никогда не полезет с громкими заявлениями, не имея хоть сколько-нибудь глубоких знаний в предметной области. Сохраните адрес этой страницы и почитайте лет через 5-10. Вспомните молодость, посмеётесь над собой. Ничего такого в этом нет, мы все такими были.
Не сделает. Гордый. :D
А вот их я не читал - в лом переводить. И не надо меня заваливать своими познаниями инглиша.
> Золотое правило демагога: вырви из контекста и неси на шесте как флаг.
Был бы контекст поскромнее, не пришлось бы рвать его. Но тут же графомания в чистом виде...
> в следующем же предложении я написал: "Случай здесь не этот, но...".
Дык если не этот, то нахрена это вообще было писать?
> если падение и будет, то несущественное по сравнению с падениями производительности от выбора алгоритма
Товарищ теоретик, я эту "несущественность" на практике заценил, так что не надо мне тут.
> Вы ведь не просто выложили кусок кода, но и сопроводили его вызывающим комментарием, а также неоднократно крайне нелестно отозвались о людях, уровень которых выше Вашего хотя бы потому, что Вы на сайте о говнокоде, а они во всемирно известной конторе.
Коменты типа "борланд дебилы" оставлял не я и даже не мои виртуалы. Я сказал только то, что компилятор тут лажает на ровном месте.
> Особенностей языка Вы, судя по упоминанию Ord() и Length() тоже не знаете, или по крайней мере не владеете этой базовой информацией свободно.
Уж поверьте, знаю предостаточно.
> Не стоит пытаться доказывать мне, что Вы супер-программист.
Я не собираюсь тут никому ничего доказывать.
В целом - из вашего потока единственная ценная мысль была о том, что так как почти никто не пишет на дельфах приложения, использующие вещественный счёт в критичных к скорости местах, то всем на этот недочёт похрен.
> А вот их я не читал - в лом переводить. И не надо меня заваливать своими познаниями инглиша.
Вы вполне можете найти переведённую версию этого документа. А то, что Вы их не читаете, чести Вам не делает: это как раз то, на что следует опираться в оптимизации на уровне кода.
> > Золотое правило демагога: вырви из контекста и неси на шесте как флаг.
> Был бы контекст поскромнее, не пришлось бы рвать его. Но тут же графомания в чистом виде...
Для употребления слова "графомания" у Вас должен быть диплом психиатра. В чём несмкромность контекста? Вам указали на то, что разница в предполагаемом Вами коде и генерируемом компилятором несущественна, со ссылкой на конкретные факты.
> > в следующем же предложении я написал: "Случай здесь не этот, но...".
> Дык если не этот, то нахрена это вообще было писать?
Мне опять повторять? Вы даже с этим ВСТУПЛЕНИЕМ не можете уловить сути. Вопрос "нахрена" отпадает?
> > сравнению с падениями производительности
> > от выбора алгоритма
> Товарищ теоретик, я эту "несущественность" на практике заценил, так что не надо мне тут.
Не могу знать, что Вы там назаценивали. Наибольшее замеченное падение - около 200 мс на 10 млн операций при процессоре с тактовой частотой 1100 МГц. Варьировались следующие параметры: включение/отключение реалтайм-проверки антивируса, использование второстепенных системных процессов. Для Core 2 Duo 2GHz на ядро результаты в среднем эквивалентны: то там, то там впереди то один, то другой алгоритм. И на будущее: если бы я был теоретиком - я бы просто не стал сюда писать, но за плечами многие годы программирования на самых разных языках и для разных платформ. Впрочем, Вам это неинтересно.
> Коменты типа "борланд дебилы" оставлял не я
> и даже не мои виртуалы. Я сказал только то, что
> компилятор тут лажает на ровном месте.
И тем не менее Вы ведь не будете отрицать, что слово "лажать", употребляемое Вами налево и направо, носит весьма экспрессивную окраску и имеет весьма и весьма унизительное происхождение для всего того, что этим словом обозначается? Вы хотели, чтобы "ухудшения" допускались только если оправданы упрощением и удешевлением? Уж и не знаю, что Вы там читаете вместо официальной документации (надеюсь, не Фленова с Архангельским), но раз доки пишутся не для Вас - сойдёмся на том, что ухудшение при определённых условиях может происходить. Сэкономлю себе время. Данная особенность даёт существенное упрощение компилятора, поскольку позволяет генерировать более однообразный код (многократно упомянутый stdcall), а как результат - требуется менее сложный алгоритм для распределения данных по регистрам. Плюс модульный подход, плюс разделение труда - вот Вам удешевление.
Было 50 мс, стало 250? Или как? В процентах это сколько? Вот я, например, заметил двухкратное преимущество простой асмовставки перед вызовом коряво реализованной функции.
Кстати, одд - это не просто загрузить из одного адреса, сохранить в другой. Надо, понимаешь, ещё и последний бит вычленить, да. Тут они смогли учесть то, что не стоит заворачивать в отдельную подпрограмму то, что выполняется за время, меньшее времени вызова подпрограммы. А вот с вещественными числами - облажались. А какое ещё слово тут подходит?
Что касается графомании - я не психиатр, но считать объём текста умею.
50 и 250 мс... Здесь предложу обратить внимание на 2 момента. Во-первых, по максимумам оценку делать несколько неосмотрительно: срабатывает элемент случайности. Реально здесь речь пойдёт не о пятикратном увеличении, а поменьше. Да и точность измерения в мс оставляет желать лучшего: из-за особенностей многозадачной системы, как известно, более-менее точная шкала - по 60 мс и мультимедиа-таймеры не слишком помогают в этом. Во-вторых, это на 10 млн округлений. Столько округлять может только сервер округлений ;) Именно в этом несущественность падения, о которой я говорю.
:D
Фленов - да.
А Архангельский то чем не понравился?
Кстати, оттуда же анекдот про компиляторы (недавно промелькнул):
- Здраствуте, что из литературы можно почитать про компиляторы?
- Естественно классику: Ахо, Ульман, Сети
- Нет, мне сети не нужны, мне про компиляторы...
- Ну тогда Фленов, Архангельский
Собственно, по мотивам...
> > Ord() и Length() тоже не знаете, или по крайней
> > мере не владеете этой базовой информацией
> > свободно.
> Уж поверьте, знаю предостаточно.
Устройство Ord() пропустим - моя вина, неправильно прочитал. Но принцип работы Length()... Если Вы знаете, как устроены Pascal-строки и/или Delphi-строки, то не мне Вам рассказывать, что Length(S) само по себе - это не операция, а просто memory operand. В отличие от Си. Чем прикажете объяснить Ваше непонимание причины, по которой вместо Length() подставляется кусок кода, а не вызов функции?
> В целом - из вашего потока единственная ценная
> мысль была о том, что так как почти никто не пишет
> на дельфах приложения, использующие вещественный
> счёт в критичных к скорости местах, то всем на этот
> недочёт похрен.
Насчёт количества пишущих на Delphi Вы несколько ошибаетесь. И мысль, сформулированная мною, относилась не к количеству программистов и проектов (коих немало), а к сфере применения Delphi.
Var
X : Byte;
N, N1 : LongInt;
Begin
X:=5; { Да хоть сколько угодно :) }
N:=Ord(X);
N1:=Byte(X);
End.
Для вычисления N и N1 компилятор даёт абсолюто одинаковый код (кроме адреса результата). Для N,N1 типа Byte код на выходе тоже одинаковый, только нет лапши для заполнения нулями трёх старших байтов.
В случае с Delphi, думается, результат будет похожий, проверял в TP, т.к. у него в листинге дизассемблирования проще и быстрее ориентироваться :) Разве что compiler-specific что-нибудь.
Возможно, что-то упускаю из виду...
Ага. На древнем проце. На новом пробовал? Не знаешь. Вот...
>Я проверял скорость, разница очень велика.
Да, но только на старых процессорах. Нет денег, что-бы поставить новый? Пока не перестаните считать каждый такт - их и не будет. ;)
>Нет, я уже перешёл на фиксированную запятую 16:16.
Вы безнадёжны. :)
>Я проверял скорость, разница очень велика.
Я тоже проверял. Очень часто даже заинлайнивание не значительных процедур - ухудшает производительность. Особенно это заметно в циклах. Цикл должен полностью помещаться в кэш. Иначе получишь тормоза на каждой итерации цикла, тк каждый раз будет происходить подгрузка в кэш.
Кэш здесь как раз к вышеупомянутому Instruction Prefetching, т.е. приёму, который реализован в процессорах производства начиная с конца 90-х. Суть приёма в том, что программа блоками по 16 байт подгружается во внутренний кэш, обладающий более высокой скоростью доступа, чем обычная ОЗУ. Таким образом удаётся несколько сократить время на загрузку инструкций в процессор.
По этой причине адреса, по которым осуществляются переходы в программе, рекомендуют выравнивать на 16-байтовую границу, т.к. при переходе куда-либо сравнительно далеко от точки перехода содержимое упомянутого кэша становится бесполезным и туда загружается новый кусок программы. Если блок начинается, например, по смещению 14 внутри 16-байтового блока, то в кэш поступит только 2 байта (максимум 2 инструкции), а затем придётся снова выполнять загрузку очередного, уже 16-байтного блока.
Касательно циклов идея в том, что если цикл умещается в 16 байт и выровнен на 16-байтовую границу, то он будет выполняться намного быстрее. Чем больше 16-байтовых блоков затрагивает цикл, тем медленнее он работает.
Надеюсь, случайным прохожим, если они сюда попадут, эта информация будет полезна.
Все современные процы делают с расчётом на то, что используются объектно ориентированное программирование, ну или как минимум функциональное. Так, что не думайте, что они для этого не оптимизированны.
Вы остались в далёком прошлом. Выходите из своего выдуманного мира в реальный. Сейчас все поминялось и не нужно сапеть над унролингом и ассемблером, переставляя команды для наибольшей производительности. Современные процы сами переставляют комманды. Пусть и не так эффективно, но время разработки - дороже. Если время разработки соизмеримо со временем использования проги, то нафих оно не сдалось.
На Delphi не пишу уже очень давно, т.к. в последние годы увлёкся идеей по-настоящему маленьких приложений и WinAPI-приложение на Delphi, занимая порядка 16 КБ минимум, несколько уступает 1 КБайтному на ассемблере. Можно и меньше, но в ущерб совместимости. Заметил, что ветка pascal-языков несколько более продуманна нежели Сишная. В плане синтаксиса, в плане работы с памятью. В Сях ощущается наследие PDP-компьютеров, этакий довесок. Но в pascal'е не хватает, конечно, некоторых краткостей: операций инкремента, декремента, например. Фигурные скобки не хочу, ибо пальцы спотыкаются :) Это к тому, что есть свои плюсы и минусы у всех языков, выбор обычно (если он есть) за тем, который а) лучше освоен и б) наиболее подходит для конкретной задачи. Это про хорошие и плохие языки.
Про совершенство. Я сам из Беларуси, сейчас проводим здесь фестиваль информационных технологий SAS IT Battles (если интересно - можете найти). В рамках фестиваля довелось встретиться с начинающим программистом, школьником. Он пишет на QBasic и решил показать нам свою игрушку. Получив заслуженное одобрение, задал несколько вопросов (попросил совета). Пришлось вспоминать молодость (я с этого языка фактически начинал), сдувать пыль с QBasic'а и лезть в справку. Так вот: тамошняя функция INKEY$() для считывания нажатых клавиш оказалась намного удобнее своих эквивалентов в Паскале и Си. И хотя это реализовано несколько сложнее в конечном итоге, для быстрой разработки приложений это несомненный плюс. Особенно для игровых, где задержка на это упрощение несущественна по сравнению с затратами на обработку (перерисовку изображения, например). Это я к тому, что иногда языки программирования спустя какое-то время оказываются очень неплохими, хотя и казались для этого полной чушью.
Позволю себе не согласиться с Вами и в вопросе об оптимизации. Хотя, конечно, сейчас наиболее эффективным способом оптимизации является поиск наиболее эффективного алгоритма, всё-таки иногда приходится обращаться и к низкоуровневой оптимизации. В том же Фасме в своих проектах использую самописные псевдо-объекты. Псевдо - потому что в них фактически реализована только инкапсуляция, никаких полиморфизмов и наследований. От последних решил отказаться, т.к. средства языка для этого не слишком удобны, да и выигрыш в быстродействии сомнителен, а необходимости нет. Не уверен, что решение правильное, но пока устраивает. В остальном - иногда просто хочется сделать приятное пользователю: написать программу, которая работает быстрее аналогов, занимает меньше места, чем аналоги. Да и демосцена - слово не чужое :) Так что низкоуровневая оптимизация хоть и отошла на второй план, всё ещё актуальна. IMHO и не ради спора, а ради присутствия альтернативного мнения. Надеюсь, Вы поймёте меня правильно.
Помоему лучше всего начинать именно с паскаль языков.
>всё-таки иногда приходится обращаться и к низкоуровневой оптимизации
К сожелению заметил, что "перемешивать" код на асеме тяжелее, чем автоматичеси компилятором. "Перемешивать" - имееться виду для верного распараллеливания комманд при выполнении. И ещё оказываеться, что при использовании ассемблерных вставок компилятор не может оптимизировать вызывающие функции и встраивать их, по своему выбору.
Если не использовать ассемблерные вставки, то компилятор сам наиболее оптимальным способом заинлайнит при необходимости функции. При использовании ассемблерных вставок приходиться делать это вручную и естественно это не гарантирует, что человек сделат это правильно, а времени обычно не так много для эксперементов.
На роль языка для новичков всегда очень здорово подходил Basic. Это в последние годы, кажется, все решили, что Pascal - для начинающих. Видимо, ориентируясь на Delphi. На самом деле классический Basic намного лучше скрывает от начинающего программиста детали низкоуровневой реализации: например, не надо на первых порах разбираться, чем отличаются целочисленные данные от вещественных, не приходится догадываться, зачем нужен Boolean. А уже потом, когда попробуют использовать переменную-флаг вместо логической, то паскалевские були становятся понятны сами по себе. С одного упоминания. Но какой язык наилучший для новичков - решать, увы, не мне. У нас в Беларуси сейчас подсовывают ABCPascal и детишки рисуют всякий бред. Лучше, чем ничего, но по сути ничто. :(
Вы - сторонник одноразовой экономики?
>Вы - сторонник одноразовой экономики?
А это что-за бред сивой кобылы? Используй свой проц много раз. Каждый раз, как сломаеться перепаивай. В конце сойдёт за брелок, но не вкоем случае не выкидывай, тк перерабатыватся ему негде, а Матушку-Землю засорять тоже не дело.
А Вы, кстати, подумали о том, что FPU-инструкции во многих старых компьютерах могут отсутствовать? FPU тал интегрированным только в 1989 году в i486. До того были i386 (которые ещё очень многими разработчиками полностью или частично поддерживаются), i286, i8086 наконец. О них Вы подумали? Так что эта попытка тоже выглядит слабо. Общая мысль несомненно правильна, а вот применение, увы, её опошляет.
Не верю, что у TarasB настолько древний проц. Конфигурацию мы так толком и не услышали (не прочитали), только упоминание, что где-то что-то отличается. Даже не услышали, как именно. Я, как человек, оставляю за собой право ошибаться, но обычно такие люди оказываются сидящими за компами с самой послдней версией ОС Windows и в ус не дующими. Я и сам придерживаюсь очень настороженного отношения ко всем новым технологиям и это неоднократно высказывал в публикациях в прессе... У меня на одном домашнем компьютере установлена Win98SE при процессоре Celeron 2000, на другом - она же при 166 МГц и 16 МБ ОЗУ. Но абсолютно не вызывает у меня подобной реакции упоминание о том, что в новых компах что-то есть лучшее. Здесь - осознанный выбор каждого. Кстати, если обратите внимание, судя по упомянутой частоте, процессор TarasB входит в число тех "новых", которые Pentium II и позже... Так что здесь скорее просто неумение признать ошибку. Даже и не ошибку, скорее неоправданный порыв гнева в адрес ненавистных разработчиков...
Может вы и CGI когда-нибудь писали на ассемблере? Где-то я тут такого видел... Да. Это очень оптимально. :p
Про CGI на ассемблере - неплохой пример :) Хотя минимальный набор возможностей, думается, обеспечить не так уж и сложно. С другой стороны, для высоконагруженных серверов, наверное, правильнее именно на асме, но с хорошей своевременной отладкой.
Я не любитель ассемблера, но из-за подобных высеров компилятора приходится.
Я не требую от него всё оптимизировать, но и усложнять код не надо. Замена трёх команд вызовом - это уже усложнение. И про кэш я не понял - а содержимое вызываемой функции в кэше место не занимает?
Вы продолжаете игнорировать всё, о чём Вам говорят и на что ссылаются. "Высер" - это очень здорово характеризует Ваше отношение к Borland. Как и все остальные слова. После "высера" ожидать от Вас адекватного отношения к вопросу не приходится. Увы.
Кстати, откуда такое трепетное внимание к любому высказыванию в адрес Борланда? Не впервой, значит, про них слушаете подобное? Может, неспроста?
А логике Вашей позавидует кто угодно!.. Такие грубые логические ошибки закатывать в такую обёртку... Во-первых, я не из Borland, чтобы, слыша подобные высказывания, одновременно их выслушивать и чтобы принимать их близко к сердцу. Во-вторых, если бы мне приходилось это регулярно слышать - я бы уже просто привык.
Всё проще. На самом деле я уже много лет пользуюсь различными компиляторами, в т.ч. и Borland'овскими, а также в исполнении их преемников. И по качеству реализации... Скорость компиляции, гибкость и простота настройки, качество генерируемого кода, степень интеграции в среду разработки и т.п. - по этим параметрам в совокупности Borland'овские продукты всегда подкупали. И, уж простите за прямолинейность, но от Ваших высказываний о них за версту несёт школотой. Если бы Вы а) действительно разбирались в этом вопросе на достаточном уровне и б) имели богатый опыт работы с этими и другими компиляторами, то Вы бы а) не задавали многих глупых вопросов, которые уже прозвучали, и б) не были бы столь категоричны в своих заявлениях. Что есть, то есть.
*Садиться в уголок и берёт покорн.* :)
>Основная идея красной нитью: если падение и будет, то несущественное по сравнению с падениями производительности от выбора алгоритма и т.п.
И программа будет меньше занимать. :) У когого там на проц и память денег не хватает? ;)
Ты хоть сначала не оскорблял никого. Тока не говори, мол, ты не стерпел выпадов в твою сторону. Пиздеж, от тебя их с самого начала было больше. Ты изначально высасывал аргументы для своей точки зрения из пальца.
Это не твоё место, имхо.
Кстати, почитай УК -- то, что я назову продукт фирмы борланд некачественным (читай, говном), это нельзя признать оскорблением, эта моя точка зрения относительно удобства использования произведения фирмы и его качества.
А Тарас молодец)
Без уважения, Тупое Малолетко.
Потрудитесь указать на выпады с моей стороны, которые бы не были адекватной реакцией. Даже самое первое сообщение, написанное ещё гостём, оно же самое экспрессивное, не содержит никаких личных оскорблений, только предложение задуматься, всё ли так однозначно. Художественный стиль моих реплик пока ещё устраивает и редакторов печатных изданий, и молодых программистов, с которыми случается проводить обмен знаниями, так что это останется, боюсь, Вашим мнением. К тому же сухой технический язык мне запретил TarasB, сказав, что "по-английски не хочу".
Вы не прочитали даже трети того, что здесь было написано. О чём Вы тогда делаете вывод? Аргументы из пальца? Ну, уж извините, отвечу в Вашем выпадном стиле: у Intel палец потолще Вашего будет, так что не надо меряться.
То, что это не моё место - Вы правы. Я больше привык работать с заинтересованными людьми, готовыми вести адекватное обсуждение. Это, знаете ли, не когда "у моей бабушки утюг кипятит воду при ста градусах", а когда "это устроено так, это этак, там было так". Аргументированно, с конкретикой. И доказывать кому-то, кто в этом не заинтересован, - это не моё, увы.
Касательно УК - это вопрос выбора своего представителя в суде, не мне Вам это объяснять. Ну и вопрос того, насколько каждый конкретный человек готов терять своё время ради успокоения кого-то там. Но то, что оскорбления в Интернете уже становились поводом обсуждения в правоохранительных органах - факт, ссылку найдёте.
> Без уважения, Тупое Малолетко.
Это Ваш стиль, а с самокритикой будьте осторожнее. Тем более, если "тупое малолетко", а не опытный человек.
С уважением, DimonSoft.
Мне всё было совершенно понятно и большей частью, описаннное, верно. ;)
Тем, что помимо загрузки и выгрузки (и фваита) она ещё и выполняет инструкцию fabs.
> Галактика IOK-1?
Нивкурил. Ты вот что-то мне говоришь про мифические новые процы, на которых именно такой код летает. У меня шестисотый селерон, для него это неверно. Поэтому я сделал вывод, что мой проц по твоей системе - древнее убожество.
На самом деле - проц нормальный, если лишнюю работу не заставлять делать.
> Вы фактически сами ответили на вопрос о том, при каком количестве вызовов Round() из разных мест программы получится выигрыш в размере программы.
А, да, я забыл, 11 байт в исходной реализации - это только при условии, что извлечение результата идёт в регистр. А если ещё и скопировать результат в память, то все 16. Где экономия?
> А логике Вашей позавидует кто угодно!.. Такие грубые логические ошибки закатывать в такую обёртку...
Про обёртку - у ваших научился. Радикальных ошибок у себя я не вижу.
> И, уж простите за прямолинейность, но от Ваших высказываний о них за версту несёт школотой.
Нет такого слова в словаре. Но говорят, им любят ругаться на собеседника лица школьного возраста.
> а) действительно разбирались в этом вопросе на достаточном уровне
Поверьте, даже небольшого разглядывания того, что генерирует дельфийский компилятор, хватает для того, чтобы больше не доверять ему узких мест.
Про случай, когда результат Round()'а будет записан в переменную вещественного типа, подумали? Так, к слову...
И, о Боги, да сколько же можно читать эту молитву?! Это говорю не один я. А насчёт древности компа - никто не говорит, что Селерон - это прошлый век. Если бы Вы читали не выборочно, то знали бы, что и у меня на домашнем компьютере не самый новый проц, тоже Celeron причём. Дело всё в том, что у Вас подозрительно отличаются результаты от тех, которые получились у многих других, включая самих разработчиков процессоров.
> это только при условии, что извлечение результата идёт в регистр
А ещё прибедняетесь!.. Да у Вас по ходу самый новый процессор, не далее как позавчера с конвеера сошёл. Иначе как объяснить, что он позволяет из FPU извлекать сразу в регистр, минуя память? Где-то Вы нас всех обманываете.
Логическая ошибка Вам была указана, так что внимания не заостряю: бесполезно.
Со школьным возрастом по работе контактирую иногда. Это слово входит в лексикон обычно только на 1-м курсе, а в употребление - не раньше 2-го. Так что тут у Вас тоже прокол. А уж как катаются мои коллеги. Ладно, не будем о грустном.
А при "небольшом разглядывании" навоз от человеческих экскрементов тоже не отличается. А вот на удобрения почему-то пускают в основном первое, а второе - разве что изредка. Да и писсуар от раковины в сущности... [Вроде формат сайта позволяе такие сравнения?] Для того, чтобы в чём-то разбираться, надо как раз неслабо повариться в конкретном вопросе, а не "немного поразглядывать".
И? Сделать fld-fistp-fld-fstp-fwait так тяжело (первое, что в голову пришло)? Тем более что компилятор примерно так и делает, ЛОЛ. Только второй fistp зачем-то вогнан в отдельную подпрограмму, которая извлекает в стек, копирует из стека в регистры, потом, после выхода из подпрограммы копирует опять в стек, потом продолжает эту цепочку...
Я не отключал оптимизацию, дельфа действительно так делает. Будешь дальше доказывать адекватность дельфийского компилятора?
> Иначе как объяснить, что он позволяет из FPU извлекать сразу в регистр, минуя память?
Подпрограмма ROUND так и делает. Делает она это посредством стека. Короче, там лишнее копирование.
Иногда оптимизатору хватает результата в регистрах, копировать в память ничего не надо. Иногда - нет, лишние байты кода.
Короче, порнушное решение, которое нихрена не экономит.
> Логическая ошибка Вам была указана, так что внимания не заостряю: бесполезно.
Что не так? Незначительная экономия кол-ва кода достигается только в одном случае - нам нужно целое число, которое можно оставить в регистрах.
> Так что тут у Вас тоже прокол.
тут ты миня обламал111 я горька плачю
> А при "небольшом разглядывании" бла бла бла
траля-ля два рубля...
> Для того, чтобы в чём-то разбираться, надо как раз неслабо повариться в конкретном вопросе, а не "немного поразглядывать".
Ты, походу, даже не разглядывал.
Я вот хоть и пользую дельфу там, где многие б не стали (мне скорость компиляции нравится), но до такого хомячизма не дохожу, чтобы оправдывать баги дельфы, придумывая им всякие нелепые объяснения, защищая борланд как святыню. (оййй, я ж с маленькой буквы борланд написал, меня сейчас молния покарает).
Кстати http://itc.ua/node/15800
Неплохой "прогресс" у семёрки после трёшки, да? Если чё, короткая полосочка означает меньшую скорость.
А это ЛОЛ. ЛишняяОперацияСПамятью.
Юзай одну frndint и будет тебе счастье. ;)
N:=N+Round(X); // X:Real; N:Int64;
компилится так:
fld qword ptr [ebp-08]
call 00402910 ; _ROUND()
add eax, dword ptr [ebp-10]
adc edx, dword ptr [ebp-0C]
И только здесь, когда уже закончилось выражение для вычисления, результат помещается в память. Надеюсь, наездов на Win32DAsm не последует со стороны аффтара, ибо это уже точно будет LOL.
Ну и, конечно, забавно пытаться дискутировать с человеком, который не использовал инструкции FRNDINT, допускает дичайшие промахи в терминологии и т.п. Не стоит обращать внимания ;-)
филд
> Если есть возможность вести дальнейшие вычисления - Delphi их проводит.
Да, только сложение с инт64 надуманно. Если сложить с другим екстендедом, то будет так, как я сказал.
> Ну и, конечно, забавно пытаться дискутировать с человеком, бла бла бла
Охренеть, какой веский аргумент. Демагожка...
Я может быть не использовал. И что? За меня это делает компилятор, но это не значит, что её не знаю и не могу дискутировать о её характеристиках и её использовании.
Доки от производителей помогают. ;)
А за меня - нет. О чём и говнокод.
> скопировать результат в память, то все 16
Это я, что ли, написал?
Ещё вопрос: слово "демагог" - это всё, что Вы можете из себя выдавить полезного?
Гуляй, демагог.
Ну это прокол, если он так действительно делает.
А вообще одна неоптимальность - не повод отказываться от благ цивилизации. Темболее, что мелкая неоптимальность - не ошибка. ;)
А про неоптимальности вообще Вы совершенно правы, как по мне.
Подлые и низменные силы зла набросились на святой борланд, и только димонсофт с мечом силы оберегает древний талисман.
Неплохая тема для митол-баллады. Правда, это, кажется, уже кто-то давно спел.
Или я запутался и мне пора спать. :(
Или у TarasB и DimonSoft разные подверсии 7-го дельфи и генерируют разный код.
Для инт64 прокол таки есть - всё равно делается лишнее перебрасывание из стека в регистры и обратно. Впрочем, оно как раз несущественно по скорости по сравнению с инструкцией калл. Я к тому, что аргумент про размер кода тут обломался.
А откуда эта фраза? Какая-то книга? Или сами придумали?
Мне он не нравится, даже как язык, не то что как компилятор. Конечно пользуюсь, но редко - для мелких служебных прог "на пять минут". Но делать из-за какого-то обиженное лицо, винить борланд во всех грехах. Просто излишне.
В конце концов у Delphi есть свои плюсы++ и их не нужно списывать со считов.
Да всё равно уже неприлично так относиться к написанию оптимизаторов.
Получается порочный круг - борланд плюёт на оптимизацию, говоря, что "а всё равно на дельфах ничего сложного не пишут", программисты ничего не пишут сложного на дельфах, говоря, что "а там компилятор дубовый, не катит".
Из пушки по воробьям, понятное дело, никто не стреляет, и странно, что у Вас это вызывает такую реакцию.
Типа Тотал Командера или Квипа? Дык а там нет сложных вычислений.
i := round(d)
компилировалось в
fld d; fistp i; fwait;
А не в
fld d; call @ROUND; mov i, eax
Первый вариант - логичный и простой, второй - какой-то дикий ненужный костыль, примотанный к здоровой ноге, из-за которого она не может нормально гнуться.
Если не нужно одинокое округление - то есть frndint
Где какое надо - номальный компилятор разберётся.
Не, ты мне вот по простому скажи - что сложного записать код команды фистп вместо кода команды калл? Там же надо ещё и запоминать адрес этого раунда, морока же лишняя.
Когда усложняется язык по мере развития - появляются места, требующие серьёзной оптимизации. ООП-код на такие места богат. И поэтому основной упор делается именно на эти участки. Потом, когда всё основное соптимизировано, можно попробовать оптимизацию мелочей. Но если подход к оптимизации изначально другой, неподходящий, то сделать это не так просто. Раздалбывать полоптимизатора разве что, чтобы воткнуть костыль. И скорость компиляции упадёт. Как это влияет на число человеческих ошибок в программе - известно. Здесь разработчик компилятора ищет баланс между сделать медленной и нудной разработку, усложнив её, или пожертвовать производительностью некритичного кода.
В Вашем случае, если помните, падение производительности от вызова функции происходит далеко не всегда.
Подробнее - в упомянутых книгах.
Какой тексель в РАД среде? O_o
Ждём. Производители видеокарт скоро начнут производить эмуляцию оной, написав драйвер на дельфи. :)
Это как раз в продолжение темы про пушки и воробьёв. Я там про написание своих OpenGL и DirectX несколькими днями ранее писал: тему замяли.
Никогда не понимал, почему дельфисты так этим кичатся. Как будто сложно накликать мышкой из стандартных контролов для виндовс 3.0 свой собственный норком. И между прочим, тоталкоммандер так и застрял в третьих виндах навечно
А потом его спросили: "А сколько вы, эксперт, написали компиляторов?"
Это сообщение было последним на том форуме.
Не знаю. Вспомнилось что-то... Эх...
Или смириться.
Или стать разработчиком следующей версии дельфи и поднять его на нужный уровень. :)
> Если считаете, что дельфи-говно - зачем обсуждать? Сотрясать воздух? Он от этого лучше не станет...
Если считаете, что дельфи-сила - зачем обсуждать? Сотрясать воздух? Он от этого лучше не станет... Это не тот сайт вообще.
Может быть. Хотя мне кажется это из-за маркетинговых неудач Borland, тк она уже тогда теряла свои позиции. Помоему она уже и компиляторами не занимается, если вообще существует. Ничего о ней давно не слышал, хотя и не интересовался этим особо.
7 мая 2008 года компания Embarcadero Technologies приобрела у Borland Software её подразделение Codegear за 23 млн долларов и 7 млн долларов в дебиторских задолженностях, доставшихся Borland.
6 мая 2009 стало известно о том, что компания Borland Software будет продана за 75 млн долларов британской компании Micro Focus, специалирующейся на поддержке крупных корпоративных систем на языке COBOL.
Про то, что сложность операции округления ниже сложности взятия модуля, - повеселило, но больше не смешно. Дальше мы опять успешно перескочили от сложности операций к особенностям реализации алгоритмов в соответствии со стандартами. Без комментариев.
Да и Ваши предположения продолжают меня восхищать своей детской наивностью. Которая успешно дополняется "тыканием" совершенно незнакомому Вам человеку. Видимо, дискуссию от коллективной пьянки мы отличать не научились. Жаль.
Нелепость объяснений. Ну-ну... Последний раз повторюсь: я не стоял со свечкой и не выяснял, почему в Borland решили реализовать именно так. Я могу лишь предполагать, опираясь на то, что вижу, и то, что знаю. И высказывать эти предположения со сслкой на конкретные документы и стандарты. Если подобные объяснения - "нелепые", то какими же тогда считать Ваши? Может быть, лучше сразу с разработчиками конкретного компилятора меряться будете, чего тут людям морочить голову, рассказывая о своих сомнительных изысканиях?
Тест очень убедителен. Информации о том, какого класса приложение создавалось, я так и не нашёл. С учётом того, что в Delphi до 7-й версии довольно стремительно развивалась VCL, накладывая отпечаток на общее быстродействие, и если вполне закономерно предположить, что приложение создавалось с использованием стандартных средств, то становится понятно, откуда такие результаты.
Но Ваше обвинение в адрес Delphi звучит по сути так: они целенаправленно ухудшали свой компилятор от версии к версии. Забавно, что при этом наибольшей популярностью и по сей день поьзуется именно седьмая версия. Нестыковка, кажется?
Ну вроде как от Borland - Delphi 7 - последний компилятор. Остальные выпустила другая фирма и по слухам они глючные. Я судить не берусь, ибо в глаза не видел.
Аааа, это мегаЛОЛ. Всё, пиздец, я сдаюсь, против этого аргрумента я бессилен. Я плачу ааа.
Остальную часть поста не читал.
Пишите вы хорошо, интересно, приводите нормальную аргументацию, т.е. опровержение в чистом виде и по факту, а не "целерон", "знаю предостаточно" и т.д. Но вы написали столько текста, сколько я не писал когда-то на диплом наверное. Просто складывается впечатление что это именно вы тот разработчик из борланда, что допустил такой ляп(? все равно call ради одной инструкции меня напрягает, несмотря на то, что на производительность он вроде как совсем не влияет). И теперь вы старательно оправдываетесь.
Если кратко то слишкам многа букфф ради одного call. Вот если вы все это скомпонуете и оформите в статью, то считаю, что будет очень интересно и познавательно. Тем более что я сейчас пишу компилятор для своего небольшого процедурного ЯП. По профессии я, если что, пишу офисный мусор на шарпе.
Букв действительно много. Зато, заметьте, охватили много смежных вопросов.
> Вот если вы все это скомпонуете и оформите в статью, то считаю, что будет очень
> интересно и познавательно.
Думаю, это действительно возможно. Обсудим размещение этой статейки с редакцией какой-нить из местных газет компьютерной тематики. По формату им как раз должно подойти. Ссылку кину, если что.
> Тем более что я сейчас пишу компилятор для своего небольшого процедурного ЯП.
А ведь оптимизация, которая обсуждается здесь - она тонкая достаточно. Стоит ли уделять именно ей столько внимания в своём компиляторе? Просто риторический вопрос, для размышления. ;)
Я пишу на высоком уровне, низкий для меня скорее хобби, мечта(своя ОС например, как раз планирую заняться) и просто развлечение.
Вообще хотелось бы видеть больше полезных и интересных сайтов по асме, одного wasm'а маловато будет.
> сайтов по асме, одного wasm'а маловато будет.
А о чём? Все сайты по асму так или иначе сводятся к разъяснению всего того, что пишут в своих доках разработчики процессоров. Вопросы на форумах это, как правило, подтверждают. Хотя, конечно, собрать бы это всё воедино да упорядочить...
http://dimonsoft.ueuo.com/opttest/
Оттуда есть ссылки на все остальные ресурсы.
А результаты тестирования уже где-то можно посмотреть?
Все "жизненно необходимые" ссылки - внизу страницы.
стека) с последующим извлечением результата инструкцией FISTP.
Фигли врёшь, я говорил сразу применить FISTP.
Ты пиздобол, Димонсофт.
А то дельфи сейчас не стоит.
Так будет легче ориентироваться. :)
fistp dword ptr [esp]
fwait
pop eax
pop edx
ret
Как-то я писал курсовую работу: компилятор Си для мк51. Четыре поставили, кстати. :( Успел доделать в последний день зачётной недели вместе с отчётом. :D
Оптимизацией у меня там даже не пахло. Как сейчас помню. Оператор = у меня превращался поменьшей мере в PUSH EAX; POP EAX; :D Там, конечно, свои, команды контролёра мк51, но сути это не меняет.
Вполне возможно, что борланду пришлось выпустить сырую версию, из-за внутренних проблем. Если бы её не выпустили, то развалились бы раньше и вообще бы ничего не выпустили...
Кому-то дельфи нравится и он его использует. Мы ему не будем мешать. Это его дела. :)
1)А вы используете дельфи?
2)Почему?
3)Для чего? (Не будет лишним список ваших программ, проектов, если конечно это не секрет).
4)Если не используете, то что используете взамен? И почему?
:)
Не нужно копать яму ложкой или есть суп лопатой. Оно конечно можно, но не так эффективно.
Delphi - RAD система. Тоесть система быстрой разработки.
Предназначен, что-бы быстренько слепить что-нибудь, показать формочки, получить деньги, свалить на канары подальше от заказчика. Всё. Причём тут скорость работы программы? O_o
Я терплю дельфу только за скорость компиляции и за простой для понимания язык.
Про то, что на этот баг всем пофиг, так как дельфу никто для программ со сложными вычислениями - я уже сказал. С этим, увы нельзя не согласиться, но тут нельзя однозначно сказать, что послужило причиной. Возможно, так сложилось как раз потому, что борланд забил на оптимизацию.
Что я написал - что-то да написал, зачем светиться, особенно перед тем товарищем?
столяр говорит:"блин, ненавижу ключ на 10, им плохо доски отёсывать"
а слесарь ему в ответ:"ты, сам му**к, ключ на 10 это классно, а вот топором гайку закручивать это попа, топор - отстой"
и пошла драка не на жизнь а на смерть
http://govnokod.ru/3376#comment30390
http://www.nestor.minsk.by/kg/2010/38/kg03804.html
Дельфи позорит, гад.
Это в http://govnokod.ru/27233
https://www.oreilly.com/library/view/learning-gnu-emacs/0596006489/
уже понятно, что тебе нужен емакс
https://i.imgur.com/9PX0wok.png
Хотя в емаксе есть LSP и анимешная ведьмочка... Блин, я призадумался.
Во всяком случае в vim с exuberant tags у меня комплишен для сей был (хоть и тупой).
Попробуй также VSCode: там есть LSP сервер для Python
Да и для емакса есть LSP с питонием. А VSCode не хочу, он мелкомягкий.
лор такой лор
Пидец. У меня такое же случилось (((
Советую почитать, там люди очень смешные вореции пишут:
Ва алейкума сСалям, ва рахматуЛлахи ва баракятух Брат!
Просто поставь антивирус и все, ин шаа Аллах проблем подобных не должно возникать... Лично у меня стоит аваст, он бесплатный и постоянно обновляет свои базы через интернет. Альхамду-лиЛлях уже больше года им пользуюсь и все в порядке. БаракаЛлаху фик!!!
Один раз я по глупости своей попался на одну спам рассылку в агенте. Вся беда в том, что ко мне пришла ссылка (ля-ля тополя), а я наивно поверив скачал что-то (сам не знаю что), и установил его у себя на компе. После установки мой манитор вдруг переполнился диалоговыми окнами, и я понял что попался на мышеловку :). После этого от моего имени началось рассылаться подобные спамы. Меня это конечно дразнило, но я нигего поделать не мог. Пытался менять код, но бестолку, рассылка не прекращалось. Обращался к одному брату, он сказал что я устанавил себе мини програмку и теперь они по средством этой програмки получают инфо о моих поролях и менять пороль бесполезно. Какие действия можно предпринять в подобных ситуациях?
Один раз я по глупости своей попался на разводку. Вся беда в том, что какие-то люди попросились ко мне попить водички (ля-ля тополя), а я наивно поверив пустил домой кого-то (сам не знаю кого), и поселил у себя на неделю. Через неделю у меня пропали все деньги, и я понял что попался на мышеловку :)