1. Assembler / Говнокод #2172

    +240.1

    1. 1
    2. 2
    fld qword ptr [d]
    call @ROUND

    Это творчество дельфийского компилятора на тему i := round(d);
    Он делает вызов функции ради одной пустяковой команды, что очень влияет на скорость.

    Запостил: TarasB, 24 Ноября 2009

    Комментарии (283) RSS

    • говноборланд ))))
      предложи в inline переделать
      Ответить
    • С самого начала знал, что борланд - идиоты, а дельфи - говно. И только ассемблер и Си - на высоте. С++ - и тот лучше.
      Ответить
      • +1

        паскаль не люблю, дельфи тоже
        си рулит!!!

        Вот у меня есть прога, работающая с логическими функциями, там используется полно логических операций & | ~.
        И на дельфи это будет длинная строка типа (a and b) or c, тем более, там нет разницы между операциями над битами и над логическими значениями, что приводит к путанице или необходимости везде писать <>0.
        Ответить
      • ты - идиот, потому как:
        разработка п.о. состоит из множества фаз, в которую входит далеко не одна фаза тестирования
        более того, если о баге составили репорт, сомневаюсь, что борланд это не пофиксит
        ты идиот во второй раз, потому как не понимаешь нихрена между компиляторома, языками и их реализациями
        да, и не забудь, что компиляторы ща намного умнее оптимизируют нежели ты... си, си++, асм... :-!
        Ответить
      • >>>С самого начала знал, что борланд - идиоты, а дельфи - говно.
        подписываюсь, всегда тошнило
        Ответить
        • I don't even know what to say, this made thngis so much easier!
          Ответить
        • Very true! Makes a change to see soemnoe spell it out like that. :)
          Ответить
    • Баг древний - в турбо паскале он, судя по результатам простого теста на скорость, тоже есть.
      Дельфа тут, если что, седьмая, старая. Про новые версии не знаю, в них это исправили, кстати? А то бесит делать ассемблерные вставки при работе с вещественными числами.
      Ответить
      • Следующие дельфи делал не борланд. Говорят, они там ещё и налажали. Глючат проги.
        Ответить
    • А мне ещё их выравнивание нравится. Которое - "MOV ECX,ECX". Чем им NOP не угодил - до сих пор не пойму.
      Ответить
      • BTW, "MOV EAX, EAX" сжирает 0 тактов процессора, т.е. работает так же как и NOP. Как "MOV ECX, ECX" не в курсе, но догадываюсь что так же :).

        Хотя я соглашусь, что это изврат. ;)
        Ответить
        • Визуально "замусоривает" отладку. На быстродействие, конечно, не влияет: процессоры стали умнее "индусов". ;)
          Ответить
        • А каков размер инструкции? Не может быть так, что одно тупо меньше другого?
          Ответить
          • mov ecx, ecx - джва байта.
            nop - один

            Возможно, они специально так делают, когда надо именно джва байта забить чтобы не нагружать декодер джвумя нопами.
            Ответить
            • А зачем бывает нужно два байта? Для выравнивания?
              Ответить
              • > для выравнивания

                Угу. Кстати я посмотрел как сейчас конпеляторы делают -- а они юзают длинную форму nop, которую префиксами и режимом адресации можно подогнать почти под любой размер.

                Возможно в делфи пытались поддержать какие-то древние процы, где этой формы не было. В интеловской доке не написано, когда эта инструкция появилась, к сожалению. А в gcc опытным путём не получается границу найти, он для 32-битного кода всякие xchg да lea ебашит вместо длинных nop'ов.
                Ответить
                • Pentium 3 походу.
                  Ответить
                  • забавно
                    Вика пишет, что опкод 0x90. При этом в Long mode (x64) он превращается в ``xchg eax, eax``, который still has no effect Ж)
                    Ответить
                    • Не, 0x90 -- это старый добрый nop. А есть ещё 0x0F 0x1F.
                      Ответить
                      • Я только CC помню наизусть по понятным причинам:)
                        Я о том, что 0x90 в long mode не совсем nop, хотя и без эффекта.

                        0x0F 0x1F это как раз чтобы два байта забить?
                        Ответить
                        • > 0x0F 0x1F это как раз чтобы два байта забить

                          У него аргументы есть, так что там от 2 до 15 где-то. По крайней мере я сейчас вижу как gcc собрал 11 байтную форму.

                          З.Ы. Пишут, что только в 2006 году задокументировали. Хотя работало задолго до этого.
                          Ответить
                          • Зачем может понадобиться выравнивание до 16 байт (или зачем там 15 байт пудинга?)
                            Ответить
                            • Чтобы функция начиналась с удобного декодеру места. Она тогда быстрее стартует.
                              Ответить
                              • То есть у декодера такая хлеборезка, что он сразу по 16 байт кусает?
                                А по 32 бывает?
                                Ответить
                                • > по 32 бывает

                                  Я не знаю, никогда не оптимизировал на таком уровне... Но вроде кусками по 16 читает. И если ты начал с середины куска, то за этот такт ты набросишь гораздо меньше инструкций на конвейер, чем если бы ты начал с начала.
                                  Ответить
                                  • Понятно. Тогда паддинг логичен.

                                    Сколько вообще в комптютере места проебывается из за этих выравниваний: и в оперативке, и вон в секции кода.

                                    Ну эти инструкции то хоть бесплатны? Модуль выполнения поймет, что они не нужны, и не будет их выполнять?
                                    Или их прямо декодер превратит в пустоту?
                                    Ответить
    • Кэп, подскажите, как делфя должно это делать правильно? Или есть стардартная команда процессора аля round?
      Ответить
      • fld qword ptr [d]
        ROUNDINT
        Вроде так. В вершине стека сопроцессора лежит результат.
        Ответить
        • Что за команда вообще такая - ROUNDINT?
          Ответить
          • Тфу. И вправду не то, заработался:
            fld qword ptr [d]
            frndint
            Ответить
            • все не так просто как кажется в FPU есть еще такая штука как разные режимы округления, и ваш код не всегда будет работать как запланировано...
              именно поэтому MSVC сначала выставляет округление по дефолту, но есть оптимизация, позволяющая отключить это
              Ответить
      • Все подобные функции должны быть макросами, то есть дельфя должна вместо вызова этой функции подставлять её содержимое, то есть команды сопроцессора fistp и fwait.
        Ответить
        • показать все, что скрытоНикому они ничего не должны.

          Просто на Дельфях не надо писать приложения, которые чувствительны к тому, как округляются даблы: call-ом или inline.

          А если лень писать на C или на голом ассемблере, полагаю, нет и смысла беситься из-за ассемблерных вставок.

          Написать свою INLINE функцию, состоящую из одной ассемблерной вставки, на Дельфях уже можно. А макросы - это зло. Точнее, зло для криворуких.

          Простой пример:

          #macro mul(a,b) a*b
          ...
          int i = mul(2+3,4); // i==14, а не 20, как хотелось бы.
          Ответить
          • Ну ты бреда понаписал.
            Сначала никто никому ничего не должен, а потом фигня получается.
            А потом писать тупые отмазки "ну не надо на дельфях писать приложения, в которых важна скорость"? Ну да, это проще, чем написать компилятор нормально.
            И я, вообще-то, не про те макросы, которые задают пользователи, забывая обрамлять их скобками, а про стандартные. Чтоб ты знал, функции типа odd - макросы.
            А инлайны в виде машинных кодов тоже наизусть предлагаешь учить?
            Ответить
            • Да, про машинные коды - это я турбо паскаль вспомнил. В дельфах это вообще отменили, круто.
              А ставить фреймворк ради новых версий - ну, нафиг, у меня комп древний.
              Ответить
          • #define mul(a,b) (a)*(b)
            Ответить
          • Так можно? В каком языке? В новых Delphi 20XX года?
            Ответить
          • >#macro mul(a,b) a*b
            А так можно и в Pascal?
            Ответить
            • Братцы. Pascal изначально, и Delphi по факту и наследию - язык учебный. Если б в Дельфях можно было писать макросы, как из приведенного мной примера, учеников (паче, учителей) порвало бы в клочья. Естественно, пример из Цэ. Но.

              В дельфях уже можно писать inline-функции (см. это слово в Help, в семерке не уверен, в 2005-х - точно). В учебниках по плюсам авторы часто подчеркивают, что не надо городить макроопределения там, где можно реализовать inline-функцию: контроль типов, обход описанной мной выше ситуации, и т.д. Посему Тарасу и было скромно намякнуто: напиши inline с asm-вставкой, и будет тебе макрос.

              Наследия округлятелей как функций сохранились с тех бородатых времен, когда у компилятора был флажок про 87-й сопр - "эмулировать или использовать его инструкции". Флажок цинично подставлял разные точки входа. Флажка в помине нет - точки входа остались. Потому что в учебном языке скорость округления дабла не роляет. Потому что в учебном языке никому не надо исправлять давно отлаженную и работающую функцию. Потому что не надо писать критичные к скорости выполнения приложения на учебных языках. Если шибко хочется считать развитую арифметику - надо брать библиотеку, написанную разработчиком конкретного процессора, и линковать ея.

              Аминь.
              Ответить
              • Хорошо расписал. Соглашусь.
                Ответить
              • Во-первых, что мешало в те времена цинично подставлять разный код, а не разные функции?
                Во-вторых, из-за такой вот ерунды и кричат всякие, что мол, Паскаль - язык для учеников, ничего серьёзного на нём написать нельзя, ну и прочая фигня.
                И я всегда крайне негативно отношусь к ухудшениям, которые сделаны не для упрощения или удешевления, а просто тупо по лени разработчика.
                Ответить
                • Правильно.
                  Ответить
                • "Три вопроса"

                  - Ты Дельфи украл, или купил?
                  - Ты преподаешь, или учишься [, или умный шопесец]?
                  - Ты профессионал, или энтузиаст [, или ты написал компилятор лучше]?

                  А так - да. Относись.
                  Ответить
                  • 1. Скачал старую версию бесплатно.
                    2. Ни то, ни то [ну ты в натуре умного корчишь, я смотрю].
                    3. Энтузиаст [ололо, сперва добейся].
                    Ответить
                  • ахахахаха, дочитал до места где ты засовываешь в нос палец и принимаешься вытаскивать оттуда сотни философии
                    Ответить
          • Обломайся, inline не позволяет ассемблерные вставки, Bugland ниасилил.
            Ответить
        • Хотелось бы увидеть такой макрос в Вашем исполнении, маэстро. Чтобы работало такое:

          printf("%d",Round(0.5));

          Не надо путать макросы и подставляемый компилятором код. Этим разные программы занимаются. Максимум - разные части одной многофункциональной программы. Препроцессирование и компиляция не есть единое и однообразное.
          Ответить
        • > макросами

          Скорее интринсиками.
          Ответить
    • Народ, думали о том, что есть 4 способа округления? Документацию Intel вообще читали? Задумывались о том, почему в Delphi, как и в других ЯВУ, меньше проблем с выводом FP-значений, чем в нашем родном, любимом низкоуровневом АСМе? Про то, что в новых процах CALL'ы оптимизированы запределно, слышали? Branch Prediction, хотя бы, Instruction Prefetching...

      Очень интересно также узнать, что думают товарищи о коде, выдаваемом M$ компиляторами Сей? По молодости дизассемблировал проги - в те времена БорландПаскалевский вариант был намного чище...
      Ответить
      • > Народ, думали о том, что есть 4 способа округления?

        И? Оттого, что выбор способа будет внутри вызываемой функции, а не будет прямо подставляться в код - код станет быстрее? Стабильнее?

        > Про то, что в новых процах 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'ов: если кратко, то нагрузка от них незначительна, поэтому нет особого смысла инлайнить некоторые процедуры. В частности, те, которые достаточно крупны или обособленны.
          Ответить
        • Ещё момент... Оттуда же, из раздела "Improving the Performance of Floating-point Applications", подраздел "Floating-Point Stalls", пункт "Hiding the One-Clock Latency of a Floating-Point Store":

          > 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-проги"? Не зря меня знакомые отговаривали от пустой траты времени на объяснение азов :(

        Конкретно здесь фишка не в читабельности, а в генерации стабильного кода, лишённого ненужных заависимостей и соответствующего общепринятым стандартам, а также упрощении внутренней реализации компилятора, что не менее важно при разработке сложного программного продукта и допустимо, если это не влияет на качество результирующего продукта, либо влияет в исключительных случаях, которые не затрагивают области применения этого продукта.
        Ответить
      • > > Это по оптимизации CALL'ов: если кратко, то нагрузка от них
        > > незначительна, поэтому нет особого смысла инлайнить
        > > некоторые процедуры.
        > Я проверял скорость, разница очень велика.
        Я проверял скорость, разница очень велика в пользу процедурного подхода. Если проверяете - указывайте аппаратное и программное обеспечение, а также приводите текст программы. Иначе мы много натестируем. Потрудитесь также найти указанный мною официальный документ и убедиться в том, что я это беру не из воздуха. Возможно, также, что Ваша ирония иронией не была и у Вас действительно старый-добрый i8086. Либо в Вашем тесте зашкалила синтетика (см. упоминание про проектирование приложения). Для сравнения, кстати, напишите аналогичную программу на Си и скомпилируйте ANSI C-совместимым компилятором. У них реализация округления понавороченней будет.

        > > Вообще, по правде сказать, не понимаю, зачем
        > > выбрасывать сюда код, сгенерированный
        > > автоматически?
        > Это сайт такой, понимаешь. Говнокод называется.
        > Сюда выкладывается говняный код. Например,
        > типа этого.
        Эм-м-м, да будет Вам известно, что г&$но-с, оно имеет животное происхождение, т.е. должно исходить от животного. В случае с кодом таковым является представитель вида Homo Sapiens. А не компилятор.

        Опять читаю прописные истины, но всё же... Продукт компиляции - это автоматически генерируемый поток информации, причём генерируемый по определённому алгоритму, решающему задачу компиляции в ОБЩЕМ виде. Не путайте наконец компилятор и ассемблер, если на то пошло. В данном случае решение разработчиков Delphi абсолютно оправданно и не противоречит здравому смыслу.

        А с Вашей стороны, если Вы претендуете на звание специалиста, было бы логичнее выложить не сгенерированный код, а тот код, который обеспечивает такую генерацию. И в формате обсуждения, потому что там специалисты покруче нас с Вами вместе взятых.
        Ответить
      • > > "Сам попробуй напиши, а потом наезжай"
        > Я сам написал ассемблерную вставку, заменяющую
        > эту функцию, что значительно ускорило программу.
        > Этого хватит?
        И речь в этом случае идёт не о написании эквивалентного кода, а о написании компилятора, который будет лишён этого недостатка и не уступит рассматриваемому по другим пунктам. Пока что в Ваших сообщениях читается отсутствие опыта работы над действительно большими проектами. Увы!.. А макроса в Вашем исполнении я так и не увидел. И не надо сейчас про оговорки: если Вы берётесь "обгаживать" большой проект, разработанный высококвалифицированными программистами - будьте добры соответствовать их уровню хотя бы частично и не путаться в БАЗОВЫХ понятиях. Как можно спорить о качестве компилятора, если Вы его не отличаете от препроцессора?

        > > Если Вы используете округление в огромном цикле, где скорость критически важна
        > Нет, я уже перешёл на фиксированную запятую 16:16.
        Рад, что в Вашей программе это возможно. В критичных по скорости выполнения приложениях бОльшая часть работы выполняется ДО (!) непосредственного использования результатов. Редкий случай, когда округление нужно здесь и сейчас и многократно и выполнить его заранее нельзя, никогда не использует ЯВУ (языки высокого уровня). Ваша ирония опять выглядит глупо.
        Ответить
      • > > Если у Вас жизненно важен каждый такт
        > > (хм, интересно, бомбу запускаете?) - тогда
        > > почему Вы пишете на Delphi?
        > А почему нельзя? Потому что Дельфа для
        > этого не предназначена? А почему? Не из-за
        > языка, а из-за того, что компилятор лажает.
        > Так? Вот я и привёл пример такой лажи.
        > Ещё ко мне вопросы есть? Нет. Всё, свободны.
        Как здорово: сказал и закрыл тему. Молодец. Хохочем всей конторой. И хотя Вы абсолютно не настроены, насколько я вижу, адекватно воспринимать контраргументы и цель была в очередной раз выпендриться (это видно по заезженным клише, которые Вы активно используете), я попытаюсь ответить на Ваши вопросы. Хоть ответы и очевидны.

        Delphi действительно не предназначена для разработки высокоскоростных приложений, как и наши любимые C++, Java, всё семейство .NET-ориентированных языков и т.п. И программы такой критичности пишут именно на ассемблере. По той же причине, по которой Вы едите суп ложкой, а не экскаваторным ковшом (я надеюсь!) и запиваете из кружки/стакана, а не напёрстка. Потому что есть инструменты, предназначенные для разработки прикладного ПО, которое большую часть времени ожидает действий пользователя и не выполняет критичных по скорости операций. И есть обратный случай, когда надо всё писать вручную, потому что никакой автоматизированный комплекс программ этого лучше программиста почти наверняка не сделает. Выбор адекватного инструмента - это отличительная особенность хорошего программиста от говнокодера. Человека от обезьяны наконец!.. И если Вы собрались написать операционную систему целиком на Delphi - это Ваше право, но место в лечебном заведении предоставляется в порядке живой очереди. Как и в случае написания, скажем, AutoCAD'а или OrCAD'а на чистом ассемблере, без FASM'овских макросов и т.п. удобств.
        Ответить
      • "Компилятор лажает". Если Вы до сих пор не поняли, что это фича, а не баг - честь и хвала Вам. Наверное, именно Вы придумали компьютеры и всё им сопутствующее, раз отрицаете даже официальную документацию разработчиков. Аминь!..

        По-прежему остаётся ощущение, что Вы вините именно язык. Ваше право, но Вы не правы. На DelphiMaster.ru, например, Вас бы очень быстро и абсолютно корректно спустили с небес на землю все, включая обитающих там сишников, джавовцев и даже железячников. С точки зрения, например, синтаксиса Паскаль, лежащий в основе Delphi, куда более продуманный.

        Вы можете сюда выкидывать сколь угодно произвольные свои изыскания, но давайте Вы не будете прикидываться, что в других компиляторах мало ляпов. Я уже далеко не первый и не второй год в этом варюсь и на своём веку дизассемблировал немало программ, самых разных. Есть действительно достойные звания говнокода места, а не подобные сомнительные изыскания.
        Ответить
    • > Читаем 4 поста

      Я прочитал всё, но на всё ответить не в состоянии, поскольку у меня нет приступа словесного поноса.

      > а в генерации стабильного кода, лишённого ненужных заависимостей

      Код, в который тупо вставлены 3 команды (fld, fistp, fwait), тоже не содержит никаких лишних зависимостей, но работает в разы быстрее, чем код, вызывающий функцию которая делает те же команды.

      > Возможно, также, что Ваша ирония иронией не была и у Вас действительно старый-добрый i8086.

      Селерон, 600 МГц. Мне убиться? Ничего, что большинство используемых нынче ЭВМ (если брать не только персоналки) примерно того же уровня?

      > Delphi действительно не предназначена для разработки высокоскоростных приложений

      Мне нужна не высокая скорость, а всего лишь приемлемая. И чтобы компилятор не делал таких элементарных ошибок. Кстати, почему вот такие конструкции, как odd() или Length(), таки ещё со времён турбо поцкаля всё-таки сделаны макросами? Значит, дело не в "разделении труда", которое вы непонятно зачем приплели.
      Ответить
      • > Селерон, 600 МГц. Мне убиться? Ничего,
        > что большинство используемых нынче
        > ЭВМ (если брать не только персоналки)
        > примерно того же уровня?
        Ну, во-первых, нынче используются даже в школах компьютеры помощнее, не в упрёк Вам будет сказано. Во-вторых - чуть дальше.

        > Мне нужна не высокая скорость, а всего лишь приемлемая.
        > И чтобы компилятор не делал таких элементарных ошибок.
        Значит, всё-таки программисты Borland тупее Вас. Позвольте Ваш автограф?

        > Кстати, почему вот такие конструкции, как odd() или Length(),
        > таки ещё со времён турбо поцкаля всё-таки сделаны макросами?
        Odd() в сущности вообще почти ничего не делает, т.к. для целочисленных типов её значение равно самому числу, а для перечисляемых - они при компиляции рассматриваются как константы с последовательными целыми значениями, т.е. тоже никаких преобразований не надо. И Odd() используется лишь для того, чтобы в языке со строгой типизацией выполнить приведение типов. Length() - это просто взятие однобайтового значения по вполне определённому ещё на этапе компиляции адресу. И тоже никаких приведений. Odd() фактически вычисляется ещё при компиляции (м.б. только за исключением редких случаев, когда сложное сочетание типов используется), а Length() - это просто byte ptr [...]. Операция присваивания сложнее, чем Odd() и Length(). Странно, что Вы расковыряли программу в Round()'ом и поленились посмотреть, как реализованы более часто используемые вещи.

        > Значит, дело не в "разделении труда", которое вы непонятно зачем приплели.
        Посмотрите исходник System.pas, найдите там реализацию этой и ещё некоторых других функций. Вы правда думаете, что это пакости ради так сделано? Или по тупости? Я рядом со свечкой не стоял, но налицо ситуация, когда разработчика самого компилятора избавили от необходимости делать то, что тот делать не обязан.
        Ответить
        • > Odd() в сущности вообще почти ничего не делает, т.к. для целочисленных типов её значение равно самому числу

          Уууу... И кто тут некомпетентен?
          Кстати, раунд тоже почти ничего не делает - всего-то загрузить кучку байт в сопроцессор и выгрузить обратно.
          Ответить
          • > > Odd() в сущности вообще почти ничего не делает,
            > > т.к. для целочисленных типов её значение равно
            > > самому числу
            > Уууу... И кто тут некомпетентен?
            Да, недосмотрел... Odd(), а не Ord(). В случае с Odd() ситуация иная, но не менее очевидная: при реализации функцией булевское значение придётся передавать в AX, а потом снаружи это AX проверять на равенство нулю. Тогда как намного проще просто сделать то, что делает вышеупомянутый Turbo Pascal: сдвиг вправо и дальнейшее использование CF. Возврат флагов соглашением stdcall не предполагается.

            > Кстати, раунд тоже почти ничего не делает -
            > всего-то загрузить кучку байт в сопроцессор
            > и выгрузить обратно.
            Вы сами задали эту тему в контексте Turbo Pascal'я. А там, если помните, есть директива, которая позволяет включать и отключать программную эмуляцию сопроцессора. В Delphi этот аргумент отпадает, но все остальные остаются актуальными.
            Ответить
            • Во-первых, можно в зависимости от директивы делать разные подстановки.
              Во-вторых, в дельфе даже этого не нужно.
              Ответить
              • > Во-первых, можно в зависимости от директивы делать разные подстановки.
                Там немаленькая подстановка получится, если делать эмуляцию, совместимую с IEEE 754. А несовместимую нельзя, потому что тогда возникнут проблемы с совместимостью с другими приложениями.

                > Во-вторых, в дельфе даже этого не нужно.
                Как я уже писал, в Дельфе этот аргумент отпадает, остаётся вопрос проектирования компилятора с его упрощением.
                Ответить
                • > Там немаленькая подстановка получится

                  Содержимое функции ROUND совместимо со всей иеее754 и занимает 6 строчек, большая часть из которых делает извлечения регистров из стека.
                  Кстати, round(const) таки компилируется сразу в результат, то есть попытки думать в направлении не плодить лишние вызовы были, но потом о них забыли.
                  Ответить
                  • > Содержимое функции ROUND совместимо со всей
                    > иеее754 и занимает 6 строчек, большая часть из
                    > которых делает извлечения регистров из стека.
                    Подстановка, если помните, относилась к эмуляции сопроцессора. Для совместимости с IEEE 754 нужно реализовать обработку случаев, когда операнд - обычное число, бесконечность и NaN. Плюс, если число не Extended, то ещё перевод в этот формат, т.е. поддержка денормализрованных операндов. В январе как раз довелось писать частичную эмуляцию: далеко не 6 строк.

                    > Кстати, round(const) таки компилируется сразу в результат,
                    > то есть попытки думать в направлении не плодить лишние
                    > вызовы были, но потом о них забыли.
                    Ничего общего. Все компиляторы и ассемблеры выражения, которые можно вычислить на стадии компиляции, вычисляют их и подставляют результаты, а не вычисление выражений. Все, кроме, м.б. учебных, написанных студентами в качестве лабы или курсача (есть такие задания). Эти операции выполняются компилятором, поэтому ни о каких вызовах там речи идти не может.
                    Ответить
                    • > Для совместимости с IEEE 754 нужно реализовать обработку случаев

                      Эту обработку умеет делать сопроцессор. Все они заложены в команду fld.

                      > Ничего общего.

                      Ха, тогда почему round(const) заменяется, а вот sin(const) - нет?
                      И ещё. Почему такую нетривиальную операцию, как abs() компилятор преобразует в набор команд, а не в вызов функции? Значит, в этом направлении были мысли? Но до конца их не довели, за что и получили пост на говнокоде.
                      Ответить
                      • Ещё раз напоминаю: речь там шла об эмуляции. Ни о каких FLD при эмуляции речи идти не может, ибо предполагается, что эти инструкции просто недоступны.

                        Нетривиальная операция ABS() нетривиальной не является: изменение единственного бита, причём независимо от того, какой FP-формат используется. А для целых - вообще готовая единственная инструкция. Там перегонка в/из память(-и) занимает больше времени, чем собственно операция.

                        Функции Sin(), Cos() и им подобные вычисляются через ряды, т.е. циклом. Как Вы понимаете, при разработке этих компиляторов я не стоял со свечкой рядом, но встраивать подсчёт этих вещей во время компиляции, по-видимому, означало как раз усложнение компилятора. Ну не могли Borland'овские разработчики в ущерб себе отказываться от реализации этой возможности, если бы она упрощала им работу. Не было среди них мазохистов. Можете поискать кого-нибудь и спросить.
                        Ответить
                        • Понимаете, функция abs() намного сложнее, чем round - ведь надо не только загрузить число в сопроцессор и выгрузить обратно, но и применить инструкцию fabs!
                          Ответить
                          • Понимаете, функция Abs() ничуть не сложнее Round(). Даже наоборот, её-то в отличие от Round() можно реализовать вообще в отсутствие сопроцессора, одной побитовой инструкцией, для любого формата, соответствующего IEEE 754. Потому что 1 бит только меняется, который стабильно оказывается старшим битом числа. А вот Round() требует анализа мантиссы и порядка, которые имеют различные размеры при разных форматах представления. Почитайте IEEE 754, хотя бы в кратком пересказе на русский язык.
                            Ответить
                            • Весь анализ прекрасно делает сопроцессор, какие проблемы?
                              Ответить
                              • А FABS по-Вашему на сервере Intel'а выполняется? Чем же тогда Abs() сложнее Round()'а?
                                Ответить
    • > Увы!.. А макроса в Вашем исполнении я так и не увидел.

      Я не на экзамене, ты не профессор.

      > И речь в этом случае идёт не о написании эквивалентного кода, а о написании компилятора, который будет лишён этого недостатка и не уступит рассматриваемому по другим пунктам

      Та ты що? Мне надо "сперва добиться" и стать Филипом Каном?

      > По-прежему остаётся ощущение, что Вы вините именно язык.

      Нет, я виню именно компилятор. Не надо обвинять меня в несуществующих грехах.

      Я смотрю, вы правила демагога используете вовсю. В том числе и чисто местное правило - любой код оправдывать якобы читаемостью и якобы тем, что на современных процессорах именно такой код более эффективен.

      И по поводу всяких абстракций и аналогий типа

      > Эм-м-м, да будет Вам известно, что г&$но-с, оно имеет животное происхождение
      > но место в лечебном заведении предоставляется в порядке живой очереди

      итд. Графоманы нынче не в почёте. Я честно прочитал ВЕСЬ этот поток сознания, но большую часть мог бы и не читать.
      Ответить
      • > Я не на экзамене, ты не профессор.
        На 33% верно. Но вообще-то за слова принято отвечать, особенно если они задевают чьи-либо честь и достоинство. В данном случае - Borland'овских разработчиков. Без жёсткой аргументации можно и под УК попасть, там есть такая статья. Другое дело, что до подобных выпадов им дела нет - и слава Богу!.. А вот на брудершафт мы с Вами не пили пока ещё, будьте добры соблюдать элементарные нормы приличия.

        > Та ты що? Мне надо "сперва добиться" и стать Филипом Каном?
        Как будет выглядеть человек, который всю свою жизнь рисует портреты прохожих и попытается сказать, что картины, скажем, Пикассо - убожество? Если Вы не знакомы в достаточной степени с предметной областью - м.б. стоит быть осторожнее в высказываниях? Или сейчас так принято?

        > Я смотрю, вы правила демагога используете вовсю.
        Да ну? Я пока что приводил вполне конкретные ссылки на конкретные ОФИЦИАЛЬНЫЕ источники, даже с названиями разделов. Уж извините, что страниц не указал, но они время от времени перевыпускаются - и номера страниц могут отличаться. А Вы ограничиваетесь лишь обвинениями непонятно кого и упрёками в мой адрес. Чем не демагогия?
        Ответить
      • > любой код оправдывать якобы читаемостью
        Золотое правило демагога: вырви из контекста и неси на шесте как флаг. Читаемость - это из общих рассуждений. Найдите в себе силы прокрутить страницу вверх и увидеть, что в следующем же предложении я написал: "Случай здесь не этот, но...". В сущности это было короткое вступление перед тем, как перейти к одному из правил надёжного программирования. Я про модульность, разбиение программы на логически самостоятельные участки.

        > и якобы тем, что на современных процессорах
        > именно такой код более эффективен.
        Я привёл Вам цитаты из конкретного документа. Всё сказанное справедливо для процессоров начиная с Pentium II и III. Ткните меня носом в то место, где я сказал, что мы получим гарантированный выигрыш в скорости? Основная идея красной нитью: если падение и будет, то несущественное по сравнению с падениями производительности от выбора алгоритма и т.п.
        Ответить
      • Про вопрос проектирования программного комплекса Вы улавливать не хотите. Возможно, в вузе Вам ещё расскажут, что написание кода - лишь около 1/13 от разработки ПО, а значительную часть времени занимает проектирование. Я не утверждаю, что спроектировано наилучшим образом, но по крайней мере не в ущерб качеству.

        Знаете, на будущее... Вы ведь не просто выложили кусок кода, но и сопроводили его вызывающим комментарием, а также неоднократно крайне нелестно отозвались о людях, уровень которых выше Вашего хотя бы потому, что Вы на сайте о говнокоде, а они во всемирно известной конторе. Это сначала привлекает внимание, а потом разрушает все сомнения насчёт Вашего опыта и подготовки. Не повторяйте больше этих ошибок - и общение со старшими коллегами будет идти Вам на пользу.

        Опережая Ваши сообщения... Не стоит пытаться доказывать мне, что Вы супер-программист. Разницу между макросом и подстановкой Вы так и не ощущаете, даже после того, как Вам указали на это. Особенностей языка Вы, судя по упоминанию Ord() и Length() тоже не знаете, или по крайней мере не владеете этой базовой информацией свободно. Опытный человек никогда не полезет с громкими заявлениями, не имея хоть сколько-нибудь глубоких знаний в предметной области. Сохраните адрес этой страницы и почитайте лет через 5-10. Вспомните молодость, посмеётесь над собой. Ничего такого в этом нет, мы все такими были.
        Ответить
        • >Сохраните адрес этой страницы и почитайте лет через 5-10. Вспомните молодость, посмеётесь над собой. Ничего такого в этом нет, мы все такими были.
          Не сделает. Гордый. :D
          Ответить
        • Прочитал. Но ничего не понял. Именно поэтому я за «PHP».
          Ответить
    • > Я привёл Вам цитаты из конкретного документа.

      А вот их я не читал - в лом переводить. И не надо меня заваливать своими познаниями инглиша.

      > Золотое правило демагога: вырви из контекста и неси на шесте как флаг.

      Был бы контекст поскромнее, не пришлось бы рвать его. Но тут же графомания в чистом виде...

      > в следующем же предложении я написал: "Случай здесь не этот, но...".

      Дык если не этот, то нахрена это вообще было писать?

      > если падение и будет, то несущественное по сравнению с падениями производительности от выбора алгоритма

      Товарищ теоретик, я эту "несущественность" на практике заценил, так что не надо мне тут.

      > Вы ведь не просто выложили кусок кода, но и сопроводили его вызывающим комментарием, а также неоднократно крайне нелестно отозвались о людях, уровень которых выше Вашего хотя бы потому, что Вы на сайте о говнокоде, а они во всемирно известной конторе.

      Коменты типа "борланд дебилы" оставлял не я и даже не мои виртуалы. Я сказал только то, что компилятор тут лажает на ровном месте.

      > Особенностей языка Вы, судя по упоминанию Ord() и Length() тоже не знаете, или по крайней мере не владеете этой базовой информацией свободно.

      Уж поверьте, знаю предостаточно.

      > Не стоит пытаться доказывать мне, что Вы супер-программист.

      Я не собираюсь тут никому ничего доказывать.

      В целом - из вашего потока единственная ценная мысль была о том, что так как почти никто не пишет на дельфах приложения, использующие вещественный счёт в критичных к скорости местах, то всем на этот недочёт похрен.
      Ответить
      • > > Я привёл Вам цитаты из конкретного документа.
        > А вот их я не читал - в лом переводить. И не надо меня заваливать своими познаниями инглиша.
        Вы вполне можете найти переведённую версию этого документа. А то, что Вы их не читаете, чести Вам не делает: это как раз то, на что следует опираться в оптимизации на уровне кода.

        > > Золотое правило демагога: вырви из контекста и неси на шесте как флаг.
        > Был бы контекст поскромнее, не пришлось бы рвать его. Но тут же графомания в чистом виде...
        Для употребления слова "графомания" у Вас должен быть диплом психиатра. В чём несмкромность контекста? Вам указали на то, что разница в предполагаемом Вами коде и генерируемом компилятором несущественна, со ссылкой на конкретные факты.

        > > в следующем же предложении я написал: "Случай здесь не этот, но...".
        > Дык если не этот, то нахрена это вообще было писать?
        Мне опять повторять? Вы даже с этим ВСТУПЛЕНИЕМ не можете уловить сути. Вопрос "нахрена" отпадает?
        Ответить
      • > > если падение и будет, то несущественное по
        > > сравнению с падениями производительности
        > > от выбора алгоритма
        > Товарищ теоретик, я эту "несущественность" на практике заценил, так что не надо мне тут.
        Не могу знать, что Вы там назаценивали. Наибольшее замеченное падение - около 200 мс на 10 млн операций при процессоре с тактовой частотой 1100 МГц. Варьировались следующие параметры: включение/отключение реалтайм-проверки антивируса, использование второстепенных системных процессов. Для Core 2 Duo 2GHz на ядро результаты в среднем эквивалентны: то там, то там впереди то один, то другой алгоритм. И на будущее: если бы я был теоретиком - я бы просто не стал сюда писать, но за плечами многие годы программирования на самых разных языках и для разных платформ. Впрочем, Вам это неинтересно.

        > Коменты типа "борланд дебилы" оставлял не я
        > и даже не мои виртуалы. Я сказал только то, что
        > компилятор тут лажает на ровном месте.
        И тем не менее Вы ведь не будете отрицать, что слово "лажать", употребляемое Вами налево и направо, носит весьма экспрессивную окраску и имеет весьма и весьма унизительное происхождение для всего того, что этим словом обозначается? Вы хотели, чтобы "ухудшения" допускались только если оправданы упрощением и удешевлением? Уж и не знаю, что Вы там читаете вместо официальной документации (надеюсь, не Фленова с Архангельским), но раз доки пишутся не для Вас - сойдёмся на том, что ухудшение при определённых условиях может происходить. Сэкономлю себе время. Данная особенность даёт существенное упрощение компилятора, поскольку позволяет генерировать более однообразный код (многократно упомянутый stdcall), а как результат - требуется менее сложный алгоритм для распределения данных по регистрам. Плюс модульный подход, плюс разделение труда - вот Вам удешевление.
        Ответить
        • > Наибольшее замеченное падение - около 200 мс на 10 млн операций при процессоре с тактовой частотой 1100 МГц.

          Было 50 мс, стало 250? Или как? В процентах это сколько? Вот я, например, заметил двухкратное преимущество простой асмовставки перед вызовом коряво реализованной функции.
          Кстати, одд - это не просто загрузить из одного адреса, сохранить в другой. Надо, понимаешь, ещё и последний бит вычленить, да. Тут они смогли учесть то, что не стоит заворачивать в отдельную подпрограмму то, что выполняется за время, меньшее времени вызова подпрограммы. А вот с вещественными числами - облажались. А какое ещё слово тут подходит?
          Что касается графомании - я не психиатр, но считать объём текста умею.
          Ответить
          • Реализация Odd() в виде процедуры была бы заведомо неэффективной, поскольку вернуть флаг из функции нельзя, ибо для результата есть AX. В этом конкретном случае размер реализации (1 инструкция) позволяет использовать вставку, да и распараллеливание лучше работает. А будь Odd() посложнее в реализации - запёрли бы в отдельную функцию. Чтобы прогу не наращивать дублированием кода.

            50 и 250 мс... Здесь предложу обратить внимание на 2 момента. Во-первых, по максимумам оценку делать несколько неосмотрительно: срабатывает элемент случайности. Реально здесь речь пойдёт не о пятикратном увеличении, а поменьше. Да и точность измерения в мс оставляет желать лучшего: из-за особенностей многозадачной системы, как известно, более-менее точная шкала - по 60 мс и мультимедиа-таймеры не слишком помогают в этом. Во-вторых, это на 10 млн округлений. Столько округлять может только сервер округлений ;) Именно в этом несущественность падения, о которой я говорю.
            Ответить
            • А ты прикинь, что произойдёт с программой, которая для каждого пиксела делает несколько округлений. Для фильтрации текстур, например.
              Ответить
              • Пример, к сожалению, притянут за уши. Если это прикладная программа, то вручную конвертировать координаты в экранные - мягко говоря опрометчивое решение. Потому что есть готовые, уже реализованные, более универсальные и специальным образом оптимизированные алгоритмы, реализованные в DirectX, OpenGL, etc. Если встраивать этот алгоритм в свою программу - это изобретение велосипеда, которым занимаются только избранные мазохисты. Если писать аналог DX или GL - то это уже совершенно другая область разработки, поскольку здесь уже будет использоваться почти прямой доступ к железу, а это обычному приложению недоступно (Ring 3 как-никак). И подобные библиотеки пишутся с использованием совершенно других инструментов, причём значительная часть именно на ассемблере. Не берусь утверждать, напрямую с видеокартами не работал пока ещё, но когда речь идёт об использовании аппаратного ускорения - видеокарта может взять на себя все преобразования координат и т.п. Посему пример неуместен.
                Ответить
            • >только округлять может только сервер округлений
              :D
              Ответить
        • >надеюсь, не Фленова с Архангельским
          Фленов - да.
          А Архангельский то чем не понравился?
          Ответить
          • Архангельского на вышеупомянутом DelphiMaster.ru не очень-то жалуют. А если учесть, что там народ с богатым опытом и местами работы от крупных контор до университетов, то есть смысл верить. А лично, когда в молодости осваивал Delphi - как-то обошёлся интернетом плюс хороший знакомый. Вышеупомянутых авторов просмотрел в порядке ознакомления уже имея богатый опыт. На сегодняшний день по Delphi, когда спрашивают, увы, ни одной книжки посоветовать не могу: везде есть упрощения, недочёты, которые как-то не очень. Поэтому никаких и не советую. :)

            Кстати, оттуда же анекдот про компиляторы (недавно промелькнул):

            - Здраствуте, что из литературы можно почитать про компиляторы?
            - Естественно классику: Ахо, Ульман, Сети
            - Нет, мне сети не нужны, мне про компиляторы...
            - Ну тогда Фленов, Архангельский

            Собственно, по мотивам...
            Ответить
      • > > Особенностей языка Вы, судя по упоминанию
        > > Ord() и Length() тоже не знаете, или по крайней
        > > мере не владеете этой базовой информацией
        > > свободно.
        > Уж поверьте, знаю предостаточно.
        Устройство Ord() пропустим - моя вина, неправильно прочитал. Но принцип работы Length()... Если Вы знаете, как устроены Pascal-строки и/или Delphi-строки, то не мне Вам рассказывать, что Length(S) само по себе - это не операция, а просто memory operand. В отличие от Си. Чем прикажете объяснить Ваше непонимание причины, по которой вместо Length() подставляется кусок кода, а не вызов функции?

        > В целом - из вашего потока единственная ценная
        > мысль была о том, что так как почти никто не пишет
        > на дельфах приложения, использующие вещественный
        > счёт в критичных к скорости местах, то всем на этот
        > недочёт похрен.
        Насчёт количества пишущих на Delphi Вы несколько ошибаетесь. И мысль, сформулированная мною, относилась не к количеству программистов и проектов (коих немало), а к сфере применения Delphi.
        Ответить
        • Ord(x) эффективнее заменять на byte(x)
          Ответить
          • Позволю себе запросить уточнение этого момента. Видимо, речь о конкретном классе случаев, ничего пока в голову не приходит. Разве что Char? В Turbo Pascal "функция" Ord() возвращает для операндов всех типов LongInt-число, 4-байтовое. Поэтому как раз приведение к Byte имеет смысл только для однобайтовых случаев: Char, Byte, ShortInt, перечисляемые типы. В остальных случаях получим неполный результат. Программа-тест:

            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 что-нибудь.

            Возможно, что-то упускаю из виду...
            Ответить
      • >Товарищ теоретик, я эту "несущественность" на практике заценил, так что не надо мне тут.
        Ага. На древнем проце. На новом пробовал? Не знаешь. Вот...
        Ответить
        • Купи мне новый проц.
          Ответить
          • Может быть, надо просто прекратить быть "не работающим, не учащимся энтузиастом" и пойти трудиться на благо общества? За это, говаривают, как раз деньги дают. На новые процы. На ГовноКоде за посты не платят.
            Ответить
    • >> Это по оптимизации CALL'ов: если кратко, то нагрузка от них незначительна, поэтому нет особого смысла инлайнить некоторые процедуры.
      >Я проверял скорость, разница очень велика.
      Да, но только на старых процессорах. Нет денег, что-бы поставить новый? Пока не перестаните считать каждый такт - их и не будет. ;)

      >Нет, я уже перешёл на фиксированную запятую 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$() для считывания нажатых клавиш оказалась намного удобнее своих эквивалентов в Паскале и Си. И хотя это реализовано несколько сложнее в конечном итоге, для быстрой разработки приложений это несомненный плюс. Особенно для игровых, где задержка на это упрощение несущественна по сравнению с затратами на обработку (перерисовку изображения, например). Это я к тому, что иногда языки программирования спустя какое-то время оказываются очень неплохими, хотя и казались для этого полной чушью.
        Ответить
      • Delphi однозначно плох, если с него начинать: слишком много информации сразу. Но есть и множество положительных моментов. Опять же, реализация, например, строк в Delphi намного эффективнее, чем в классическом Си: определение длины строки Length() за константное время O(1) против линейного O(n) для strlen() строки длины n. Плюс экономия памяти за счёт одинаковых строк. На Фасме реализовал для себя набор макросов и функций, упрощающих операции с Delphi-подобными строками. Только один пример. Попросите - назову и плюсы C/C++, не проблема. :)

        Позволю себе не согласиться с Вами и в вопросе об оптимизации. Хотя, конечно, сейчас наиболее эффективным способом оптимизации является поиск наиболее эффективного алгоритма, всё-таки иногда приходится обращаться и к низкоуровневой оптимизации. В том же Фасме в своих проектах использую самописные псевдо-объекты. Псевдо - потому что в них фактически реализована только инкапсуляция, никаких полиморфизмов и наследований. От последних решил отказаться, т.к. средства языка для этого не слишком удобны, да и выигрыш в быстродействии сомнителен, а необходимости нет. Не уверен, что решение правильное, но пока устраивает. В остальном - иногда просто хочется сделать приятное пользователю: написать программу, которая работает быстрее аналогов, занимает меньше места, чем аналоги. Да и демосцена - слово не чужое :) Так что низкоуровневая оптимизация хоть и отошла на второй план, всё ещё актуальна. IMHO и не ради спора, а ради присутствия альтернативного мнения. Надеюсь, Вы поймёте меня правильно.
        Ответить
        • >Delphi однозначно плох, если с него начинать
          Помоему лучше всего начинать именно с паскаль языков.

          >всё-таки иногда приходится обращаться и к низкоуровневой оптимизации
          К сожелению заметил, что "перемешивать" код на асеме тяжелее, чем автоматичеси компилятором. "Перемешивать" - имееться виду для верного распараллеливания комманд при выполнении. И ещё оказываеться, что при использовании ассемблерных вставок компилятор не может оптимизировать вызывающие функции и встраивать их, по своему выбору.
          Если не использовать ассемблерные вставки, то компилятор сам наиболее оптимальным способом заинлайнит при необходимости функции. При использовании ассемблерных вставок приходиться делать это вручную и естественно это не гарантирует, что человек сделат это правильно, а времени обычно не так много для эксперементов.
          Ответить
          • Покрайней мере это относиться к современным С++ компиляторам.
            Ответить
            • Да ко всем относится в той или иной степени. Они ведь рассчитаны на то, чтобы работать по определённым своего рода шаблонам, т.е. выдавать готовые куски кода и правильно их компоновать. Поэтому когда используется нестандартный приём - они могут давать и обычно дают посредственный результат. Это нормально.
              Ответить
          • Вы совершенно правы насчёт Паскаль-языков, это общепризнанно наконец. Но я в своём посте разделял Delphi и Pascal. По опыту общения с новичками я пришёл к выводу, что начинать с Delphi - ненадёжный вариант: слишком много разнородной информации приходится осилить одним махом. Намного проще и даже в каком-то смысле лучше (с точки зрения выработки приёмов программирования, например) сначала изучить Паскаль (фактически, основы программирования и алгоритмизации), а только потом нырять с головой в Delphi с ООП, огромных размеров библиотекой VCL, а также особенностями WinAPI. Последние 3 вещи намного лучше понимаются, когда есть прочная отработанная до автоматизма база, когда синтаксис знаком до боли и на него не приходится отвлекаться. К сожалению, часто сталкиваюсь с тем, что молодёжь учат Delphi - и они (не все, но большиснтво) не могут даже грамотно оформить синтаксически if с двойным вложением: путаются в точках с запятой. Куда им сразу объекты? Тем более, как им сразу объяснить, почему при присваивании переменной объектного типа не создаётся копия нового объекта? Если нет общего понятия об указателях и операциях над ними...

            На роль языка для новичков всегда очень здорово подходил Basic. Это в последние годы, кажется, все решили, что Pascal - для начинающих. Видимо, ориентируясь на Delphi. На самом деле классический Basic намного лучше скрывает от начинающего программиста детали низкоуровневой реализации: например, не надо на первых порах разбираться, чем отличаются целочисленные данные от вещественных, не приходится догадываться, зачем нужен Boolean. А уже потом, когда попробуют использовать переменную-флаг вместо логической, то паскалевские були становятся понятны сами по себе. С одного упоминания. Но какой язык наилучший для новичков - решать, увы, не мне. У нас в Беларуси сейчас подсовывают ABCPascal и детишки рисуют всякий бред. Лучше, чем ничего, но по сути ничто. :(
            Ответить
      • Так что, всем, у кого старый проц, выкинуть его и поставить новый? И где всё это будет перерабатываться?
        Вы - сторонник одноразовой экономики?
        Ответить
        • А это-то к чему или лишь бы что сказать?

          >Вы - сторонник одноразовой экономики?
          А это что-за бред сивой кобылы? Используй свой проц много раз. Каждый раз, как сломаеться перепаивай. В конце сойдёт за брелок, но не вкоем случае не выкидывай, тк перерабатыватся ему негде, а Матушку-Землю засорять тоже не дело.
          Ответить
          • В другую крайность не надо кидаться. Логика "пишем под новые процы, а кто не купил - тот сам виноват", конечно, выгодна для экономики, потому что и программистам деньги быстрее идут, и производителям железа. Да только куда списанный хлам потом девать? Вас не пугает то, что мы тратим ресурсы намного быстрее, чем они восстанавливаются?
            Ответить
            • Вы пытаетесь поменять тему. Совместимость на сегодняшний день у 32-битных процессоров идёт вплоть до i8086. Просто чем старше процессор, тем больше неудобств может возникнуть. но в целом программы имеют шанс работать, если написаны из расчёта на это.

              А Вы, кстати, подумали о том, что FPU-инструкции во многих старых компьютерах могут отсутствовать? FPU тал интегрированным только в 1989 году в i486. До того были i386 (которые ещё очень многими разработчиками полностью или частично поддерживаются), i286, i8086 наконец. О них Вы подумали? Так что эта попытка тоже выглядит слабо. Общая мысль несомненно правильна, а вот применение, увы, её опошляет.
              Ответить
              • Потребность писать под 386 у меня пока не возникала.
                Ответить
                • Тогда не стоит обвинять людей в использовании логики "пишем под новые процы".
                  Ответить
          • Менять проц по первому свисту - это тоже не дело. Если помните, когда выходила WinVista - гринписовцы тревогу били столько железа уйдёт на свалки.

            Не верю, что у TarasB настолько древний проц. Конфигурацию мы так толком и не услышали (не прочитали), только упоминание, что где-то что-то отличается. Даже не услышали, как именно. Я, как человек, оставляю за собой право ошибаться, но обычно такие люди оказываются сидящими за компами с самой послдней версией ОС Windows и в ус не дующими. Я и сам придерживаюсь очень настороженного отношения ко всем новым технологиям и это неоднократно высказывал в публикациях в прессе... У меня на одном домашнем компьютере установлена Win98SE при процессоре Celeron 2000, на другом - она же при 166 МГц и 16 МБ ОЗУ. Но абсолютно не вызывает у меня подобной реакции упоминание о том, что в новых компах что-то есть лучшее. Здесь - осознанный выбор каждого. Кстати, если обратите внимание, судя по упомянутой частоте, процессор TarasB входит в число тех "новых", которые Pentium II и позже... Так что здесь скорее просто неумение признать ошибку. Даже и не ошибку, скорее неоправданный порыв гнева в адрес ненавистных разработчиков...
            Ответить
            • Ха, так тем более - даже на моём "новом" проце лишний вызов функции изрядно замедляет округление.
              Ответить
    • Да и вообще проще взять обычный компилятор, чем ассемблер и тот сам переставит в нужном порядке комманды, чем это сделаешь ты, потратив чёртову уйму времени. Приэтом программа будет с более сложной логикой и её сложнее будет поправить и понять через пару месяцев. Темболее для одного проца это наиболее оптимальная перестановка, а для другого - другая.

      Может вы и CGI когда-нибудь писали на ассемблере? Где-то я тут такого видел... Да. Это очень оптимально. :p
      Ответить
      • К сожалению - чистейшая правда. К счастью - не всё так плохо. В конце концов, процессор ухитряется сам выполнять инструкции не в том порядке, в каком они записаны в программе, лишь создавая видимость линейности за счёт того, что операции записи в память и т.п. выполняются в порядке их следования в программе, а не реальном порядке выполнения. Об этом, кстати, в том же мануале сказано. Так что Вы совершенно правы: здесь всё чаще приходится доверяться компилятору и разработчикам процессоров.

        Про CGI на ассемблере - неплохой пример :) Хотя минимальный набор возможностей, думается, обеспечить не так уж и сложно. С другой стороны, для высоконагруженных серверов, наверное, правильнее именно на асме, но с хорошей своевременной отладкой.
        Ответить
      • Дык этот говнокод как раз про "обычный компилятор".
        Я не любитель ассемблера, но из-за подобных высеров компилятора приходится.
        Я не требую от него всё оптимизировать, но и усложнять код не надо. Замена трёх команд вызовом - это уже усложнение. И про кэш я не понял - а содержимое вызываемой функции в кэше место не занимает?
        Ответить
        • Там достаточно большой кусок кода, чтобы уместиться в 16 байт. Так лучше пусть инструкции гарантированно начнутся с 16-байтовой границы, чем будут разбиваться 16-байтной границей на куски и создавать задержку. И, кстати, по размеру выигрыш наступает при вызове приблизительно из 3-4 разных мест, можете уточнить в Intel IA-32 Architecture Software Developer's Manual.

          Вы продолжаете игнорировать всё, о чём Вам говорят и на что ссылаются. "Высер" - это очень здорово характеризует Ваше отношение к Borland. Как и все остальные слова. После "высера" ожидать от Вас адекватного отношения к вопросу не приходится. Увы.
          Ответить
          • Проблема в том, что с вызовом мы имеем 11 байт кода (2 команды), и 10 байт (6 команд) самой функции. А с подстановкой мы имеем 13 байт кода (3 команды, одна из них fwait, она не всегда нужна) и всё. Где экономия?
            Кстати, откуда такое трепетное внимание к любому высказыванию в адрес Борланда? Не впервой, значит, про них слушаете подобное? Может, неспроста?
            Ответить
            • Вы фактически сами ответили на вопрос о том, при каком количестве вызовов Round() из разных мест программы получится выигрыш в размере программы. По этому же конкретному вопросу разница в том, как эти команды разлягутся относительно 16-байтовых границ.

              А логике Вашей позавидует кто угодно!.. Такие грубые логические ошибки закатывать в такую обёртку... Во-первых, я не из Borland, чтобы, слыша подобные высказывания, одновременно их выслушивать и чтобы принимать их близко к сердцу. Во-вторых, если бы мне приходилось это регулярно слышать - я бы уже просто привык.

              Всё проще. На самом деле я уже много лет пользуюсь различными компиляторами, в т.ч. и Borland'овскими, а также в исполнении их преемников. И по качеству реализации... Скорость компиляции, гибкость и простота настройки, качество генерируемого кода, степень интеграции в среду разработки и т.п. - по этим параметрам в совокупности Borland'овские продукты всегда подкупали. И, уж простите за прямолинейность, но от Ваших высказываний о них за версту несёт школотой. Если бы Вы а) действительно разбирались в этом вопросе на достаточном уровне и б) имели богатый опыт работы с этими и другими компиляторами, то Вы бы а) не задавали многих глупых вопросов, которые уже прозвучали, и б) не были бы столь категоричны в своих заявлениях. Что есть, то есть.
              Ответить
    • Ну вы инафлудафилили. :)
      *Садиться в уголок и берёт покорн.* :)
      Ответить
    • >call @ROUND
      >Основная идея красной нитью: если падение и будет, то несущественное по сравнению с падениями производительности от выбора алгоритма и т.п.
      И программа будет меньше занимать. :) У когого там на проц и память денег не хватает? ;)
      Ответить
    • Вообще вызов раунда связан со старой реализацией этой функцией. От части там был код, связанный с обработкой исключений округления.
      Ответить
    • Ой как бурлит говно. Сейчас закипит и взорвётся! :D
      Ответить
    • TarasB, на самом деле, если вы Open Source программист, а не комерческий, то могу лишь уважительно скосить глаза. Если человек делает что-то бесплатно и для людей и по этому не может купить новый комп, и при этом хочет что-бы его программы работали на компьютере людей наиболее оптимально и готов ради этого лезть в ассемблер. Приклоняюсь. :)
      Ответить
      • Он же написал: ни преподаёт, ни учится, энтузиаст. Задержится ли такой человек в OpenSource надолго? Вряд ли, как по мне. Либо уйдёт на другие хлеба, либо изменит один из перечисленных статусов. IMHO, конечно... ;)
        Ответить
    • Дим, ты демагог. Из-за художественного стиля твоих реплик тебя невозможно читать. Не осилил третью треть.
      Ты хоть сначала не оскорблял никого. Тока не говори, мол, ты не стерпел выпадов в твою сторону. Пиздеж, от тебя их с самого начала было больше. Ты изначально высасывал аргументы для своей точки зрения из пальца.
      Это не твоё место, имхо.
      Кстати, почитай УК -- то, что я назову продукт фирмы борланд некачественным (читай, говном), это нельзя признать оскорблением, эта моя точка зрения относительно удобства использования произведения фирмы и его качества.

      А Тарас молодец)

      Без уважения, Тупое Малолетко.
      Ответить
      • Рад, что у Вас есть точка зрения, отличающаяся от официальной. И на счёт конкретного вопроса и относительно меня.

        Потрудитесь указать на выпады с моей стороны, которые бы не были адекватной реакцией. Даже самое первое сообщение, написанное ещё гостём, оно же самое экспрессивное, не содержит никаких личных оскорблений, только предложение задуматься, всё ли так однозначно. Художественный стиль моих реплик пока ещё устраивает и редакторов печатных изданий, и молодых программистов, с которыми случается проводить обмен знаниями, так что это останется, боюсь, Вашим мнением. К тому же сухой технический язык мне запретил TarasB, сказав, что "по-английски не хочу".

        Вы не прочитали даже трети того, что здесь было написано. О чём Вы тогда делаете вывод? Аргументы из пальца? Ну, уж извините, отвечу в Вашем выпадном стиле: у Intel палец потолще Вашего будет, так что не надо меряться.

        То, что это не моё место - Вы правы. Я больше привык работать с заинтересованными людьми, готовыми вести адекватное обсуждение. Это, знаете ли, не когда "у моей бабушки утюг кипятит воду при ста градусах", а когда "это устроено так, это этак, там было так". Аргументированно, с конкретикой. И доказывать кому-то, кто в этом не заинтересован, - это не моё, увы.

        Касательно УК - это вопрос выбора своего представителя в суде, не мне Вам это объяснять. Ну и вопрос того, насколько каждый конкретный человек готов терять своё время ради успокоения кого-то там. Но то, что оскорбления в Интернете уже становились поводом обсуждения в правоохранительных органах - факт, ссылку найдёте.

        > Без уважения, Тупое Малолетко.

        Это Ваш стиль, а с самокритикой будьте осторожнее. Тем более, если "тупое малолетко", а не опытный человек.

        С уважением, DimonSoft.
        Ответить
        • >Рад, что у Вас есть точка зрения, отличающаяся от официальной.

          Взаимно
          Ответить
      • >Не осилил третью треть.
        Мне всё было совершенно понятно и большей частью, описаннное, верно. ;)
        Ответить
    • > А FABS по-Вашему на сервере Intel'а выполняется? Чем же тогда Abs() сложнее Round()'а?

      Тем, что помимо загрузки и выгрузки (и фваита) она ещё и выполняет инструкцию fabs.

      > Галактика IOK-1?

      Нивкурил. Ты вот что-то мне говоришь про мифические новые процы, на которых именно такой код летает. У меня шестисотый селерон, для него это неверно. Поэтому я сделал вывод, что мой проц по твоей системе - древнее убожество.
      На самом деле - проц нормальный, если лишнюю работу не заставлять делать.

      > Вы фактически сами ответили на вопрос о том, при каком количестве вызовов Round() из разных мест программы получится выигрыш в размере программы.

      А, да, я забыл, 11 байт в исходной реализации - это только при условии, что извлечение результата идёт в регистр. А если ещё и скопировать результат в память, то все 16. Где экономия?

      > А логике Вашей позавидует кто угодно!.. Такие грубые логические ошибки закатывать в такую обёртку...

      Про обёртку - у ваших научился. Радикальных ошибок у себя я не вижу.

      > И, уж простите за прямолинейность, но от Ваших высказываний о них за версту несёт школотой.

      Нет такого слова в словаре. Но говорят, им любят ругаться на собеседника лица школьного возраста.

      > а) действительно разбирались в этом вопросе на достаточном уровне

      Поверьте, даже небольшого разглядывания того, что генерирует дельфийский компилятор, хватает для того, чтобы больше не доверять ему узких мест.
      Ответить
      • > Тем, что помимо загрузки и выгрузки (и фваита) она ещё и выполняет инструкцию fabs.
        Про случай, когда результат Round()'а будет записан в переменную вещественного типа, подумали? Так, к слову...

        И, о Боги, да сколько же можно читать эту молитву?! Это говорю не один я. А насчёт древности компа - никто не говорит, что Селерон - это прошлый век. Если бы Вы читали не выборочно, то знали бы, что и у меня на домашнем компьютере не самый новый проц, тоже Celeron причём. Дело всё в том, что у Вас подозрительно отличаются результаты от тех, которые получились у многих других, включая самих разработчиков процессоров.

        > это только при условии, что извлечение результата идёт в регистр
        А ещё прибедняетесь!.. Да у Вас по ходу самый новый процессор, не далее как позавчера с конвеера сошёл. Иначе как объяснить, что он позволяет из FPU извлекать сразу в регистр, минуя память? Где-то Вы нас всех обманываете.

        Логическая ошибка Вам была указана, так что внимания не заостряю: бесполезно.

        Со школьным возрастом по работе контактирую иногда. Это слово входит в лексикон обычно только на 1-м курсе, а в употребление - не раньше 2-го. Так что тут у Вас тоже прокол. А уж как катаются мои коллеги. Ладно, не будем о грустном.

        А при "небольшом разглядывании" навоз от человеческих экскрементов тоже не отличается. А вот на удобрения почему-то пускают в основном первое, а второе - разве что изредка. Да и писсуар от раковины в сущности... [Вроде формат сайта позволяе такие сравнения?] Для того, чтобы в чём-то разбираться, надо как раз неслабо повариться в конкретном вопросе, а не "немного поразглядывать".
        Ответить
    • > Про случай, когда результат Round()'а будет записан в переменную вещественного типа, подумали?

      И? Сделать fld-fistp-fld-fstp-fwait так тяжело (первое, что в голову пришло)? Тем более что компилятор примерно так и делает, ЛОЛ. Только второй fistp зачем-то вогнан в отдельную подпрограмму, которая извлекает в стек, копирует из стека в регистры, потом, после выхода из подпрограммы копирует опять в стек, потом продолжает эту цепочку...
      Я не отключал оптимизацию, дельфа действительно так делает. Будешь дальше доказывать адекватность дельфийского компилятора?

      > Иначе как объяснить, что он позволяет из FPU извлекать сразу в регистр, минуя память?

      Подпрограмма ROUND так и делает. Делает она это посредством стека. Короче, там лишнее копирование.
      Иногда оптимизатору хватает результата в регистрах, копировать в память ничего не надо. Иногда - нет, лишние байты кода.
      Короче, порнушное решение, которое нихрена не экономит.

      > Логическая ошибка Вам была указана, так что внимания не заостряю: бесполезно.

      Что не так? Незначительная экономия кол-ва кода достигается только в одном случае - нам нужно целое число, которое можно оставить в регистрах.

      > Так что тут у Вас тоже прокол.

      тут ты миня обламал111 я горька плачю

      > А при "небольшом разглядывании" бла бла бла

      траля-ля два рубля...

      > Для того, чтобы в чём-то разбираться, надо как раз неслабо повариться в конкретном вопросе, а не "немного поразглядывать".

      Ты, походу, даже не разглядывал.

      Я вот хоть и пользую дельфу там, где многие б не стали (мне скорость компиляции нравится), но до такого хомячизма не дохожу, чтобы оправдывать баги дельфы, придумывая им всякие нелепые объяснения, защищая борланд как святыню. (оййй, я ж с маленькой буквы борланд написал, меня сейчас молния покарает).

      Кстати http://itc.ua/node/15800
      Неплохой "прогресс" у семёрки после трёшки, да? Если чё, короткая полосочка означает меньшую скорость.
      Ответить
      • >fld-fistp-fld-fstp-fwait
        А это ЛОЛ. ЛишняяОперацияСПамятью.
        Юзай одну frndint и будет тебе счастье. ;)
        Ответить
        • Ладно, ладно, я же сказал, что первое, что в голову пришло. frndint мне не нужен был ни разу, мне он в голову не пришёл.
          Ответить
        • А ЛОЛ-то здесь ещё и в том, что после FISTP использовать FLD - это очень круто. Разве что всегда 0 выгружаться будет. Интересно только, как же TarasB дизассемблировал программу на Delphi и увидел там, что сразу же идёт помещение в память. Если есть возможность вести дальнейшие вычисления - Delphi их проводит.

          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, допускает дичайшие промахи в терминологии и т.п. Не стоит обращать внимания ;-)
          Ответить
          • > после FISTP использовать FLD

            филд

            > Если есть возможность вести дальнейшие вычисления - Delphi их проводит.

            Да, только сложение с инт64 надуманно. Если сложить с другим екстендедом, то будет так, как я сказал.

            > Ну и, конечно, забавно пытаться дискутировать с человеком, бла бла бла

            Охренеть, какой веский аргумент. Демагожка...
            Ответить
          • >забавно пытаться дискутировать с человеком, который не использовал инструкции FRNDINT
            Я может быть не использовал. И что? За меня это делает компилятор, но это не значит, что её не знаю и не могу дискутировать о её характеристиках и её использовании.
            Доки от производителей помогают. ;)
            Ответить
            • Я это не о Вас говорил.
              Ответить
              • Не, если наехал, то по-честному, а не "я не о вас". Придумал критерий "человека, с которым не о чем разговаривать" - так отвечай за него.
                Ответить
                • А Вы ещё и экстрасенс? Наверное, я лучше знаю, что и о ком пишу? И не надо строить из себя обиженного...
                  Ответить
                  • Не, а хренли, я как ты буду - раз ты так написал, значит всё, так дословно и учтём.
                    Ответить
              • Я знаю. TarasB тоже нужна поддерка. :)
                Ответить
            • > За меня это делает компилятор

              А за меня - нет. О чём и говнокод.
              Ответить
      • Этож кому придёт в голову округлять числа, запихивая их ради этого в память... Только вам. ;)
        Ответить
        • И борланду.
          Ответить
          • Макроса для Си я так и не дождался. М.б. Вы нас осчастливите нас хотя бы кодом, который бы выгружал числа из FPU напрямую в регистры? А то местные представители Intel в шоке.
            Ответить
            • Я же сказал, что это делает дельфийская функция через стек (фистп дворд птр есп итд). Не умеешь читать - иди гуляй, демагог.
              Ответить
              • > это только при условии, что извлечение результата идёт в регистр. А если ещё и
                > скопировать результат в память, то все 16
                Это я, что ли, написал?

                Ещё вопрос: слово "демагог" - это всё, что Вы можете из себя выдавить полезного?
                Ответить
                • А что не так? Функция РАУНД извлекает результат в регистр. Своим хитрым и нахрен не нужным способом. Давай, придерись к словам, что я там букву не вставил. Сказать-то нечего.
                  Гуляй, демагог.
                  Ответить
                  • Если есть возможность - она продолжает вычисления в регистрах. Если это предполагает алгоритм. В память всё равно извлекать придётся. И для дальнейших вычислений потом из памяти в регистры тоже придётся грузить. Разве только Вы напишете единственный Round(). Назначение одинокого раунда непонятно.
                    Ответить
                    • Если надо - можно будет из памяти загрузить в регистры. Если нет - то зачем загружать из памяти в регистры, а потом обратно сохранять в память?
                      Ответить
                      • Разницу между RAD и LowLevel объяснять или гугл поможет?
                        Ответить
                        • То есть при разработке RAD на оптимизацию можно забить? Тогда нахрена вообще обманывать людей директивой {$O+}?
                          Ответить
                          • Вот если бы Вы попробовали написать свой компилятор - Вы бы понимали, какое количество оптимизаций делается компилятором, и ощущали ничтожность приводимых Вами тонких оптимизаций по сравнению с более грубыми
                            Ответить
                            • Дык в том-то и прикол, что эта оптимизация тоже отнюдь не тонкая, а очень даже толстая и влияющая на скорость в местах, где делается много вещественных вычислений. Это вообще додуматься надо было - влепить сюда вызов левой функции.
                              Ответить
                              • Вы пробовали писать классы на ассемблере. Писать - это в том смысле, что создавать фрагменты кода и данных, которые в совокупности будут себя вести как классы. Писать то, что должны выдавать компиляторы с языков, поддерживающих ООП. Если округление - это грубая оптимизация, то оптимизация ООП-кода - это и не оптимизация вовсе, а переписывание того, что написано человеком, по-человечески, т.е. по процессорному.
                                Ответить
      • >Я не отключал оптимизацию, дельфа действительно так делает. Будешь дальше доказывать адекватность дельфийского компилятора?
        Ну это прокол, если он так действительно делает.
        А вообще одна неоптимальность - не повод отказываться от благ цивилизации. Темболее, что мелкая неоптимальность - не ошибка. ;)
        Ответить
        • Можете посмотреть выше: обещанного нам TarasB кода Delphi не выдала. Вместо этого наперекор злопыхателям считает всё выражение в регистрах и только потом, когда заканчивается присваивание, сбрасывает результат в память. Так что прокол отсутствует, можете спать спокойно.

          А про неоптимальности вообще Вы совершенно правы, как по мне.
          Ответить
          • > Вместо этого наперекор злопыхателям

            Подлые и низменные силы зла набросились на святой борланд, и только димонсофт с мечом силы оберегает древний талисман.
            Неплохая тема для митол-баллады. Правда, это, кажется, уже кто-то давно спел.
            Ответить
          • >Так что прокол отсутствует, можете спать спокойно.
            Или я запутался и мне пора спать. :(
            Или у TarasB и DimonSoft разные подверсии 7-го дельфи и генерируют разный код.
            Ответить
            • Он из IOK-1, мы уже выяснили :D
              Ответить
              • Так гуманоиды с Альфа-Центавры называют Землю.
                Для инт64 прокол таки есть - всё равно делается лишнее перебрасывание из стека в регистры и обратно. Впрочем, оно как раз несущественно по скорости по сравнению с инструкцией калл. Я к тому, что аргумент про размер кода тут обломался.
                Ответить
                • Тк земляне называют самую удалённую от Земли из известных галактик. Гугл, ага...
                  Ответить
              • >IOK-1
                А откуда эта фраза? Какая-то книга? Или сами придумали?
                Ответить
        • На самом деле я конкретно это не проверял. Просто поверил TarasB на слово. :(
          Ответить
          • ДемогГогт на самом деле привёл надуманный пример с инт64. Если сложить с екстендедом, то будет как раз то самое порно с округлением через память. В качестве памяти выступает стек.
            Ответить
      • >придумывая им всякие нелепые объяснения, защищая борланд как святыню
        Мне он не нравится, даже как язык, не то что как компилятор. Конечно пользуюсь, но редко - для мелких служебных прог "на пять минут". Но делать из-за какого-то обиженное лицо, винить борланд во всех грехах. Просто излишне.
        В конце концов у Delphi есть свои плюсы++ и их не нужно списывать со считов.
        Ответить
        • > Но делать из-за какого-то обиженное лицо, винить борланд во всех грехах.

          Да всё равно уже неприлично так относиться к написанию оптимизаторов.
          Получается порочный круг - борланд плюёт на оптимизацию, говоря, что "а всё равно на дельфах ничего сложного не пишут", программисты ничего не пишут сложного на дельфах, говоря, что "а там компилятор дубовый, не катит".
          Ответить
          • Устал Вам рассказывать, где и чего можно почитать. Поищите методом тройного гугла информацию о том, какие приложения написаны на Delphi, а потом мысленно прибавьте количество приложений, которые используются в различных конторах закрытым образом - и сохраните результат в память. Это про "программисты ничего не пишут сложного на дельфах".

            Из пушки по воробьям, понятное дело, никто не стреляет, и странно, что у Вас это вызывает такую реакцию.
            Ответить
            • > какие приложения написаны на Delphi

              Типа Тотал Командера или Квипа? Дык а там нет сложных вычислений.
              Ответить
              • Опять пушки и воробьи?
                Ответить
                • Ну дык а я об этом порочном круге и говорю. Потому и не катит дельфа для сложных вычислений, потому что компилятор иногда такое вытворяет...
                  Ответить
                  • Конкретно "такое" (всм то, что в заголовке) - весьма спорно. Здесь это уже обсуждалось. В целом - чего Вы хотите от среды разработки высокоуровневого ПО? Автоматизированной разработки. Здесь многое допускается из-за необходимости гибкого сочетания больших объёмов кода. VCL - это не "Hello, world", к сожалению.
                    Ответить
                    • Я хочу, чтобы
                      i := round(d)
                      компилировалось в
                      fld d; fistp i; fwait;
                      А не в
                      fld d; call @ROUND; mov i, eax
                      Первый вариант - логичный и простой, второй - какой-то дикий ненужный костыль, примотанный к здоровой ноге, из-за которого она не может нормально гнуться.
                      Ответить
                      • Законное желание. Но, позвольте попросить пример, когда одинокое округление будет нужным. Это мисдизайном может оказаться
                        Ответить
                        • Например, чтобы вычислить тексель.
                          Если не нужно одинокое округление - то есть frndint
                          Где какое надо - номальный компилятор разберётся.
                          Ответить
                          • Пример такой RAD-среды, схожей по возможностям с Delphi, пожалуйста. И скорость компиляции в отношении к качеству результата. Озвучивать не надо, здесь многие знают ответ и поэтому таких примеров не приводят
                            Ответить
                            • А причём тут скорость компиляции? Скорость связана только с особенностями языка (нету возможности делать свои макрос, шаблоны, считай нет инклудов). Записать в екзешник код команды fistp вместо кода команды call - это компиляцию не замедлит ни на милисекунду.
                              Ответить
                              • И всё же я Вам рекомендую почитать что-нибудь приличное по написанию компиляторов. Там, правда, авторы тоже по Вашей классификации в демагоги попадают, но остальным нравится. Пересказывать полкниги мне некогда, есть реальные проекты и по вечерам хочется отдохнуть, а не доказывать кому-то что-то, что написано в любой книге по теме.
                                Ответить
                                • "Я авторитетнее тебя, поэтому ты априори не прав, я выиграл."
                                  Не, ты мне вот по простому скажи - что сложного записать код команды фистп вместо кода команды калл? Там же надо ещё и запоминать адрес этого раунда, морока же лишняя.
                                  Ответить
                                  • В двух словах: чем сложнее система, тем сильнее её надо структурировать. Чтобы она не развалилась, как дом, построенный из кирпичей разных размеров. Для этого придумали такие вещи, как соглашения вызова.

                                    Когда усложняется язык по мере развития - появляются места, требующие серьёзной оптимизации. ООП-код на такие места богат. И поэтому основной упор делается именно на эти участки. Потом, когда всё основное соптимизировано, можно попробовать оптимизацию мелочей. Но если подход к оптимизации изначально другой, неподходящий, то сделать это не так просто. Раздалбывать полоптимизатора разве что, чтобы воткнуть костыль. И скорость компиляции упадёт. Как это влияет на число человеческих ошибок в программе - известно. Здесь разработчик компилятора ищет баланс между сделать медленной и нудной разработку, усложнив её, или пожертвовать производительностью некритичного кода.

                                    В Вашем случае, если помните, падение производительности от вызова функции происходит далеко не всегда.

                                    Подробнее - в упомянутых книгах.
                                    Ответить
                              • И всё же я Вам рекомендую почитать что-нибудь приличное по написанию компиляторов. Там, правда, авторы тоже по Вашей классификации в демагоги попадают, но остальным нравится. Пересказывать полкниги мне некогда, есть реальные проекты и по вечерам хочется отдохнуть, а не доказывать кому-то что-то, что написано в любой книге по теме.
                                Ответить
                              • И всё же я Вам рекомендую почитать что-нибудь приличное по написанию компиляторов. Там, правда, авторы тоже по Вашей классификации в демагоги попадают, но остальным нравится. Пересказывать полкниги мне некогда, есть реальные проекты и по вечерам хочется отдохнуть, а не доказывать кому-то что-то, что написано в любой книге по теме.
                                Ответить
                          • >Например, чтобы вычислить тексель.
                            Какой тексель в РАД среде? 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 - последний компилятор. Остальные выпустила другая фирма и по слухам они глючные. Я судить не берусь, ибо в глаза не видел.
          Ответить
          • Именно так. Вообще говоря, формально говоря "Borland" мы говорим о чём-то несуществующем. И насчёт качества значительная доля правды в этом есть. Они уже в 7-й версии попытались на .NET позариться, но там ещё прилично в этом плане было. Дальше, AFAIK, .NET перевесил - и среда стала загибаться. Borland как юридическая сущность исчезла. И оно, наверное, к лучшему. Пусть имя этой компании лучше будет ассоциироваться с их славным прошлым, чем с глупой кончиной.
            Ответить
        • > Которая успешно дополняется "тыканием" совершенно незнакомому Вам человеку.

          Аааа, это мегаЛОЛ. Всё, пиздец, я сдаюсь, против этого аргрумента я бессилен. Я плачу ааа.

          Остальную часть поста не читал.
          Ответить
          • Заметьте, не только этого поста.
            Ответить
            • Дык ты пиши поменьше. А хотя... Спасибо за срач в моём говнокоде, я могу им гордиться.
              Ответить
    • делфи говно. используйте с++. а лучше ассемблер. вы ниповерити. это самый быстрый язык!!!!!!111111
      Ответить
      • Для выполнения кода - да. Именно поэтому многие из здесь присутствующих сейчас там. Для разработки - увы, не всегда. RAD тоже ведь не зря придумали.
        Ответить
        • Тому гостю я бы даже не стал отвечать... :D У того нет шансов что-то понять, да и читать он весь пост не будет...
          Ответить
          • Возможно, Вы и правы. Скорее всего правы. Фразы там и правда шаблонны. ;-)
            Ответить
            • Решил сюда вам скомментить.

              Пишите вы хорошо, интересно, приводите нормальную аргументацию, т.е. опровержение в чистом виде и по факту, а не "целерон", "знаю предостаточно" и т.д. Но вы написали столько текста, сколько я не писал когда-то на диплом наверное. Просто складывается впечатление что это именно вы тот разработчик из борланда, что допустил такой ляп(? все равно call ради одной инструкции меня напрягает, несмотря на то, что на производительность он вроде как совсем не влияет). И теперь вы старательно оправдываетесь.

              Если кратко то слишкам многа букфф ради одного call. Вот если вы все это скомпонуете и оформите в статью, то считаю, что будет очень интересно и познавательно. Тем более что я сейчас пишу компилятор для своего небольшого процедурного ЯП. По профессии я, если что, пишу офисный мусор на шарпе.
              Ответить
              • Не разработчик из Borland уж точно. Просто не люблю ситуации "Один: ЧтоТоТам - отстой! Все: Ура, ЧтоТоТам - отстой!". Категоричность деструктивна.

                Букв действительно много. Зато, заметьте, охватили много смежных вопросов.

                > Вот если вы все это скомпонуете и оформите в статью, то считаю, что будет очень
                > интересно и познавательно.
                Думаю, это действительно возможно. Обсудим размещение этой статейки с редакцией какой-нить из местных газет компьютерной тематики. По формату им как раз должно подойти. Ссылку кину, если что.

                > Тем более что я сейчас пишу компилятор для своего небольшого процедурного ЯП.
                А ведь оптимизация, которая обсуждается здесь - она тонкая достаточно. Стоит ли уделять именно ей столько внимания в своём компиляторе? Просто риторический вопрос, для размышления. ;)
                Ответить
                • > А ведь оптимизация, которая обсуждается здесь - она тонкая достаточно. Стоит ли уделять именно ей столько внимания в своём компиляторе?
                  Я пишу на высоком уровне, низкий для меня скорее хобби, мечта(своя ОС например, как раз планирую заняться) и просто развлечение.

                  Вообще хотелось бы видеть больше полезных и интересных сайтов по асме, одного wasm'а маловато будет.
                  Ответить
                  • > Вообще хотелось бы видеть больше полезных и интересных
                    > сайтов по асме, одного wasm'а маловато будет.
                    А о чём? Все сайты по асму так или иначе сводятся к разъяснению всего того, что пишут в своих доках разработчики процессоров. Вопросы на форумах это, как правило, подтверждают. Хотя, конечно, собрать бы это всё воедино да упорядочить...
                    Ответить
                  • Ну как, занялся?
                    Ответить
              • Ссылку на транк или хуй простой.
                Ответить
              • Спустя полгода выбрался наконец-то скинуть ссылку. Получилось чуть интереснее, чем просто статья :)

                http://dimonsoft.ueuo.com/opttest/

                Оттуда есть ссылки на все остальные ресурсы.
                Ответить
                • Я почитаю. Спасибо. :)
                  Ответить
                • По аналогии с Говнокодом сначало случайно прочитал "Экскримент «Тонкости оптимизации»" :-[

                  А результаты тестирования уже где-то можно посмотреть?
                  Ответить
                  • По той же ссылке есть подборка результатов экспериментов. В статьях рассказано, как разбирать эти результаты, и даны некоторые комментарии по поводу полученных результатов.

                    Все "жизненно необходимые" ссылки - внизу страницы.
                    Ответить
                    • > Предлагаемый им вариант заключается в использовании инструкции FRNDINT (которая, собственно, производит округление числа в вершине
                      стека) с последующим извлечением результата инструкцией FISTP.

                      Фигли врёшь, я говорил сразу применить FISTP.
                      Ты пиздобол, Димонсофт.
                      Ответить
    • Приведите кто-нибудь, пожалуйста, ассемблерный код функции _ROUND.
      А то дельфи сейчас не стоит.
      Так будет легче ориентироваться. :)
      Ответить
      • sub esp, 8
        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
      Ответить
    • Нужна скорость работы программы и очень хочется на языке паскаль? Тогда есть компиляторы, Free Pascal (если не ошибаюсь) - компилирует паскалевский код в Си, а оттуда оптимизирующим gcc получает приличный по скорости код. :)
      Ответить
    • Да, там не дворд, а куворд, конечно.
      Я терплю дельфу только за скорость компиляции и за простой для понимания язык.
      Про то, что на этот баг всем пофиг, так как дельфу никто для программ со сложными вычислениями - я уже сказал. С этим, увы нельзя не согласиться, но тут нельзя однозначно сказать, что послужило причиной. Возможно, так сложилось как раз потому, что борланд забил на оптимизацию.
      Что я написал - что-то да написал, зачем светиться, особенно перед тем товарищем?
      Ответить
    • Кстати, прикол: c := d он таки компилирует ровно так, как я сказал. C: comp.
      Ответить
      • встретились столяр и слесарь.
        столяр говорит:"блин, ненавижу ключ на 10, им плохо доски отёсывать"
        а слесарь ему в ответ:"ты, сам му**к, ключ на 10 это классно, а вот топором гайку закручивать это попа, топор - отстой"
        и пошла драка не на жизнь а на смерть
        Ответить
    • TarasB, вам сюды:
      http://govnokod.ru/3376#comment30390
      Ответить
    • Посоны, про меня в статье написали!!!
      http://www.nestor.minsk.by/kg/2010/38/kg03804.html
      Ответить
      • Я в этом треде тоже спорил от гостя). Но тогда я так не троллил. :/
        Ответить
        • Да ещё и этот пиздобол мало того, что спиздел, про то, что я якобы предлагал подряд писать FRNDINT и FISTP, так ещё и минусов мне натыкал ровно в каждый пост, я заебался выправлять.
          Дельфи позорит, гад.
          Ответить
      • > minsk

        Это в http://govnokod.ru/27233
        Ответить
    • Как я попал в этот тред?
      Ответить
      • Зашёл в профиль тарасбера, кликнул на первую страницу его говнокодов, пролистал вниз, перешёл в самый нижний. Насрал.
        Ответить
        • Пиздец ты Шерлок Холмс.
          Ответить
          • пиздец ты кошкодевочка без единого кода.
            Ответить
            • Я IDE не могу выбрать, какие говнокоды, ты о чем?
              Ответить
              • Тогда меняй файку, ты не программерша.
                Ответить
              • книжк почитай, ну
                https://www.oreilly.com/library/view/learning-gnu-emacs/0596006489/

                уже понятно, что тебе нужен емакс
                Ответить
                • GNU-VEDMOCHKA_PROGRAMMER
                  https://i.imgur.com/9PX0wok.png
                  Ответить
                • Я не могу в емаксе писать, я хочу клацать мышкой и автоподсказки >:с

                  Хотя в емаксе есть LSP и анимешная ведьмочка... Блин, я призадумался.
                  Ответить
                  • на каком языке?
                    Ответить
                    • На «C++» и «python».
                      Ответить
                      • для С++ есть таги и еще какая-то пораша от clang, долже н быть какой-то комплишен

                        Во всяком случае в vim с exuberant tags у меня комплишен для сей был (хоть и тупой).

                        Попробуй также VSCode: там есть LSP сервер для Python
                        Ответить
                        • https://www.linux.org.ru/forum/development/15899205

                          Да и для емакса есть LSP с питонием. А VSCode не хочу, он мелкомягкий.
                          Ответить
                        • унылый анальный троллинг в комментах

                          лор такой лор
                          Ответить
    • https://asar-forum.com/viewtopic.php?t=6765

      Пидец. У меня такое же случилось (((

      Советую почитать, там люди очень смешные вореции пишут:

      Ва алейкума сСалям, ва рахматуЛлахи ва баракятух Брат!
      Просто поставь антивирус и все, ин шаа Аллах проблем подобных не должно возникать... Лично у меня стоит аваст, он бесплатный и постоянно обновляет свои базы через интернет. Альхамду-лиЛлях уже больше года им пользуюсь и все в порядке. БаракаЛлаху фик!!!
      Ответить
      • Это просто прекрасно, просто восхитительно!

        Один раз я по глупости своей попался на одну спам рассылку в агенте. Вся беда в том, что ко мне пришла ссылка (ля-ля тополя), а я наивно поверив скачал что-то (сам не знаю что), и установил его у себя на компе. После установки мой манитор вдруг переполнился диалоговыми окнами, и я понял что попался на мышеловку :). После этого от моего имени началось рассылаться подобные спамы. Меня это конечно дразнило, но я нигего поделать не мог. Пытался менять код, но бестолку, рассылка не прекращалось. Обращался к одному брату, он сказал что я устанавил себе мини програмку и теперь они по средством этой програмки получают инфо о моих поролях и менять пороль бесполезно. Какие действия можно предпринять в подобных ситуациях?
        Ответить

        • Один раз я по глупости своей попался на разводку. Вся беда в том, что какие-то люди попросились ко мне попить водички (ля-ля тополя), а я наивно поверив пустил домой кого-то (сам не знаю кого), и поселил у себя на неделю. Через неделю у меня пропали все деньги, и я понял что попался на мышеловку :)
          Ответить
    • Всё же `FRNDINT` требует наличия математического сопроцессора.
      Впрочем, fld вероятно его тоже требует
      Ответить
      • «Вероятно». Да всё, что на F, его требует. Даже FNOP, который ничего не делает, его требует.

        Можно, конечно, без сопроцессора, если ты повесишь обработчик исключения номер шесть и смумулируешь сопроцессор.
        Ответить
        • Мне кажется, будет не очнеь производительно. Я бы советовал приобрести сопроцессор фирмы крей

          Можно еще апгрейтнуться на 486, там кажется FPU всегда встроен
          Ответить
          • У 486SX нету сопроцессора. Нужно брать 486DX/DX2/DX4 (у последнего обычно множитель 3, а не 4, но всем как обычно).

            SX вроде получают из бракованных DX с заблокированным сопроцессором, шоб не глючил.

            К слову, на некоторых материнках с 386DX помимо гнезда/площадки для 80387 ещё бывает гнездо для сопроцессора Weitek. Weitek программируется не через опкоды ЦПУ, а через порты. Я не знаю, какие программы и библиотеки умели работать с Weitek и чем он отличается по возможностям от 80387.
            Ответить
            • Похоже у Weitek не было 80-битных питухов и была регистровая модель вместо стековой.
              Ответить
            • Разумеется, речь шла о DX. Я же не бомж, чтобы брать SX, ну.

              А ты знаешь о проблемах переиспользования регистров FPU новой технологией MMX?

              (ток-шоу некрофилы)
              Ответить
              • Да, один и тот же физический регистр шарится между командами FPU и MMX, поэтому после выполнения цепочки команд MMX нужно вызвать команду FEMMX, чтобы регистры вернулись к удобоваримому для FPU состоянию.

                Из-за этого при обработке прерываний и в многозадачной среде много пердолинга.
                Ответить
                • Насрали в вечность. Сэкономили ~ 640 бит, зато в многозадачной среде из ускорителя получили замедлитель.

                  Это архитекторы? Это архитекторы? Пидоры, говно жрут.
                  Ответить
                  • говно какое, именно по-этому я за SSE
                    Ответить
                    • Немножко ошибся в мнемонике. Их аж две было:

                      https://www.club155.ru/x86cmd3dnow/FEMMS

                      https://www.club155.ru/x86cmdmmx/EMMS
                      Ответить
                    • А я за AVX
                      Ответить
          • А ты в курсе, что Интел ещё выпустил сопроцессор ввода-вывода 8089, но поскольку IBM не стала его втыкать в свой PC, он остался малоизвестным. Х. з., использовался ли он где-то вообще или вся партия осталась на складе, но в клонах IBM PC сопроцессора 8089 не было.
            Ответить
    • Сишник (выносит интерфейс модуля в .h файл)

      Джаваёб и джаваскриптоблядь: "ахаха, тупой сишник вынужден писать одно и тоже в .h файле и в реализации, одни и те же символы"

      Джаваёб: Так, ладно:
      interface Petuzh { 
         int getKurochka();
      }
      
      class PetuzhImpl implements Petuzh

      потому что еще в эффектив джава написано, что программировать нужно против интерфейсаов.


      Джаваскриптоблядь: так-так-так, а где бы взять `.ts.d` файл для этого модуля?
      Ответить

    Добавить комментарий