Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами, возникает вопрос — как лучше с этими числами работать (с точки зрения повышения производительности) как _int64 или double? Компилятор VC-6, платформа — x86 WinXP.

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

A>Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами, возникает вопрос — как лучше с этими числами работать (с точки зрения повышения производительности) как _int64 или double? Компилятор VC-6, платформа — x86 WinXP.

1. Выкиньте компилятор
2. Premature optimization is the root of all evil
3. Intel любят double, AMD любят int (могу, впрочем, и ошибаться)
4. Что-то мешает сделать typedef и потом устроить бенчмарк?

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

A>Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами, возникает вопрос — как лучше с этими числами работать (с точки зрения повышения производительности) как _int64 или double? Компилятор VC-6, платформа — x86 WinXP.

А в чём чила даны изначально?

Вообще-то, насколько я понимаю, double на современных процах лучше. Но возможны варианты.
В любом случае можешь ли ты оценить вероятность переполнения?
В конце-концов double нельзя сравнивать, а __int64 нельяз переполнять. Что важнее?

ИМХО лучше всего правильно складывать. (например иерархически)

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

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

A>Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами, возникает вопрос — как лучше с этими числами работать (с точки зрения повышения производительности) как _int64 или double? Компилятор VC-6, платформа — x86 WinXP.

Целые? положительные? значит int64. А если есть, то unsigned int64.
Только за переполнением следи.

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

N>Целые? положительные? значит int64. А если есть, то unsigned int64.
N>Только за переполнением следи.

Как на С++

adc op1,1

(и иже с ними) провернуть без проверок?

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

E>В конце-концов double нельзя сравнивать,

Что за глупости?

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

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

E>>В конце-концов double нельзя сравнивать,

SWW>Что за глупости?

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

E>>В конце-концов double нельзя сравнивать,
SWW>Что за глупости?

double непредсказуемо ведёт себя при сравнении на равенство. Соответственно, если алгоритм предполагает какие-то сравнения на равенство (скажем, если сумма этих 1000 элементов равнв сумме той 1000), то double использовать сложнее...

А что касается глупостей, то я не знаю. Ты их где-то нашёл, тебе и виднее что за глупости

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

E>>>В конце-концов double нельзя сравнивать,
SWW>>Что за глупости?

E>double непредсказуемо ведёт себя при сравнении на равенство.

Во-первых, было написано "нельзя сравнивать". Про сравнение на равенство ничего не не было.

E>Соответственно, если алгоритм предполагает какие-то сравнения на равенство (скажем, если сумма этих 1000 элементов равнв сумме той 1000), то double использовать сложнее...

А во-вторых, при определенных ситуациях можно сравнивать и на равенство. Не результаты подобных вычислений, разумеется, но в определенных случаях можно.

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

SWW>Во-первых, было написано "нельзя сравнивать". Про сравнение на равенство ничего не не было.
SWW>А во-вторых, при определенных ситуациях можно сравнивать и на равенство. Не результаты подобных вычислений, разумеется, но в определенных случаях можно.

Ты, мил человек, русский хорошо знаешь? Я писал ответ человеку, вполне в контексте. Думаю, что там всё понятно написано. Если тебе не понятно -- то это плохо. Но может со временем отпустит.

А что касается "глупостей" из твоего сообщения, то я с его источником определился Спасибо и на этом.

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

SWW>>Во-первых, было написано "нельзя сравнивать". Про сравнение на равенство ничего не не было.

E>Ты, мил человек, русский хорошо знаешь? Я писал ответ человеку, вполне в контексте. Думаю, что там всё понятно написано.

Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами

В конце-концов double нельзя сравнивать,

Человек пишет что требуется сравнение. Ты утверждаешь, что double сравнивать нельзя. В этом контексте могу заявить только одно: ты не прав, так как сравнивать их можно. А то, что требуется сравнение на равенство нигде не написано. Не говоря уже о том, что в определенных ситуациях можно сравнивать и на равенство.

Здравствуйте, SWW, Вы писали:
SWW>Человек пишет что требуется сравнение. Ты утверждаешь, что double сравнивать нельзя. В этом контексте могу заявить только одно: ты не прав, так как сравнивать их можно. А то, что требуется сравнение на равенство нигде не написано. Не говоря уже о том, что в определенных ситуациях можно сравнивать и на равенство.


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

