powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Тяпничный идеальный сборщик мусора
25 сообщений из 87, страница 2 из 4
Тяпничный идеальный сборщик мусора
    #39270725
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vitprofНизкие расходы на доступ к памяти (для полноты картины)

Тут не совсем понятно.

Например если аллоцирован array[] на 10 элементов то при доступе к индексатору
идет каждый раз проверка на попадение в диапазон.

Это имелось в виду?
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270731
nojava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonnojavaКакая замшелая безграмотность, госпаде. MVCC это просто принцип https://ru.wikipedia.org/wiki/MVCC
а то, что я описал - это давно доступно в базе данных LightningDB. https://symas.com/products/lightning-memory-mapped-database/
которая работает именно как библиотека к прилоежнию, без всяких там серверов баз данных.

Ну уж извините. Зарос я мхом...

А про эти ваши Лайтманы и прочие Рабиновичи - слышу нечасто. Да и хде они в рэйтингах
и бенчмарках? Хде они в обзорах? Хде имплементированы? Награждены Орденом Ленина?
Увековечены в монографиях?

Или .... речь идет (мне даже страшно предположить) о некоем новом .... FVMAS?
там все есть по ссылке. и бенчмарки и примеры использования.

его библиотека реализована просто как тупейшее key-value хранилище, это не совсем база данных с SELECTами и прочем.
есть обертка в виде sqlite, но то такое....


вот тебе синтетические тесты: http://lmdb.tech/bench/microbench/
вот примеры применения: https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database#Application_Support

хотя какой-то чувак с highload 2014 весьма скептически отзывался, лень искать доклад, но типо есть чего еще допиливать в части безотказности при вырубании по питанию
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270738
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nojava, ОК. Спасибо.

Но давай не уклоняться от темы. На правах топик стартера я предагаю
вернуться к обсуждению идеального GC.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270739
vitprof
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonvitprofНизкие расходы на доступ к памяти (для полноты картины)

Тут не совсем понятно.

Например если аллоцирован array[] на 10 элементов то при доступе к индексатору
идет каждый раз проверка на попадение в диапазон.

Это имелось в виду?

В частности, да. В общем, могут быть какие-то блокировки в случае многопоточности. Пример - C++ smart_ptr. Мы же общие требования формулируем!?
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270744
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vitprofВ частности, да. В общем, могут быть какие-то блокировки в случае многопоточности. Пример - C++ smart_ptr. Мы же общие требования формулируем!?
ОК. Обобщим!

Поменьше блокирующих структур. Больше операций на основе atomic и CAS.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270749
nojava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonnojava, ОК. Спасибо.

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

так там и есть идеальный GC, в чем вопрос-то?
тебе нужны long running objects? отлично - суй их в эту memory mapped database, и пусть они там и живут.

объект живет себе и в базе данных и в оперативке одновременно, никакая хрень вроде Hibernate вообще не нужна - все уже зампаплено в базу данных изначально, красота.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270764
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nojavaобъект живет себе и в базе данных и в оперативке одновременно, никакая хрень вроде Hibernate вообще не нужна - все уже зампаплено в базу данных изначально, красота.
Да признаю что нулевые расходы на копирование - это привлекательно.

Но такое решение не скейлится. Оно изначально проектируется под 1 хост и целиком
и полностью зависит от перформанса 1 вычислительного узла.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270779
nojava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonnojavaобъект живет себе и в базе данных и в оперативке одновременно, никакая хрень вроде Hibernate вообще не нужна - все уже зампаплено в базу данных изначально, красота.
Да признаю что нулевые расходы на копирование - это привлекательно.

Но такое решение не скейлится. Оно изначально проектируется под 1 хост и целиком
и полностью зависит от перформанса 1 вычислительного узла.

как уже говорилось - NAS и SAN никто не отменял, это раз, а два - если скейлить, то все равно нужно базу данных шардить, потому там просто шардится все целиком - и приложение и база данных бьется на две части, и вперед, в чем проблема-то?

