>Ъ интырпрайз? даже 512 хватает на подавляющее большинство нужд. И даже на огромную кучу вендовых игр. Что за погоня такая за V?

Любитель по свапить?

статья про писькомер!

Какой же автор теста КРЕТИНОИД. От попытки онаукообразить последние выводы хочется ПЛАКАТЬ.

> Короче позор авторам, что так затупили и позор модерам, что пропустили такое на лор...

Мне тоже не всё понравилось в тесте, но дело в том, что как-то не очень попадаются вменяемые тесты вообще, когда чисто сравнили бы _строго_ на одном и том же железе несколько дистров для i686 и x86_64.

> На этом фоне сам факт того, что сравнивался скорее результат сравнения производительности сборки для i386 и i686, чем i686 и x86_64 - уже мелочи.

Не понял, где ты увидел сборку для i386?

Все это просто и замечательно - на AMD Athlon. Хотелось бы узнать, насколько медленнее или быстрее x86_64 на, скажем, Core 2 Mobile...

>Я тестировал одну свою программку, у нее был прирост в районе 20%, просто от того, что она была собрана под x86_64, естественно gcc

А ты ее попробуй компилить не под 386 и с fpmath=sse

>Т.е. "В два раза больше в два раза больших регистров"

Т.е., сохранять контекст при переключении задач надо в два раза больше в два раза большего, за счет в 2-раза большей адресации увеличивается размер кода, соответственно больше загаживается кэш.

На точность и научный подход не претендую, так, добавлю свои 5 копеек на тему 32 vs 64.

Имеется dual quad-core xeon, 2 gb оперативы, maya2008 (32 и 64) со встроенным mental ray. Проприетарщина конечно, но что делать...

Сцена (eiffel из тестов ixbt.com) считается в 32-битной Суське10.3 примерно за 6.28, в 64-битной за 5.38, в ВыньХП64 за 6.20 (для фана пробовал). Разница очевидна. Если подключать distributed render, то польза от 64 бит еще больше.

зы. сам предпочитаю на десктопе бубунту, на серверах дебиан.

Все говорят, что тест говно, а самим слабать слабо?

на Intel - всех хуже. и если FP прирост - падает лишь наполовину (20% мб чуть больше). то IO - только треть от упомянутых 80%. все не бенчил, но 30% разницы - самое большее что удалось выжать и из десктопных C2Duo C2Q и из немногочисленных(к счастью)зионов.

p.s. why sse ? это только для "малтимидий" такая (результирующая) точность приемлема. ANSI FP Only !!! никаких "динамически улучшенных точностей" (c), ибо даже на 3D в результате - без слез не глянуть(если есть с чем сравнить, ессно). а если хочется sse - точите уже под 3-й, там хоть "какая-то" вещественная математика появилась.

p.p.s. Новые камни Intel потестить нипалучилось(Вилли и прочие), да не особо-то и надо. от старых не знаем как избавиться :/

64 не использую

>32-битное ядро было без PAE? 4Г памяти на приличном десктопе - это уже норма, значит при 32 битах придётся включать PAE - вот тогда и посмотреть на скорость x86 vs. x86_64, особенно на приложениях, которые память "любят":)

И как ты собрался эти 4Г использовать? Будет ли комп с 4Г быстрее компа с 1Г (да даже с 512МБ)?

>А вообще статья полезная. Теперь я знаю, что федора тоже тормозное поделие, хотя ни разу её не ставил.

откуда вы такие аналитики беретесь? Этот тест - убог. Где усредненные значения? Или все мерялось искаропки? Надо привести к каждому дистру вывод ps ax. вывод chkconfig --list и т.п. И потом сравнивать. И не по одному разу тесты прогонять. Короче, это не тест, а х.з.ч.

>Короче, это не тест, а х.з.ч.

Извините! Это не х.з.ч., это КГ/АМ :)

Предыдущий флейм про Ганса был страниц на 25 вроде.

А ну поднажми! Что бы мне вечером было что читать, акромя толксов =)

Опять тест ни о чём

Интересно, эти "аналитики" используют компьютер только для возни с музыкой
и перекомпиляции ядра?

> Тестирование системы проводилось без внесения каких-либо
> изменений в настройки системы.

Хм. Получаеться Fedora самый быстрый дисрибутив что ли ?
Так как изначально 9-ка ( без updates ) была очень тормозная
и по умолчанию оно ставиться с SE-Linux.

Если это учесть то наверное Fedora отрветься далеко вперед !

> Все говорят, что тест говно, а самим слабать слабо?

Возьми unixbench и слабай?

Автор хотя бы раз по 100 каждый тест прогнал, выкидывая первые результаты, и привел цифры с ошибками, вместо ловли относительной разницы в 0.5% после одного прогона. + вопрос, что именно меряет time.

Неужели никто не заметил опечатки в таблицах с процентным соотношением 32 битных версий и 64 битных? Там в каждой таблице в заголовке [ Fedora 9 i386 | Fedora 9 x86_64 ] написано.

Плохому танцору SSE мешает?

> p.s. why sse? это только для "малтимидий" такая (результирующая) точность
> приемлема.

А мужики-то и не знают:

http://arxiv.org/pdf/astro-ph/0511062

Во-первых, нормальная там точность. Во-вторых, в sse есть целочисленные
и "строковые" инструкции. А в третьих, i387 запарил своим придурошным
стеком.

> ANSI FP Only !!!

Может таки IEEE?

> никаких "динамически улучшенных точностей" (c),

Чего-чего?

>>32-битное ядро было без PAE? 4Г памяти на приличном десктопе - это уже норма, значит при 32 битах придётся включать PAE - вот тогда и посмотреть на скорость x86 vs. x86_64, особенно на приложениях, которые память "любят":)

>И как ты собрался эти 4Г использовать? Будет ли комп с 4Г быстрее компа с 1Г (да даже с 512МБ)?

Нет, на отдельной задаче, будет даже медленней - так устроен контролер памяти в amd64, просаживается. Но при большом количестве процессов это компенсируется отсутствием свопа.

Цифрам верить не стоит, но тенденция очевидна. А что еще нужно от простого теста?

Кстати, я встречал тесты, где bzip2 показывал двух-кратный прирост на x64!!! Скорей всего здесь проблема в io

>Нет, на отдельной задаче, будет даже медленней - так устроен контролер памяти в amd64, просаживается. Но при большом количестве процессов это компенсируется отсутствием свопа.

по твоему 4Г без свопа быстрее, чем 512МБ со свопом? хехе. Оно-то быстрее _иногда_, но этого не заметить (ну разве что doom3 быстрее запускаться будет, так как память не придется освобождать). Своп не дураки придумывали. и лучше за те деньги, которые ты на 3GB памяти потратишь купить винт еще один. Пользы намного больше.

>А в третьих, i387 запарил своим придурошным стеком.

Мсье из параллельной вселенной? :)

> о твоему 4Г без свопа быстрее, чем 512МБ со свопом?

Конечно, быстрее.

>хехе. Оно-то быстрее _иногда_, но этого не заметить

Отлично заметно.

>(ну разве что doom3 быстрее запускаться будет, так как память не придется освобождать).

Ну и все остальное тоже будет быстрее запускаться.

>Своп не дураки придумывали.

Конечно, не дураки, но винт всяко медленнее работает, чем оперативка.

>и лучше за те деньги, которые ты на 3GB памяти потратишь купить винт еще один. Пользы намного больше.

Это смотря для каких задач польза. Для некоторых польза, для некоторых нет.

>чем 512МБ со свопом?

Не, ну меньше гига в наше время смысла нет брать.

>Конечно, быстрее.

не быстрее. Была возможность сравнить. не 4GB vs. 512MB. А 2GB vs. 512MB. Разницы вообще никакой не было. (не в играх).

>Конечно, не дураки, но винт всяко медленнее работает, чем оперативка.

не критично. Так как задачи, которые туда выпихиваются обычно в фоне крутятся и мне до них никакого дела нет. И если программа попала в своп, то значит ты ее уже сравнительно длительное время не активировал. И значит подождать 2 секунды, пока она оттуда грузанется не страшно.

>Ну и все остальное тоже будет быстрее запускаться.

остальное что? Есть еще программы (ну кроме монструозных игр типа ETQW), которые на раз требуют около 400 метров оперативки?

>>>и лучше за те деньги, которые ты на 3GB памяти потратишь купить винт еще один. Пользы намного больше. >Это смотря для каких задач польза. Для некоторых польза, для некоторых нет.

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

>Не, ну меньше гига в наше время смысла нет брать.

если новый комп брать то да. Ну а если уже торчит 512MB, но наращивать не обязательно. Ну разве что OO отжирает дофига... Ну так он сам по себе тормозной. Если что-то писать, так в кошерном LyX+LaTeX.

>> Раз уж проги консольные, дык и тестили бы в консоли

>вот уж не знал, что от этого скорость работы консольных программ меняется

mc в консоли и в Х-ах копирует с очень большой разницей в скорости копирования. Просто проверь скорость копирования дерева мелких файлов.

>mc в консоли и в Х-ах копирует с очень большой разницей в скорости копирования. Просто проверь скорость копирования дерева мелких файлов.

что за чушь. Посто сделай ltrace. И убедись, что при копировании функции вызываются те же самые.

другое дело, что mc может тратить время на перерисовку прогресбара. Ну так в Иксах тем более с этим намного лучше обстоит дело, чем в консоли.

Из универа меня выперли так, что теорию я не осилил. А в политех не поступил, так что с практикой тоже все плохо.

Милый ЛОР, научи меня проводи эксперименты,а ?

> А 2GB vs. 512MB. Разницы вообще никакой не было.
на 64 бит ?
ну разве что в в консольке и без x11
батенька видимо шутник или ненавистник графических приложений ...

> Из статьи: time make && make modules_install Вообще-то в данном варианте тайм будет считать только мейк, а мейк модулес_инсталл пройдёт просто.

Ага, а еще там абсолютно разные ядра собираются для 64 и 32 бит.

>Ага, а еще там абсолютно разные ядра собираются для 64 и 32 бит.

Точно, почему до сих пор никто внимания не обратил

>mc в консоли и в Х-ах копирует с очень большой разницей в скорости копирования. Просто проверь скорость копирования дерева мелких файлов.

Бред, никакой разницы.

А вот если сравнивать mc, консоль и копипасту, то разница просто огромная.

У меня на "killall nina fs" была разница между консолью и конкваровской копипастой 6 раз.

>на 64 бит ? ну разве что в в консольке и без x11 батенька видимо шутник или ненавистник графических приложений ...

KDE 3.5.9 правда без OO.

> - для дистрибутива Fedora 9 - от 1.2% до 26.9%;

4.2. Там же отрицательный показатель для Федоры вылез, который в итоге не учли. Причесывание фактов.

>на 64 бит ?

32бит Athlon 2GHz

Признавайтесь, кто тут Алексей Михайлов?

>Это в смысле? А что тестировалось?

А тестировались _собранные_. Что и показал флак.

>вот уж не знал, что от этого скорость работы консольных программ меняется

Меняется. Потому что выводят текст на консоль. Очень рекомендую поэкспериментировать.

>99.999 прог пишут не "под 64 бит", а не выделываясь - на обычных С/C++ и т.п., и это правильно - оптимизацией под железо ( за редкими случаями - где действительно есть смысл ) занимается компилятор

Т.е. тупо, о чем я и говорю.

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

Скорее всего ассемблерные вставки, столь популярные в кодеках, никто толком не трогал.

>Все говорят, что тест говно, а самим слабать слабо?

Зачем?

нормально. Надеюсь, продолжение последует - всё-же тестировались не самые жизненно-важные параметры систем :)

> и они со страшной силой "едят" процессорное время? :))))

Они со страшной силой поганят кеш и TLB, а также генерят кучу ошибок по данным
(переключение контекста -- сброс конвейера).

>по твоему 4Г без свопа быстрее, чем 512МБ со свопом? хехе. Оно-то быстрее _иногда_, но этого не заметить (ну разве что doom3 быстрее запускаться будет, так как память не придется освобождать). Своп не дураки придумывали. и лучше за те деньги, которые ты на 3GB памяти потратишь купить винт еще один. Пользы намного больше.

ага-ага. это мы наверное зря серваки с 8-32 Гиг покупаем. нада 512 метров и дисков побольше. грамотность прет, да.

> И значит подождать 2 секунды, пока она оттуда грузанется не страшно.

Когда памяти не хватает и такое происходит часто - это раздражает. Намного комфортнее, когда не нужно ничего ждать. Если редко - то это, согласен, не беда.

> остальное что? Есть еще программы (ну кроме монструозных игр типа ETQW), которые на раз требуют около 400 метров оперативки?

Остальное - например, софт для виртуализации типа VMWare/VirtualBox (особенно когда надо одновременно несколько машин), обработка видео, обработка изображений высокого разрешения, возможно, обработка звука. Опять же, навороченные IDE типа Visual Studio с аддонами требует относительно много ОЗУ и если ее мало, любит свопиться и соответственно тормозить.

По поводу первого и второго склонен согласиться. Ханс небыл заносчивым когда я его знал. Он даже по своему был компанейским. Бывало пойдем обедать в Муму на арбате, он в очереди прямо с лаптом стоит подзывает девелоперов по очереди чтото поспрошать или обсудить. Он был вспыльчивым немного и не любил признавать свои ошибки. Жалко что он таки Нину замочил, я до последнего сомневался.

Хотя... думаю, Ханс мог быть заносчивым с людьми не из "его тусовки".

По поводу (3), ты сам не знаешь о чем говоришь, хоть я в r3 и не участвовал но близко знаком с людьми что делали ее. Ты обижаешь этих людей незаслуженно. И когда вы уже все поймете, Ханс _ничего_ кроме корявого псевдокода последние лет 10 не писАл!!!! ПисАли нормальные люди, не энтузиасты, не студенты, они еще много чего дедали и делают.

Ставили CentOS 32\64 бита и соотвественно Oracle 32\64. Сервер - 2 Dual Xeon, 4Gb RAM, 10xSAS в RAID10. БД - около 4 Гб, Пускали задачу, в которой делалось много расчетов, около 2 часов. 64 бита оказались где-то на 30-40% быстрее. Не факт, что так удачно будет всегда, но резон однозначно есть.

Во всех трёх системах был включен selinux в enforced, а также стояли одинаковые политики? Или тест показывает, что selinux ест довольно мало проца? ;)