Короче разные алгоритмы.

Чтобы ты наконец понял о чём биш то я, я тебе приведу задачу.

Дан большой (скажем 1е9) массив целых чисел (пусть знаковых)
Нужно найти идущий подряд подмассив этого массива с максимальной суммой элементов.
При этом из всех подмассивов с одиниковой суммой выбрать тот, у которого самая маленькая левая граница.
А из всех подмассивов с совпадающей левой границей надо выбрать тот, у которого правая граница расположена левее всего.

приведи решение с даблами и с длинными целыми, пжлст

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

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

E>>>В конце-концов double нельзя сравнивать,
SWW>>Что за глупости?

E>double непредсказуемо ведёт себя при сравнении на равенство. Соответственно, если алгоритм предполагает какие-то сравнения на равенство (скажем, если сумма этих 1000 элементов равнв сумме той 1000), то double использовать сложнее...

абсолютно предсказуемо, процессор не датчик случайных чисел!
т.е. если есть два 8битных плавающих, то результат сравнения предсказуем.

E>А что касается глупостей, то я не знаю. Ты их где-то нашёл, тебе и виднее что за глупости

я согласен с SWW

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

E>вообще говоря у целых чисел, сравнение на больше подразумевает исравнение на неравенство.
E>То есть если ты знаешь, что одно целое меньше другого, то ты знаешь, что они не равны. А если ты сравниваешь даблы, и выяснил что один меньше другого, то ты не знаешь равны ли они

Если я выяснил, что один меньше другого, то я могу однозначно утверждать, что они не равны.
Вот если я выяснил, что один не меньше другого — то да, он может быть больше или равен.

E>(так как равенство надо проверять хитро, с относительной погрешностью или ещё как )

Зависит от природы задачи. Вообще, мне как-то не встречались задачи, в которых double приходилось бы сравнивать на равенство. Ведь когда в вычислениях используются double, то ими кодируются какие-то "аналоговые" величины, а их сравнивать на равенство бессмысленно. Если и приходится сравнивать с относительной погрешностью, то по причине "аналоговости" этой величины, а не потому что double нельзя сравнивать на равенство. Но ведь могут быть особые, "искусственные", случаи — например функция возвращает результат вычислений или 0 когда вычисления по какой-то причине провести не удалось (разумеется если 0 не может быть результатом). То есть, одно из значений просто используется в качестве флага. В таком случае можно совершенно безопасно написать return 0; и проверять if(f() == 0).

E>Чтобы ты наконец понял о чём биш то я, я тебе приведу задачу.
E>Дан большой (скажем 1е9) массив целых чисел (пусть знаковых)
E>Нужно найти идущий подряд подмассив этого массива с максимальной суммой элементов.
E>При этом из всех подмассивов с одиниковой суммой выбрать тот, у которого самая маленькая левая граница.
E>А из всех подмассивов с совпадающей левой границей надо выбрать тот, у которого правая граница расположена левее всего.
E>приведи решение с даблами и с длинными целыми, пжлст

Поскольку задача искусственная, то и подходить к ее решению можно формально
if(s1 > s2) то выбираем s1 так как он больше.
else if(s1 == s2) то сравниваем их левые границы.
Но в реальной задаче скорее всего сравнивать на равенство будет бессмысленно так как точное равенство будет встречатьс крайне редко, а заказчика вероятно устроило бы и равенство с погрешностью, а ты его мне не задал.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>абсолютно предсказуемо, процессор не датчик случайных чисел!
СМ>т.е. если есть два 8битных плавающих, то результат сравнения предсказуем.

Если даны флаги процессора, опции типа /Op Improves floating-point consistency то результат предсказуем. Точнее говоря можно, но очень осторожно. Переполнение не возникает, но потеря точности наступит раньше.


Дорого стоит преобразование из унсигнед в флоат. Также дорого флоат — целое, если без опции QIfist Suppresses the call of the helper function _ftol when a conversion from a floating-point type to an integral type is required Вроде SSE2 тоже можно задействовать, но не знаю

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

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

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

SWW>>Поскольку задача искусственная, то и подходить к ее решению можно формально
P>Вот например геометрия разная очень веселая бывает. Лежит ли например точка на прямой ? или просто мышкой чуть-чуть рядом ткнули.