или ты видел приложения, в которых можно оставить один сервер баз данных, но добавить 1024 серверов приложений вместо одного, и все не будет тормозить? да неужели?
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270846
uid unique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все GC используют процессор для чистки, больше памяти на том же процессоре значит дольше будет идти чистка.
Как ни тужься но упрешься в поиск в несортированном массиве рано или поздно.

Нужно переходить на принципиально другой вид памяти, совмещенный с процессором и использовать понятие как удельная процессорная мощность на некоторый объем памяти.

По аналогии с удельным давлением на грунт или удельной мощностью на массу у гусеничных машин.
Хочешь танк потяжелее но с такой же подвижностью и проходимостью? сохраняй удельные параметры.

Идеальная память с удельной процессорной мощностью 1.0 это САМ (Content-addressable memory)
https://en.wikipedia.org/wiki/Content-addressable_memory
Фиксированный по времени поиск в сколько угодно большом несортированном массиве данных.
Как вариант можно делать гибридные решения с обычной памятью (попадались такие платы ускорители для баз данных но давненько это было).
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270896
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как быстро похудеть? - Надо меньше жрать!

Вот и с памятью так.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270897
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
uid uniqueИдеальная память с удельной процессорной мощностью 1.0 это САМ (Content-addressable memory)
https://en.wikipedia.org/wiki/Content-addressable_memory
Фиксированный по времени поиск в сколько угодно большом несортированном массиве данных.
Как вариант можно делать гибридные решения с обычной памятью (попадались такие платы ускорители для баз данных но давненько это было).
Мы так далеко уедем. Давайте отложим в сторону.
Эта тема очень интересна но... пожалуйста отдельным топиком.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270901
Фотография schwa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonschwaУправление памятью на свой страх и риск aka возможность считывания byte/signed/usigned int/float/double/etc с указанной позиции в памяти это конечно хорошо, но толку мало - программы это структуры данных и работа с ними. Поэтому нужна нормальная поддержка указателей на структуры, которые расположены вне хипа с поддержкой на уровне рантайма, языка и его стандартной библиотеки.
Если честно - непонятно. Что за "структуры вне хипа" ? И что за хитрый указатель?
Вне хипа, который управляется сборщиком мусора.
Указатель - объект доступа к структуре данных. Он может ничем не отличатся от обычного экземпляра класса кроме того, что GC его жизненным циклом не управляет. Но, как было верно замечено, "собственно в мире C так давно уже все и работает. " - т.е. для реализации этого в наш язык со сборщиком нужно реализовать небольшой сабсет C... От чего в принципе хотели уйти - зачем еще GC-то.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270906
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nojavaкак уже говорилось - NAS и SAN никто не отменял, это раз, а два - если скейлить, то все равно нужно базу данных шардить, потому там просто шардится все целиком - и приложение и база данных бьется на две части, и вперед, в чем проблема-то?

Меня конечно поражает легкость с которой жонглируете NAS/SAN и тому подобное. Масштабирование
собственно системы хранения - это сегодня задача уже решенная для R/O. Хеширование и Hadoop в помощь. Но я обращу
внимание на то что когда мы решаем задачи масштабирования в общем понимании этого слова то нам
нужно решать вопросы конкурентных updates.

или ты видел приложения, в которых можно оставить один сервер баз данных, но добавить 1024 серверов приложений вместо одного, и все не будет тормозить? да неужели?
Не говорил я такого.

И я вас тоже решительно прошу вернуться к главной теме. А именно к GC.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270911
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Далее я напишу по сабжу. (Рассуждаю пока).

Коли для уборщика мусора представляет сложность сам процесс релокации surival
объектов то разумно заведомо их туда положить. Тоесть классифицировать объекты
по их времени жизни. Разумеется для этого нужно ввести какой-то механизм.

Например аннотации или хинты к new. Например:

Код: java
1.
2.
3.
4.
5.
String fuckenString = @Eden new String("Hello");

XmlDocument fuckenDoc = @OldGen new XmlDocument(Factory.getNewDocument());

Class class = @MetaSpace Class.forName("jdbc.oracle.Driver");



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

С точки зрения разработчика С++ - стековая аллокация alloca(...) - констатация
того что объект виден в скоупе процедуры и копироваться не будет и должен
быть деаллоцирован сразу после выхода из процедуры. Тоесть по сути это
@Eden new. или

