Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>Вот тут не очень понятно. Точнее совсем не понятно. Как можно логически изменяемые данные просто сделать не изменяемыми на уровне системы типов и все?
WH>Данных которые можно очень легко сделать неизменяемыми сильно больше чем кажется.
Да, есть такое. Это идет от старого "одногопоточного" мышления разработчиков. Многие исторически привыкли просто не обращать на это внимания, т.к. в однопоточной среде нет никакой разницы между изменяемым и неизменяемым, между записью и чтением. Ну разьве что, если язык поддерживает константность, то можно сделать сделать логически немного более красиво, объявив что-то константным. В многопоточном же мире это имеет колоссальное значение.
Тем не менее, ЭТО НИКАК НЕ ИЗМЕНЯЕТ ТОГО ФАКТА, ЧТО ЕСТЬ И *ИЗМЕНЯЕМЫЕ* ДАННЫЕ.
С неизменяемым всё хорошо, пожалуйста, никаких возражений. Но давай же теперь наконец рассмотрим ситуацию, если у нас есть изменяемые данные, и не можем никак спроектировать вокруг этого!
Здравствуйте, remark, Вы писали:
R>Я не понимаю твой тезис и подход. R>Я сказал, что системы исключительно на обмене сообщениями могут быть очень не оптимальными в некоторых ситуациях.
Ты их не представил.
R>Что бы понять насколько технология хороша в общем случае, т.е. для *всех* случаев, надо пытаться её противопоставить не благоприятным для неё условиям, а наиболее НЕблагоприятным. R>Никто не спорит, что передача сообщений очень хороша в некоторых случаях. Можно противопоставлять благоприятным условиям, но это даёт практически 0 информации, не считая маркетинговой.
Нужно понимать что любую технологию можно сломать.
Другое дело что сделать это идя от реальной задачи оооочень сильно сложнее.
R>Поэтому я не понимаю твоей позиции в разговоре, никто не спорит, что WolfHound смог очень хорошо применить передачу сообщений для какой-то конкретной задачи. Но это никак не опровергает мой тезис, что системы исключительно на обмене сообщениями могут быть очень не оптимальными в некоторых ситуациях.
Каких?
R>Вот я и предлагаю рассмотреть вариант *НЕ* благоприятный для передачи сообщений. Когда структура часто модифицируется, поэтому копировать и реплицировать её не целесообразно. Структура очень большая, сравнимая с размером ОП.
Что за структура?
R>Для кэшей вот например как бывает. Можно взять N = 100, но тогда и кэшировать сможем в 100 раз меньше информации. А если взять N = 1, то тогда кэшировать сможем в 100 раз больше информации.
Для кешей ооочень хорошо работает url-хешь.
И этот самый url-хешь очень легко разрешает данную делему.
R>Либо считаешь, что в принципе вообще нет таких ситуаций, когда нельзя применить полное копирование + атомарная подмена?
Полное не обязательно.
Часто можно делать инкрементальные структуры в которых нужно создать O(log(N)) или вобще O(1) новых узлов.
Остальное старые данные.
А мосорщик со временем приберется.
Кстати на неизменяемых структурах данных он может быть реализован сильно эффективней.
У меня есть подозрение что ГЦ паузу на неизменяемых кучах можно будет свести к барьеру памямяти во всех потоках.
Можешь сам посмотреть на реализацию неизменяемых бинарных деревьев. Или на rope.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
R>>Я сказал, что системы исключительно на обмене сообщениями могут быть очень не оптимальными в некоторых ситуациях.
WH>Ты их не представил.
Так бы и сказал, что нужен реалистичный пример.
Ну вот допустим сервер онлайн игры. Надо хранить модель мира. Игроки постоянно модифицируют модель своими действиями, плюс модификации по таймерам. Взаимодействия хаотичны, т.е. игроки постоянно взаимодействуют с разными частями мира. Потенциально возможно взаимодействие любого игрока с любой частью мира.
Если есть статическая неизменяемая часть мира, то она нас сейчас не интересует. Допустим, что она реализована как неизменяемая и бог с ней.
Здравствуйте, remark, Вы писали:
R>С неизменяемым всё хорошо, пожалуйста, никаких возражений. Но давай же теперь наконец рассмотрим ситуацию, если у нас есть изменяемые данные,
Для этого нужно знать что это за данные.
R>и не можем никак спроектировать вокруг этого!
Вот в это я почему то не верю.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>Допустим у нас стоит RAID с максимальной пропускной способностью 320 Мб/с.
В самом самом благоприятном случае которого никогда не бывает.
Ибо необходимо обеспечить строго последовательную запись.
И я тебе больше скажу: В действиетльно критических местах RAID не используют. Уж больно они непредсказуемы и ненадежны.
Только софтовая репликация на простые винты без надстроек.
RAID это для бедных.
Ну или как вариант можно использовать десятый на одноранговых (одна сдохнет никто кроме админов и не заметит) реверсных проксях под дисковый кешь.
R>Т.е. если размер транзакции 4 кб, то мы в пределе можем фиксировать 90'000 т/с. А если размер транзакции 256 байт, то — 1.5 млн т/с. R>Т.е. на 32-процессорной машине у нас есть всего 21 мкс на транзакцию. А на 4-процессорной — 2.5 мкс на транзакцию.
Тебе в любом случае понадобится процесс который будет писать все на винт.
И это будет один процесс. Те нужна по крайней мере одна MP/SC очередь.
Ибо если их будет больше то под такой нагрузкой ты сразу получишь деградацию производительности винтов на порядки.
Так что тут нужно ну очень сильно думать.
Причем нужно действовать от задачи.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ибо если их будет больше то под такой нагрузкой ты сразу получишь деградацию производительности винтов на порядки.
Кстати, на flash'евых винтах НУЖНО более одного процесса запускать (или использовать что-то типа AIO/Overlapped IO) — так как там они в несколько аппаратных каналов параллельно умеют писать.
Здравствуйте, WolfHound, Вы писали:
R>>Либо считаешь, что в принципе вообще нет таких ситуаций, когда нельзя применить полное копирование + атомарная подмена?
WH>Полное не обязательно. WH>Часто можно делать инкрементальные структуры в которых нужно создать O(log(N)) или вобще O(1) новых узлов.
А-а-а. Частично изменяемые структуры (PCOW, partial copy-on-write) это уже совсем другое. На высоком уровне они уже модифицируемые структуры со всеми вытекающими — потенциально надо делать блокировки, что бы обеспечить консистентность. То, что отдельные маленькие кусочки подменяются целиком, уже больше становится деталью реализации.
Со списками и деревьями реализация более-менее понятна, а вот с произвольными графами становится значительно труднее. Т.к. надо вычленить часть графа, сделать для него обновленную копию и как-то атомарно подменить, и как-то решить вопрос, если кто-то ещё меняет эту же часть графа.
И уж как это решать на основе обмена сообщениями, я совсем не представляю...
WH>Остальное старые данные. WH>А мосорщик со временем приберется. WH>Кстати на неизменяемых структурах данных он может быть реализован сильно эффективней. WH>У меня есть подозрение что ГЦ паузу на неизменяемых кучах можно будет свести к барьеру памямяти во всех потоках.
А как быть с указателями в старых узлах? Они же должны обновляться, что бы указывать на новые. Это же уже не COW, это — PCOW.
WH>Можешь сам посмотреть на реализацию неизменяемых бинарных деревьев. Или на rope.
На неизменяемые-то чего на них смотреть. А вот на частично изменяемые бы посмотрел, есть какие-нибудь ссылки?
Разрешу себе вклиниться в дискуссию. Вы с remark'ом просто говорите про разные задачи. Если между очередьми нужно слать реально большие данные, и они mutable по поред., то копирование не имеет никакого смысла. И тогда мы приходим к тому, что хранить их нужно где-то отдельно. Тогда получается, что все эти очереди не решают почти никаких проблем, кроме убирания всего синхронизирующего добра под капот.
Именно поэтому мы не видим всемирной экспансии эрланга.
Здравствуйте, WolfHound, Вы писали:
R>>Допустим у нас стоит RAID с максимальной пропускной способностью 320 Мб/с. WH>В самом самом благоприятном случае которого никогда не бывает. WH>Ибо необходимо обеспечить строго последовательную запись.
WH>И я тебе больше скажу: В действиетльно критических местах RAID не используют. Уж больно они непредсказуемы и ненадежны. WH>Только софтовая репликация на простые винты без надстроек.
WH>RAID это для бедных. WH>Ну или как вариант можно использовать десятый на одноранговых (одна сдохнет никто кроме админов и не заметит) реверсных проксях под дисковый кешь.
Я поражаюсь твоей способности уводить разговор в сторону!
Так что по сути? Я пока вижу только очень сравнимые цифры, того что бы запись на диск была бы на 3 порядка медленней я не вижу. Ну не RAID, а ещё что-нибудь. Ну не 320 Мб/с, а 100 Мб/с. Принципиально ничего не меняется.
R>>Т.е. если размер транзакции 4 кб, то мы в пределе можем фиксировать 90'000 т/с. А если размер транзакции 256 байт, то — 1.5 млн т/с. R>>Т.е. на 32-процессорной машине у нас есть всего 21 мкс на транзакцию. А на 4-процессорной — 2.5 мкс на транзакцию. WH>Тебе в любом случае понадобится процесс который будет писать все на винт. WH>И это будет один процесс. Те нужна по крайней мере одна MP/SC очередь.
Именно. Я ничего против очередей вообще и не говорил. Я наоборот говорил, что если их можно применить, то замечательно. На всякий случай процитирую себя:
С помощью пайпов (очередей сообщений) система хорошо структурируется на независимые части, каждая часть "однопоточно" (читай эффективно) работает со своими локальными данными, а всё взаимодействие с остальным миром очень чётко структурировано — можно только отправлять сообщения или принимать сообщения.
Здравствуйте, WolfHound, Вы писали:
R>>Покажи на примере. Допустим есть множество лицевых счетов. На сервер поступает поток транзакций вида: изменить баланс л/с, перевести сумму с одного л/с на другой л/с, получить баланс л/с, открыть новый л/с и т.д. R>>Как тут сделать данные не изменяемыми на уровне системы типов?
WH>Эти данные будут жить в базе данных по любому. WH>Те ACID в полный рост с фиксацией на гооооораздо более тормозных винтах.
Ну так может мы сами и делаем специализированную БД.
Лог операций пишем в журнал. Учитывая скорость винтов, мы можем писать сотни тысяч записей в секунду.
Так что вопрос остается открытым — как нам реализовать "программную часть".
Если используется промышленная БД, то тоже вполне можно писать более 100'000 записей в секунду. Развитые БД специально для этого предоставляют интерфейс для потокового сохранения записей. В Oracle это Direct Path Loading, в PostgreSQL — COPY BINARY.
А что бы обеспечить обработку потока в 100'000 записей в секунду надо ого-го как потрудиться. Я не думаю, что вот так просто получится что-то тяп-ляп сделать, да что б ещё потом сказать "глядите, все упирается в диски, а наш сервер практически не загружен". И если речь идёт об SMP сервере, то вопрос о доступе к данным в многопоточном окружении тут будет одним из самых сложных.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, WolfHound, Вы писали:
КЛ>[]
КЛ>Разрешу себе вклиниться в дискуссию. Вы с remark'ом просто говорите про разные задачи. Если между очередьми нужно слать реально большие данные, и они mutable по поред., то копирование не имеет никакого смысла. И тогда мы приходим к тому, что хранить их нужно где-то отдельно. Тогда получается, что все эти очереди не решают почти никаких проблем, кроме убирания всего синхронизирующего добра под капот.
Да вроде как не про разные. WolfHound говорит, что таких задач просто нет (по-крайней он не видит, а никто не может привести реалистичный пример):
R>>Я правильно понял мысль, что в канал потоку может писать произвольное кол-во других потоков. Но если в программе данному конкретному потоку пишет только один другой поток, то сингулярити это гарантированно детектирует и будет использовать более оптимальную реализацию очереди? WH>Концы каналов могут свободно мигрировать между потоками. WH>В том числе и внутри других каналов. WH>Но в один момент времени один конец может находится только в одном потоке. WH>Также зная состояние конца канала можно точно сказать является ли этот конец в данный момент потребителем или производителем.
Вообще интересно. Т.е. подсоединили к косумеру одного продьюсера — за кулисами создалась spsc очередь. Потом подключили второго — за кулисами очередь изменилась на mpsc. Потом убрали первого — очередь опять изменилась на spsc.
Надо подумать...
Здравствуйте, Константин Л., Вы писали:
КЛ>Разрешу себе вклиниться в дискуссию. Вы с remark'ом просто говорите про разные задачи. Если между очередьми нужно слать реально большие данные, и они mutable по поред., то копирование не имеет никакого смысла. И тогда мы приходим к тому, что хранить их нужно где-то отдельно. Тогда получается, что все эти очереди не решают почти никаких проблем, кроме убирания всего синхронизирующего добра под капот.
Задачу в студию.
КЛ>Именно поэтому мы не видим всемирной экспансии эрланга.
Не по этому.
Эрлаг динамически типизированный язык.
Динамически типизированные языки не могут работать быстро. Просто никак.
Именно по этому экспансии эрланга и не будет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>Именно. Я ничего против очередей вообще и не говорил. Я наоборот говорил, что если их можно применить, то замечательно. На всякий случай процитирую себя:
Еще раз: В данном случае нам просто необходим ровно один процесс который пишет на винт.
Иначе мы получим просто дикую деградацию винта.
Я сам видел деградацию винта на 60М/С (точно не помню) до 0.5М/С.
И это еще кешь файловой системы использовался... а тут нужно писать мимо кеша сразу на винт.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>А-а-а. Частично изменяемые структуры (PCOW, partial copy-on-write) это уже совсем другое.
Нет. ты не понял.
Они вобще неизменяемые.
Просто большая часть новой структуры это все таже старая.
При этом старая вобще не меняется. Ни на бит.
Без мусорщика это не работает. Но кто сказал что нам нужно мучатся без мусорщика?
R>На высоком уровне они уже модифицируемые структуры со всеми вытекающими — потенциально надо делать блокировки, что бы обеспечить консистентность. То, что отдельные маленькие кусочки подменяются целиком, уже больше становится деталью реализации.
С деревьями и списками вобще все просто.
Они очень лего реализуются вобще не изменяемыми.
R>Со списками и деревьями реализация более-менее понятна, а вот с произвольными графами становится значительно труднее. Т.к. надо вычленить часть графа, сделать для него обновленную копию и как-то атомарно подменить, и как-то решить вопрос, если кто-то ещё меняет эту же часть графа.
А с графами по любому звиздец.
Те что-бы мы не делали, а всеравно придется выкручитваться проблемнозависимыми методами.
R>А как быть с указателями в старых узлах? Они же должны обновляться, что бы указывать на новые. Это же уже не COW, это — PCOW.
Так в фоне обновляем. Причем если железо позволяет то пишем мимо кеша.
А дальше барьер памяти...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Кстати, на flash'евых винтах НУЖНО более одного процесса запускать (или использовать что-то типа AIO/Overlapped IO) — так как там они в несколько аппаратных каналов параллельно умеют писать.
Я с ними дел пока не имел.
Так что паттерны эффективной работы с такими винтами не знаю.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>Так бы и сказал, что нужен реалистичный пример. R>Ну вот допустим сервер онлайн игры. Надо хранить модель мира. Игроки постоянно модифицируют модель своими действиями, плюс модификации по таймерам. Взаимодействия хаотичны, т.е. игроки постоянно взаимодействуют с разными частями мира. Потенциально возможно взаимодействие любого игрока с любой частью мира. R>Если есть статическая неизменяемая часть мира, то она нас сейчас не интересует. Допустим, что она реализована как неизменяемая и бог с ней.
В данном случае речь может идти только о кластере. Ибо если сервер не масштибируется то игра сдохнет как только станет хоть скольконибудь популярной.
А в случае кластера нам ну никак без обмена сообщениями не обойтись.
Ибо шарить нам нечего.
С произвольными частями мира игроки не взаимодействуют ни в одной из извесных мне игр. (хотя я не особо любитель MMORPG)
Везьде есть либо деление на сектора. Либо под группу просто создают клон вселенной.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>Разрешу себе вклиниться в дискуссию. Вы с remark'ом просто говорите про разные задачи. Если между очередьми нужно слать реально большие данные, и они mutable по поред., то копирование не имеет никакого смысла. И тогда мы приходим к тому, что хранить их нужно где-то отдельно. Тогда получается, что все эти очереди не решают почти никаких проблем, кроме убирания всего синхронизирующего добра под капот. WH>Задачу в студию.
тут я не спец. remark пусть придумывает. только не надо говорить, что таких не существует
КЛ>>Именно поэтому мы не видим всемирной экспансии эрланга. WH>Не по этому. WH>Эрлаг динамически типизированный язык. WH>Динамически типизированные языки не могут работать быстро. Просто никак. WH>Именно по этому экспансии эрланга и не будет.
во-первых эрланг у нас не единственный, во-вторых в задачах, где он используется, его слабая скорость не играет роли
Здравствуйте, remark, Вы писали:
R>Вообще интересно. Т.е. подсоединили к косумеру одного продьюсера — за кулисами создалась spsc очередь. Потом подключили второго — за кулисами очередь изменилась на mpsc. Потом убрали первого — очередь опять изменилась на spsc.
Нет. В сингулярити каналы всегда spsc.
Другое дело что в зависимости от состояния канала производитель с потребителем иногда меняются местами.
Таким образом возможно создавать диалоги.
Временами оба конца могут находится в состоянии потребителя. Это случается когда один уже все сказал, а второй еще на все прочитал. Как только прочитает станет производителем.
А за тем чтобы оба не попытались говорить следит конечный автомат который проверяет система типов (в сингулярити сделано несколько тупее но такая система типов возможна).
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Кстати, на flash'евых винтах НУЖНО более одного процесса запускать (или использовать что-то типа AIO/Overlapped IO) — так как там они в несколько аппаратных каналов параллельно умеют писать. WH>Я с ними дел пока не имел. WH>Так что паттерны эффективной работы с такими винтами не знаю.
Пора присматриваться: http://www.i4u.com/article17560.html
