LINUX.ORG.RU
ФорумTalks

А есть ли тесты?

 ,


0

1

Если тесты сравнения производительности реальных программ собранных разными компиляторами (msvc,gcc,icc)? По идее, в тории, то прирост производительности возможен из-за увеличенного числа регистров общего назначения и измененного набора команд. А на деле как? Только интересуют тесты, при чем во множественном числе. Для объективности. Субъективное мнение не особо ценно.

★★★★★

Последнее исправление: Dudraug (всего исправлений: 1)
Ответ на: комментарий от Dudraug

элементарно, размер регистра влияет на кол-во обрабатываемых данных за 1 операцию.

высосанный из пальца пример. На сложение 2х 64-х битных чисел 64-х битный процессор потратит 1 такт. 32х-битный потратит побольше чем 1 такт, т.к. ему придется сложить младшие 32х-битные части чисел и потом старшие+возможный перенос разряда из суммы младших.

n_play
()
Ответ на: комментарий от n_play

32х-битный потратит побольше чем 1 такт, т.к. ему придется сложить младшие 32х-битные части чисел и потом старшие+возможный перенос разряда из суммы младших

А оно точно так работает? Или это предположение?

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Без использования MMX и прочих SIMD 32-х разрядный процессор по другому просто не может. Даже 64-х разрядный в режиме совместимости с 32-х разрядным так должен делать из соображений совместимости.

om-nom-nimouse ★★
()
Ответ на: комментарий от x3al

Да. Только сначала задефайнь реальные программы. И вообще, в гугль.

Да без разницы, интересна реальная ситуация. А гугл полон субъективных мнений.

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Так ежу же понятно, что для разных классов приложений разный результат. При внедрении 64 бит жаба зверски тормозила без каких-либо преимуществ (ну кроме возможности сожрать >4Гб). С другой стороны, разницу в кодеках и архиваторах видно невооруженным глазом.

x3al ★★★★★
()
Ответ на: комментарий от n_play

высосанный из пальца пример. На сложение 2х 64-х битных чисел 64-х битный процессор потратит 1 такт. 32х-битный потратит побольше чем 1 такт, т.к. ему придется сложить младшие 32х-битные части чисел и потом старшие+возможный перенос разряда из суммы младших.

Суперскалярность? Конвейеризация? Не, не слышал.

Relan ★★★★★
()
Ответ на: комментарий от Dudraug

Эм, а как размер регистра связан с производительностью?

можно больше в него запихнуть.

dikiy ★★☆☆☆
()

Возможны потери производительности в 32-битном коде из-за регрессий, вызванных переносом сил на 64-битную оптимизацию. Тесты недавно были на хабре.

atrus ★★★★★
()
Ответ на: комментарий от TDrive

facepalm.jpg

Ты вообще читать умеешь? Меня интересует конкретная статистика по компиляторам, как это на деле, а не теория. Теорию я знаю.

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от gadfly

Ааа, допёр. Как видишь, разница есть O_O , так что не зря сравнивают :)

true_admin ★★★★★
()
Ответ на: комментарий от Relan

вы так говорите будто на 64-х битном эти плюшки отсуствуют и неработают.

n_play
()
Ответ на: комментарий от true_admin

Перескажу для Ъ:

x86_64 быстрее во всех задачах кроме кодирования FLAC под Fedora (на Ubuntu и OpenSuse и эта задача выполняется быстрее). И даже система грузится чуть-чуть быстрее не смотря на панику «программы в два раза больше весят!».

Вывод:

1) x86_64 быстрее

2) в Fedora очень плохая оптимизация при компиляции (и в 32 и в 64 битах она выполняла задачи медленнее, чем конкуренты и разрыв между 32 и 64 был минимальный) по сравнению с Ubuntu и OpenSuse.

KivApple ★★★★★
()
Ответ на: комментарий от true_admin

Ну это не для вас, а для ТС. Вы то содержимое ссылки прочитали раз запостили её :-)

KivApple ★★★★★
()
Ответ на: комментарий от TDrive

Я просто распарсил твое сообщения как на призыв почитать тред о том «чем 32 отличается от 64».

Dudraug ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.