The OpenNET Project / Index page

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

Проект гибридного x86_64 Linux ABI с 32-битной адресацией памяти X32

20.02.2012 21:14

Ганс Питер Анвин (Hans Peter Anvin), один из ключевых разработчиков Linux-ядра в компании Intel и создатель таких проектов как syslinux, klibc и LANANA, опубликовал в списке рассылки разработчиков ядра Linux серию патчей, реализованных в рамках проекта X32, нацеленного на создание гибридного x86_64 ABI с 32-х битной адресацией памяти.

X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, эмулирующую на 64-разрядных системах 32-х битную модель адресации памяти. Как следствие, приложения могут использовать все преимущества архитектуры x86_64, такие как дополнительные регистры, более быстрые инструкции, PIC ABI, но в то же время смогут работать с 32-х битными указателями памяти, что положительно скажется на потреблении памяти, кэша и общей скорости исполнения кода.

Замеры производительности, сделанные разработчиками, показали, что внедрение нового ABI в некоторых случаях позволяет добиться прироста скорости исполнения кода до 32% в сравнении с классическим x86_64 ABI, хотя не исключены ситуации, в которых наблюдается небольшое падение производительности на 0.5-6%. Также ограничением служат запросы приложения к размеру используемой оперативной памяти, которые теперь ограничиваются 4 Гб.

