Плавающая запятая и 64 разряда
 

В погоне за увеличениием производительности при вычислениях с плавающей запятой купили четырёхядерный процессор (не Xeon), установили 64 разрядную ОС, применили опции транслятора для использования имеющихся четырёх ядер. Да, задача стала считать быстрее - пропорционально числу процессоров, но 64 разряда не сказались никак. Вопрос: справедливо ли утверждение, что изменение разрядности касается только основного процессора, а процессор, обрабатывающий числа с плавающей запятой остался тем же, что и на 32 разрядных процессорах? Или есть неизвестные нам возможности повышения производительности при работе с плавающей запятой при использовании 64 разряных ОС? Спасибо.

в первую очередь программное обеспечение должно быть написано именно под 64-битную систему, иначе большого прироста добиться не удастся.

иначе НИКАКОГО прироста добиться не удасться. 64-битные процы имеют два набора инструкций (под 32 и 64 бита). Соответственно, если работает 64-битная ось, то используется один набор инструкций, если 32-битная, то другой. Следовательно, если софт 32-битный, то прироста вообще не будет, что и показывает ваш пример. Все так и должно быть.

вопрос спорный. Ибо многие юзера сообщают о лучшей производительности 32-битных софтин, портированных под 64-бита.

Если быть точным, это не процессор, а его блок - FPU (Floating Point Unit). Как сказал FRZ, если ОС 64-битная, то процессор работает в 64-битном режиме, следовательно и FPU-блок тоже.

Ну во-первых 64-разрядные технологии дают существенный прирост при работе с большими целыми числами, либо очень точными дробями. Тоесть - шифрование, медиакодирование, астрономические и другие расчёты. Если род вычислений другой - существенной разницы Вы не получите. Во-вторых. Не только ОС и софт должен быть 64-битный, более того - абсолютно вся программная среда должна быть 64-битной (плагины, енкодеры/декодеры (если выполняется медиакодирование) и т.д.). В-третьих, 64-битные технологии позволяют использовать более 3,5 Гб оперативки. Тоесть, если в Вашем случае увеличение ОЗУ даст прирост производительности, то можно смело ставить большие объёмы памяти.

Благодарю Вас за внимание к вопросу. Но, мне кажется, обсуждение несколько уклоняется от сути вопроса. Для ShaddyR. Речь идёт о ПРОГРАММИРОВАНИИ, то есть работает СВОЙ 64 разрядный код, рождённый под 64 разрядной ОС 64 разрядным вариантом транслятора. Ваше условие выполнено. Для FRZ. Аналогично. Почему Вы решили, что "софт 32 разрядный"? Для xommer. Что касается "процессор обработки плавающей запятой" или "блок процессора, обрабатывающий плавающую запятую", то это вопрос терминологии, раньше их, как Вы помните, разделяли, теперь объединяют. Что касается разрядности мантиссы, то для сравнения она выдерживается одинаковой, двойной точности. Что касается абсолютности разрядности для ВСЕЙ начинки ОС (плагины, декодеры и так далее - что мы, естественно, гаранировать и проверить не можем), то, мне кажется, это не принципиально, так как вся эта начинка не участвует в создании кода и не используется кодом, созданным транслятором. Да, известно, что увеличенная разрядность позволяет адресовать больше памяти. Но и это не принципиально, если эта память не нужна задаче. Вопрос сводится к одному: уменьшилось ли число тактов, за которые выполняются четыре арифметические операции (перечислять не буду)? Если "Да", то прирост скорости будет. Он нами не отмечен. А прирост скорости в действиях самой ОС весьма заметен. Вот тут я и проявляю собственную неосведомлённость и интересуюсь информированностью коллег. Что Вам известно об изменениях в архитектуре блока обработки плавающей запятой для процессоров, способных работать с 64 разрядами? Спасибо.

Vlad46, По моему вы немного ошиблись форумом, можно конечно поискать в сети статьи которые более подробно освещают как саму архитектуру 64 разрядных процессоров и особенности работы их в 64 разрядной среде. Лично я не вникал особенно в технологии 64 разрядных процессоров, просто знал что они помогают преодолеть ограничение 4GB в объеме оперативной памяти.

Для Ment69. Подтема форума "Процессоры", я интереуюсь реализацией обработки числа с плавающей запятой процессором. Вопрос "не форматный"? Почему? Мы собираем эту информацию в меру сил. И вырисовывается занятная картина. Intel рассказывает (Quad) про основной блок, а про "эту" часть... Ну не выпячивается вопрос. Волей-неволей начнёшь думать, что прежний FPU просто перенесён из Core Duo. Так это или не так?

Так а чего про него рассказывать? Про него уже всё давным давно рассказали, ещё со времён появления Athlon 64! А вот какраз про технологию 4 ядер и про всё остальное и надо народу доложить, чего нового и т.д.