Код: plaintext
1.
/* FAST ALLOC */ mayton::string fuckenString = new mayton::string("Hello");
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39270992
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Одиночный объект ты можешь сунуть в alloca, но STL контейнер уже нет - аллокатор полезет в глобал хип. И там глубока кроличья нора зависимостей.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271031
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglОдиночный объект ты можешь сунуть в alloca, но STL контейнер уже нет - аллокатор полезет в глобал хип. И там глубока кроличья нора зависимостей.
А можно всем "зависимостям" сказать дескыть - хочу alloca?
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271043
YesSql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonSiemarglОдиночный объект ты можешь сунуть в alloca, но STL контейнер уже нет - аллокатор полезет в глобал хип. И там глубока кроличья нора зависимостей.
А можно всем "зависимостям" сказать дескыть - хочу alloca?
можно
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271065
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YesSql, у меня сходу нелетает. MinGW 5.30

Код: sql
1.
2.
3.
In file included from example.cpp:1:0:
short_alloc.h:29:58: error: 'max_align_t' is not a member of 'std'
 template <std::size_t N, std::size_t alignment = alignof(std::max_align_t)>
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271084
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>gcc -std=c++11 small_vector.cpp -lstdc++
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271089
YesSql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonYesSql, у меня сходу нелетает. MinGW 5.30

Код: sql
1.
2.
3.
In file included from example.cpp:1:0:
short_alloc.h:29:58: error: 'max_align_t' is not a member of 'std'
 template <std::size_t N, std::size_t alignment = alignof(std::max_align_t)>


std::max_align_t определена в С++11
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271122
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YesSqlmaytonпропущено...

А можно всем "зависимостям" сказать дескыть - хочу alloca?
можно
Строго говоря, alloca тут не используется, просто буфер создается на стеке. Это хуже, т.к предварительно ограничивает размер.
Хотя переписать, думаю не составит проблемы.

С другой стороны, тот же Мейерс пишет, что аллокаторы не всегда используются (Совет 10, 11). Хотя книжка старая, может уже починили.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271143
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Насколько я понимаю стека не так много. Тут надо покурить Windows/Linux доки по ОС
и созданию потоков и процессов чтобы понять сколько стека по дефолту
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271156
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton Идеальный GC должен:

1) Хорошо скейлится. . Тоесть при переходе с 16G кучи до 32G мы не должны
наблюдать "удвоенную" нагрузку на процессы GC.

2) Иметь жестко регулируемый Stop-The-World. . Тоест грубо говоря мы должны
иметь ИНСТРУМЕНТ или регулятор которым мы говорим дескыть - Мы не желаем
чтобы стоп-вселенная длилась более чем 10 милисекунд. Вот так вот.

3) Иметь средства диагностики и отладки . Ну здесь как-бе все ясно. Что. Где. Когда.
Детальный лог по активностям GC.

4) Иметь возможность workaround механизма GC . Как ни крути но есть
ситуации когда мы сами желаем иметь прямой неуправляемый доступ к памяти
и мы требуем чтобы (на свой страх и риск) у нас все таки была возможность
выделять сырую память и удалять ее вручную.

.... здесь можно еще дописать ваши предложения.

Можно также обсудить че есть и где какие алгоритмы используются.

Таблицы и графики - приветствуются.
для некоторых языков, важным пунктом является дешевая(быстрая) операция выделения памяти под маленький объект с короткой жизнью.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271157
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonvitprofЯ бы добавил:

Низкие расходы на выделение памяти под объект


В большинстве GC - уже учтено. Реально выделение происходит как в queue.
как оказалось, далеко не во всех языках.
ибо не во всех языках, оно столь важно.
...
Рейтинг: 0 / 0
Тяпничный идеальный сборщик мусора
    #39271256
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nojavaAn ultra-fast, ultra-compact, crash-proof key-value embedded data store Я выделил то, что сигнализирует - "дальше можно не читать".
...
Рейтинг: 0 / 0
25 сообщений из 87, страница 2 из 4
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Тяпничный идеальный сборщик мусора
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]