Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Ну ни фига себе! Надо разобраться 13.03.02 12:36 Число просмотров: 1367
Автор: Mosich <Mosichev Valentine> Статус: Member
|
> WinMe, обычный The Matrix
а может поставить фирменный днетовский?
|
|
<dnet>
|
По поводу Pentium 4 12.03.02 08:13
Автор: Pavel [SPB] Статус: Незарегистрированный пользователь
|
|
Подскажите, как обстоит дело у этого процессора с производительностью под клиентом ? Стоит ли вообще ставить коровок на Р4-1500 ?
|
|
По поводу Pentium 4 17.03.02 23:08
Автор: Mishka Статус: Незарегистрированный пользователь
|
> Подскажите, как обстоит дело у этого процессора с
> производительностью под клиентом ? Стоит ли вообще ставить
> коровок на Р4-1500 ?
Vot tut para ssylok proyasnyayuschie problemu:
http://n0cgi.distributed.net/faq/cache/264.html
From: Nathaniel Cameron Begeman
nbegeman@engin.umich.edu
Subject: Speed table
Date sent: Tue, 27 Nov 2001 03:05:59 -0500
The following is a selection of RC5 core/processor speeds on the
various machines at my disposal. Unless otherwise specified, the
core used is the one that was automatically selected.
The Clocks/key column is the number of processor cycles required
to process one key. The keys/s/MHz column is the crunch rate per
Mhz.
Processor Clocks/key keys/s/MHz
68000 81
68010 85
68020 361
68030 384
386/386SX 2040 490
386/386SX(SMC) ~1350 740 (Latest self-modifying core.
Estimate)
68040 907
486/486SX 1020 980
Itanium (GCC 3) 980 1020
486/486SX(SMC) 960 1040 (Latest self-modifying core)
Pentium 700 1430
P4 700 1430 (4 clock latency on rotate
left!!!)
AMD K6/K6-2/K6-3 610 1640
UltraSparc II 507 1980
Pentium-MMX 485 2060
PowerPC 601 421 2375 (allitnil)
Celeron/PII/PIII 340 2940
68060 3030
AMD K5 310 3220
PowerPC 603/604 296 3378 (lintilla)
Athlon 290 3450
PowerPC G4 110.25 9070 (AltiVec)
=================================================
http://n0cgi.distributed.net/faq/cache/55.html
Why are PowerPC-based and (most) Intel-based
computers so much faster than other platforms on
RC5-64?
Integral to the mathematics of the RC5 algorithm
are 32-bit rotate operations.
For whatever reason, the designers of the IA32
(32bit Intel x86) and the PowerPC architectures
decided to implement the rotate function as a
hardware instruction.
Many other CPUs do not have built-in hardware rotate
instructions and must emulate the operation by (at
the very least) two shifts and a logical OR. This
handicap is why many non-32bit-Intel [1] and
non-PowerPC computers run RC5 slower than one
might expect based on real-world benchmarks. It is
also the main reason why the RC5 client is a poor
benchmark to use in determining the speed or
performance of a particular CPU.
[1] The IA32 architecture is that used by the
Intel 80386, 80486, Pentium, Pentium Pro, Pentium II,
Pentium III and Pentium 4 processors. The Pentium 4
does not however have a hardware rotate instruction.
|
| |
По поводу Pentium 4 18.03.02 19:09
Автор: StR <Стас> Статус: Elderman
|
> The Pentium 4
> does not however have a hardware rotate instruction.
Наконец-то хоть один нашел нормальный ответ...
Вывод: rc5 на P4 нормально работать не будет...
быстрее бы он кончался... :(((
|
| | |
По поводу Pentium 4 19.03.02 08:52
Автор: A6PAMOB Статус: Незарегистрированный пользователь
|
|
Интересно, а какой RCx-yy будет работать быстро на P4?
|
| | | |
По поводу Pentium 4 19.03.02 13:04
Автор: StR <Стас> Статус: Elderman
|
> Интересно, а какой RCx-yy будет работать быстро на P4?
имхо никакой, потому что алгоритм остается тот же... меняется только длина ключа...
|
| | | | |
По поводу Pentium 4 19.03.02 15:27
Автор: xelator Статус: Незарегистрированный пользователь
|
> > Интересно, а какой RCx-yy будет работать быстро на P4?
> имхо никакой, потому что алгоритм остается тот же...
> меняется только длина ключа...
Ответ неверный. Скажите у какого процессора архитектуры IA32 есть 64битная целочисленная арифметика?! Нет таких?! Неверный ответ.
Есть. Тот самый злосчастный P4 и SSE2. Вся присутствует.
Так вот на Атлоне эти действия придется эмулировать операциями над парой 32битных чисел.
Вывод - а как будет работать RC5-128? ;-)) У него ведь слова длины 64 бита...
Ответ еще один - надейтесь, конечно, на Хаммер. Но заметьте, что до сих пор АМД не имеет своего компилятора. Поэтому, о магическая фраза апологетов АМД, придется ВСЕ писать на ассемблере и хорошо, если это будет возможно не только под GAS. Про дебаггеры молчу. АМД должна активней проявлять себя на x86-64.org на Винде. А то пропадет здоровый конкурент у Интела.
|
| | | | | |
По поводу Pentium 4 19.03.02 16:25
Автор: Mishka Статус: Незарегистрированный пользователь
|
>
> Ответ неверный. Скажите у какого процессора архитектуры
> IA32 есть 64битная целочисленная арифметика?! Нет таких?!
> Неверный ответ.
> Есть. Тот самый злосчастный P4 и SSE2. Вся присутствует.
Насколько мне известно, когда используешь SSE2 набор, то не можешь использовать FPU. Иными словами, эта система подкоманд использует FPU. Далее, если все это правда (народ, что скажете?), то 64 битная целая арифметика всегда была частью FPU. Т.е. начиная с 486 любая IA 32 содержит 64 битную целую арифметику.
> Так вот на Атлоне эти действия придется эмулировать
> операциями над парой 32битных чисел.
>
> Вывод - а как будет работать RC5-128? ;-)) У него ведь
> слова длины 64 бита...
>
> Ответ еще один - надейтесь, конечно, на Хаммер. Но
> заметьте, что до сих пор АМД не имеет своего компилятора.
> Поэтому, о магическая фраза апологетов АМД, придется ВСЕ
> писать на ассемблере и хорошо, если это будет возможно не
> только под GAS. Про дебаггеры молчу. АМД должна активней
> проявлять себя на x86-64.org на Винде. А то пропадет
> здоровый конкурент у Интела.
А ты погляди на SuSE Linux - его уже портировали на Hammer. Вместе со многими вещами. Кстати, по-моему, где-то на АМД есть Билкины обещания насчет Hammer. Здесь только могу добавить, что это только обещания.
|
| | | | | | |
По поводу Pentium 4 20.03.02 08:01
Автор: xelator Статус: Незарегистрированный пользователь
|
> Насколько мне известно, когда используешь SSE2 набор, то не
> можешь использовать FPU. Иными словами, эта система
> подкоманд использует FPU.
Опять неверно. Это же вроде прописные истины. Так было в MMX.
Регистры MMX есть регистры FPU x87 поэтому одновременно использовать
MMX и FPU команды, мягко говоря, не рекомендуется. Да, и MMX функционально не использует FPU. Для него есть отдельный Execution Unit.
Вообще говоря, каюсь, MMX содержит операции на 64битными целыми, но с указаными выше ограничениям. Прелесть SSE2 - в их отсутствии и в том,
что можно делать одновременно 2 операции над 64битным целым или одну над 128битным, если это сдвиг. Это важная фича для RC5 на этапе key expansion.
> Далее, если все это правда
> (народ, что скажете?), то 64 битная целая арифметика всегда
> была частью FPU. Т.е. начиная с 486 любая IA 32 содержит 64
> битную целую арифметику.
>
Неправда. И вывод неверный. В FPU можно эмулировать целочисленное
сложение, умножение и деление если режим его работы округление к нулю.
Но как насчет сдвигов? А ротейтов? Не выйдет. Сразу же - делать одни
операции в FPU потом скидывать в память потом читать в целочисленный регистр делать сдвиг и абратно в FPU слишком дорого. Лучше эмуляция
через пару 32битных числа.
Для пущей честности, левый сдвиг на k бит можно эмулировать умножением на 2^k в вещественной арифметике, правый сдиг на k - умножением на 2^(-k) с последущим конвертацией результата к целому с округлением к нулю (truncate). Соответственно, rotate можно эмулировать 2 предыдущими командами и сложением их результата. Операции с парой 32битных чисел все равно гораздно быстрей.
И по чей-то злостной воле упорно блуждают абсурднейшие слухи о том, что в P4 нет аппаратной инструкции rotate. Хоть отдельный FAQ пиши на эту тему. ;-(( Есть она! ЕСТЬ!!!!!!!.
> А ты погляди на SuSE Linux - его уже портировали на Hammer.
> Вместе со многими вещами. Кстати, по-моему, где-то на АМД
> есть Билкины обещания насчет Hammer. Здесь только могу
> добавить, что это только обещания.
Я на это могу ответить, что MS Visual C до сих пор даже MMX-коды делать
не научился. Отсюда вывод, что вряд ли x86-64 набору больше повезет.
Что же касается ПодЛинукса, то все равно GCC не обеспечит нужной производительности и надо будет писать на ASM'e. До сих пор я не видел у АМД толкового мануала о том, как что-либо оптимизировать под их процы.
Он есть, но в нем написаны вещи типа - делай такую макро-операцию так-то, проц знает эту последовательность машинных команд и выполнит ее быстро. А насчет универсальных приемов с упором на архитектуру - НЕТ.
Если я делаю какие-то нестандартные операции, отличные от перевода целого числа в вещественное или подсчет количества ненулевых битов регистре, то я остаюсь в полном безвестном творческом пPолете.
|
| | | | | | | |
По поводу Pentium 4 20.03.02 22:25
Автор: Mishka Статус: Незарегистрированный пользователь
|
> Опять неверно. Это же вроде прописные истины. Так было в
> MMX.
> Регистры MMX есть регистры FPU x87 поэтому одновременно
> использовать
> MMX и FPU команды, мягко говоря, не рекомендуется. Да, и
> MMX функционально не использует FPU. Для него есть
> отдельный Execution Unit.
Посмотрел доки на П4:
Intel® Pentium® 4 Processor Optimization Reference Manual
http://developer.intel.com/design/pentium4/manuals/248966.htm
Page 4-2 (162)
General Rules on SIMD Integer Code
The overall rules and suggestions are as follows:
- Do not intermix 64-bit SIMD integer instructions with x87 floating-point
instructions. See “Using SIMD Integer with x87 Floating-point” section. Note that
all of the SIMD integer instructions can be intermixed without penalty.
- When writing SSE2 code that works with both integer and floating-point data, use
the subset of SIMD convert instructions or load/store instructions to ensure that the
input operands in XMM registers contain properly defined data type to match the
instruction. Code sequences containing cross-typed usage will produce the same
result across different implementations, but will incur a significant performance
penalty. Using SSE or SSE2 instructions to operate on type-mismatched SIMD
data in the XMM register is strongly discouraged.
- Use the optimization rules and guidelines described in Chapters 2 and 3 that apply
both to the Pentium 4 processor in general and to using the SIMD integer
instructions.
- Incorporate the prefetch instruction whenever possible (for details, refer to
Chapter 6, “Optimizing Cache Usage for Intel® Pentium® 4 Processors”).
- Emulate conditional moves by using masked compares and logicals instead of
using conditional branches.
Using SIMD Integer with x87 Floating-point
All 64-bit SIMD integer instructions use the MMX registers, which share register state
with the x87 floating-point stack. Because of this sharing, certain rules and
considerations apply. Instructions which use the MMX registers cannot be freely
intermixed with x87 floating-point registers. Care must be taken when switching
between using 64-bit SIMD integer instructions and x87 floating-point instructions
(see Using the EMMS Instruction section below).
The SIMD floating-point operations and 128-bit SIMD integer operations can be
freely intermixed with either x87 floating-point operations or 64-bit SIMD integer
operations. The SIMD floating-point operations and 128-bit SIMD integer operations
Intel Pentium 4 and Intel Xeon Processor Optimization Optimizing for SIMD Integer Applications 4
use registers that are unrelated to the x87 FP / MMX registers. The emms instruction is
not needed to transition to or from SIMD floating-point operations or 128-bit SIMD
operations.
Из чего делаю вывод: MMX & SSE - FPU sharing, SSE2 - independent. Т.е. при работе с 128 битовыми целыми - все хорошо, а с 64 битовыми напряженка. При этом, насколько я понимаю, из описания и доки, то ССЕ2 с 64 не работает.
>
> Вообще говоря, каюсь, MMX содержит операции на 64битными
> целыми, но с указаными выше ограничениям. Прелесть SSE2 - в
> их отсутствии и в том,
> что можно делать одновременно 2 операции над 64битным целым
> или одну над 128битным, если это сдвиг. Это важная фича для
> RC5 на этапе key expansion.
>
Далее читаем:
Page 2-5 (56)
Optimize Instruction Selection
- Avoid longer latency instructions: shifts, integer multiplies and divides. Replace
them with alternate code sequences (e.g. adds instead of shifts, and shifts instead
of multiplies).
- Use the lea instruction and the full range of addressing modes to do address
calculation.
- Some types of stores use more µops than others, try to use simpler store variants
and/or reduce the number of stores.
- Avoid use of complex instructions that require more than 4 uops.
Page 2-55 (106)
Use of the shift and rotate Instructions
The shift and rotate instructions have a longer latency on the Pentium 4 processor
than on previous processor generations. The latency of a sequence of adds will be
shorter for left shifts of three or less. Fixed and variable shifts have the same latency.
Assembly/Compiler Coding Rule 42. (M impact, M generality) If a shift is on a critical
path, replace it by a sequence of up to three adds. If its latency is not critical, use the shift
instead because it produces fewer uops.
The rotate by immediate and rotate by register instructions are more expensive than
a shift. The rotate by 1 instruction has the same latency as a shift.
Assembly/Compiler Coding Rule 43. (ML impact, L generality) Avoid rotate by register
or rotate by immediate instructions. If possible, replace with a rotate by 1 instruction.
Вывод делаю - всякие сдвиги - очень дорого.
> Неправда. И вывод неверный. В FPU можно эмулировать
> целочисленное
> сложение, умножение и деление если режим его работы
> округление к нулю.
> Но как насчет сдвигов? А ротейтов? Не выйдет. Сразу же -
> делать одни
> операции в FPU потом скидывать в память потом читать в
> целочисленный регистр делать сдвиг и абратно в FPU слишком
> дорого. Лучше эмуляция
> через пару 32битных числа.
Со сдвигом согласен, если его только не осуществлять через сложение умножение. А для других операций - тут пардон. Кроме того, целочисленные операции имеют свои коды FIADD, FIDIV, etc. Используя их не надо переводить процессор в режим округления специальной командой.
> Для пущей честности, левый сдвиг на k бит можно эмулировать
> умножением на 2^k в вещественной арифметике, правый сдиг на
> k - умножением на 2^(-k) с последущим конвертацией
Это вещи известные, только вот операции умножения очень дорогие.
> результата к целому с округлением к нулю (truncate).
> Соответственно, rotate можно эмулировать 2 предыдущими
> командами и сложением их результата. Операции с парой
> 32битных чисел все равно гораздно быстрей.
>
Согласен.
>
> И по чей-то злостной воле упорно блуждают абсурднейшие
> слухи о том, что в P4 нет аппаратной инструкции rotate.
> Хоть отдельный FAQ пиши на эту тему. ;-(( Есть она!
> ЕСТЬ!!!!!!!.
Дык, никто и не спорит, только сильно глюкавая она:
Page C-6 (356)
Table C-1 Streaming SIMD Extension 2 128-bit Integer Instructions (continued)
Instruction Latency1 Throughput Execution Unit
PSLLDQ xmm, imm8 4 2 MMX_SHFT
PSLLW/PSLLD/PSLLQ xmm, xmm/imm8 2 2 MMX_SHFT
PSRAW/PSRAD xmm, xmm/imm8 2 2 MMX_SHFT
PSRLDQ xmm, imm8 4 2 MMX_SHFT
PSRLW/PSRLD/PSRLQ xmm, 2 2 MMX_SHFT
Page C-15 (366)
Latency and Throughput with Memory Operands
Typically, instructions with a memory address as the source operand, add one more
µop to the reg, reg instructions type listed in Table C-1 through C-7. However, the
throughput in most cases remains the same because the load operation utilizes port 2
without affecting port 0 or port 1.
Many IA-32 instructions accept a memory address as either the source operand or as
the destination operand. The former is commonly referred to as a load operation, while
the latter a store operation.
The latency for IA-32 instructions that perform either a load or a store operation are
typically longer than the latency of corresponding register-to-register type of the IA-32
instructions. This is because load or store operations require access to the cache
hierarchy and, in some cases, the memory sub-system.
Intel Pentium 4 and Intel Xeon Processor Optimization IA-32 Instruction Latency and Throughput C
For the sake of simplicity, all data being requested is assumed to reside in the first level
data cache (cache hit). In general, IA-32 instructions with load operations that execute
in the integer ALU units require two more clock cycles than the corresponding
register-to-register flavor of the same instruction. Throughput of these instructions
with load operation remains the same with the register-to-register flavor of the
instructions.
Floating-point, MMX technology, Streaming SIMD Extensions and Streaming SIMD
Extension 2 instructions with load operations require 6 more clocks in latency than the
register-only version of the instructions, but throughput remains the same.
When store operations are on the critical path, their results can generally be forwarded
to a dependent load in as few as zero cycles. Thus, the latency to complete and store
isn't relevant here.
Если посмотреть мой первый пост, то там ссылочка на днет - про тоже и говорит - 4 такта ожидания дополнительно. А сам Интел советует заменять сдвиги влево на 1 на сложение. И еще - посмотри, что происходит, если операнд в памяти, а не на регистре - еще 6 тактов. Правда, тут надо считать, что быстрее Load/Shift.Save или Shift в памяти. Но тут для RC5 выбор практически предопределен.
Вопрос - а что будет быстрее после этого - использование команды сдвига или эммуляцие ее?
>
> повезет.
> Что же касается ПодЛинукса, то все равно GCC не обеспечит
> нужной производительности и надо будет писать на ASM'e. До
> сих пор я не видел у АМД толкового мануала о том, как
> что-либо оптимизировать под их процы.
Здесь я не про то, что нет оптимизированного компайлера, а про то, что ты сказал, что этого в принципе нет. А с отсутствием оптимизирующего компилятора я и не спорю. Но наличие хоть какого-то IDE (если gcc/gdb можно так назвать) дает возможность написать всю обслугу на С, а само ядро на ассемблере. На мой взгляд, текущий клиент для большинства платформ так и написан.
> Он есть, но в нем написаны вещи типа - делай такую
> макро-операцию так-то, проц знает эту последовательность
> машинных команд и выполнит ее быстро. А насчет
> универсальных приемов с упором на архитектуру - НЕТ.
> Если я делаю какие-то нестандартные операции, отличные от
> перевода целого числа в вещественное или подсчет количества
> ненулевых битов регистре, то я остаюсь в полном безвестном
> творческом пPолете.
А тут, увы, возразить нечего.
PS Я не слишком напрягаю народ, когда цитирую на английском языке в таком количестве? Если что, то пинайте, я обещаю исправиться.
|
| | | | | | | | |
По поводу Pentium 4 21.03.02 16:16
Автор: xelator Статус: Незарегистрированный пользователь
|
Ну ты даешь! ;-)) У меня челюсть до низу отвисла когда я увидел СКОЛЬКО
текста! Достаточно страницы указать! Есть у меня этот мануал, другим ссылку можно дать. Да и отвечать теперь неудобно.
>Из чего делаю вывод: MMX & SSE - FPU sharing, SSE2 -
> independent. Т.е. при работе с 128 битовыми целыми - все
> хорошо, а с 64 битовыми напряженка.
Непонятен вывод, т.к. непонятно откуда он.
MMX&SSE а также SSE2 разделяют блоки, которые выполняют
эти команды, но не регистры.
> При этом, насколько я
> понимаю, из описания и доки, то ССЕ2 с 64 не работает.
PSLLQ xmm, imm8 - сдвигает 2 64битных числа в xmm-регистре
Не используй верхнюю часть и все хорошо.
> Вывод делаю - всякие сдвиги - очень дорого.
Почему дорого?
PSRLW/PSRLD/PSRLQ xmm,xmm/imm8 2 2
Т.е. 2 такта. Но и сдвигают они 2 64битных числа.
Т.е. для свдига 2 64битных чисел на P4 нужно 2 такта.
ROL/ROR 4 1
А это старые-добрые x86 ротейты. Да 4 такта, но каждый такт
можно запускать новый ротейт.
Другой вариант - загнать 4 32битных числа в xmm0 и xmm1
один сдвинуть влево, другой вправо и сделать логическое и:
PSRLW/PSRLD/PSRLQ xmm,xmm/imm8 2 2
PSLLW/PSLLD/PSLLQ xmm, xmm/imm8 2 2
POR xmm, xmm 2 2
Итого, 2+2+2 = 6. Но мы сделали ротейт для 4 чисел, т.е. 1ротейт
стоит = 6/4=1.5 такта. Вот в чем смысл SIMD.
> Со сдвигом согласен, если его только не осуществлять через
> сложение умножение.
Не понял. А как еще его можно реализовать?
> А для других операций - тут пардон.
> Кроме того, целочисленные операции имеют свои коды FIADD,
> FIDIV, etc. Используя их не надо переводить процессор в
> режим округления специальной командой.
Надо. Дело в том, что целочисленные операции работают в режиме округления к нулю, или проще говоря отбрасывают неуместившиеся
в мантиссу биты. Если ты сложишь 2 числа, возможно переполнение,
и тогда результат должен быть в точности такой, как если бымы взяли его точный и отрезали нужное количество бит. Но по умолчанию стоит режим округления к ближайшему, поэтому FIADD в половине случаев будет давать
результат отличный на единицу.
> Это вещи известные, только вот операции умножения очень
> дорогие.
Насколько дорогие? Миф это. Тот же самый как и отсутствие аппаратного
ротейта в P4.
> Дык, никто и не спорит, только сильно глюкавая она:
> Если посмотреть мой первый пост, то там ссылочка на днет -
> про тоже и говорит - 4 такта ожидания дополнительно.
Через 4 такта результат ротейта готов. В нашем случае
все данные должны сидеть в кэше, поэтому пеналти маловероятны.
При оценке производителности их даже не учитывают.
> А сам
> Интел советует заменять сдвиги влево на 1 на сложение.
Сложение стоит 0.5тактов, сдвиг 4. Так было всегда - я имею
ввиду сложение лучше чем сдвиг. Вопрос на сколько. Когда
последователность сложений выгодней использовать чем сдвиг.
Посмотри исходники ядер - не найдешь там ни одного сдвига.
Только ротейт.
>И
> еще - посмотри, что происходит, если операнд в памяти, а не
> на регистре - еще 6 тактов.
Данные в кеше. Штрафов нет.
> PS Я не слишком напрягаю народ, когда цитирую на английском
> языке в таком количестве? Если что, то пинайте, я обещаю
> исправиться.
Пинаю!! ;-)) Дважды я не смог ответить потому, что непонятно было где
в тексте мысль, а где мусор.
|
| | | | | | | | | |
По поводу Pentium 4 22.03.02 06:44
Автор: Mishka Статус: Незарегистрированный пользователь
|
|
Я не знаю интересно ли это народу (и интересно ли это тебе), так что все можно на мыло перевести - кидай мне на evs@telerama.com.
|
| | | | | | | | | |
По поводу Pentium 4 22.03.02 06:20
Автор: Mishka Статус: Незарегистрированный пользователь
|
> Ну ты даешь! ;-)) У меня челюсть до низу отвисла когда я
> увидел СКОЛЬКО
> текста! Достаточно страницы указать! Есть у меня этот
> мануал, другим ссылку можно дать. Да и отвечать теперь
> неудобно.
Почесал ушибленное место и начал путь к исправлению.
>
>
> >Из чего делаю вывод: MMX & SSE - FPU sharing, SSE2 -
> > independent. Т.е. при работе с 128 битовыми целыми -
> все
> > хорошо, а с 64 битовыми напряженка.
> Непонятен вывод, т.к. непонятно откуда он.
> MMX&SSE а также SSE2 разделяют блоки, которые выполняют
> эти команды, но не регистры.
>
По доке выходит, что SSE MMX разделяют регистр состояния - смотри советы по оптимизации, страница 4-2.
> > При этом, насколько я
> > понимаю, из описания и доки, то ССЕ2 с 64 не работает.
> PSLLQ xmm, imm8 - сдвигает 2 64битных числа в xmm-регистре
> Не используй верхнюю часть и все хорошо.
>
> > Вывод делаю - всякие сдвиги - очень дорого.
> Почему дорого?
> PSRLW/PSRLD/PSRLQ xmm,xmm/imm8 2 2
> Т.е. 2 такта. Но и сдвигают они 2 64битных числа.
> Т.е. для свдига 2 64битных чисел на P4 нужно 2 такта.
>
> ROL/ROR 4 1
> А это старые-добрые x86 ротейты. Да 4 такта, но каждый такт
> можно запускать новый ротейт.
> Другой вариант - загнать 4 32битных числа в xmm0 и xmm1
> один сдвинуть влево, другой вправо и сделать логическое и:
> PSRLW/PSRLD/PSRLQ xmm,xmm/imm8 2 2
> PSLLW/PSLLD/PSLLQ xmm, xmm/imm8 2 2
> POR xmm, xmm 2 2
>
> Итого, 2+2+2 = 6. Но мы сделали ротейт для 4 чисел, т.е.
> 1ротейт
> стоит = 6/4=1.5 такта. Вот в чем смысл SIMD.
>
В чем смысл SIMD (а также SISD, MIMD MISD:-) я понимаю, а как насчет того как данные туда попадают? Это тоже надо бы учесть.
>
> > Со сдвигом согласен, если его только не осуществлять
> через
> > сложение умножение.
> Не понял. А как еще его можно реализовать?
>
Если говорить на уровне команд - то да, а на уровне микрокода - просто аппаратным сдвигом (если есть аппаратура).
> > А для других операций - тут пардон.
> > Кроме того, целочисленные операции имеют свои коды
> FIADD,
> > FIDIV, etc. Используя их не надо переводить процессор
> в
> > режим округления специальной командой.
> Надо. Дело в том, что целочисленные операции работают в
> режиме округления к нулю, или проще говоря отбрасывают
> неуместившиеся
> в мантиссу биты. Если ты сложишь 2 числа, возможно
> переполнение,
> и тогда результат должен быть в точности такой, как если
> бымы взяли его точный и отрезали нужное количество бит. Но
> по умолчанию стоит режим округления к ближайшему, поэтому
> FIADD в половине случаев будет давать
> результат отличный на единицу.
>
Тут меня гложут сильные сомнения. Я, конечно, от жизни немного поотстал - бросил возиться с FPU когда вышел 486. Но для 386/387 я писал RTL для компайлеров. Никогда такого не встречал. Может набросаешь мне код, а я проверю его на разных CPU? Чтобы он давал результат отличный на 1.
> > Это вещи известные, только вот операции умножения
> очень
> > дорогие.
> Насколько дорогие? Миф это. Тот же самый как и отсутствие
> аппаратного
> ротейта в P4.
>
ADD/SUB r,r 0.5 0.5
IMUL r32 14 3
IDIV r32 56-70 23
Это не дорого?
Теперь для MMX:
PADDQ/PSUBQ mm, mm 2 1 MMX_ALU
PADDQ/ PSUBQ3 xmm, xmm 6 2 MMX_ALU
PMULHUW/PMULHW/PMULLW3 xmm, xmm 8 2 FP_MUL
PMULUDQ mm, mm 8 2 FP_MUL
Деление SIMD не нашел:-)
Разница и здесь есть.
> > Дык, никто и не спорит, только сильно глюкавая она:
> > Если посмотреть мой первый пост, то там ссылочка на
> днет -
> > про тоже и говорит - 4 такта ожидания дополнительно.
> Через 4 такта результат ротейта готов. В нашем случае
> все данные должны сидеть в кэше, поэтому пеналти
> маловероятны.
> При оценке производителности их даже не учитывают.
>
Я, конечно перечитаю доки еще раз, но у меня сложилось впечатление, что латенси и пенальти вещи разные.
> > А сам
> > Интел советует заменять сдвиги влево на 1 на сложение.
> Сложение стоит 0.5тактов, сдвиг 4. Так было всегда - я имею
Да не всегда - сдвин на 1 был обычно быстрым - таким же как и сложение.
> ввиду сложение лучше чем сдвиг. Вопрос на сколько. Когда
> последователность сложений выгодней использовать чем сдвиг.
> Посмотри исходники ядер - не найдешь там ни одного сдвига.
> Только ротейт.
>
Я не разбирал RC5 досконально, но это может быть вызвано самим алгоримом, а не преимуществами команды. И еще
RCL/RCR reg, 18 4 1
RCL/RCR reg, 18 4 1
ROL/ROR 4 1
SAHF 0.5 0.5 ALU
SAL/SAR/SHL/SHR 4 1
Т.е. я не вижу разницы между сдвигами и вращениями для обычных команд.
> >И
> > еще - посмотри, что происходит, если операнд в памяти,
> а не
> > на регистре - еще 6 тактов.
> Данные в кеше. Штрафов нет.
>
Здесь полностью согласен с тем, что кэш поможет, но есть еще и пенальти за сложные адресации памяти. И здесь надо учитывать не столько саму сложность адресации операнда, а те ложные зависимости между командами, про которые толкует Интел.
> Пинаю!! ;-)) Дважды я не смог ответить потому, что
> непонятно было где
> в тексте мысль, а где мусор.
Ага, по поводу языка возражений нет:-) А про количество - смотри выше.
|
| | | | | | | |
По поводу Pentium 4 20.03.02 18:09
Автор: StR <Стас> Статус: Elderman
|
> И по чей-то злостной воле упорно блуждают абсурднейшие
> слухи о том, что в P4 нет аппаратной инструкции rotate.
> Хоть отдельный FAQ пиши на эту тему. ;-(( Есть она!
> ЕСТЬ!!!!!!!.
Так будет оно (рц5) нормально работать на П4 или нет???
|
|
По поводу Pentium 4 12.03.02 18:24
Автор: StR <Стас> Статус: Elderman
|
> Подскажите, как обстоит дело у этого процессора с
> производительностью под клиентом ? Стоит ли вообще ставить
> коровок на Р4-1500 ?
Ставить стоит на все...
А производительность п4-1500 на последней версии клиента соответствует производительности п3-750... на более старых версиях еще немного ниже...
хочется верить, что до конца проекта днет сделает ядро под п4, но... судя по состоянию дел, никто и заморачиваться не будет... :(((
|
| |
У меня p4 а толку нет. 13.03.02 10:48
Автор: GorynYch Статус: Member
Отредактировано 13.03.02 10:57 Количество правок: 1
|
> > Подскажите, как обстоит дело у этого процессора с
> > производительностью под клиентом ? Стоит ли вообще
> ставить
> > коровок на Р4-1500 ?
> Ставить стоит на все...
У меня p4-1,4Ггерц 256DDR памяти, комп включен постоянно(круглосуточно), процессов на компе, стандартных виндовых и dnetc, нету... Казалось-бы все прекрастно. Тока вот не очень, посмотрите мою статистику на dnet.
Так что dnet стоит у меня только для приличия.
RC5-64 / Participant History for GorynYch
|
| | |
PIV1400 = PIII683!!!. 18.03.02 13:04
Автор: Kobazev Статус: Незарегистрированный пользователь
Отредактировано 18.03.02 15:12 Количество правок: 1
|
> > > Подскажите, как обстоит дело у этого процессора с
> > > производительностью под клиентом ? Стоит ли вообще ставить коровок на Р4-1500 ?
Описание моего проца смотри ниже. А считает он со скоростью примерно 1,81 Mkeys/sec. :(((
При этом в памяти ничего кроме FireWall, NortonAntivirus и Norton Activ Monitor нет.
Насчёт того, ставить или нет - конечно устанавливай! Тем более что выхода у тебя, как я понимаю нет. Не будешь же ТЫ менять его на PIII. Хотя мой двухпроцессорный PIII 2x750MHz c RAM-овской памятью выдаёт 4 Mkes/sec. И бьёт Р4-1500 в 2 раза.
Если у тебя Win2k+1 или XP: Отключи dnet. Запусти "Диспетчер задач" (Ctrl-Shift-Esc). Запусти свой sreen saver "Matrix". Подожди некоторое время и выруби его. В Диспетчере на вкладке быстродействие посмотри какая была загрузка твоего проца.
И выбирай - или стильная заставка, или производительные надои. Я, в своё время, выбрал второе.
Сходи на distributed.net > Client Speeds. Посмотри сколько должен выдавать твой проц.
************************************************************************
I N T E L (R) A C T I V E M O N I T O R
System Information Report
18.03.2002 12:28:45
************************************************************************
General Information
************************************************************************
Product name Genuine Intel(R) Pentium(R) 4 processor based system
Board model Genuine Intel(R) D850GB system board
OS version Windows* 2000 version 5.0 build 2195
OS memory 261 424 KB RAM
************************************************************************
Processor
************************************************************************
Processor Genuine Intel(R) Pentium(R) 4 processor
Processor speed 1,40 GHz
Bus speed 400 MHz
L1 cache Data Cache 8KB, Execution Trace Cache 12K Micro-ops
L2 cache Advanced Transfer Cache 256KB
Form factor ZIF Socket
Stepping 10
************************************************************************
System
************************************************************************
Physical memory 256 MB RAM
Memory speed PC800
Memory type Other, RAMBUS
Form factor RIMM
BIOS date 07/18/2001
BIOS size 512 KB
BIOS version P14 (GB85010A.86A.0063.P14.0107182015)
************************************************************************
|
| | |
Ну ни фига себе! Надо разобраться 13.03.02 11:43
Автор: Kost без куки Статус: Незарегистрированный пользователь
|
Не помню точно, но блоков 600 в день он давать должен.
Какая ОС, какой скринсейвер ;-)?
|
| | | |
Ну ни фига себе! Надо разобраться 13.03.02 11:48
Автор: GorynYch Статус: Member
|
> Не помню точно, но блоков 600 в день он давать должен.
> Какая ОС, какой скринсейвер ;-)?
WinMe, обычный The Matrix
|
| | | | |
Ну ни фига себе! Надо разобраться 13.03.02 12:36
Автор: Mosich <Mosichev Valentine> Статус: Member
|
> WinMe, обычный The Matrix
а может поставить фирменный днетовский?
|
| | | | | |
Ну ни фига себе! Надо разобраться 13.03.02 12:51
Автор: GorynYch Статус: Member
|
> > WinMe, обычный The Matrix
> а может поставить фирменный днетовский?
Ради экспиремента его вообще можно отключить, что я слелал.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
