LINUX.ORG.RU
ФорумTalks

До чего доводит параноя, люди боятся выделять память


0

0

http://extrasystems.kiev.ua/

/trueonly

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

Основным моментом, которому уделялось внимание, является скорость, стабильность и надежность работы сервера. Разработчики пришли к заключению, что единственным способом добиться этой цели является полный отказ от динамического создания каких-либо объектов по ходу работы сервера. Таким образом, все необходимые объекты (потоки, сокеты, буферы памяти и т.п.) создаются данным сервером однократно в момент запуска и в дальнейшем используются по мере необходимости. Многомесячные испытания данной концепции в ряде тестирующих организаций подтвердили правильность такого подхода.

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

★★★

Да здравствует классический Паскаль?

DNA_Seq ★★☆☆☆
()

>К сожалению это уже умерло

Кто умер?

wfrr ★★☆
()

верно, ибо динамическое выделение памяти
a) медленное
б) ведет к утечкам -> изобретению костылей вроде сборщиков мусора

anonymous
()

> Разработчики пришли к заключению, что единственным способом добиться этой цели является полный отказ от динамического создания каких-либо объектов по ходу работы сервера. Таким образом, все необходимые объекты (потоки, сокеты, буферы памяти и т.п.) создаются данным сервером однократно в момент запуска и в дальнейшем используются по мере необходимости

есть такое, в основном в RTOS, где нельзя гарантировать детерминированность выделения памяти по времени, и проще сделать пул объектов заранее при старте приложения, потом брать объекты из пула.
Из той же оперы, см. зональный аллокатор в Doom и Quake
Правда, не думаю что к производительности этого конкретного сервера такие уж жёсткие требования

anonymous
()

Ну... В принципе... Всегда есть католики, которые хотят быть святее папы римского. В нашем продукте использование своего спец-аллокатора памяти вместо системного позволяет ускорить работу программы в два раза. Да-с... Но вот стоит ли такая прибавка такого траха? А еще можно на ассемблере писать...

Beria1937
()
Ответ на: комментарий от r_asian

>> а какое отношение приведённый текст имеет к ссылке :-?
> Тест на Ъ. Вот ты - не Ъ


На Ъ можно тестировать и автора сообщения: если сначала идёт новость, а затем ссылка, то автор - Ъ. Если же наоборот, автор - неЪ.
(При этом половина читателей-Ъ, увидев в начале сообщения ссылку, говорят: "Не будем читать эту новость - автор неЪ" и уходят).

Byron
()
Ответ на: комментарий от Beria1937

А в какой отрасли продукт, что делает? Со сборщиком мусора не пробовали собирать, как оценка производительности в целом изменилась?

> А еще можно на ассемблере писать...

всё равно нужно память выделять :) вот на форте можно было бы всё в стеке держать и не париться :))

anonymous
()
Ответ на: комментарий от Byron

наверно, подразумевалось что текст надо читать сзаду наперёд :)

anonymous
()
Ответ на: комментарий от anonymous

> б) ведет к утечкам

Утечки при статичном пуле ресурсов ещё опаснее.

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

> костылей вроде сборщиков мусора

Не гнать на сборщики мусора, ламер!

anonymous
()
Ответ на: комментарий от anonymous

>Не гнать на сборщики мусора, ламер!

Запомни эту прописную истину: чисто не там, где убирают, а там, где не мусорят :)

anonymous
()
Ответ на: комментарий от klalafuda

>а какое отношение приведённый текст имеет к ссылке :-?

думаю, хост, работающий на вышеописанном сервере.

jcd ★★★★★
()
Ответ на: комментарий от anonymous

>Запомни эту прописную истину: чисто не там, где убирают, а там, где не мусорят :)

Нет, дружок, чисто _только_ там где убирают.

gnomino
()
Ответ на: комментарий от gnomino

>Нет, дружок, чисто _только_ там где убирают.

Вот и попробуй не скатиться до уровня одного анонимуса, иначе никакой модератор не в силах будет за тобой убрать

anonymous
()
Ответ на: комментарий от anonymous

Вот и попробуй ответить за свой базар. Ты заявил, что GC это костыль. Такие наглые заявления необходимо строго и корректно обосновывать. Каждый же, кто в ответ на требование привести доказательства разводит ГСМную вонь, должен делать себе вдоль.

anonymous
()

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

ПАРАНОИКИ однозначно.

vada ★★★★★
()
Ответ на: комментарий от anonymous

>Вот и попробуй ответить за свой базар. Ты заявил, что GC это костыль.

Зачем нужны костыли? Чтобы облегчать жизнь людям с ограниченными возможностями. У некоторых из них, к примеру, руки растут известно откуда и память течет неизвестно куда. Для них и придумывают костыли, и заставляют ходить на костылях всех, кто пользуется их трудом. Поэтому программистов с ограниченными возможностями не нужно допускать к производству массовых вещей, хотя костыли сами по себе полезная вещь, для нуждающихся.

anonymous
()
Ответ на: комментарий от anonymous

>У некоторых из них, к примеру, руки растут известно откуда и память течет неизвестно куда.

В любой системе без GC память течет по определению. Просто открой top и понаблюдай за любой монолитной С++ программой работающей в режиме 24/7.

Absurd ★★★
()
Ответ на: комментарий от anonymous

>У некоторых из них, к примеру, руки растут известно откуда и память течет неизвестно куда.

В любой системе без GC память течет по определению. Просто открой top и понаблюдай за любой монолитной С++ программой работающей в режиме 24/7.

Absurd ★★★
()
Ответ на: комментарий от anonymous

