ПО, ЭВМ и АСУ из Таможенного Союза

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.

Многокучесть

Страница: 1

Сообщений 1 страница 25 из 25

1

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42

Единственной известной мне экосистемой, которая позволяет создавать много куч в пределах одного процесса является C++.

Singularity и Bortok я не смотрел.

Хотелось бы обсудить, как такая система могла бы реализовываться на уровне синтаксиса.
Ну, например:
1) если есть отдельные кучи, то в библиотеке описания метаинформации для кучи должен быть свой класс (как AppDomain, только другой).
2) должно быть что-то для обмена сообщениями между объектами разных куч

Мне, неясно:
1) почему AppDomain сделали все с одной общей кучей;
2) в чём смысл перехода от Remoting к WCF (что именно стало лучше с точки зрения взаимодействия объектов разных куч)

0

2

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

А зачем много куч?

0

3

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42
utkin написал(а):

А зачем много куч?

затем что обход большой кучи долог, а поколения (generations) не спасают.

0

4

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

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

И опять же зачем нам С++? Вроде же был разговор за чистоту расы и предлагалось использовать One Script...

Отредактировано utkin (2017-12-26 10:36:57)

0

5

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42
utkin написал(а):

И опять же зачем нам С++? Вроде же был разговор за чистоту расы и предлагалось использовать One Script...

C++ нам для конкретики ПРИ ОБСУЖДЕНИИ. Следует знать врага и всё такое. Изучить с целью построения новой теоретической модели управления памятью.

А для задач написания сайта я продолжаю предлагать 1Скрипт.

Отредактировано Лис (2017-12-26 10:51:35)

0

6

  • Автор: Павиа
  • Участник
  • Зарегистрирован: 2017-10-23
  • Приглашений: 0
  • Сообщений: 386
  • Уважение: [+3/-0]
  • Позитив: [+2/-3]
  • Провел на форуме:
    18 дней 1 час
  • Последний визит:
    2021-04-01 13:43:30

От куч надо избавляться. Винда создаёт как минимум 5 куч на процесс в результате чего в Delphi выделить непрерывный кусок более 500 мб проблематично.

Лис написал(а):

2) должно быть что-то для обмена сообщениями между объектами разных куч

Зачем? Ихмо достаточно стандартного механизма для обмена сообщениями у объектов из разных потоков как в Qt.

0

7

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

C++ нам для конкретики ПРИ ОБСУЖДЕНИИ.

Так у всех механизмы реализации различны между собой :). Все что говорится о С++  именно к нему и относится.

А для задач написания сайта я продолжаю предлагать 1Скрипт.

А какой такой язык для компиляции? Ну чтобы можно было разговаривать о кучах предметно (с++ же не кошерен).

0

8

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42
utkin написал(а):

А какой такой язык для компиляции? Ну чтобы можно было разговаривать о кучах предметно (с++ же не кошерен).

1Скрипт++

Он ещё не написан, но если не обсуждать как его сделать - никогда и не будет.

0

9

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

Он ещё не написан, но если не обсуждать как его сделать - никогда и не будет.

Это вопрос к разработчикам OneScript или Вы анонсируете создание собственного языка? Тут как бы сразу вопрос в названии - скрипты предполагают интерпретацию (относительно небольшой программы), что по духу ближе ко мне, чем к Вам. Такое название неудачный маркетинговый ход.

Отредактировано utkin (2017-12-26 12:58:22)

0

10

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42
utkin написал(а):

Это вопрос к разработчикам OneScript или Вы анонсируете создание собственного языка?

Я инициирую темы, которые могли бы быть интересны разработчикам разных новых языков (и, например, мне самому). Это не вопрос конкретно к разработчикам 1Скрипт, и я не анонсирую создание нового языка.

0

11

  • Автор: MihalNik
  • Evangelist of AL-IV
  • Зарегистрирован: 2017-08-17
  • Приглашений: 0
  • Сообщений: 1096
  • Уважение: [+9/-1]
  • Позитив: [+7/-0]
  • Провел на форуме:
    21 день 0 часов
  • Последний визит:
    2023-09-30 09:30:29

на уровне синтаксиса.

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

0

12

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42
MihalNik написал(а):

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

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

Безусловно, есть алгоритмы распределённой сборки мусора, но можно ведь и частные случаи рассмотреть?

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

MihalNik написал(а):

задача сводится к описанию работы с произвольными графами.

не сводится, мне видится другая задача, которая надстраивается

0

13

  • Автор: MihalNik
  • Evangelist of AL-IV
  • Зарегистрирован: 2017-08-17
  • Приглашений: 0
  • Сообщений: 1096
  • Уважение: [+9/-1]
  • Позитив: [+7/-0]
  • Провел на форуме:
    21 день 0 часов
  • Последний визит:
    2023-09-30 09:30:29
Лис написал(а):

