Добрый день.

Есть много-много данных, они хранятся в массивах и структурах. Тип элементов(этих массивов и структур) можно выбрать:
1) как WORD (2 байта)
2) как INTEGER (4байта)

т.е. второй вариант займет в два раза больше памяти. Но, вопрос в другом:
Какой вариант будет обрабатываться процессором БЫСТРЕЕ?

Под обработкой подразумеваются любые операции над данными (сложение, вычисление, сравнение, хранение ссылок для адресов памяти)

Если зависит от среды, то:
— Компилятор — 32 bit
— Процессор — 64 bit (32 bit)
— ОС Windows — 64 bit

Здравствуйте, Tihomir.I, Вы писали:

TI>т.е. второй вариант займет в два раза больше памяти. Но, вопрос в другом:
TI>Какой вариант будет обрабатываться процессором БЫСТРЕЕ?

Обычно в два раза больше памяти обрабатывается примерно в два раза дольше, но результат очень зависит от конкретного алгоритма. Почему бы тебе не замерить самому?

Здравствуйте, Don Reba, Вы писали:

DR>Обычно в два раза больше памяти обрабатывается примерно в два раза дольше, но результат очень зависит от конкретного алгоритма. Почему бы тебе не замерить самому?

Вы думаете, что 32-битный процессор будет складывать числа(WORD) в два раза быстрее, чем числа(INTEGER)?

Протестировать можно, но нужно понять причину — Т.е. как скорость зависит от разрядоности данных?

TI>Есть много-много данных, они хранятся в массивах и структурах. Тип элементов(этих массивов и структур) можно выбрать:
TI> 1) как WORD (2 байта)
TI> 2) как INTEGER (4байта)
TI>т.е. второй вариант займет в два раза больше памяти. Но, вопрос в другом:
TI>Какой вариант будет обрабатываться процессором БЫСТРЕЕ?
TI>Под обработкой подразумеваются любые операции над данными (сложение, вычисление, сравнение, хранение ссылок для адресов памяти)
Арифметические операции — пофигу.
Ибо все одно — на регистрах.
Вопрос в скорости доступа к памяти и кэщах.
У меня матрицы 25000*25000 элементов.
Скорость обработки по горизонтали существенно выше скорости обработки по вертикали — из-за кэша.
Строка — вся целиком в кэш помещается, а столбец — не весь (ибо в памяти массив по строкам) — смена кэша сильно замедляет.
Вплоть до того, что быстрее оказалось сначала переписать столбец в строку, а потом эту строку обрабатывать.
Кстати, элементы у меня байтовые.

Здравствуйте, LaptevVV, Вы писали:

LVV>Арифметические операции — пофигу.
LVV>Ибо все одно — на регистрах.
LVV>Вопрос в скорости доступа к памяти и кэщах.
LVV>У меня матрицы 25000*25000 элементов.
LVV>Скорость обработки по горизонтали существенно выше скорости обработки по вертикали — из-за кэша.
LVV>Строка — вся целиком в кэш помещается, а столбец — не весь (ибо в памяти массив по строкам) — смена кэша сильно замедляет.
LVV>Вплоть до того, что быстрее оказалось сначала переписать столбец в строку, а потом эту строку обрабатывать.
LVV>Кстати, элементы у меня байтовые.

Т.е. Вы храните в байтах только для экономии места, чтоб поместиться в кэше?
Допустим, что кеша очень много. Будет ли выигрыш в скорости, если перевести данные из байтов в INTEGER (32бит), т.е. в разрядность регистров?

TI>Т.е. Вы храните в байтах только для экономии места, чтоб поместиться в кэше?
Нет. 25000*25000 — это МАЛЕНЬКАЯ матрица. Нужно больше.
Но в 32-битной архитектуре без дополнительных ухищрений в память овер 40000*40000 не влезает.
Перешли на 64-битную (машину купили... ) и уже не экономим на памяти.
TI>Допустим, что кеша очень много. Будет ли выигрыш в скорости, если перевести данные из байтов в INTEGER (32бит), т.е. в разрядность регистров?
1. Кэша очень много не бывает — он многоуровневый.
2. В арифметике — не будет. Будет влиять опять же на скорость доступа к памяти — за счет выравнивания по более крупным границам.
Арифметика один фиг на регистрах...

