На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
Модераторы: ANDLL, ALXR
Страницы: (5) « Первая ... 3 4 [5]  все  ( Перейти к последнему сообщению )  
> == 0 ИЛИ !, C++
   
== 0 ИЛИ !
Гости не могут просматривать результаты голосования.
Гости не могут голосовать 
    Я имел ввиду схемотехническую реализацию, аппаратную. И цитата та не от amk. ;)
      Цитата Славян @
      засылка значения - это как привоз некими 32-мя фурами издалека значения 0 или 1 (распараллелили)
      Это не завоз издалека. Это когда ты приходишь куда-то, а нужное значение у тебя тут-же с собой, в кармане, и не надо никого за ним куда-то посылать, ни из подручных средств на месте готовить.
      Всё написанное выше это всего лишь моё мнение, возможно ошибочное.
        Э, погодьте-ка! Регистр всё же кусок памяти процессора, такие-то ячейки на подложке, элементы микросхемы. Поэтому ничего в кармане у них вечно нет, - всё откуда-то завозится. И непосредственное значение, даже бит его, всё равно придёт=принесётся! А вот нанофабрика по созданию операции XOR вполне может быть тут же, в шаге; так что мне мыслится это быстрее. Хоть и соглашусь, что практическая реализация может статься и наоборот сделана. :yes-sad:
          Непосредственные данные (в диапазоне от -128 до 127 это всего 1 байт) поступают на исполнение одновременно с командой, так что никаких дополнительных задержек они в принципе создать не могут. А вот для команды XOR приходится задействовать ALU - пересылать данные туда-сюда. Хорошо, что требуется на это всего один такт. Но потом-то приходится ещё и инкремент делать. А это отдельная команда, вдобавок завязанная на результат предыдущей, запараллелить её не получится.
          Всё написанное выше это всего лишь моё мнение, возможно ошибочное.
            Ну я вижу работу декодера как-то так:
            ExpandedWrap disabled
              if( XOR )
              {
                switch( операнды )
                {
                  case reg32s:
                      if( reg32a vs reg32a ) обнулить!( reg32a );
                      else ФабрикаXOR(...);
                      ...
                  case память:
                      ВытащитьДанные();
                      ФабрикаXOR(...);
                      ...
                  case ...
                }
              }
            А команды mov reg32, data8 всё равно ж нет, так что приходится зачитывать аж 32 бита, что долго и много.
              Цитата amk @
              На AMD, судя по таймингам, одинаково, только комбинация push+pop немного длиннее
              Почему длиннее? push 1 = 2 байта, pop eax = 1 байт, итого 3.
              xor eax,eax = 2 байта, inc eax = 1 байт (на 32-х битах, не 64), итого тоже 3.

              Цитата amk @
              А непосредственная засылка единицы в регистр на обоих процессорах будет работать ещё быстрее.
              Это понятно, но тут оптимизации по размеру.

              Цитата Славян @
              Это они практически такие же, но идеологически test не меняет регистр, а лишь "проверяет" (and "в уме") биты, посему ДОЛЖЕН быть быстрее.
              OMG, в каком "уме"? "В уме" может так же означать (в теории), что его нужно куда-то скопировать и там сделать and. Это как вариант. Как там в микрокоде конкретно реализовано - не знаю. Но это всё демагогия. А надо смотреть на таблицы, которые говорят, что на Nehalem, к примеру, mov, xor, test, or, and, add, sub, inc и dec (для операция reg,reg или reg,imm) имеют одни и те же характеристики: используемые порты, кол-во микроопераций и latency. К тому же, xor с inc не могут параллелиться даже чисто теоретически, т.к. inc зависим от результата предыдущей операции - xor.
              Ещё в качестве примера: inc eax по твоей логике должен быть быстрее, чем add eax,1, однако на Pentium 4 он работает медленнее, т.к. не меняет значения флага CF, что требует дополнительной микрооперации.
              Ещё "в теории" loop должен работать быстрее, чем dec eax + jnz, но вот на практике всё иначе (ещё со времён царя Гороха)...

              Цитата Славян @
              Ну я вижу работу декодера как-то так
              Видь. А Intel видим её по-своему :tong:
              vpmultishiftqb vscatterpf0dps vfmsubadd132pd vgatherpf1dps vpclmulhqlqdq vcmptrue_ussd vaeskeygenassist
                Цитата Jin X @
                Ещё в качестве примера: inc eax по твоей логике должен быть быстрее, чем add eax,1, однако на Pentium 4 он работает медленнее, т.к. не меняет значения флага CF, что требует дополнительной микрооперации.
                Ну во многих древних книжках по ASM'у так и писалось, что INC - короткая и быстрая, а не то что ADD. Что там поменяли существенно с годами - неясно, но всё же думается, что первые инженеры процессоров не зря сделали такую команду отдельно, - нутром чуяли её специфику, а потому и ускорение. :yes: :yes:
                  Славян, напомню, что раньше память ОЗУ была в дифиците и измерялась килобайтами, а не гигабайтами, поэтому вполне логично было иметь 1-байтовые инструкции как альтернативу 3-байтовым - это раз.
                  Ну и да, во времена 8086 процессора add (reg,imm) выполнялась за 4 такта, а inc - за 3. Но с тех пор воды утекло целое озеро Байкал...
                  vpmultishiftqb vscatterpf0dps vfmsubadd132pd vgatherpf1dps vpclmulhqlqdq vcmptrue_ussd vaeskeygenassist
                  1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
                  0 пользователей:


                  Рейтинг@Mail.ru
                  [ Script Execution time: 0,1033 ]   [ 16 queries used ]   [ Generated: 23.07.18, 15:49 GMT ]