Phoronix провёл (http://www.phoronix.com/scan.php?page=article&item=ubuntu_32...) тестирование производительности архитектур x86, x86 PAE и x86-64 в дистрибутиве Ubuntu, используя конфигурацию компьютера с 4GB RAM и Linux ядром 2.6.31. Линус Торвальдс предупреждал, что использование PAE может негативно сказаться на производительности (до 25%), однако тесты Phoronix это не подтвердили.
По результатам тестирования, ядра Linux x86 и x86 с PAE показали приблизительно одинаковую производительность, зато на синтетических тестах архитектура x86-64 оказалась в некоторых тестах на порядок быстрее.URL: http://www.phoronix.com/scan.php?page=article&item=ubuntu_32...
Новость: http://www.opennet.me/opennews/art.shtml?num=24859
Насколько я понимаю, деградация производительности при использовании PAE связана с трёхуровневым VM'ом, который для этой цели используется в ядре Linux.Однако, чтобы он действительно был трёхуровневым, необходим микропроцессор с наличием PAE Extension и отсутствием PSE36 Extension.
Кто и когда в последний раз такое видел?-)
обьясните что вы понимаете под трех уравневым VMом
виртуал мемори
или
виртуал машин
?
> виртуал машинЭто тут вообще никаким боком.
Дополнительный уровень вложенности: таблица указателей на page directory - page directory pointer table (pdpt_entry_t)
Скажите, почему у апача такая разница в тестах? В чём дело?
Потому что подозреваю что в их случае x86 - это i386, скомпилировано с максимальной совместимостью вплоть до 486 процессоров.А x64 - явление относительно новое, и процессоры с ним начинаются с Athlon64.
Не обращай внимания, это ж Фроникс, они не измеряют, они просто придумывают бенчмарки.
да нет же, подобный тест (в котором сравниваемые сущности параметрически схожи) таки уместен, и результаты похожи на правду (а предположение анонимуса о компиляции x86 как i386 может являться объяснением результатов). и уж лучше такой тест, чем никакой. он дает хотя бы пищу для ума (не согласен - проверь). а вот pavlinux/User294 ничего не дает, т.е. совсем. а! нет, же! из за них тяжело читать простыню с комментариями, что должно способствовать тренировки быстрого отсева зерен от плевел у пользователя форума! мда, ну вы поняли...
Какая пища, мы спасаем ваш мозг от этого бреда.
В течении 2-х лет я повторно тестировал, по аналогии с Фрониксами,
вот тогда и понял что они - это лажа.
Совпадения были лишь там где легко предсказуемы, например разница в 2%.
У статистов 2% - это всего погрешность в измерениях не более, но никак не различие.Всё тесты с Фрониксов, пишутся по схеме - два одинаковых + 1 явное выделение результата.
либо все одинаковые, но с той же 2% разницей.
Это реклама сайта, спонсоры слева Featured Links и Affiliates
Не выдели они Апачь с 5-кратной разницей, не было бы столь трафика и говнобазара!
Когда-то очень давно где-то я видел статью человека на эту тему. Человек был ненавистником "ненормального x86_64" и несколько лет назад объяснял свою точку зрения на наглядном примере Apache. Что из-за того, что в 64-битных системах длиннее адреса памяти, Апач в памяти занимает почти в 2 раза больше места, и прочее.
дело в том, что 64битные процессоры отличаются далеко не только способностью адрессировать больше 4 гигабайт памяти. в 2 раза больше памяти может, конечно, и занимать. в случае бешеной кривости кода и разбазариванием памяти. сам код становиться больше на 15-30%. значит область данных должна увеличиться на 70-85%. что-то тут не так с арифметикой. либо код апача действительно криво написан. в последнем я сомневаюсь.
наверно все-таки не "адрессировать", а адресовать
да, уж извините за ошибку великодушно
Может автор новости не заметил, но во _всех_ 14-и, а не в некоторых, приведённых результатах тестов х84-64 оказалась быстрее. Только в одном (первом) все оказались равны. В конце статьи недоверчивым предлагается провести тесты самим, со ссылками на тесты.
"Во всех, кроме одного" не звучит.
А статья нужная. Многие ропчут на x86_64 и говорят, что прирост мизерный и незаметный совершенно, так что специально для них появилась ещё одна ссылка.
разница по апачу в 20 раз кажется НУ ОЧЕНЬ ПОДОЗРИТЕЛЬНОЙ
а postmark - в 10 разони явно что-то намутили.
ибо это серьезная деградация x86 по отношению к 86_64
Мужики? Ну откуда x86_64 будет быстрее x86_32? Ну реально, в чем? Все тоже самое, те же атомы, просто адресация расширилась с 64 битами и все процессы стали жрать оперативы в два раза больше...
ппц...
Оттуда, что там более другая система команд, не столь завязанная на совместимость с 8086. AFAIK.
Мне кажется, дело в дополнительных регистрах, новом ABI и значительно меньшем использовании стека.
> те же атомы
> все процессы стали жрать оперативы в два раза большелютый фейспалм.
>и все процессы стали жрать оперативы в два раза больше...а это с какого перепуга? история показала, что размерность байта при при переходе с 8битной архитектуры на 16битную не изменилась.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2723 root 15 0 142m 6320 3024 S 0 0.3 2:31.26 snmpd
2791 root 15 0 126m 2376 1464 S 0 0.1 0:00.00 cupsd
16254 admin 15 0 86944 1676 964 S 0 0.1 0:00.00 sshd
2427 root 12 -3 143m 1100 596 S 0 0.1 5:35.39 audispd
25638 root 21 0 99.6m 1540 868 S 0 0.1 0:00.00 crond
6945 root 16 0 98.7m 1372 1080 S 0 0.1 0:00.00 su
2694 root 25 0 95488 1204 908 S 0 0.1 3:07.08 automount
2425 root 13 -3 83920 848 508 S 0 0.0 26:11.35 auditdЭто что 142 метра на стек положили? Если да, то почему именно, 142 а не полгига, скажем?.
Tasks: 343 total, 1 running, 342 sleeping, 0 stopped, 0 zombie
Cpu0 : 17.3%us, 1.0%sy, 0.0%ni, 81.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 16.5%us, 1.0%sy, 0.0%ni, 82.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 2.8%us, 1.9%sy, 0.0%ni, 95.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 1.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4127252k total, 4084556k used, 42696k free, 140k buffers
Swap: 12811820k total, 0k used, 12811820k free, 3415120k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
2058 pavel 40 0 651m 48m 30m S 3.9 1.2 7:32.20 1 kdeinit4: plasma-desktop [kdeinit]
1775 root 40 0 148m 50m 7976 S 3.2 1.3 7:47.08 0 /usr/bin/Xorg -br -nolisten tcp :0 vt7 -auth /var/lib/xdm/auth
2338 pavel 20 0 839m 201m 23m S 1.0 5.0 3:10.36 0 java -Xms16m -Xmx128m -cp /opt/azureus/Azureus2.jar:/opt/azure
6575 pavel 40 0 17208 1384 860 R 0.5 0.0 0:00.54 2 top
2063 pavel 40 0 8900 1076 704 S 0.2 0.0 0:07.33 1 ksysguardd
2093 pavel 40 0 506m 81m 26m S 0.2 2.0 0:29.91 0 yakuake -session 10a9a97365000125729274600000025050008_1262398
2357 pavel 20 0 839m 201m 23m S 0.2 5.0 0:22.51 2 java -Xms16m -Xmx128m -cp /opt/azureus/Azureus2.jar:/opt/azure
2362 pavel 20 0 839m 201m 23m S 0.2 5.0 0:04.84 0 java -Xms16m -Xmx128m -cp /opt/azureus/Azureus2.jar:/opt/azure
2456 pavel 20 0 839m 201m 23m S 0.2 5.0 0:07.64 2 java -Xms16m -Xmx128m -cp /opt/azureus/Azureus2.jar:/opt/azure
просто узнайте куда и чего и спрашивайте у девелоперов, почему.
cat /proc/<pid>/maps
PAE вызовер рельное падение производительности при условии, что в системе более четырёх гигабайт RAM; и видимо, нужно, чтобы сумма памяти, занимаемой приложениями, тоже была больше четырёх гигабайт.
Лично я за переход на 64-е бита и сделал это сам как только у меня появился 64-х бытный процессор. даже если бы была не значительное падение производительности я бы не вернулся на 32 бита вот такой я человек :-)а на счет тестов действительно кажется уж очень подозрительный такой прирост производительности... я бы мог предположить прирост на 10-15% при приложениях использующих больше 800 мега памяти так как вся память low или low+high может быть разница... но PAE показывает что разница совсем не значительная... (я имею в виду что PAE = low + high + PAE в сравнении c low+high) но вот такой прирост... иногда до 2-х десяткова раз...
я конечно очень верю в специалистов AMD придумавших 64-х битную систему команд... но если такой прирост то респект им в двойне!!!ЗЫ.
на счет памяти больше жрет глупость 5-и буквенная строчка в utf-16 что там что там жрет 10 байт и размер 32-х битного целого мне кажется то же не поменялся :-) и на счет того что команды длинее стали... я не уверен но мне кажется здесь не ARM где все команды одной длинны... да и по моему опыту бинарники 64-и бита иногда в разы короче своих 32-х битных собратьев