Здравствуйте, LaptevVV, Вы писали:

LVV>Будет влиять опять же на скорость доступа к памяти — за счет выравнивания по более крупным границам.
Не совсем понял, про "крупные" границы.
Например, где будет быстрее доступ:
— к данным типа Byte (1байт)
— к данным типа Word (2байта)
— к данным типа Integer (4байта)

?

LVV>>Будет влиять опять же на скорость доступа к памяти — за счет выравнивания по более крупным границам.
TI>Не совсем понял, про "крупные" границы.
TI>Например, где будет быстрее доступ:
TI> — к данным типа Byte (1байт)
TI> — к данным типа Word (2байта)
TI> — к данным типа Integer (4байта)
Ну, поскольку в кэш попадает сразу несколько мегабайт, то пофигу.
Но о выравнивании данных вот: http://sasm.narod.ru/docs/pm/pm_app/app_1/ac.htm
Но это в том случае если:

Установлен флаг AM в CR0.
Установлен флаг AC в EFLAGS.

Устанавливает ли эти биты компилятор — я не знаю.
По не выровненным границам раньше было медленнее — раза в два (386 процессор).
Как сейчас — не знаю.
Так что не парься и пробуй.
Я вот тоже не знал, что проблема смены кэша настолько мне замедлит работу.
Обнаружил — принял меры.

Здравствуйте, LaptevVV, Вы писали:

LVV>Арифметические операции — пофигу.
LVV>Ибо все одно — на регистрах.

(мне важно разобраться, если ошибаюсь, пожалуйста, поправьте)
Чтобы BYTE попал в 32-битный регистр, будет ли он конвертироваться (не знаю как, типа добавляется 24 нулевых бита), а данные INTEGER (уже процессорной разрядности) не требуют конвертации.
Т.е. верно ли утверждение, что данные в INTEGER будут быстрее обрабатываться?

LVV>>Арифметические операции — пофигу.
LVV>>Ибо все одно — на регистрах.
TI>(мне важно разобраться, если ошибаюсь, пожалуйста, поправьте)
TI>Чтобы BYTE попал в 32-битный регистр, будет ли он конвертироваться (не знаю как, типа добавляется 24 нулевых бита), а данные INTEGER (уже процессорной разрядности) не требуют конвертации.
TI>Т.е. верно ли утверждение, что данные в INTEGER будут быстрее обрабатываться?
Нет. В Интеле есть команды для работы с любыми длинами.
Можно в регистр ан прочитать байт, а можно — в регистр ах прочитать short, а можно в eax прочитать integer.
Любое действие делается 1-й командой.
точно также одной командой можно сложить и байты и short и integer.
Справедливости ради надо сказать, что целое деление требует подготовки двух регистров, ибо вычисляется сразу и частное, и остаток.
Но есть команды, которые позволяют сразу группу данных складывать — до 128 байтов, 64 shortов или 32 integerов.
А скорости отдельных команд в современных интелах таковы, что программисту париться об этом нет никакой необходимости.
К тому же оптимизация в компиляторах сейчас хороша...
Так что есть смысл сначала написать и посмотреть скорость работы.
Только если не устраивает — надо предпринимать какие-то меры.

Здравствуйте, Tihomir.I, Вы писали:

LVV>>Будет влиять опять же на скорость доступа к памяти — за счет выравнивания по более крупным границам.
TI>Не совсем понял, про "крупные" границы.
TI>Например, где будет быстрее доступ:
TI> — к данным типа Byte (1байт)
TI> — к данным типа Word (2байта)
TI> — к данным типа Integer (4байта)
TI>?

Для одиночной операции — практически одинаково. Оперативная память на x86 уже лет 15 как читается и пишется порциями по 64 байта. Цена на чтение из кэша L1 — условно считаем 2 такта, L2 — 2+6, L3 — 2+6+24. (Слегка отличается по версиям процессоров.) Цена на чтение строки, не лежащей ни в одном кэше, измеряется цифрами вроде 240 тактов (2 на промах L1, 6 на промах L2, 24 на промах L3 и 210 на чтение RAM при смене строки). В зависимости от тактовой процессора и скорости памяти, эти цифры будут меняться до ~2 в обе стороны (например, разогнав процессор, но поставив самую медленную память, можно получить и 400 тактов), но суть ситуации не поменяется. После этого, читаете вы 1, 2 или 4 байта в одной строке, без разницы — это всё равно одно чтение.

Невыровненность при чтении более 1 байта добавляет цену — если нужно читать не 1, а 2 строки, то время удваивается. Это именно столько стоит при случайном чтении. При последовательном этой цены фактически нет — чтение последовательно, например, миллиона 4-байтовых значений стоит столько же (62500 раз по эти ~240 тактов) даст, если они не выровнены, ровно на 1 чтение строки больше, 0.0016%, и будет эта задержка не в начале чтения, а на 1 чтение из 16 посредине. При чтении из произвольных мест цена невыровненности сильно выше.
Аналогичные зависимости и для записи (записать 2 байта на границе строк значит прочитать 2 строки, модифицировать и записать их), произвольная запись, можно условно считать, в 2 и заметно более раза дороже последовательной (при последовательной модифицируются уже кэшированные строки, для произвольной их ещё надо прочитать), невыровненная последовательная — почти столько же, сколько выровненная, невыровненная случайная — ещё в 2 раза дороже, чем выровненная случайная. Если весь набор данных влезет в L3, и не будет крупного отвлечения на другие задачи, то тут будет и 10-кратное ускорение (если уже лежит в L3) по сравнению с общением с RAM, но и в этом случае невыровненность при произвольных чтении/записи замедляет в 2 раза от выровненного варианта и почти не влияет при последовательных чтении/записи.

А дальше в вашем варианте начинает влиять собственно объём потока чтения и записи. Банально, миллион значений по 1 байту это мегабайт, по 4 байта это 4 мегабайта, и если кэш заметно меньше, то основные затраты по времени будут на общение с RAM, и во втором случае они будут в примерно 4 раза больше. Но и если в L3 влезет (в L2 — уже не верю) — то цифры будут в 10 раз меньше, но отношение будет тем же — N байт обрабатывается в 4 раза быстрее, чем 4*N байт.

По арифметике без разницы, если компилятор не включит SSE, а он может.
По доступу, при большом обьеме первый вариант будет быстрее.
А вообще идиотский вопрос, собрать оба варианта в релизе и посмотреть на реальных данных какой быстрее, с синтетикой возиться не надо, все равно узкое место уже угадать не получиться, все стало очень запутанно.
Здравствуйте, Tihomir.I, Вы писали:
TI>Добрый день.

TI>Есть много-много данных, они хранятся в массивах и структурах. Тип элементов(этих массивов и структур) можно выбрать:
TI> 1) как WORD (2 байта)
TI> 2) как INTEGER (4байта)

TI>т.е. второй вариант займет в два раза больше памяти. Но, вопрос в другом:
TI>Какой вариант будет обрабатываться процессором БЫСТРЕЕ?

TI>Под обработкой подразумеваются любые операции над данными (сложение, вычисление, сравнение, хранение ссылок для адресов памяти)

TI>Если зависит от среды, то:
TI> — Компилятор — 32 bit
TI> — Процессор — 64 bit (32 bit)
TI> — ОС Windows — 64 bit

Здравствуйте, LaptevVV, Вы писали:

LVV>А скорости отдельных команд в современных интелах таковы, что программисту париться об этом нет никакой необходимости.
LVV>К тому же оптимизация в компиляторах сейчас хороша...
...вот, мне-"программисту" приходится париться. Работаю над сложной задачей, с большими объемами вычислений. На оптимизацию компилятора даже не надеюсь (другой порядок сложности). Ищу архитектурное решение, например, использование кэша и выравнивание данных при адресации.