Если не ошибаюсь, ещё во времена Pentium MMX процессоры могли обрабатывать 80-битные числа (за счёт MMX), чуть позже, с появлением SSE - до 128-бит добрались. Хотите повышения производительности - используйте SSE1/2/3/4. Причём на Core 2 они обрабатываются за 1 такт, вместо двух на старой архитектуре. Либо две 64-битные за такт. Как больше нравится. Я не вчитывался сейчас - утро... спать... Извлекаю из памяти без ECC;)

Возможно, чем-то будет интересна статья об архитектурных новшествах Conroe: http://www.ixbt.com/cpu/p6-nexgen.shtml

Для VINDIGO1. Ваше замечание "а чего про него рассказывать" было бы справедливо, если бы ситуация оставалась неизменной и для обработки числа с плавающей запятой никто ничего и не собирался бы делать. Но есть люди, которым это очень не безразлично и при выходе на рынок нового изделия они вправе интересоваться: а как там дела в ЭТОМ деле? Нет? Не очень понятно, почему выход Athlon 64 ознаменовал собой окончание разработок процессоров по обработке числа с плавающей запятой, если учесть, что именно в этой области обычно Intel имел преимущество над AMD, но, тем не менее - спасибо. Для Coutty. Большое спасибо за ссылку, очень "в тему", хотя и 2005 год. Команды наборов SSE, насколько я понимаю, всё же вводятся для обработки данных мультимедийного характера, во всяком случае, я не видел в опциях вполне современных трансляторов FORTRAN вариантов их использования. Во всяком случае, после прочтения статьи по Вашей ссылке я сделал для себя вывод, что моё начальное предположение о том, что этот блок - FPU - остался прежним несмотря на переход от 32 к 64 разрядам в целом для процессора, это предположение не такое уж и криминальное. Похоже, так и есть.

Пожалуй, их используют в основном для этого, но кто мешает задействовать в других целях?
Про SSE1:
Arithmetic
Scalar - ADDSS, SUBSS, MULSS, DIVSS, RCPSS, SQRTSS, MAXSS, MINSS, RSQRTSS
Packed - ADDPS, SUBPS, MULPS, DIVPS, RCPPS, SQRTPS, MAXPS, MINPS, RSQRTPS

Основные арифметические присутствуют. Сам-то я с SSE не работал, а уж с фортраном и подавно (php больше по душе), поэтому утверждать всё же не буду (аналогично, и тему продолжать;))

double был "родным" ещё для 80387
Просто понятие разрядности может относиться к совершенно разным предметам: ширина шины, разрядность команд, разрядность адреса и т.п.
Говоря о 64-разрядных ОС (Windows, Linux) и процессорах (Intel, AMD) подразумевают в первую очередь ширину адреса.

Vlad46, Ну дык это я тоже пытался доказать. На примерах. :)

А с чего Вы это взяли?
Мне кажется, в контексте ещё имеется ввиду, что нынешний блок ненамного быстрее 32-разрядного блока.

Наверно, я не вполне корректно сформулировал свой вопрос. На самом деле необходимо было бы упомянуть, что сравнение идёт между счётом на Intel Core 2 Duo и Intel Core 2 Quad. Как видно, отличия не значительные. В частности, первый только 32 разрядный, а второй - может работать и в 32-ух и в 64-х разрядных режимах. Да, Busla прав, в данном случае имеется ввиду разрядность адреса. Но, не зная точно, можно предположить, раз разрядность адресной части команды увеличилась, значит увеличилась ширина "потока ввода", то, МОЖЕТ БЫТЬ, и для данных он срабатывает? Ну, что-то в этом роде. На самом деле ничего подобного НЕ присходит, это показали как наш реальный опыт, так и общая теория вопроса (Conroe есть Conroe), изложенная в http://http://ru.wikipedia.org/wiki/Intel_Core_2_Duo и в http://http://ru.wikipedia.org/wiki/Intel_Core_2_Quad. Вообще, цикл статей, посвящённых процессорам, в этой энциклопедии на русском языке вполне достойный, мне кажется. Для Busla. Да, конечно, Ваше замечание о 387 справедливо. Просто с тех пор много времени прошло, теперь это уже RISC процессоры с конвейрной обработкой, вполне можно ожидать новостей при выходе новой модели. В нашем случае новостей нет. Спасибо.

Действительно, стоило упомянуть. Core 2 Quad - это два Core 2 Duo под одной крышкой, поэтому следует ожидать масштабирования только по числу ядер. С чего бы ему другие улучшения получать?

C2D тоже 64-битный режим поддерживает. Со времён Pentium4 6xx 64-битный поддерживается.

Опачки! А мужики-то и не знали!
Они оба "двухрежимные", более того, - по большому счёту, Quad - это два Duo в одном корпусе.
Если ваша задача на Quad считается практически в два раза быстрее чем на Duo - могу вас только поздравить - она очень эффективно распараллелилась. Большего ожидать и не стоит.

о "ширине потока ввода" imho в данном случае можно не беспокоиться - кеш и конвейер остаются теми же что в 32, что в 64 режиме, так что FPU будет получать данные одинаково.