Казалось бы, при чем тут double? Все пикселы имеют целочисленные координаты.

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

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

Попал — не попал это простой случай. А как Вам операция обьединения полигонов?

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

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

SWW>>>Поскольку задача искусственная, то и подходить к ее решению можно формально
P>>Вот например геометрия разная очень веселая бывает. Лежит ли например точка на прямой ? или просто мышкой чуть-чуть рядом ткнули.

SWW>Казалось бы, при чем тут double? Все пикселы имеют целочисленные координаты.
Пиксили-то целочисленные, а все вычесления, в компьютерной графике — в double, и только в самом конце округляются при выводе на девайс. Ради эксперимента, попробуй потрансформировать какую-нибудь векторную фигуру используя целочисленные матрицы

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

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

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

P>Попал — не попал это простой случай. А как Вам операция обьединения полигонов?

Только хотел про GPC вспомнить и совершенно замечательные решения. Кстати есть там и куски которые на равенство плавающие числа сравнивают ,о конечно иони полученны из одного источника.

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

>В конце-концов double нельзя сравнивать,
>double непредсказуемо ведёт себя при сравнении на равенство.

А сдаётся мне, что если на входе целые числа, исходные данные
и промежуточные результаты не более 2^52,
то все вычисления на Double будут производиться точно.

А если взять Extended, то можно поднять верхнюю планку точности до 2^63.

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

W>А если взять Extended, то можно поднять верхнюю планку точности до 2^63.
нет такого типа на этом компилере The representation of long double and double is identical. However, long double and double are separate types.

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

W>>А если взять Extended, то можно поднять верхнюю планку точности до 2^63.
P>нет такого типа на этом компилере The representation of long double and double is identical. However, long double and double are separate types.

если Вы посмотрите, то форум С/C++, и не надо о ограничениях конкретного компилятора.

ps
в русском языке нет слова "компилер", "компилиться" и тп

Здравствуйте, Сергей Мухин, Вы писали:

СМ>если Вы посмотрите, то форум С/C++, и не надо о ограничениях конкретного компилятора.

Исходный пост про VC6. Но если гуи у автора нет, то перенести не долго

Здравствуйте, Сергей Мухин, Вы писали:

W>>>А если взять Extended, то можно поднять верхнюю планку точности до 2^63.
P>>нет такого типа на этом компилере The representation of long double and double is identical. However, long double and double are separate types.

СМ>если Вы посмотрите, то форум С/C++, и не надо о ограничениях конкретного компилятора.

Если так рассуждать, то придется признать что и double может быть не только IEEE 754...

Прикольно люди Микрософт лечат http://www.rsdn.ru/Forum/Message.aspx?mid=922025&only=1

Автор: adontz
Дата: 29.11.04