Здравствуйте, Tihomir.I, Вы писали:

TI>Здравствуйте, Don Reba, Вы писали:
DR>>Обычно в два раза больше памяти обрабатывается примерно в два раза дольше, но результат очень зависит от конкретного алгоритма. Почему бы тебе не замерить самому?
TI>Вы думаете, что 32-битный процессор будет складывать числа(WORD) в два раза быстрее, чем числа(INTEGER)?
Это эквивалентные по скорости операции.
TI>Протестировать можно, но нужно понять причину — Т.е. как скорость зависит от разрядоности данных?
Поскольку складывает процессоры числа быстрей, чем читает данные из памяти, то от скорости доступа к данным. Прочитать из памяти 2 гигабайта это в два раза быстрей, чем прочитать 4 гигабайта.

А вообще если ну прям очень хочется разобраться, то есть intel architectures optimization manual где всё это расписано + аппаратные счетчики событий. Прогоняешь тест и видишь, что для "INTEGER" число инструкций на такт упало, а пенальти от кеша и памяти подскочил.

Здравствуйте, Tihomir.I, Вы писали:

TI>Здравствуйте, LaptevVV, Вы писали:

LVV>>А скорости отдельных команд в современных интелах таковы, что программисту париться об этом нет никакой необходимости.
LVV>>К тому же оптимизация в компиляторах сейчас хороша...
TI>...вот, мне-"программисту" приходится париться. Работаю над сложной задачей, с большими объемами вычислений. На оптимизацию компилятора даже не надеюсь (другой порядок сложности). Ищу архитектурное решение, например, использование кэша и выравнивание данных при адресации.

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

Но мне кажется вы как то зря и рано запарились.
Что же касается архитектуры, думаю актуальнее прежде всего думать о многопоточности вычислений.
Если уж совсем предполагается жесткая числодробилка, то возможно стоит еще немного запарится и просмотреть в сторону вычислений на GPU и соответственно Open CL.

LVV>>А скорости отдельных команд в современных интелах таковы, что программисту париться об этом нет никакой необходимости.
LVV>>К тому же оптимизация в компиляторах сейчас хороша...
TI>...вот, мне-"программисту" приходится париться. Работаю над сложной задачей, с большими объемами вычислений. На оптимизацию компилятора даже не надеюсь (другой порядок сложности). Ищу архитектурное решение, например, использование кэша и выравнивание данных при адресации.
Ну, тогда надо обратить внимание на параллельные алгоритмы (не на скорость выполнения команд).
В моих задачах это уже встало в полный рост — мощностей компов не хватает при последовательном алгоритме решения.
Вот про оптимизацию ты не прав.
Сейчас компилеры очень хорошо оптимизируют.
ОЧЕНЬ ХОРОШО.
Я использую на полную катушку.
Но параллельность ускоряет просто в разы.

Здравствуйте, LaptevVV, Вы писали:

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

Что подразумевается под параллельными алгоритмами (это выносить вычисления "за пределы компа", или использование нескольких ядер своего процессора)?

LVV>>Ну, тогда надо обратить внимание на параллельные алгоритмы (не на скорость выполнения команд).
LVV>>В моих задачах это уже встало в полный рост — мощностей компов не хватает при последовательном алгоритме решения.
TI>Что подразумевается под параллельными алгоритмами (это выносить вычисления "за пределы компа", или использование нескольких ядер своего процессора)?
Если говорить об Интеле, то это — многоядерное и GPU.
Несколько разные принципы, но и то, и это — параллельность.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Tihomir.I, Вы писали:

LVV>>>Будет влиять опять же на скорость доступа к памяти — за счет выравнивания по более крупным границам.
TI>>Не совсем понял, про "крупные" границы.
TI>>Например, где будет быстрее доступ:
TI>> — к данным типа Byte (1байт)
TI>> — к данным типа Word (2байта)
TI>> — к данным типа Integer (4байта)
TI>>?

N>Для одиночной операции — практически одинаково. Оперативная память на x86 уже лет 15 как читается и пишется порциями по 64 байта.

