The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Сравнение производительности различных x86 архитектур

30.12.2009 13:08

Phoronix провёл тестирование производительности архитектур x86, x86 PAE и x86-64 в дистрибутиве Ubuntu, используя конфигурацию компьютера с 4GB RAM и Linux ядром 2.6.31. Линус Торвальдс предупреждал, что использование PAE может негативно сказаться на производительности (до 25%), однако тесты Phoronix это не подтвердили.

По результатам тестирования, ядра Linux x86 и x86 с PAE показали приблизительно одинаковую производительность, зато на синтетических тестах архитектура x86-64 оказалась в некоторых тестах на порядок быстрее.

  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
Автор новости: Artem S. Tashkinov
Тип: Обобщение
Короткая ссылка: https://opennet.ru/24859-x86
Ключевые слова: x86, x86-64, benchmark, pae
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (27) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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.4, const86 (ok), 16:08, 30/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > виртуал машин

    Это тут вообще никаким боком.

     
  • 3.16, cvsup (ok), 20:20, 30/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Дополнительный уровень вложенности: таблица указателей на page directory - page directory pointer table (pdpt_entry_t)
     

  • 1.3, segoon (ok), 16:05, 30/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Скажите, почему у апача такая разница в тестах? В чём дело?
     
     
  • 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%. что-то тут не так с арифметикой. либо код апача действительно криво написан. в последнем я сомневаюсь.
     
     
  • 4.27, aurved (?), 08:24, 03/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    наверно все-таки не "адрессировать", а адресовать


     
     
  • 5.29, Карбофос (ok), 13:15, 03/01/2010 [^] [^^] [^^^] [ответить]  
  • +/
    да, уж извините за ошибку великодушно
     

  • 1.12, Аноним (-), 19:22, 30/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Может автор новости не заметил, но во _всех_ 14-и, а не в некоторых, приведённых результатах тестов х84-64 оказалась быстрее. Только в одном (первом) все оказались равны. В конце статьи недоверчивым предлагается провести тесты самим, со ссылками на тесты.
     
     
  • 2.13, Zenitur (?), 19:28, 30/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    "Во всех, кроме одного" не звучит.
    А статья нужная. Многие ропчут на x86_64 и говорят, что прирост мизерный и незаметный совершенно, так что специально для них появилась ещё одна ссылка.
     

  • 1.14, Аноним (-), 19:51, 30/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    разница по апачу в 20 раз кажется НУ ОЧЕНЬ ПОДОЗРИТЕЛЬНОЙ
     
     
  • 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-х битных собратьев

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру