The OpenNET Project / Index page

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



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

Оглавление

Замена алгоритма сортировки в sysinit позволила ускорить загрузку FreeBSD, opennews (??), 21-Авг-23, (0) [смотреть все]

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


113. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (113), 21-Авг-23, 18:02 
надо было прочесть фабрикаторский линк - квик сорт это была первая и самая естественная реализация - от неё отказались из-за рекурсий и опасений за стек ядра, вы слишком много выёживаетесь, юзер, вы даже не админ
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

144. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от User (??), 21-Авг-23, 22:52 
> надо было прочесть фабрикаторский линк - квик сорт это была первая и
> самая естественная реализация - от неё отказались из-за рекурсий и опасений
> за стек ядра, вы слишком много выёживаетесь, юзер, вы даже не
> админ

Что и кому сказать-то хотели, аноним?

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

154. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (113), 22-Авг-23, 07:21 
прямым текстом написал - не надо выёживаться
Ответить | Правка | Наверх | Cообщить модератору

157. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от User (??), 22-Авг-23, 08:00 
> прямым текстом написал - не надо выёживаться

А, ну т.е. без какой-либо связи с вышенаписанным, просто "в лужу"? Ну, тогда предлагаю перечитать )

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

202. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Бывалый смузихлёб (?), 23-Авг-23, 08:34 
А вот даже интересно, почему не делают процов с бездонным стеком( который растёт нормально пока не займёт всю ОЗУ а не как на нынешних процах - до очень ограниченного потолка )
Помнится, иной байткод аккурат под подобную абстрактную машину и генерируется

Очень уж многое упирается в нынешний стек, точнее, в его размеры

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

205. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Совершенно другой аноним (?), 23-Авг-23, 08:57 
> А вот даже интересно, почему не делают процов с бездонным стеком( который
> растёт нормально пока не займёт всю ОЗУ а не как на
> нынешних процах - до очень ограниченного потолка )

Ну, вообще, как-бы у самого процессора ограничений нет - для 32-х разрядного режима можете хоть 4G стека сделать, правда толку в этом мало, только на записи в таблице страниц потратитесь, а использовать его почти никто не будет. Если правильно помню, то в ядре Linux для системных программ (драйверов и т.д.) обходятся 8K стека, и, вроде как, хватает.

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

207. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Бывалый смузихлёб (?), 23-Авг-23, 10:42 
Проблема в том, что стек растёт в обратную сторону относительно обычной памяти
Т.е, для него изначально выделили отдельный небольшой блок и далее он в нём растёт пока не дойдёт до потолка
И это всё далеко от общего количества ОЗУ

Например, посоны поговаривают по тому же C#
> размер стека С# составляет всего 1 МБ для 32-битных процессов и 4 МБ для 64-битных процессов

И это при 64+ Гб ОЗУ которые сейчас можно поставить( на новые компы 64-128 - это само-собой разумеющийся максимум даже для младшей серии !)
У меня прямо сейчас 64 Гб ОЗУ. Не скажу что сильно избыточно. Осн. объём жрут браузеры )

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

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

208. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Совершенно другой аноним (?), 23-Авг-23, 11:48 
> Проблема в том, что стек растёт в обратную сторону относительно обычной памяти
> Т.е, для него изначально выделили отдельный небольшой блок и далее он в
> нём растёт пока не дойдёт до потолка
> И это всё далеко от общего количества ОЗУ

Ну, вообще, реально выделяют страницу или две (если физически), а заказывают столько, сколько считают нужным. Если происходит исключение, то подсистема памяти видит, что физически страница закончилась и выделяет новую.

Для однопоточных программ было следующее распределение памяти (от младших адресов к старшим):

КОД
ДАННЫЕ
КУЧА (растёт вниз)
/свободное место/
СТЕК (растёт в верх)

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

С многопоточными всё стало сложнее. Тем не менее, если необходимо, то есть межанизм заказать столько стека, сколько надо.

В Unix см. https://man7.org/linux/man-pages/man3/pthread_attr_setstack.... и https://man7.org/linux/man-pages/man3/pthread_attr_setstacks...

В Windows - см. https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...

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

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

не совсем, насколько я понимаю, в LLVM используется идея бесконечного числа регистров.

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

217. Скрыто модератором  +/
Сообщение от Аноним (-), 23-Авг-23, 20:14 
Ответить | Правка | Наверх | Cообщить модератору

218. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (218), 23-Авг-23, 20:15 
> КОД
> ДАННЫЕ
> КУЧА (растёт вниз)
> /свободное место/
> СТЕК (растёт в верх)

Это что, дотнетчики такие извращенцы что усложнили работу железу по максимуму? Обычно стеку назначается вершина - и он растет вниз, потому что почти все процессоры так работают. Сие кроме всего прочего означает что раскладывание в адресах ниже стека чего-то ценного не совсем безопасная идея без принятия специальных мер. По той же причине без специальных мер стек может вынести кусок стека parent caller'а. И все это решаемо, но с существующими в железе моделями памяти и прав доступа - ведет к суровому оверхеду. Или вот нужде в всяких извтатах с виртуалками. Единственные кто это частично наели зайдя с другого бока - хруст и тому подобные. Но даже они уповают на MMU при этом.

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

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

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




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

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