The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Разработчики ядра Linux обсуждают вопрос удаления субархитек..., opennews (?), 12-Дек-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


159. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (159), 13-Дек-18, 09:29 
Поставил на слабый планшет с 32 бит загрузчиком 64-битный минт. Производители была поставлена x86 винда.
Так вот с запущенным Chromium это все жрет 1.3 ГБ памяти из 2 ГБ. Используется swap, но замедления работы не видно.
Я это все к тому, что современные 64бит программы умеют подстраиваться под недостаток памяти и рядовому юзеру 32 бит не нужны.
Ответить | Правка | Наверх | Cообщить модератору

179. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (179), 13-Дек-18, 11:01 
> современные 64бит программы умеют подстраиваться под недостаток памяти

Если точнее, то подстраивается система.
А размер указатела все равно в 2 раза больше, что приводит к увеличению потребления памяти до 2-х раз и соответственно снижению скорости операций с памятью до двух раз. Что в свою очередь происходит не только из-за увеличения объема читаемых/записываемых/передаваемых данных, но и увеличения частоты кэшпромахов. Всё это в совокупности также снижает энергоэффективность системы.
Какие выгоды мы получаем:
1. Система может работать с объемом памяти больше 64Гб;
2. Каждый процесс может адресовать более 4Гб.
Если говорить в контексте упомянутого Chromium'а, то у него каждая вкладка - тдельный процесс. Т.о. он может адресовать все 64Гб в 32 битной системе. И вероятно у вас нет такого объема памяти, т.к. основываясь даже на статистике steam, среднестатистическому PC геймера далеко до такого объема. А PC офисного сотрудника или встраиваемой технике - тем более.

Ответить | Правка | Наверх | Cообщить модератору

211. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +1 +/
Сообщение от Аноним (251), 13-Дек-18, 12:18 
Ну больше и больше. Указатели серьёзно погоду делают только в случае чрезмерно сложных структур с простейшими элементами. Если элемент чуть сложнее uint64, указатели уже погоды не делают.
Ответить | Правка | Наверх | Cообщить модератору

335. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (335), 13-Дек-18, 20:59 
std::string - 3 указателя, один на начало данных, второй на конец, третий на емкость - 24 байта.
std::list - 2 указателя на каждый элемент - 16 байт....
В хромиуме структуры содержат множество строковых полей, которые зачастую пусты. В итоге получается хранятся только указатели, без данных. Отсюда такая зависимость потребления памяти от битности.
Ответить | Правка | Наверх | Cообщить модератору

336. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Michael Shigorinemail (ok), 13-Дек-18, 21:42 
> std::string - 3 указателя [...] - 24 байта

Это в модели ptr8 :)  Оговорились...

Ответить | Правка | Наверх | Cообщить модератору

372. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Онаним (?), 14-Дек-18, 09:24 
Насколько помню, std::string короткие строки вписывает в саму структуру.
Ответить | Правка | К родителю #335 | Наверх | Cообщить модератору

379. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +1 +/
Сообщение от Аноним (514), 14-Дек-18, 10:13 
> Насколько помню, std::string короткие строки вписывает в саму структуру.

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

Ответить | Правка | Наверх | Cообщить модератору

485. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 15-Дек-18, 22:50 
> Это не отменяет наличие трёх указателей.

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

Обычно анализ программы срабатывает нормально, так что убираются только те указатели (и проч) которые никто явно не использовал.

Но есть способы этот анализ надуть. Самый очевидный способ - микроконтроллеры, обработчик IRQ. Компилер не знает что железо позовет обработчик IRQ. И не знает как это. В этот момент об оптимизнутом указателе можно конкретно пожалеть. В этом случае сишники явно пишут volatile, показывая компилеру и оптимизатору что это реально должно работать так как заявлено и что есть неожиданные способы использовать это, которые компилятор не знает. Тогда компилер забьет на оптимизации в этом месте - и таки будут все указатели или что там должно быть.

Но для обычных программ в user mode операционки - использование volatile как бы очень странное дело.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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