| 1.1, Andrew Kolchoogin (?), 15:43, 30/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Насколько я понимаю, деградация производительности при использовании PAE связана с трёхуровневым VM'ом, который для этой цели используется в ядре Linux.
Однако, чтобы он действительно был трёхуровневым, необходим микропроцессор с наличием PAE Extension и отсутствием PSE36 Extension.
Кто и когда в последний раз такое видел?-)
| | |
| |
| 2.2, hatelinux (?), 16:04, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
обьясните что вы понимаете под трех уравневым VMом
виртуал мемори
или
виртуал машин
?
| | |
| |
| 3.16, cvsup (ok), 20:20, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Дополнительный уровень вложенности: таблица указателей на page directory - page directory pointer table (pdpt_entry_t)
| | |
|
|
| |
| 2.5, Аноним (-), 16:13, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Потому что подозреваю что в их случае x86 - это i386, скомпилировано с максимальной совместимостью вплоть до 486 процессоров.
А x64 - явление относительно новое, и процессоры с ним начинаются с Athlon64.
| | |
| 2.6, pavlinux (ok), 16:15, 30/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Не обращай внимания, это ж Фроникс, они не измеряют, они просто придумывают бенчмарки.
| | |
| |
| |
| |
| Часть нити удалена модератором |
| 5.9, stollen (?), 17:04, 30/12/2009 [ответить]
| +/– |
да нет же, подобный тест (в котором сравниваемые сущности параметрически схожи) таки уместен, и результаты похожи на правду (а предположение анонимуса о компиляции x86 как i386 может являться объяснением результатов). и уж лучше такой тест, чем никакой. он дает хотя бы пищу для ума (не согласен - проверь). а вот pavlinux/User294 ничего не дает, т.е. совсем. а! нет, же! из за них тяжело читать простыню с комментариями, что должно способствовать тренировки быстрого отсева зерен от плевел у пользователя форума! мда, ну вы поняли...
| | |
| |
| 6.10, pavlinux (ok), 17:18, 30/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Какая пища, мы спасаем ваш мозг от этого бреда.
В течении 2-х лет я повторно тестировал, по аналогии с Фрониксами,
вот тогда и понял что они - это лажа.
Совпадения были лишь там где легко предсказуемы, например разница в 2%.
У статистов 2% - это всего погрешность в измерениях не более, но никак не различие.
Всё тесты с Фрониксов, пишутся по схеме - два одинаковых + 1 явное выделение результата.
либо все одинаковые, но с той же 2% разницей.
Это реклама сайта, спонсоры слева Featured Links и Affiliates
Не выдели они Апачь с 5-кратной разницей, не было бы столь трафика и говнобазара!
| | |
|
|
|
|
| 2.20, Zenitur (?), 22:30, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Когда-то очень давно где-то я видел статью человека на эту тему. Человек был ненавистником "ненормального x86_64" и несколько лет назад объяснял свою точку зрения на наглядном примере Apache. Что из-за того, что в 64-битных системах длиннее адреса памяти, Апач в памяти занимает почти в 2 раза больше места, и прочее.
| | |
| |
| 3.23, Карбофос (ok), 22:08, 01/01/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
дело в том, что 64битные процессоры отличаются далеко не только способностью адрессировать больше 4 гигабайт памяти. в 2 раза больше памяти может, конечно, и занимать. в случае бешеной кривости кода и разбазариванием памяти. сам код становиться больше на 15-30%. значит область данных должна увеличиться на 70-85%. что-то тут не так с арифметикой. либо код апача действительно криво написан. в последнем я сомневаюсь.
| | |
|
|
| 1.12, Аноним (-), 19:22, 30/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Может автор новости не заметил, но во _всех_ 14-и, а не в некоторых, приведённых результатах тестов х84-64 оказалась быстрее. Только в одном (первом) все оказались равны. В конце статьи недоверчивым предлагается провести тесты самим, со ссылками на тесты.
| | |
| |
| 2.13, Zenitur (?), 19:28, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
"Во всех, кроме одного" не звучит.
А статья нужная. Многие ропчут на x86_64 и говорят, что прирост мизерный и незаметный совершенно, так что специально для них появилась ещё одна ссылка.
| | |
|
| |
| 2.15, Аноним (-), 19:53, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
а postmark - в 10 раз
они явно что-то намутили.
ибо это серьезная деградация x86 по отношению к 86_64
| | |
|
| 1.17, ЙА Не АНАНИМ (?), 21:18, 30/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Мужики? Ну откуда x86_64 будет быстрее x86_32? Ну реально, в чем? Все тоже самое, те же атомы, просто адресация расширилась с 64 битами и все процессы стали жрать оперативы в два раза больше...
ппц...
| | |
| |
| 2.18, Karpion (ok), 21:23, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Оттуда, что там более другая система команд, не столь завязанная на совместимость с 8086. AFAIK.
| | |
| 2.21, noname (??), 22:34, 30/12/2009 [^] [^^] [^^^] [ответить]
| +2 +/– |
Мне кажется, дело в дополнительных регистрах, новом ABI и значительно меньшем использовании стека.
| | |
| 2.22, Zulu (?), 12:21, 31/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
> те же атомы
> все процессы стали жрать оперативы в два раза больше
лютый фейспалм.
| | |
| 2.24, Карбофос (ok), 22:27, 01/01/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>и все процессы стали жрать оперативы в два раза больше...
а это с какого перепуга? история показала, что размерность байта при при переходе с 8битной архитектуры на 16битную не изменилась.
| | |
| |
| 3.25, ЙА Не АНАНИМ (?), 03:21, 03/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
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 а не полгига, скажем?.
| | |
| |
| 4.26, pavlinux (ok), 03:33, 03/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
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 cached
PID 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
| | |
| 4.30, Карбофос (ok), 13:24, 03/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
просто узнайте куда и чего и спрашивайте у девелоперов, почему.
cat /proc/<pid>/maps
| | |
|
|
|
| 1.19, Karpion (ok), 21:25, 30/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
PAE вызовер рельное падение производительности при условии, что в системе более четырёх гигабайт RAM; и видимо, нужно, чтобы сумма памяти, занимаемой приложениями, тоже была больше четырёх гигабайт.
| | |
| |
| 2.28, ТТТ (?), 11:23, 03/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Лично я за переход на 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-х битных собратьев
| | |
|
|