__declspec(align(2)) class long_double
    {
        private:
            unsigned char data[10];
        public:
            __forceinline long_double()
                {
                    __asm FLdZ;
                    __asm Mov ECX, this;
                    __asm FStP TBYTE PTR [ECX];
                }
            __forceinline 
................................
__asm 
__asm 
__asm 
__asm 
.................................

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


SWW>Зависит от природы задачи. Вообще, мне как-то не встречались задачи, в которых double приходилось бы сравнивать на равенство. Ведь когда в вычислениях используются double, то ими кодируются какие-то "аналоговые" величины, а их сравнивать на равенство бессмысленно. Если и приходится сравнивать с относительной погрешностью, то по причине "аналоговости" этой величины, а не потому что double нельзя сравнивать на равенство. Но ведь могут быть особые, "искусственные", случаи — например функция возвращает результат вычислений или 0 когда вычисления по какой-то причине провести не удалось (разумеется если 0 не может быть результатом). То есть, одно из значений просто используется в качестве флага. В таком случае можно совершенно безопасно написать return 0; и проверять if(f() == 0).

Не, мужчина, вы вообще не свои посты читаете?

В оригинале рассказывали что-то о вычислениях "с неотрицательными целыми".
Я всё пытаюсь обратить твоё драгоценнейшее внимание на то, что double немного не под то заточен.
Ты всё правильно пишешь, что для double интересоваться точным равенстовм странно. Но для целых-то не странно, а наоборт естественно
Так что если ты для реализации операций над целыми, которые надо ещё и сравнивать, заюзаешь double возможны трудности.
Они конечно не непреодилимые, но на борьбу с ними потребуется тратить производительность...


E>>Чтобы ты наконец понял о чём биш то я, я тебе приведу задачу.
Видимо не помогло. Попробуй ещё раз. Ключевое слов я выделил!

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

SWW>Поскольку задача искусственная, то и подходить к ее решению можно формально
SWW>if(s1 > s2) то выбираем s1 так как он больше.
SWW>else if(s1 == s2) то сравниваем их левые границы.
Ты прости, но я не понял что ты тут написал. Кто такие s1 и s2? Какого они типа? Почему тебе кажется, что задача искуственная?
Положим, что массив -- это доход от каких-то финансовых инструментов. И мы ищем период, когда был самый большой абсолютный рост...

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

интересно бы узнать откуда это следует? Числа-то целые. Пусть даже ограниченные по модулю числом 10 000 000.

В общем я человек простой, с русским у меня непросто всё.
Не могёшь на С++ написать ответ?

пусть у тебя есть мегафункция

int getNextValue()

Которая возвращает последовательность целых чисел. И надо указать порядковые номера границ искомого подмассива.

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

SWW>>>Поскольку задача искусственная, то и подходить к ее решению можно формально
P>>Вот например геометрия разная очень веселая бывает. Лежит ли например точка на прямой ? или просто мышкой чуть-чуть рядом ткнули.

SWW>Казалось бы, при чем тут double? Все пикселы имеют целочисленные координаты.

казалось бы...
Тут вроде и обсуждают что будет, если целочисленные вычисления по каким-то соображениям делать через double...

Здравствуйте, Сергей Мухин, Вы писали:

СМ>абсолютно предсказуемо, процессор не датчик случайных чисел!
СМ>т.е. если есть два 8битных плавающих, то результат сравнения предсказуем.
E>>А что касается глупостей, то я не знаю. Ты их где-то нашёл, тебе и виднее что за глупости
СМ>я согласен с SWW

И тебе, мил человек, задача:

Дан большой (скажем 1е9) массив знаковых целых чисел
Нужно найти идущий подряд подмассив этого массива с максимальной суммой элементов.
При этом из всех подмассивов с одиниковой суммой выбрать тот, у которого самая маленькая левая граница.
А из всех подмассивов с совпадающей левой границей надо выбрать тот, у которого правая граница расположена левее всего.
массив задан при помощи функции.

int getNext()

первый вызов возвращает 1-й элемент массива, второй -- 2-й и т. д..

ОТвет желательно на C++
через __int64 и через double.
Потом смотрим и сравниваем что увидили....

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

W>А сдаётся мне, что если на входе целые числа, исходные данные
W>и промежуточные результаты не более 2^52,
W>то все вычисления на Double будут производиться точно.

W>А если взять Extended, то можно поднять верхнюю планку точности до 2^63.

В целом никто не обещал, хотя скорее всего так и будет конечно, но вдруг значение всегда нормализуют?
Кроме того, если просто вязть и использовать __int64 (о котором и спросили, собственно), то сразу бужем иметь границу в 2^63 или даже 2^64 вообще без извратов совместимо и гарантированно

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

E>И тебе, мил человек, задача:

мне трудно понять, человек, который путает int & size_t, который говорит, что double не сравниваются, мне будет задачки давать? Бред

Здравствуйте, Сергей Мухин, Вы писали:

СМ>мне трудно понять, человек, который путает int & size_t, который говорит, что double не сравниваются, мне будет задачки давать? Бред

Выделенное -- это конечно печально. Но попробуй сконцентрироваться
И если ты уже постучал по столу всем чем хотел и крепость ствола демонстрировать закончил, то попробуй не переходить на личности, а пояснить можно или нельзя сравнивать double в рамках предложеной задачи (она как раз такая, как в стартовом сообщении темы. ПРо большое число целых чисел, которые надо складывать и сравнивать)

Потому что я не знаю как объяснить понятнее

И. Т. Егор.
p. s.
А как ты узнал, что я "путаю" size_t и int? Их очень просто отличить, например по позиции буквы "i" в названии типа

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

E>Дан большой (скажем 1е9) массив целых чисел (пусть знаковых)

Не пусть, а именно знаковых. Иначе ответ будет — [0;1e9)

E>Нужно найти идущий подряд подмассив этого массива с максимальной суммой элементов.

E>При этом из всех подмассивов с одиниковой суммой выбрать тот, у которого самая маленькая левая граница.
E>А из всех подмассивов с совпадающей левой границей надо выбрать тот, у которого правая граница расположена левее всего.

Проще сказать, выбрать крайне левый (или первый попавшийся, если алгоритм потоковый).

E>приведи решение с даблами и с длинными целыми, пжлст

Спасибо за этюд, в таком ракурсе я над этой задачей не сталкивался...
То есть, наша задача — не просто найти такой массив, но ещё и побороться с переполнениями и округлениями.

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

E>Вообще-то, насколько я понимаю, double на современных процах лучше. Но возможны варианты.
E>В любом случае можешь ли ты оценить вероятность переполнения?
E>В конце-концов double нельзя сравнивать, а __int64 нельяз переполнять. Что важнее?

Я что-то пропустил в мире ИТ? С каких это пор числа с плавающей точкой обрабатываются быстрее целочисленной арифметики?

Здравствуйте, Аноним, Вы писали:

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

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

A>Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами, возникает вопрос — как лучше с этими числами работать (с точки зрения повышения производительности) как _int64 или double? Компилятор VC-6, платформа — x86 WinXP.

А как реализован _int64 в VC-6, вот если через MMX (нам же флоаты не нужны), то вопросом просто и быть не должно, если нет — сделайте сами...

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

К>Спасибо за этюд, в таком ракурсе я над этой задачей не сталкивался...
К>То есть, наша задача — не просто найти такой массив, но ещё и побороться с переполнениями и округлениями.

Точно так.
Правда этюд так себе.
Так как 1е9 мало, чтобы переполнить int64 складывая int32
А вот с double уже веселее всё будет

Здравствуйте, <Аноним>, Вы писали:

А>Я что-то пропустил в мире ИТ? С каких это пор числа с плавающей точкой обрабатываются быстрее целочисленной арифметики?

С тех пор, как 32х битные процессоры научились умножать и делить 64 битные целые.

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

VEA>Как на С++
VEA>

VEA>adc op1,1 
VEA>

VEA>(и иже с ними) провернуть без проверок?

Использовать компилятор с поддержкой 64 битных целых.

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

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

VEA>>Как на С++
VEA>>

VEA>>adc op1,1 
VEA>>

VEA>>(и иже с ними) провернуть без проверок?

GN>Использовать компилятор с поддержкой 64 битных целых.

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

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

GN>Здравствуйте, <Аноним>, Вы писали:

А>>Я что-то пропустил в мире ИТ? С каких это пор числа с плавающей точкой обрабатываются быстрее целочисленной арифметики?

GN>С тех пор, как 32х битные процессоры научились умножать и делить 64 битные целые.

спасибо за информацию. Никогда бы не подумал. Зашел на сайт Intel на котором приведены результаты тестов для 64-битной архитектуры. Действительно floating-point equation быстрее чем integer

Здравствуйте, <Аноним>, Вы писали:

А>Зашел на сайт Intel на котором приведены результаты тестов для 64-битной архитектуры.

Я не имел ввиду 64 бита, там не всё так однозначно, например, A64 только делит медленнее (сложение и вычитание понятно что будет быстрее для целых). А вот 32х битным процам приходится выполнять далеко не одну инструкцию, что бы перемножить 64 бита, в отличае от FPU.

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

GN>Здравствуйте, <Аноним>, Вы писали:

А>>Зашел на сайт Intel на котором приведены результаты тестов для 64-битной архитектуры.

GN>Я не имел ввиду 64 бита, там не всё так однозначно, например, A64 только делит медленнее
Деление еще и остаток вычисляет, а потом забить могли на деление — транзисторы сэкономить в ущерб какому нибудь паралелизму

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

P>Здравствуйте, gear nuke, Вы писали:

GN>>Здравствуйте, <Аноним>, Вы писали:

А>>>Зашел на сайт Intel на котором приведены результаты тестов для 64-битной архитектуры.

GN>>Я не имел ввиду 64 бита, там не всё так однозначно, например, A64 только делит медленнее
P>Деление еще и остаток вычисляет, а потом забить могли на деление — транзисторы сэкономить в ущерб какому нибудь паралелизму
Разве не забито на деление в CPU? Т.е. всё деление (и целочисленное) в FPU?
Может и бред...