Это имеется ввиду block offset? Т.е. туда 16 int'ов можно загнать?

Здравствуйте, Tihomir.I, Вы писали:

TI>Добрый день.

TI>Есть много-много данных, они хранятся в массивах и структурах. Тип элементов(этих массивов и структур) можно выбрать:
TI> 1) как WORD (2 байта)
TI> 2) как INTEGER (4байта)

TI>т.е. второй вариант займет в два раза больше памяти. Но, вопрос в другом:
TI>Какой вариант будет обрабатываться процессором БЫСТРЕЕ?

Во-первых, как в комментариях заметили, написали-протестировали. А во-вторых, думается, что время будет приблизительно сопоставимо, может word'ы на десятки или сотни наносекунд будут шустрее. Это надо смотреть. А вот где точно будет заметно падении производительности -- так это работа float/double типами данных. На порядки все будет медленнее.

Про локальность кэшей советую почитать вики -- https://en.wikipedia.org/wiki/Locality_of_reference

Здравствуйте, Sharov, Вы писали:

N>>Для одиночной операции — практически одинаково. Оперативная память на x86 уже лет 15 как читается и пишется порциями по 64 байта.
S>Это имеется ввиду block offset?

Я не знаю, что такое block offset в данном случае. Это 64 байта, выровненные на границу адреса, кратного 64.

S> Т.е. туда 16 int'ов можно загнать?

Да.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Sharov, Вы писали:

N>>>Для одиночной операции — практически одинаково. Оперативная память на x86 уже лет 15 как читается и пишется порциями по 64 байта.
S>>Это имеется ввиду block offset?

N>Я не знаю, что такое block offset в данном случае. Это 64 байта, выровненные на границу адреса, кратного 64.

В сколько слов может помещаться в строке(записи) кэша.

Здравствуйте, Sharov, Вы писали:

S> А вот где точно будет заметно падении производительности -- так это работа float/double типами данных. На порядки все будет медленнее.

Это на каких допотопных процессорах так?

В интеловском "Intel® 64 and IA-32 Architectures Optimization Reference Manual" таблицы затрат на операции (начиная с Core и более современных)
* ADDSD, ADDPD — L=3, 1/T=0.8
* MULSD, MULPD — L=5, 1/T=0.5
* DIVSD, DIVPD — L<24, 1/T=12
* MUL, IMUL — L<=14 (ранние Core), L<=10 (*Bridge и после)
* DIV (самый тяжёлый случай) — L<=90

то есть плавающая точка быстрее.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, netch80, Вы писали:

N>>Здравствуйте, Sharov, Вы писали:

N>>>>Для одиночной операции — практически одинаково. Оперативная память на x86 уже лет 15 как читается и пишется порциями по 64 байта.
S>>>Это имеется ввиду block offset?

N>>Я не знаю, что такое block offset в данном случае. Это 64 байта, выровненные на границу адреса, кратного 64.

S>В сколько слов может помещаться в строке(записи) кэша.

Вы рядом ссылаетесь на locality of reference, но задаёте вопросы, на которые вообще непонятно, как отвечать, и зачем, если Вы вообще представляете себе, что такое кэш. Я не понимаю, это троллинг, или как?

Если хотите конструктивного ответа, начните с определения, что такое "слово". Для меня это обычно 4 байта, но если Вы работаете в Windows или других территориях тяжкого наследия x86 legacy, то это 2 байта, и ответ будет отличаться в 2 раза.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Sharov, Вы писали:

S>> А вот где точно будет заметно падении производительности -- так это работа float/double типами данных. На порядки все будет медленнее.

N>Это на каких допотопных процессорах так?

N>В интеловском "Intel® 64 and IA-32 Architectures Optimization Reference Manual" таблицы затрат на операции (начиная с Core и более современных)
N>* ADDSD, ADDPD — L=3, 1/T=0.8
N>* MULSD, MULPD — L=5, 1/T=0.5
N>* DIVSD, DIVPD — L<24, 1/T=12
N>* MUL, IMUL — L<=14 (ранние Core), L<=10 (*Bridge и после)
N>* DIV (самый тяжёлый случай) — L<=90