>У некоторых из них, к примеру, руки растут известно откуда и память течет неизвестно куда.

В любой системе без GC память течет по определению. Просто открой top и понаблюдай за любой монолитной С++ программой работающей в режиме 24/7.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>В любой системе без GC память течет по определению. Просто открой top и понаблюдай за любой монолитной С++ программой работающей в режиме 24/7.
>Absurd (*) (25.09.2008 18:42:53)


>В любой системе без GC память течет по определению. Просто открой top и понаблюдай за любой монолитной С++ программой работающей в режиме 24/7.

>Absurd (*) (25.09.2008 18:45:41)


Ну не знаю как там насчет С++ программ 24/7, но у тебя в системе явно-что-то потекло )))

anonymous
()
Ответ на: комментарий от anonymous

Ты дебил. Какие такие "ограниченные возможности", кретин? Сравни, например, что больше затормозит исполнение - удаление глубокого, большого дерева (а лучше графа) явным образом (то есть, остановка исполнения, пока все узлы не будут пройдены), или же постепенное подчищение его остатков во время работы GC, в реальном времени, с гарантированным временем отклика?

Есть огромное количество задач, семантика которых ТРЕБУЕТ той или иной формы сборки мусора. Ты, как и полагается неумному, наглому ламеру, ничего про них не знаешь - ты узколобенький и убогонький, но от того, что ты туп и узколоб, эти задачи менее важными не становятся. Можешь делать вдоль.

anonymous
()
Ответ на: комментарий от anonymous

>Ну не знаю как там насчет С++ программ 24/7, но у тебя в системе явно-что-то потекло )))

Глюки ЛОР'а

Absurd ★★★
()
Ответ на: комментарий от anonymous

Объясни подробней, что ты имел ввиду

anonymous
()
Ответ на: комментарий от anonymous

>Сравни, например, что больше затормозит исполнение - удаление глубокого, большого дерева (а лучше графа) явным образом (то есть, остановка исполнения, пока все узлы не будут пройдены), или же постепенное подчищение его остатков во время работы GC, в реальном времени, с гарантированным временем отклика?

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

>это не когда за тебя откладывают сборку мусора на неопределенный срок, а точное знание сколько будет выполняться каждый шаг (пусть даже этот шаг занимает достаточно продолжительное время)?

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

>И ещё, ты знаешь сборщики мусора, которые могут смогут удалить кольцевой граф?

Первый томик Кнута, последняя глава.

Absurd ★★★
()
Ответ на: комментарий от vada

это вообще удивительно
я тоже боюсь работать с памятью, и чем дальше тем страшнее
но отказываться полность, это чё, резервировать ВСЕ доступные ресурсы?
но раз нет исходников, такие шикарно интересные проекты просто сгниют

Может попросим код, хотя бы в режиме на почитать под одеялом

fMad ★★★
() автор топика
Ответ на: комментарий от fMad

>но отказываться полность, это чё, резервировать ВСЕ доступные ресурсы?

>но раз нет исходников, такие шикарно интересные проекты просто сгниют

Один из таких шикарно интересных проектов, со временем резервирующих ВСЕ доступные ресурсы, назывался Firefox 2.0, и, как ни странно, был достаточно распространён.

jcd ★★★★★
()
Ответ на: комментарий от jcd

ты пытаешь играть словами не более. поиграй лучше в лего

fMad ★★★
() автор топика
Ответ на: комментарий от Absurd

> В любой системе без GC память течет по определению. Просто открой top и понаблюдай за любой монолитной С++ программой работающей в режиме 24/7.

Ну зачем-же так сразу. В плюсах тоже бывают разновидности сборщиков, - auto_ptr (убиараемый правда из стандарта), shared_ptr и куча других xxxxx_ptr-ов. С тем-же shared_ptr-ом получаем сравнимую по скорости работы с ручным вызовом delete "когда надо" деаллокацию, практически без каких-либо накладных ресурсов. Конечно при этом необходимо соблюдать некоторые правила гигиены и например да, не допускать колцевых структур данных завязанных shared_ptr-ами, но это не так сложно в большинстве случаев.

По поводу наездов на gc в свою очередь скажу: существуют языки, где выделение памяти так-же автоматизировано и скрыто от программиста, да и вообще семантика языка скрывает такие вещи как ручное создание обьектов, вот тут GC - это настоящий Ъ. (Задание школьникам: назовите для примера 2 таких языка :)

quarck
()

True Jedi Path.
malloc придумали слабые духом.

ranka-lee
()

А я в детстве когда писал array [0..65535] думал быдлокод, а оно вот как оказалось, это "многолетние усилия" ...

redgremlin ★★★★★
()
Ответ на: комментарий от tailgunner

>> auto_ptr (убиараемый правда из стандарта)

> Ссылку?

Точно не скажу в каком драфте это написано, Майерс это упоминал в effective stl-е

quarck
()
Ответ на: комментарий от maloi

> И ещё, ты знаешь сборщики мусора, которые могут смогут удалить кольцевой граф?

Как раз всякие там reference counting средства не являются никоим образом сборщиками мусора (так что кто тут смартпоинтеры поминал - в сад!). Любой же нормальный GC, такие как stop and copy, mark and sweep и их комбинации, прекрасно подчистит сколь угодно циклическую структуру. С гарантированным временем работы одного прохода сборки, кроме всего прочего, что, опять же, абсолютно недоступно с reference counting.

> анонимус, ты хоть понимаешь,

Ламер, ты не имеешь права на менторский тон. Ты же даже не знаешь, как сборка мусора работает!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.