Внутри кучи это верно. Но например дерево процессов является вполне себе деревом.

Ку́ча (англ. heap) в информатике и программировании — название структуры данных, с помощью которой реализована динамически распределяемая память приложения.

В компьютерных науках ку́ча — это специализированная структура данных типа дерево, которая удовлетворяет свойству кучи: если B является узлом-потомком узла A, то ключ(A) ≥ ключ(B). Из этого следует, что элемент с наибольшим ключом всегда является корневым узлом кучи, поэтому иногда такие кучи называют max-кучами (в качестве альтернативы, если сравнение перевернуть, то наименьший элемент будет всегда корневым узлом, такие кучи называют min-кучами).

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

Лис написал(а):

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

Ну а причём тут синтаксис? Если для какого-нибудь дерева будет отдельный синтаксис, как он бывает для массивов или списков (на последних вполне себе делают деревья), то, например:
запись "delete []A;" вместо "delete A;" ничего хорошего не представляет - разработчик ЯП довольно не умел, чтобы не суметь определить, что А - массив?
Представьте, Лис: кто-то захотел поменять дерево/список на массив или обратно. Потребуется перефигачивать весь код? Только не надо отмазок в духе Utkin'a про изначально неверное проектирование. Программирование - это моделирование в первую очередь, а сие предполагает возможность частого внесения изменений.
Не ясно, что мешает размещать данные в обычных структурах - динамических массивах, списках, произвольных деревьях, "кучах" и т.д. Подходов к обмену памятью м/у ними и ОС всего несколько штук: точечно, блочно и прогрессивно. То, что обычный список вполне размещаем в массив, мы уже обсуждали.

Отредактировано MihalNik (2017-12-27 00:46:59)

0

14

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42

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

Отредактировано Лис (2017-12-27 03:28:44)

0

15

  • Автор: Павиа
  • Участник
  • Зарегистрирован: 2017-10-23
  • Приглашений: 0
  • Сообщений: 386
  • Уважение: [+3/-0]
  • Позитив: [+2/-3]
  • Провел на форуме:
    18 дней 1 час
  • Последний визит:
    2021-04-01 13:43:30
MihalNik написал(а):

ку́ча — это специализированная структура данных типа дерево

Не читайте вы википедию. Куча это не дерево,а список.

MihalNik написал(а):

Ну а причём тут синтаксис? Если для какого-нибудь дерева будет отдельный синтаксис, как он бывает для массивов или списков (на последних вполне себе делают деревья), то, например:

Потому что куча это не классический список. Поэтому он вполне заслуживает отдельных функций.

Отредактировано Павиа (2017-12-27 05:59:30)

0

16

  • Автор: Павиа
  • Участник
  • Зарегистрирован: 2017-10-23
  • Приглашений: 0
  • Сообщений: 386
  • Уважение: [+3/-0]
  • Позитив: [+2/-3]
  • Провел на форуме:
    18 дней 1 час
  • Последний визит:
    2021-04-01 13:43:30

Однако на больших кучах всё тормозит. Хотим добавить возможность ручного управления (для разделения кучи на части)

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

Так что если будут ссылки на сторонюю кучу то объект должен каждый раз проверять на nil и захватывать мьютекс.
Так что это будет всё тормозить неменьше.

Но тут можно сделать запрет на использование объектов из разных куч.

Синтаксически потребуется ввести новый тип указателя ссылающийся на дальние кучи.
Так как указатели обычно скрыты то это должно быть слово/слова которое характеризует объекты и классы.

0

17

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42
Павиа написал(а):

можно сделать запрет на использование объектов из разных куч.

Я об этом и говорю с первого сообщения. Сейчас для организации такого "запрета" используются границы процессов. А я предлагаю перенести это на уровень языка.

Павиа написал(а):

слово/слова которое характеризует объекты и классы.

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

Отредактировано Лис (2017-12-27 07:22:29)

0

18

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

Хотелось бы обсудить, как такая система могла бы реализовываться на уровне синтаксиса.

Да как все ООП - создаете новый объект куча (массив куч, список куч). При обращении явное указание и все. Внутри объекта юзается какая-нибудь собственная библиотека доступа к памяти, которая ходит по абсолютным ссылкам. Уничтожаете объект - трется все, что там есть. Вопрос эффективности остается открытым.

Однако на больших кучах всё тормозит.

А на малых тормозить не будет? Фон-Неймановская архитектура достигла определенных пределов. Теперь решение задач не осуществляется линейным увеличением производительности. Только и всего. Куча куч Вас не спасет - обработка big data отличается от обработки массива. Вы же ищите волшебную палочку, которая позволила бы применять старые алгоритмы к новым задачам.

0