Для реализации X32 ABI разработчикам потребовалось добавить около 1000 строк кода в ядро Linux, а также интегрировать поддержку новой "архитектуры" в пакеты binutils, libc и GCC. Патчи, а также инструкции по сборке и установке можно получить на официальной странице проекта.



  1. Главная ссылка к новости (https://lkml.org/lkml/2012/2/1...)
Автор новости: Evgeny Zobnin
Тип: К сведению
Ключевые слова: abi, x86_64, linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (174) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, h31 (ok), 21:33, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    О, отличная вещь. Как раз ушёл с amd64 из-за потребления памяти.
     
     
  • 2.2, AlexAT (ok), 21:43, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Проще добавить памяти - она сегодня настолько дешевая, что можно не заморачиваться.
     
     
  • 3.10, klalafuda (?), 22:05, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > Проще добавить памяти - она сегодня настолько дешевая, что можно не заморачиваться.

    А также сменить мать, системник ну и проц до кучи. Когда свободных посадочных мест под планки памяти уже нет.

     
     
     
    Часть нити удалена модератором

  • 5.35, xoomer (ok), 22:57, 20/02/2012 [ответить]  
  • +2 +/
    Хм, а что делать с нетбуками?
    4-Гб планка - хорошо, но её энергопотребление больше, чем у 2-Гб...
     
     
  • 6.52, BratSinot (?), 23:43, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Для начала посчитай количество нетбуков с amd64 и c x86. А ноуты не просто так под amd64, там уже 3+GiB, а PAX еще больший костыль был.
     
     
  • 7.81, Yakov Markovitch (?), 00:57, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пардон? Все нетбучные Интел Атомы, начиная с 300-й серии (330 и далее, т.е. как минимум с 2010 года) поддерживают x86-64.
     
     
  • 8.217, BratSinot (?), 11:30, 06/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Читать умеем ... текст свёрнут, показать
     
  • 7.105, Аноним (-), 06:26, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    из атомов только самый первый (N270) не умеет х86_64
     
  • 4.33, terr0rist (ok), 22:51, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Знаем-знаем, Athlon64 (K8) c 2 слотами ДДР1 =)
    Проще сменить архитектуру - а главное, бесплатно! Хотя есть ли вообще смысл использовать амд64 на <4гиг, тоже вопрос. Разве что понты?
     
     
  • 5.53, BratSinot (?), 23:46, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Знаем-знаем, Athlon64 (K8) c 2 слотами ДДР1 =)
    > Проще сменить архитектуру - а главное, бесплатно! Хотя есть ли вообще смысл
    > использовать амд64 на <4гиг, тоже вопрос. Разве что понты?

    Быстрая обработка чисел за раз, SSE, SSE2 в стандарте, доп. регистры и т.д.

     
  • 5.54, BratSinot (?), 23:47, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Всмысле более быстрая обработка бОльших чисел.
     
  • 5.84, me (??), 01:07, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Есть: можно делать mmap больших файлов в большом количестве не боясь вычерпать адресное пространство процесса.
     
  • 4.39, AlexAT (ok), 23:10, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Проще добавить памяти - она сегодня настолько дешевая, что можно не заморачиваться.
    > А также сменить мать, системник ну и проц до кучи. Когда свободных
    > посадочных мест под планки памяти уже нет.

    Вам мало 16 гиг на десктопе? :)

     
     
  • 5.114, Аноним (-), 08:54, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >>> Проще добавить памяти - она сегодня настолько дешевая, что можно не заморачиваться.
    >> А также сменить мать, системник ну и проц до кучи. Когда свободных
    >> посадочных мест под планки памяти уже нет.
    > Вам мало 16 гиг на десктопе? :)

    Им масла в рогах мало. Длину и качество члена они заменяют длиной и количеством планок памяти. А потом стонут - "Мне тысячу закладок в файрфоксе открыть не хватает!" :D:D:D:D

     
     
  • 6.165, Аноним (-), 16:23, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    87 вкладок в опере. )
    $ free -m
                 total       used       free     shared    buffers     cached
    Mem:         16083       2461      13621          0         62        520
    -/+ buffers/cache:       1878      14204
    Swap:            0          0          0
     
     
  • 7.174, playnet (ok), 17:11, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > 87 вкладок в опере. )

    90 вкладок в хроме съедают 8 гиг рамы - пример мега прожорливости. При этом процессов хрома под 100. С другой стороны, в отличии от фф он не течет и выжирает свои 8 гиг где-то через 2-3 дня после открытия, без существенного роста и через месяц. В отличии от фф...Плюс отзывчивость хрома не в пример лучше.

     
     
  • 8.176, linvinus (?), 17:41, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    покажите скрин где в хроме умещаются все 90 вкладок и можно работать Это единс... текст свёрнут, показать
     
     
  • 9.206, playnet (ok), 22:07, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Окон при этом конечно не 1 - по окну на задачу, и не больше 15 табов на окно То... текст свёрнут, показать
     
  • 2.99, Аноним (-), 04:39, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > О, отличная вещь. Как раз ушёл с amd64 из-за потребления памяти.

    Отличается процентов на 20 в большинстве программ, не более. И как-то на машине с 8 Гб 32 бита просто не могут заадресовать мне всю мою память...

     
     
  • 3.124, Я (??), 11:19, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И как-то на машине с 8 Гб 32 бита просто не могут заадресовать мне всю мою память...

    Совсем никак?

     
     
  • 4.141, Ваня (??), 13:43, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ОС может до 64 Гб, приложения совсем никак.
     
  • 3.161, Frank (ok), 16:14, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вот смотрю на самое жрущее после BOINC приложение - firefox - и вижу +50% потребления как минимум, после перехода на х64.
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    5527 frank     20   0 2465m 1.5g  24m S   41 27.4 882:49.39 firefox
    Вкладок всего лишь пару десятков, да.
     
     
  • 4.168, Аноним (-), 16:26, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот смотрю на самое жрущее после BOINC приложение - firefox - и
    > вижу +50% потребления как минимум, после перехода на х64.
    >   PID USER      PR  NI
    >  VIRT  RES  SHR S %CPU %MEM  
    >  TIME+  COMMAND
    >  5527 frank     20   0 2465m
    > 1.5g  24m S   41 27.4 882:49.39 firefox
    > Вкладок всего лишь пару десятков, да.

    VIRT  RES   SHR  CPU  %MEM
    1826m 1.3g  25m  25   8.2

    Opera
    Версия: 11.61
    Сборка: 1250
    Платформа: Linux
    Система: x86_64, 3.2.1

    87 вкладок.

     

  • 1.3, Df232z (ok), 21:49, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Это не просто костыль, а как-то особо в космических масштабах с отягчающими обстоятельствами костыль.
     
     
  • 2.4, Df232z (ok), 21:51, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    А, ядро все стерпит.
     
  • 2.14, Michael Shigorin (ok), 22:16, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Это не просто костыль, а как-то особо в космических масштабах

    Почему?  Если памяти много процессам не требуется, а вот появившиеся в этом веке регистры с командами не помешают -- вполне занятный хак, о котором было слышно ещё осенью, что ли.

     
     
  • 3.20, Df232z (ok), 22:29, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Если памяти много процессам не требуется,

    Сейчас? А через год? Два? Или 4gb хватит всем?

     
     
  • 4.22, Michael Shigorin (ok), 22:32, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +8 +/
    >>Если памяти много процессам не требуется
    > Сейчас? А через год? Два? Или 4gb хватит всем?

    Вы так пишете, как если бы собственно x86_64 собирались выкинуть...  Добавляется _возможность_, для многих типов задач -- действительно полезная, но вовсе не обязательная к применению любой ценой.

     
     
  • 5.24, Df232z (ok), 22:34, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Намекаю: перекомпиляция приложений. А иметь в системы два варианта программы под разные архитектуры удовольствие маленькое.
     
     
  • 6.89, neindog (?), 01:48, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    запуск в контейнерах/виртуалках под ограниченный круг задач, например, dns-сервер, веб-сервер и т.п
     
  • 5.27, Df232z (ok), 22:39, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не говоря уже о том что они собираются под свои нужды патчить libc, что, мягко говоря, требует длительного тестирования, чем, судя по их сайту, они заниматься не собираются.
     
     
  • 6.31, Michael Shigorin (ok), 22:49, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Намекаю: перекомпиляция приложений.

    Само собой.

    > Не говоря уже о том что они собираются под свои нужды патчить libc

    Что-то мне подсказывает, что hpa справится.

    > не собираются.

    Видите ли, это не те люди, у которых на сайтЕ сплошное жонглирование подробными планами.  Это те, благодаря которым на моих и Ваших линуксах всё вообще в принципе загружается и работает.

     
     
  • 7.44, Df232z (ok), 23:13, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >Что-то мне подсказывает, что hpa справится.

    А SELINUX мне подсказывает что если и справится то проблем будет больше чем пользы.
    >Видите ли, это не те люди, у которых на сайтЕ сплошное жонглирование подробными планами.

    Да, планов на сайте у них мало. Зато сообщений о багах много.

     
     
  • 8.79, Michael Shigorin (ok), 00:49, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ... текст свёрнут, показать
     
     
  • 9.86, Df232z (ok), 01:26, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    syslinux конечно ... текст свёрнут, показать
     
     
  • 10.93, Michael Shigorin (ok), 01:57, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И какие у Вас претензии к syslinux, о путающий его с SELINUX ... текст свёрнут, показать
     
     
  • 11.100, Аноним (-), 04:40, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нормально так перепутал ... текст свёрнут, показать
     
  • 11.169, Крокозяблик (?), 16:28, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    видимо нет даёт ему удовлетворения ... текст свёрнут, показать
     
     
  • 12.183, filosofem (ok), 19:23, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    не радует... текст свёрнут, показать
     
  • 4.30, Hugo Reyes (ok), 22:48, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И много у тебя в системе процессов, потребляющих более 4gb памяти?
    Не думаю, что через 2 года их количество увеличится хотя бы на 5%
     
     
  • 5.38, Df232z (ok), 23:09, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >И много у тебя в системе процессов, потребляющих более 4gb памяти?

    3. Догадаешься каких?

     
     
  • 6.51, Hugo Reyes (ok), 23:40, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>И много у тебя в системе процессов, потребляющих более 4gb памяти?
    > 3. Догадаешься каких?

    для всех остальных можно использовать прослойку X32

     
     
  • 7.58, Аноним (-), 00:11, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > для всех остальных можно использовать прослойку X32

    А что, она позволяет _выборочное_ применение к процессам?
    В новости написано, что она требует специального ядра и окружения, т.е. отдельного хоста (физического или виртуального).

     
     
  • 8.66, Hugo Reyes (ok), 00:26, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    под отдельным окружением имеется ввиду поддержка X32 в glibc, gcc, binutils, и я... текст свёрнут, показать
     
  • 8.69, Hugo Reyes (ok), 00:34, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    IA32-архитектура требует отдельного окружения, и что для запуска 32-битных прил... текст свёрнут, показать
     
     
  • 9.207, Аноним (-), 12:26, 27/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Что и что Читай по слогам ... текст свёрнут, показать
     
     
  • 10.208, Hugo Reyes (ok), 12:28, 27/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Про отдельный хост в новости ничего не говорится ни про физический, ни про вирт... текст свёрнут, показать
     

     ....нить свёрнута, показать (23)

  • 1.5, Anonimous (?), 21:51, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    А вот на VDS-ках было бы актуально.
     
  • 1.6, Аноним (-), 21:52, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >приложения могут использовать все преимущества архитектуры x86_64, такие как дополнительные регистры, более быстрые инструкции, PIC ABI, но в то же время смогут работать с 32-х битными указателями памяти

    А как дополнительные регистры сохранить с 32-х битными указателями памяти?
    Читаю про MOV:
    >Opcodes A0–A3, in 64-bit mode, are the only cases that support a 64-bit offset value.

     
     
  • 2.194, ZloySergant (ok), 00:13, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >А как дополнительные регистры сохранить с 32-х битными указателями памяти?

    По abi - указатель (всегда 32-х битный) загоняется в регистр (%rbx, %rbp, %r10 и т.д.). Биты с 32 по 63 - нули.

     

  • 1.7, alexxy (ok), 21:55, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кто то вспомнил про то что в 90х на mips было n32 ABI и решил её реинкарнировать но на ia32 =D
     
  • 1.9, Аноним (-), 22:05, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чудесно. И приделать адресацию больших объемов памяти через PAE
     
     
  • 2.13, Crazy Alex (ok), 22:16, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да есть куча случаев, когда адресация больших объемов не нужна. Ну то есть вообще. И подозреваю, что средний десктоп - это как раз тот самый случай.
     
     
  • 3.142, Xasd (ok), 14:12, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    както я написал скрипт да да, для десктопа который обрабатывает инфу и впри... текст свёрнут, показать
     
     
  • 4.179, Crazy Alex (ok), 18:50, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Писание скриптов (увы) никак не укладывается в "средний десктоп". А для стандартного набора  - браузер/плеер/офис/картинки/игры 4-х гиг на программу явно хватает - графический редактор один черт свой свап использует.

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

     
  • 4.180, Crazy Alex (ok), 18:51, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    gt оверквотинг удален Или если ответить по-другому - лучше пусть оно сломается... текст свёрнут, показать
     

  • 1.11, Андрей (??), 22:08, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Помню читал в lkml, что Линусу такой подход (или его предложенная реализация) не понравился.

    Вот бы иметь статистику, как часто одно приложение на десктопе/сервере потребляет более 4 ГБ памяти. Я так понимаю, что 4 ГБ - ограничение лишь на каждую прогу по отдельности, а не на все в целом, т.к. хост - 64битный.

    Да и такие исключения можно запускать чистыми x86_64.

     
     
  • 2.42, klalafuda (?), 23:12, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот бы иметь статистику, как часто одно приложение на десктопе/сервере потребляет более 4 ГБ памяти.

    vmware а лучше сразу несколько копий. в т.ч. на десктопе.

     
     
  • 3.59, Аноним (-), 00:13, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > vmware а лучше сразу несколько копий. в т.ч. на десктопе.

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

     
     
  • 4.71, Hugo Reyes (ok), 00:36, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Сабж нужен для скорости, а на хостах с вмварью про скорость никто
    > никогда не слышал.

    "виртуализация на серверах? не, не слышал"

     
  • 3.112, agapit (?), 08:44, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >> Вот бы иметь статистику, как часто одно приложение на десктопе/сервере потребляет более 4 ГБ памяти.
    > vmware а лучше сразу несколько копий. в т.ч. на десктопе.

    Так вам и не нужно vmware запускать в данном режиме. Это было бы верх долбоебизма. А вот внутри виртуалок процессы запускать - вполне нормально будет.

     
  • 2.143, Xasd (ok), 14:18, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Вот бы иметь статистику, как часто одно приложение на десктопе/сервере потребляет более 4 ГБ памяти.

    при чём тут "как часто"? если это случилось у человека хотябы один раз -- то нужно понимать что человек получил сбой (или получил БЫ еслибы был на 32)! сбой которого ВПРИНЦЕПЕ не должно было быть!

    ...по вашему это нормально кагда програмы УМЫШЛЕННО сбоят, в случаях если эти сбои редкие????

    переход 64=>32 это заведомо УМЫШЛЕННОЕ обрекание программ на редкие сбои!

     
     
  • 3.177, виндотролль (?), 18:29, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Странная логика, если честно. Эдак дойдем до того, что покупка компьютера с 8 ГБ памяти это заведомо обрекание программ на редкие сбои, надо не меньше 64 ГБ...
     

  • 1.12, Crazy Alex (ok), 22:14, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отличная идея, давно пора. Как минимум у себя на десктопе я не знаю приложения, которое способно было бы сожрать 4 гига.
     
     
  • 2.60, Аноним (-), 00:14, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Отличная идея, давно пора. Как минимум у себя на десктопе я не
    > знаю приложения, которое способно было бы сожрать 4 гига.

    Запустите что-нибудь на яве, vuze например. Или firefox свежий.

     
     
  • 3.103, Crazy Alex (ok), 05:43, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да в файрфоксе я всё время сижу, пока больше двух гиг не было, хотя вкладок и за две сотни переваливает. А яве на десктопе делать нечего, тем более в виде vuze. Лично у меня rtorrent прижился даже без морд, но и всяких гуёвин со вменяемым потреблением ресурсов хватает.
     

  • 1.16, Аноним (-), 22:22, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    может просто поставить 32 битную систему с PAE ядром?
     
     
  • 2.19, Аноним (-), 22:28, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это не то, в новости так и написано, что программы смогут использовать все плюшки x86_64, однако будут оперировать 32-битными указателями, что повысит производитьельность и уменьшит потребление памяти
     
  • 2.23, Anonus (?), 22:33, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    регистры
     
     
  • 3.128, антоним (?), 11:56, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Что регистры? Вот что есть в 64 битном режиме. Кажется, ровно то же самое что и в 32 битном режиме - основные регистры, сопроцессор, ммх и ссе.

    Архитектура x86-64 имеет:
    16 целочисленных 64-битных регистра общего назначения (RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, R8 — R15);
    8 80-битных регистров с плавающей точкой (ST0 — ST7);
    8 64-битных регистров Multimedia Extensions (MM0 — MM7, имеют общее пространство с регистрами ST0 — ST7);
    16 128-битных регистров SSE (XMM0 — XMM15);
    64-битный указатель RIP и 64-битный регистр флагов RFLAGS.

     
     
  • 4.136, Аноним (-), 13:29, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    кажись, как минимум, целочисленных общего назначения в два раза меньше было. Наверное доступ к тем R8-R15 только в 64-битном режиме. Соответственно, если использовать "понимающий" компилятор и перекомпилировать программы, то большее число вызовов функций теперь параметры будут передавать через эти регистры общего назначения, а не через стек. Что значительно быстрее.
     
  • 4.140, Аноним (-), 13:42, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    х86:
    EAX, EBX, ECX, EDX, EBP, ESI, EDI, ESP - 8 регистров общего назначения, а не 16
    регистров много не бывает.
     
  • 4.214, Аноним (-), 10:10, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > 16 128-битных регистров SSE (XMM0 — XMM15);

    А в IA32 их 8 (XMM0 - XMM7).


     

  • 1.17, Zenittur (?), 22:22, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Это железо появилось ещё полгода назад, а поддержкап в Linux только что. На чём же оно работало?
     
     
  • 2.82, the joker (ok), 01:00, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Железо? Ядро не железное. Это заблуждение.
     

  • 1.18, Петр (??), 22:26, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А смысл? 32 бита сейчас актуальны в основном для поддержки старого железа, которое в обозримом будущем окончательно устареет. Экономия памяти? При ее современных объемах и стоимости нет смысла делать что-то новое - кому позарез нужно, есть PAE.
     
     
  • 2.21, Аноним (-), 22:29, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я согласен, однако если подумать, то тут возможно помимо экономии памяти и на производительность как-то повлияет.
     
     
  • 3.32, Michael Shigorin (ok), 22:50, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Я согласен, однако если подумать, то тут возможно помимо экономии памяти и
    > на производительность как-то повлияет.

    hint: L1/L2 cache -- тоже память.

     
     
  • 4.48, AlexAT (ok), 23:16, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > hint: L1/L2 cache -- тоже память.

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

     
     
  • 5.73, Hugo Reyes (ok), 00:37, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> hint: L1/L2 cache -- тоже память.
    > Префиксы. Не забывайте, что изменение размера операнда - тоже не особо ценный
    > мех, и в ряде случаев сожрет все плюсы от мелких указателей.

    размеры новых операндов выровнены для быстрого prefetch

     
  • 2.28, terr0rist (ok), 22:43, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А смысл использовать 64-битные указатели, если достаточно 32-битных? :)
    Ваш вопрос похож на вопрос автомобилиста в США в 70-х: "Если бензин такой дешёвый, нафига нужны маленькие машины и дизельные двигатели?"
     
     
  • 3.134, Ваня (??), 13:05, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А смысл тогда в булевых переменных? sizeof(bool) = 1 байт, хотя по факту используем лишь 1 бит. Жутко неэффективно, батенька, коэффициент эффективности лишь 1/8 = 12,5%. В то время как в ситуации с указателями = 1/2 = 50%.
     
     
  • 4.178, Lain_13 (?), 18:46, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Булевы переменные нужны исключительно для удобства и этим компенсируют свою неэффективность. Если тебе нужна эффективность — используй битовые поля и << move it, move it >>.
     

  • 1.26, MidNighter (?), 22:37, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Все почемуто забыли о встраиваемых системах, роутерах, телефонах на ядре.. там ведь нет потребления более 4гб памяти. Если этот патч ускорит производительность работы с памяти на подобных системах то это конечно будет здорово.
     
     
  • 2.34, Michael Shigorin (ok), 22:52, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Все почемуто забыли о встраиваемых системах, роутерах, телефонах на ядре..

    Это всё-таки не x86 в подавляющем большинстве, так что именно эта новость их прямщас скорее не затрагивает (хотя понятно, что интелу такое положение дел покоя не даёт).

     
     
  • 3.41, Crazy Alex (ok), 23:11, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Есть вагон встроенных систем на x86 - но вот 64 бит там обычно нет и близко. Зато может 386 оказаться :-)
     
     
  • 4.119, Аноним (-), 09:37, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Есть вагон встроенных систем на x86 - но вот 64 бит там
    > обычно нет и близко. Зато может 386 оказаться :-)

    Современные аццкие одмины обычно не знают или не помнят о такой вещи, как промэлектроника.

     

  • 1.36, filosofem (ok), 22:58, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >что внедрение нового ABI в некоторых случаях позволяет добиться прироста скорости исполнения кода до 32%

    За счет чего так?

     
     
  • 2.43, Crazy Alex (ok), 23:13, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    За счет локальности, вестимо. В отдельных (редких) случаях от попадания или не попадания в кэш всего алгоритма производитлеьность может меняться на порядки, не то что на 30%.
     
     
  • 3.138, Ваня (??), 13:38, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Здесь стоит добавить что в новых поколениях процессоров оптимизированные под старые поколения процессоров программы зачастую работают медленнее вообще неоптимизированных. Халявы не будет.
     
     
  • 4.193, Crazy Alex (ok), 00:08, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В опенсорс-мире в большинстве случаев это решается простой перекомпиляцией :-) В оставшихся -вроде кодирования/декодирования видео - да, надо добавлять ручные оптимизации, что и делается.
     
  • 2.49, AlexAT (ok), 23:18, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>что внедрение нового ABI в некоторых случаях позволяет добиться прироста скорости исполнения кода до 32%
    > За счет чего так?

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

     
     
  • 3.50, Crazy Alex (ok), 23:22, 20/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тесты они там на вид стандартные гоняют.
     
  • 2.56, СуперАноним (?), 00:06, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >За счет чего так?

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

     
     
  • 3.110, AlexAT (ok), 07:34, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Команды прямой адресации короче => больше команд помещается на конвейере, за один
    > цикл чтения из области кода излекается больше команд, декодирование более коротких
    > команд быстрее.

    Ага, зато у каждой команды, работающей с широкими операндами, появляется префикс смены размера операнда.

     

  • 1.55, антоним (?), 23:50, 20/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Замеры производительности, сделанные разработчиками, показали, что внедрение
    > нового ABI в некоторых случаях позволяет добиться прироста скорости исполнения
    > кода до 32% в сравнении с классическим x86_64 ABI, хотя не исключены ситуации,
    > в которых наблюдается небольшое падение производительности на 0.5-6%.

    Что должно означать что 64 битный код на 32% медленнее 32-битного на том же железе в тех же условиях. Поскольку такого в реальности не наблюдается то делаем вывод - автор чего-то темнит.  

     
     
  • 2.62, annulen (ok), 00:16, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Что должно означать что 64 битный код на 32% медленнее 32-битного на том же железе в тех же условиях.

    Не просто 32-битного, а 32-битного, использующего 16 регистров общего назначения

     
  • 2.80, zuborg (?), 00:56, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Скорость выполнения кода на современных процессорах настолько высока, что зачастую ограничивается не столько вычислительными блоками процессора, сколько системой памяти.
    Уменьшение размеров указателей в два раза позволяет значительно сократить обьемы пересылаемых данных, а также поместить больше данных в кеш, так что прирост 32% выглядит абсолютно адекватно.
     
     
  • 3.88, антоним (?), 01:45, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Уменьшение размеров указателей в два раза позволяет значительно сократить обьемы
    > пересылаемых данных, а также поместить больше данных в кеш, так что прирост 32% выглядит
    > абсолютно адекватно.

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

     
     
  • 4.102, inferrna (?), 05:09, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Не просто 32-битного, а 32-битного, использующего 16 регистров общего назначения
     
  • 4.125, zuborg (?), 11:25, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Собственно говоря, этот прирост в чистом 32-х битном режиме и обнаруживается (для тех типов приложений, которые оперируют данными, состоящими значительной частью из указателей). Проявляется в виде соответствующего падения производительности при работе такой программы в 64-х битном режиме.

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

     
     
  • 5.137, Ваня (??), 13:36, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Подробнее можно?

    Кто мешает в начале программы обнулить все 64-разрядные регистры, дальше оперируя исключительно 32-разрядными регистрами?

     
     
  • 6.144, zuborg (?), 15:02, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    64-х битный указатель нельзя просто так обнулить и использовать его 32-х битную младшую половину.
     
     
  • 7.148, Ваня (??), 15:37, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это кто тебе такую глупость то сказал?

    ; обнуляем 64-разрядные регистры
    xor rsi,rsi
    xor rdi,rdi
    xor rcx,rcx

    ; дальше используем только 32-разрядный код
    mov esi,src  ; 32-разрядный указатель
    mov edi,dest ; 32-разрядный указатель
    mov ecx,cnt
    rep movsd

     
  • 5.139, антоним (?), 13:41, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Собственно говоря, этот прирост в чистом 32-х битном режиме и обнаруживается (для тех
    > типов приложений, которые оперируют данными, состоящими значительной частью из
    > указателей). Проявляется в виде соответствующего падения производительности при работе
    > такой программы в 64-х битном режиме.

    Из чего и делаем вывод, что данная фишка имеет смысл только если 64-битная программа медленней 32-битной. И много таких встречалось?

     
     
  • 6.145, zuborg (?), 15:05, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Собственно говоря, этот прирост в чистом 32-х битном режиме и обнаруживается (для тех
    >> типов приложений, которые оперируют данными, состоящими значительной частью из
    >> указателей). Проявляется в виде соответствующего падения производительности при работе
    >> такой программы в 64-х битном режиме.
    > Из чего и делаем вывод, что данная фишка имеет смысл только если
    > 64-битная программа медленней 32-битной. И много таких встречалось?

    Согласен, данный патч не имеет особенного смысла на десктопах и большинстве веб-серверов.
    Возможно базы данных, специфическая математика, ну и ембед-системы с жесткими лимитами на память..
    Никто и не призывает его пользовать везде и повсюду. Но сама идея вовсе не так абсолютно бесполезна, как некоторые пытаются заявить.

     
     
  • 7.147, annulen (ok), 15:24, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >ембед-системы с жесткими лимитами на память

    Нафига в "ембед-системе" x86(64)? Нормальных архитектур хватает

     
     
  • 8.157, Xasd (ok), 16:04, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    1 для десктопа эта new X32 архитектура не нужна 2 для embedded -- есть архит... текст свёрнут, показать
     
  • 7.173, ананим (?), 16:41, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Согласен, данный патч не имеет особенного смысла на десктопах и большинстве веб-серверов.

    глупости какие "спецы" несут.
    именно для десктопа и сервисов с малым потреблением памяти это и нужно.

    этот патч - это создание 64-разрядных приложений, но с 32-х битной адресацией памяти.
    т.е. всё работает как в 64 битах - а это sse, 64-битная логика (в 1 тик),... да даже таймер hpet.
    куча вещей не доступна для 32-бит в современном компе.
    а 64-бита - перерасход озу. порой в 2-а раза.

     
     
  • 8.182, Xasd (ok), 19:12, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а потом нистого ниссего оказывается что некая-программа не может работать с фа... текст свёрнут, показать
     
     
  • 9.184, ананим (?), 19:40, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Какой ужОснах Т е эта программа не работала бы и в 32-битном режиме вообще Он... текст свёрнут, показать
     
  • 9.188, Аноним (-), 21:44, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Нее, это потому что в одной убогой системе off_t по умолчанию 32-битный ... текст свёрнут, показать
     
  • 9.189, angra (ok), 21:58, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    То есть загрузка в память для обработки всего файла это по-вашему нормально Мож... текст свёрнут, показать
     
     
  • 10.204, AlexAT (ok), 19:10, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Бугага, учите матчасть memory mapping загрузка файла... текст свёрнут, показать
     
     
  • 11.205, Andrey Mitrofanov (?), 19:17, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, и, __конечно__ же, не _всего файла Ога-ога ... текст свёрнут, показать
     
  • 2.106, Аноним (-), 06:41, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Пиковые значение именно такие, правда бывает это редко. Особенно выражено на атомах и других процессорах с (очень) маленьким кэшем.
     
  • 2.132, arikhin (ok), 12:53, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Что должно означать что 64 битный код на 32% медленнее 32-битного на
    > том же железе в тех же условиях. Поскольку такого в реальности
    > не наблюдается то делаем вывод - автор чего-то темнит.

    Linux с переходом на 64 теряет очень много \к сожалению в том числе скорость\

     
     
  • 3.135, AlexAT (ok), 13:06, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Linux с переходом на 64 теряет очень много \к сожалению в том
    > числе скорость\

    OMGWTF?

     

     ....нить свёрнута, показать (22)

  • 1.63, Аноним (-), 00:19, 21/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Кому это на ноуте понадобилось больше чем 4 гига памяти?! Под какие такие нужды?! Наверное сервер с ноута хотите сделать?! Пусть ноуты будут x86, тут вам и лишнего потребления памяти не будет, и энергии батареи. Хотите мощность садитесь за десктоп, нужно еще мощности садитесь за сервер. Производительности без потерь не бывает.

    Хотите видеть больше 4гб память на x86 то PAE вам в руки.

     
     
  • 2.65, Аноним (-), 00:22, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Кому это на ноуте понадобилось больше чем 4 гига памяти?! Под какие такие нужды?! Наверное сервер с ноута хотите сделать?!

    Пользователи Chrome/Chromium смотрят на вас с недоумением.

     
     
  • 3.68, Hugo Reyes (ok), 00:32, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    использую на работе хром на 4-гиговом ноуте, смотрю на коммент с недоумением.
     
     
  • 4.72, Аноним (-), 00:36, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > использую на работе хром на 4-гиговом ноуте, смотрю на коммент с недоумением.

    Знаем, знаем, с 3 вкладками.

     
     
  • 5.74, Hugo Reyes (ok), 00:39, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> использую на работе хром на 4-гиговом ноуте, смотрю на коммент с недоумением.
    > Знаем, знаем, с 3 вкладками.

    зачем? 10-15 вкладок.

     
     
  • 6.76, Аноним (-), 00:41, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Знаем, знаем. Вам печатная машинка нужна, а тут компьютеры обсуждают. Проходите мимо.
     
     
  • 7.78, Hugo Reyes (ok), 00:44, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Знаем, знаем. Вам печатная машинка нужна, а тут компьютеры обсуждают. Проходите мимо.

    Поиграть на нем тоже можно. Oil Rush, например, на ура идет. хром закрывать не приходится.

     
     
  • 8.101, Аноним (-), 04:45, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А у меня хромиум может запросто спровоцировать oom killer на машине с 8Г операти... текст свёрнут, показать
     
     
  • 9.115, Hugo Reyes (ok), 08:56, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ну так не используйте бета-версию... текст свёрнут, показать
     
     
  • 10.187, Аноним (-), 21:43, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё не хватало Разумеется от версии это не зависит ... текст свёрнут, показать
     
  • 6.77, Hugo Reyes (ok), 00:41, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > зачем? 10-15 вкладок.

    помимо этого еще запущен netbeans или eclipse (в зависимости от проекта)
    в виртуалке постоянно крутится pl/sql-developer.
    тормозов не замечаю.

     
  • 4.104, Crazy Alex (ok), 05:45, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Хром порождает несколько процессов, каждый из них сможет использовать 4 гигабайта памяти, насколько я понимаю.
     
  • 3.181, Lain_13 (?), 18:54, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вот уж кому не стоит беспокоиться, так это пользователям Chrome/Chromium. С такой архитектурой браузера переход обратно на 32-битную адресацию памяти это чистейший WIN. Много раз вы видели, чтоб один (и я подчёркиваю ОДИН) процесс хрома занимал 4 Гб?
     
  • 2.67, Hugo Reyes (ok), 00:31, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    больше памяти - жирнее дисковый кэш, меньше дискового IO, экономим электроэнергию на запусках диска/перемещениях головки.
    Даже если использовать твердотельный накопитель, то меньше телодвижений с 32-битным IO по шине SATA
     
  • 2.70, Аноним (-), 00:35, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Кому это на ноуте понадобилось больше чем 4 гига памяти?! Под какие такие нужды?! Наверное сервер с ноута хотите сделать?!

    Запомни, пионер - нет никакой разницы между "ноутом" и "сервером". Это тебе микрософт мозги промыл, потому что им выгодно втюхать тебе "домашнюю" винду с ограничением в 3 окна, потом "рабочую" когда ты поймёшь что на этом работать невозможно, а потом и "серверную". А если ты не знаешь зачем нужна память, мне тебя просто жаль.

     
     
  • 3.83, Аноним (-), 01:07, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Я смотрю, для вас напрочь отсутствует классификация оборудования исходя из сферы... текст свёрнут, показать
     
     
  • 4.96, Аноним (-), 02:27, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Она отсутствует не для меня, а объективно Я уже написал про промытые мозги, под... текст свёрнут, показать
     
     
  • 5.190, Аноним (-), 22:12, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А покажи мне ноут который по производительности натянет вот это http ck koli... текст свёрнут, показать
     
     
  • 6.192, Аноним (-), 23:15, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Когда вы видите слово "сервер" у вас в воображении возникают исключительно монструозные мейнфреймы и осбуживающие их техники в белых халатах ? Датацентры значительной частью забиты серверами более слабыми чем средний современный ноут и они не перестают быть серверами как это ни странно.

     
  • 2.85, Michael Shigorin (ok), 01:25, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хотите видеть больше 4гб память на x86 то PAE вам в руки.

    Спасибо, дружище.  Только вот не "больше 4", а "больше трёх с небольшим"; а тот же Линус рекомендовал применение x86_64 для систем от 1Gb RAM: http://www.realworldtech.com/forums/index.cfm?action=detail&id=78966&threadid (и лично у меня ядро с PAE гораздо чаще не просыпается по сравнению с нормальным).

    Так что для очень специфических случаев -- как вот когда корень на SSD должен быть совместим с core/core2 -- PAE применять приходится, но радости эти игрушки и впрямь не приносят.

    PS: и да, это мой мобильный сборочный сервер -- когда нет доступа к быстрому хосту, зато есть время, настроение и ещё несколько часов батареи.

     
     
  • 3.87, Аноним (-), 01:44, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вы хотите мощность и производительность без потерь. То есть хотите оперировать большим объемом информации и при этом ничем не жертвовать. Вы можете запускать на том же ноуте что угодно это ваше право, я с этим не спорю. Я лишь говорю о том, что получить все сразу и без жертв не получится.

    Арифметика проста:

    Если вы хотите оперировать большим объемом памяти, то вам нужна x86_64 но платой за это будут дополнительные расходы ресурсов системы которые уходят на обеспечение реализации ее работы.

     
     
  • 4.92, Michael Shigorin (ok), 01:55, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы хотите мощность и производительность без потерь.

    Отнюдь, трейдоффы вполне ясны.

     
  • 3.209, netch (ok), 18:09, 28/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Хотите видеть больше 4гб память на x86 то PAE вам в руки.
    > Спасибо, дружище.  Только вот не "больше 4", а "больше трёх с
    > небольшим"; а тот же Линус рекомендовал применение x86_64 для систем от
    > 1Gb RAM: http://www.realworldtech.com/forums/index.cfm?action=detail&id=78966&threadid

    Линус, как известный коммунист, ругается crap'ами и политическими проститутками примерно с такой же частотой, как Ленин. И неудивительно - им сам Белый Доктор так повелел. Но я так и не увидел ни у него, ни у оппонентов доказательства осмысленности границы тут именно в 1GB. У большинства более внятных комментаторов граница пробегает на 4GB, причины очевидны.

     
     
  • 4.210, Michael Shigorin (ok), 18:31, 28/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > У большинства более внятных комментаторов граница пробегает на 4GB, причины очевидны.

    Не смешно, поскольку если бы они вообще понимали, о чём говорят -- то цифра была бы в районе 3.2..3.5 (ну 3.6, не помню особо точно, но там зазор в несколько сот метров).  Проверено на куче всякого разного, от старых xeon'ов до не очень старых ноутов.

    PS: подозреваю/смутно припоминаю, что CONFIG_HIGHMEM4G уже таит костыли для проброса данных окошками, только и всего.  По крайней мере не всё железо физически умело DMA настолько высоко.

     
     
  • 5.211, netch (ok), 18:35, 28/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> У большинства более внятных комментаторов граница пробегает на 4GB, причины очевидны.
    > Не смешно, поскольку если бы они вообще понимали, о чём говорят --
    > то цифра была бы в районе 3.2..3.5 (ну 3.6, не помню
    > особо точно, но там зазор в несколько сот метров).

    Не домысливай. Память обычно ставят или 3, или уже 4, так 3 ещё нет, 4 уже да. Твои 3.6 по любому в этом диапазоне. Так что они понимают, о чём говорят, это ты читаешь справа налево.
    Так на исходный вопрос будет ответ? В чём магичность цифры 1GB, или Торвальдсу приглючилось?

     
     
  • 6.212, Michael Shigorin (ok), 00:36, 29/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    code free -m 124 head -2 total used free shar... текст свёрнут, показать
     
     
  • 7.213, netch (ok), 11:18, 29/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Что глянуть Что там будет доступно меньше чем 3 5 Спасибо, кэп Муть зелёная ... текст свёрнут, показать
     
  • 2.120, Аноним (-), 09:39, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Кому это на ноуте понадобилось больше чем 4 гига памяти?! Под какие
    > такие нужды?! Наверное сервер с ноута хотите сделать?! Пусть ноуты будут
    > x86, тут вам и лишнего потребления памяти не будет, и энергии
    > батареи. Хотите мощность садитесь за десктоп, нужно еще мощности садитесь за
    > сервер. Производительности без потерь не бывает.
    > Хотите видеть больше 4гб память на x86 то PAE вам в руки.

    Не поверишь, чувак. Для некоторых профессионалов ноут - не консьюмерский продукт посейчас. А рабочий инструмент. Из которого нужен именно что МОБИЛЬНЫЙ СЕРВЕР. Вдумайся. И там, случается, приходится и Oracle EE гонять. И одновременно пару-тройку активных виртуалок. А иногда и более тяжкие приложения.

     
  • 2.133, Ваня (??), 13:01, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    РАЕ - это для другого. РАЕ позволяет операционной системе (и только ей) видеть до 64 Гб ОП (вместо 4 Гб) за счёт увеличения размера страницы с 4 кб до 32 кб. 32-разрядное приложение с PAE получит макс. 4 Гб, без него макс. 3 Гб, а без доп.настроек Windows и вовсе лишь 2 Гб. Чтобы одно приложение использовало больше 4 Гб нужна 64-разрядная адресация. Приложений, использующих больше 4 Гб предостаточно: игры, Photoshop, 3d max, MathLab, ..
     
     
  • 3.215, Омский линуксоид (?), 20:01, 17/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Причем тут Шindoшs? Оно не нужно. Вообще разговор про Linux.
     

     ....нить свёрнута, показать (29)

  • 1.91, ананим (?), 01:55, 21/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Буду ждать в ваниле (ведра,гцц,..), тогда и позмотрю.
    Ваглядит заманчиво, особенно для всяких мплэйер, ффмпег и тд, где памяти много не нужно, а всякие фичи цпу очень даже.
     
  • 1.127, Kodir (ok), 11:38, 21/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Меня что-то смешит резон "снижается потребление памяти". Если взять все указатели программы, очевидно, что их объём стократ меньше самих указываемых данных. Обработка 64 битов тоже ведётся одновременно, т.е. выйгрыш ну настолько смехотворный, что смахивает на лапшу.
    Да и если подумать, ну вот кому нужны громады больше 4 гигабайт?! (речь про десктоп) Если это обработка видео, всё спокойно делается при помощи memory mapped files (под винду). Других файлов больше даже 1 гига вообще не видел. Блюрэй? Мёртворождённый отстой. Так что даже и не знаю, имел ли вообще смысл прыгать с 64 битами.
     
     
  • 2.131, Ваня (??), 12:10, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Есть приложения игры в основном, также Photoshop, 3D max, MathLab, , использ... текст свёрнут, показать
     
     
  • 3.216, Омский линуксоид (?), 20:05, 17/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Да и если подумать, ну вот кому нужны громады больше 4 гигабайт?
    > Есть приложения (игры в основном, также Photoshop, 3D max, MathLab, ..), использующие
    > больше 4 Гб ОП одновременно. Для использования одним приложением больше 4
    > Гб (точнее больше 3 Гб) нужны 64 бита.

    Это проблемы Шindoшs. У нас всё ОК!

     
  • 2.186, Аноним (-), 21:40, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Думаешь часто получается хранить данные одним куском лежат Связные список интов... текст свёрнут, показать
     
  • 2.195, Crazy Alex (ok), 00:17, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрите как-нибудь сколько памяти потребляет, скажем, rb-tree, хранящее map int->int (т.е. что-то вроде разреженного массива). Сложные структуры данных тратят на указатели в разы больше памяти, чем на сами данные. А учитывая нынешнюю любовь к куче уровней абстракции - такого счастья становится много. Если есть ООП - считай, любой объект - это минимум два указателя: указатель на объект и указатель на таблицу виртуальных функций. В общем, много их.
     

  • 1.129, Ваня (??), 12:01, 21/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А в чём суть проекта? В long mode никто не запрещает использовать 32-разрядные регистры и указатели, и даже команды с ними [32-разрядными регистрами] будут на 1 байт меньше. Берём и тупо пишем 32-разрядный код. В чём проблема то?
     
     
  • 2.146, stl (?), 15:12, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    суть в том, чтоб не писать 32-разрядный-only код, там где возможно, нахяляву иметь преимущества x86_64, просто пересобрав уже существующие. проект отлично подойдёт для задачеориентированных virtual appliances, vds и т.п..
     
     
  • 3.149, Ваня (??), 15:39, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А сейчас кто мешает? В 64-разрядном окружении возможно исполнение 32-разрядного кода.
     
     
  • 4.151, stl (?), 15:46, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    перечитай новость. для чего: экономия памяти (очевидное), повышение производительности (менее очевидное, даже наоборот); сейчас: на i586 нельзя воспользовать преимуществами регистров x86_64 и прочими оптимизациями, на x86_64 для запуска 32-разрядных приходится деражить 32-разрядные версиии софта (как правило дублируя родные), у которых тоже, неясно, что там с оптимизацией и использованием регистров; предлагают: создать архитектуру, где всё как x86_64, только 32. для запуска контейнера vds/виртуалки достаточно подготовить шаблон для сборки/установки или запустить debootstrap/zypper/нужное_подставить
     
     
  • 5.153, Ваня (??), 15:55, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    1.
    На i586 (Pentium 10-летней давности) не было 64-разрядных регистров и только поэтому "нельзя воспользовать преимуществами регистров x86_64 и прочими оптимизациями".

    2. "предлагают: создать архитектуру"

    Дальше можно не читать. Вы ВООБЩЕ не понимаете о чём говорите.

     
     
  • 6.156, stl (?), 16:04, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 1.
    > На i586 (Pentium 10-летней давности) не было 64-разрядных регистров и только поэтому
    > "нельзя воспользовать преимуществами регистров x86_64 и прочими оптимизациями".
    > 2. "предлагают: создать архитектуру"
    > Дальше можно не читать. Вы ВООБЩЕ не понимаете о чём говорите.

    то, что можно будет указать при сборке (архитектура/abi). понятие инфраструктура - для тебя, видимо, из области гуманитарных наук, если приходится объяснять по 5 раз то, что написано в новости, и спецификациям по ссылкам, по которым ты даже не удосужился сходить

     
     
  • 7.159, Ваня (??), 16:10, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    1. не внося в исходники исправлений вообще
    2. то, что можно будет указать при сборке (архитектура/abi)

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

     
     
  • 8.162, stl (?), 16:15, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это исправления на уровене двух-трёх ifdef ов, которые хорошо автоматизируются и... текст свёрнут, показать
     
  • 3.150, Ваня (??), 15:39, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На, держи пример:

    ; обнуляем 64-разрядные регистры
    xor rsi,rsi
    xor rdi,rdi
    xor rcx,rcx

    ; дальше используем только 32-разрядный код
    mov esi,src  ; 32-разрядный указатель
    mov edi,dest ; 32-разрядный указатель
    mov ecx,cnt
    rep movsd

     
     
  • 4.152, stl (?), 15:48, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > На, держи пример:
    > ; обнуляем 64-разрядные регистры
    > xor rsi,rsi
    > xor rdi,rdi
    > xor rcx,rcx
    > ; дальше используем только 32-разрядный код
    > mov esi,src  ; 32-разрядный указатель
    > mov edi,dest ; 32-разрядный указатель
    > mov ecx,cnt
    > rep movsd

    мне что переписывать весь софт для этого?

     
     
  • 5.154, Ваня (??), 16:01, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, эмулирующую на 64-разрядных системах 32-х битную модель адресации памяти"

    Ещё раз: "32-х битную модель адресации памяти" можно использовать в "64-разрядных системах" безо всяких ухищерений. Сути проекта всё ещё не понимаю.

     
     
  • 6.158, stl (?), 16:06, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > "X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, эмулирующую на 64-разрядных
    > системах 32-х битную модель адресации памяти"
    > Ещё раз: "32-х битную модель адресации памяти" можно использовать в "64-разрядных системах"
    > безо всяких ухищерений. Сути проекта всё ещё не понимаю.

    суть в том, чтоб взять debootstrap, имеющийся софт, указать архитектуру/abi x32 и создать шаблон для chroot/openvz/xen/kvm, не внося в исходники исправлений вообще

     
  • 6.160, xxx (??), 16:13, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Ещё раз: "32-х битную модель адресации памяти" можно использовать в "64-разрядных системах" безо всяких ухищерений.

    Это если на ASM'е фигачить. А как насчёт существующих компиляторов C/C++ (нас в данном случае интересует GCC, ну и может clang/llvm). Они так могут? Для того может и создают отдельный ABI. Или ты предлагаешь расширить существующий x86_64 ABI?

     
     
  • 7.163, Ваня (??), 16:16, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это всё объясняет. Спасибо. Но по мне так сами придумали геморрой, сами себе его героически лечат.
     
  • 7.171, ананим (?), 16:33, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Это если на ASM'е фигачить. А как насчёт существующих компиляторов C/C++ (нас в данном случае интересует GCC, ну и может clang/llvm). Они так могут?

    да. могут. и всегда могли! :D
    просто делают 32-битный код и всё.
    а вот как его выполнить в 64-битной системе - это уже думает ядро+бинутилс+32-битные-либы.
    >Для того может и создают отдельный ABI. Или ты предлагаешь расширить существующий x86_64 ABI?

    нет. не для этого.
    идея сабжа такова - создавать 64-х битные (!!!!) приложения, но в которых указатели 32-битные.
    что уменьшает размер кода, инструкций, адресной логики, уменьшает использования памяти, кэша.
    но при этом все плюшки x86-64 остаются.

     
     
  • 8.191, xxx (??), 22:15, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Что они могли Генерировать код который использует 64-х битные плюшки и 32-х бит... текст свёрнут, показать
     
     
  • 9.196, ананим (?), 00:44, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не нужно неуклюжих оправдований Вы с ваней скатились на 32 в 64 окружении Что ... текст свёрнут, показать
     
     
  • 10.202, xxx (??), 13:07, 22/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Единственное что мне тут не понятно, так это как ты научился писать не умея чита... текст свёрнут, показать
     
  • 6.167, ананим (?), 16:25, 21/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >"X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, эмулирующую на 64-разрядных системах 32-х битную модель адресации памяти"
    >Ещё раз: "32-х битную модель адресации памяти" можно использовать в "64-разрядных системах" безо всяких ухищерений. Сути проекта всё ещё не понимаю.

    чего тут не понятного?
    грубо x32 - это 64-битное приложение (да-да! со всеми вытекающими), но с 32-битной адресацией памяти.

     

  • 1.172, cat666 (?), 16:35, 21/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Снимаю шапку перед Анвином, молодец !!! Ему только за SYSLINUX памятник поставить надо, остальные пусть подавятся асcемблерным кодом :)
     

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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