N>то есть плавающая точка быстрее.

Быстрее чем что? Одного плавающего деления достаточно, чтобы все убить.

Здравствуйте, Sharov, Вы писали:

N>>то есть плавающая точка быстрее.

S>Быстрее чем что?

Чем такие же операции в целых числах.

S> Одного плавающего деления достаточно, чтобы все убить.

Точно так же одного целочисленного деления достаточно, чтобы "всё убить" ещё в 2-3 раза больше.

Здравствуйте, netch80, Вы писали:

S>>В сколько слов может помещаться в строке(записи) кэша.

N>Вы рядом ссылаетесь на locality of reference, но задаёте вопросы, на которые вообще непонятно, как отвечать, и зачем, если Вы вообще представляете себе, что такое кэш. Я не понимаю, это троллинг, или как?

Никакого троллинга, я не понял вот это Ваше утверждение:

Оперативная память на x86 уже лет 15 как читается и пишется порциями по 64 байта.

Почему 64 байта? Откуда взялась эта цифра? Я так понял из-за размера блока данных в кэше, т.е. он может хранить 16*4 байт.

Здравствуйте, Sharov, Вы писали:

S>>>В сколько слов может помещаться в строке(записи) кэша.

N>>Вы рядом ссылаетесь на locality of reference, но задаёте вопросы, на которые вообще непонятно, как отвечать, и зачем, если Вы вообще представляете себе, что такое кэш. Я не понимаю, это троллинг, или как?

S>Никакого троллинга, я не понял вот это Ваше утверждение:
S>

S> Оперативная память на x86 уже лет 15 как читается и пишется порциями по 64 байта.

S>Почему 64 байта? Откуда взялась эта цифра? Я так понял из-за размера блока данных в кэше,

Да, она ровно это и означает. (Уточнение: я не рассматриваю uncached вариант для оперативки, его обычно не включают)
Ваш "блок данных в кэше" официально называется строкой кэша (cache line).

S> т.е. он может хранить 16*4 байт.

Он может хранить 64 байта. Интерпретация этого как 16*4, 8*8 или как-то иначе — произвольна и не имеет отношения к данному вопросу.

Здравствуйте, netch80, Вы писали:


N>Да, она ровно это и означает. (Уточнение: я не рассматриваю uncached вариант для оперативки, его обычно не включают)
N>Ваш "блок данных в кэше" официально называется строкой кэша (cache line).

Может напутал с терминологией, мне казалось cache line -- тег+индекс+данные. Ладно, не суть.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, netch80, Вы писали:


N>>Да, она ровно это и означает. (Уточнение: я не рассматриваю uncached вариант для оперативки, его обычно не включают)
N>>Ваш "блок данных в кэше" официально называется строкой кэша (cache line).

S>Может напутал с терминологией, мне казалось cache line -- тег+индекс+данные.

Не, ну понятно, что внутри там хранится множество интересного типа полного адреса, откуда взята эта строка, состояние изменённости и отношение к соседним кэшам (modified/exclusive/shared/invalid/etc.), внутренний счётчик "использования" для алгоритма LRU и прочие вкусности и тонкости. Но в обсуждении о размерах и границах их обычно опускают.

S> Ладно, не суть.

Угу.

Здравствуйте, Tihomir.I, Вы писали:
TI>т.е. второй вариант займет в два раза больше памяти. Но, вопрос в другом:
TI>Какой вариант будет обрабатываться процессором БЫСТРЕЕ?
когда начинаешь разбираться с этим подробно, то оказывается, что самый медленный элемент компьютера, исключая сеть, конечно, это оперативная память. на такая медленная, что нее можно анекдоты сочинять

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

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

если принимаешь ставки, то ставлю на шорты

Здравствуйте, Sharov, Вы писали:

S>Быстрее чем что? Одного плавающего деления достаточно, чтобы все убить.

целочисленного, ты хотел сказать? ибо плавающее выполняется примерно за такт на число