19

  • Автор: MihalNik
  • Evangelist of AL-IV
  • Зарегистрирован: 2017-08-17
  • Приглашений: 0
  • Сообщений: 1096
  • Уважение: [+9/-1]
  • Позитив: [+7/-0]
  • Провел на форуме:
    21 день 0 часов
  • Последний визит:
    2023-09-30 09:30:29
Павиа написал(а):

Не читайте вы википедию.

Я выше же дал пример, что там сплошная каша.

Куча это не дерево,а список.

Давайте уже называть списки списками, а деревья деревьями. А кучу - абстрактной кашей, что хоть более менее соответствует сокрытости механизма со стороны ОС.

Лис написал(а):

Для того, чтобы что-нибудь прописать нужны соответствующие слова (или хотя бы знаки).

Ещё раз - что мешает завести одну структуру данных внутри другой?

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

Тот же список в массиве со стороны ОС выделяется и отдаётся целиком. В любом ЯП, где есть простые структуры и массивы в терминологии Сей или Паскаля. В чём проблема?

Павиа написал(а):

Поэтому он вполне заслуживает отдельных функций.

Функции и синтаксис - это разные вещи. Отдельный синтаксис означает сложность внесения изменений. Неспроста же соответствующим функциям в контейнерах дают по возможности одинаковые названия.

Отредактировано MihalNik (2017-12-27 09:37:13)

0

20

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

Хотим добавить возможность ручного управления (для разделения кучи на части). Ручное управление - это когда надо явно прописать что так, а что эдак.

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

Для того, чтобы что-нибудь прописать нужны соответствующие слова (или хотя бы знаки).

Синтаксис вообще самое последнее дело в истории, ну напишете:

создать куча1, куча2, куча3 как куча
куча1.создать(массив(1...10), х1)
х1[1]=100

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

Отредактировано utkin (2017-12-27 09:53:07)

0

21

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42
MihalNik написал(а):

Отдельный синтаксис означает сложность внесения изменений.

Парни из Rust так не считают. Новый механизм (проверка borrow checking) - значит новый синтаксис (и новый язык).

0

22

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

Парни из Rust так не считают.

Ну не считают и не считают. Влияние Rust на программирование на уровне статистической погрешности. Смысл от их несчитания?

0

23

  • Автор: MihalNik
  • Evangelist of AL-IV
  • Зарегистрирован: 2017-08-17
  • Приглашений: 0
  • Сообщений: 1096
  • Уважение: [+9/-1]
  • Позитив: [+7/-0]
  • Провел на форуме:
    21 день 0 часов
  • Последний визит:
    2023-09-30 09:30:29
Лис написал(а):

Парни из Rust так не считают

Давайте переходить к более конструктивным доводам.

Новый механизм (проверка borrow checking)

И по-возможности к русскому языку. Без восхищений, по существу. Тогда, наверное, многие вопросы сами по себе отпадут.

Отредактировано MihalNik (2017-12-27 10:08:11)

0

24

  • Автор: ВежливыйЛис
  • Администратор
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1103
  • Уважение: [+2/-1]
  • Позитив: [+4/-1]
  • Провел на форуме:
    7 дней 7 часов
  • Последний визит:
    2024-02-01 16:07:42
utkin написал(а):

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

И что, обсуждает ли кто из вас семантику? Т.е. как должен быть изменён алгоритм сборки мусора и что многокучесть ему даст. Нет, только всю тему зафлудили отвлечёнными рассуждениями.

Сначала обсудим алгоритм сборки - будет видно в чём профит.

Потом алгоритм компиляции для нового алгоритма сборки.

И только потом станет ясно, какой синтаксис удобнее. А там есть варианты кроме того, который предложил Уткин.

Отредактировано Лис (2017-12-28 08:35:01)

0

25

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

И что, обсуждает ли кто из вас семантику?

Потому что я задал простой вопрос - зачем? Зачем нужна многокучевость? Просто упражняться в теории легко и просто, но смысл?

Нет, только всю тему зафлудили отвлечёнными рассуждениями.

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

Сначала обсудим алгоритм сборки - будет видно в чём профит.

Вот не было, не было и опять. ЗАЧЕМ? Для чего это нужно. Вот Вы обсуждаете детали инструмента просто так без упоминания для чего им пользоваться? Я вот по себе вижу - есть куча, люди там пользуются, чего-то копошатся по своему. И приходит Лис и как ни в чем не бывало - а давай многокучевость. Ну как бы первый вопрос от человека который не пользуется многокучевостью, который не видел в своей работе необходимость кучи куч - зачем это надо?

А там есть варианты кроме того, который предложил Уткин.

наверняка есть. Тем более это не я предложил это простое следствие использования ООП - создать объект, провести в нем операции и удалить объект. Это просто термины ООП там, никакого ноу-хау нет. И схема тоже сама собой напрашивается - использовать библиотеку, которая самостоятельно распоряжается памятью в обход стандартного менеджера.

Отредактировано utkin (2017-12-28 08:59:58)

0

Страница: 1