Здравствуйте, BulatZiganshin, Вы писали:

BZ>целочисленного, ты хотел сказать? ибо плавающее выполняется примерно за такт на число

Да ну? Это если только компилятор заранее посчитал обратное, но для этого ещё и флаги типа -ffast-math надо включать. А при делении на новое число (т.е. собственно при инструкции даблового деления) я такого не замечал, примерно одинаковая задержка в районе полусотни тактов.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Sharov, Вы писали:

S>>Быстрее чем что? Одного плавающего деления достаточно, чтобы все убить.

BZ>целочисленного, ты хотел сказать? ибо плавающее выполняется примерно за такт на число

С трудом вериться, что деление float чисел можно выполнить за один такт. Но с другой стороны для работы с ними есть отдельный сопроцессор, который можно разогнать...

Здравствуйте, BulatZiganshin, Вы писали:

S>>Быстрее чем что? Одного плавающего деления достаточно, чтобы все убить.

BZ>целочисленного, ты хотел сказать? ибо плавающее выполняется примерно за такт на число

Intel пишет — latency=6 тактов, inv_throughput=5 (для FPU, одинаково для режимов single и double; для extended клетка пуста).

Я им как-то больше верю.

Здравствуйте, netch80, Вы писали:

BZ>>целочисленного, ты хотел сказать? ибо плавающее выполняется примерно за такт на число

N>Intel пишет — latency=6 тактов, inv_throughput=5 (для FPU, одинаково для режимов single и double; для extended клетка пуста).

N>Я им как-то больше верю.

avx обрабатывает 4/8 чисел за операцию

Здравствуйте, cures, Вы писали:
C>Да ну? Это если только компилятор заранее посчитал обратное, но для этого ещё и флаги типа -ffast-math надо включать. А при делении на новое число (т.е. собственно при инструкции даблового деления) я такого не замечал, примерно одинаковая задержка в районе полусотни тактов.
пока он делит он может еще кое-что делать, может быть даже сразу новое делить начинать, из-за этого даже если бы он, например, делил 50 тактов, но каждый новый такт начинал делить новое число, то при длинной последовательности мы бы имели в среднем такт на деление. видеокарты, соб-но, так и работают — у них в среднем это деление может занимать тактов 200, одна только операция с памятью тактов 600, но зато мы можем начинать тысячи новых операций чуть ли не каждый такт и в итоге получать результатов с большой задержкое, зато сразу большими пачками и в среднем во много раз быстрее, чем на cpu

Здравствуйте, LaptevVV, Вы писали:

LVV>>>А скорости отдельных команд в современных интелах таковы, что программисту париться об этом нет никакой необходимости.
LVV>>>К тому же оптимизация в компиляторах сейчас хороша...
TI>>...вот, мне-"программисту" приходится париться. Работаю над сложной задачей, с большими объемами вычислений. На оптимизацию компилятора даже не надеюсь (другой порядок сложности). Ищу архитектурное решение, например, использование кэша и выравнивание данных при адресации.
LVV>Ну, тогда надо обратить внимание на параллельные алгоритмы (не на скорость выполнения команд).
LVV>В моих задачах это уже встало в полный рост — мощностей компов не хватает при последовательном алгоритме решения.
LVV>Вот про оптимизацию ты не прав.
LVV>Сейчас компилеры очень хорошо оптимизируют.
LVV>ОЧЕНЬ ХОРОШО.
LVV>Я использую на полную катушку.
LVV>Но параллельность ускоряет просто в разы.

Советую посмотреть в сторону CUDA.

http://developer.download.nvidia.com/books/cuda-by-example/cuda-by-example-sample.pdf

На задачах связанных с обработкой массивов данных, особенно изображений и других сигналов частенько рвёт любой CPU как тузик грелку.

Но там нужно хорошо понимать особенности работы конкретного GPU чтобы получить по настоящему высокое быстродействие.

Я, к примеру, реализовывал 2D блюр на CUDA и различными манипуляциями с shared memory получил прирост быстродействия в 10 раз.