Здравствуйте, WolfHound, Вы писали:
WH>С произвольными частями мира игроки не взаимодействуют ни в одной из извесных мне игр. (хотя я не особо любитель MMORPG)
Есть такие. Например, Lineage II — там один большой мир, без деления на секторы. Как они это делают мне и самому интересно.
Здравствуйте, Cyberax, Вы писали:
C>Есть такие. Например, Lineage II — там один большой мир, без деления на секторы. Как они это делают мне и самому интересно.
И все все игроки в одном мире?
Или есть куча паралельных миров в каждом из которых тусуется относительно небольшая (100-200) кучка игроков?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Константин Л., Вы писали:
КЛ>тут я не спец. remark пусть придумывает. только не надо говорить, что таких не существует
Что-то у него пока плохо получается.
КЛ>во-первых эрланг у нас не единственный,
И что еще?
КЛ>во-вторых в задачах, где он используется, его слабая скорость не играет роли
В любом случае низкая скорость фатальный недостаток.
Причем она просто теоритически не может стать высокой.
Ибо типизация динамическая, а значит ничего не наоптимизировать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>Разрешу себе вклиниться в дискуссию. Вы с remark'ом просто говорите про разные задачи. Если между очередьми нужно слать реально большие данные, и они mutable по поред., то копирование не имеет никакого смысла. И тогда мы приходим к тому, что хранить их нужно где-то отдельно. Тогда получается, что все эти очереди не решают почти никаких проблем, кроме убирания всего синхронизирующего добра под капот.
WH>Задачу в студию.
Может кто ещё приведёт пример задачи. Мне сходу в голову никакой пример-убийца не приходит. Ну если Вы тоже считаете, что таких примеров нет, то тоже выскажитесь. Может и действительно нет...
Суть: должно быть большое "множество" (массив, список, дерево — не важно) данных. Данные часто и регулярно изменяются. Нет возможности партицировать данные. Нет возможности сделать N копий данных. Данные меняются несколькими потоками.
Здравствуйте, WolfHound, Вы писали:
C>>Есть такие. Например, Lineage II — там один большой мир, без деления на секторы. Как они это делают мне и самому интересно. WH>И все все игроки в одном мире? WH>Или есть куча паралельных миров в каждом из которых тусуется относительно небольшая (100-200) кучка игроков?
Миров там несколько (штук 6), но в каждом мире запросто до 10000 игроков бывает.
[]
КЛ>>во-первых эрланг у нас не единственный, WH>И что еще?
а что нам мешает делать подобный системы на стат. тип. языках?
КЛ>>во-вторых в задачах, где он используется, его слабая скорость не играет роли WH>В любом случае низкая скорость фатальный недостаток. WH>Причем она просто теоритически не может стать высокой. WH>Ибо типизация динамическая, а значит ничего не наоптимизировать.
ну это понятно. Хотя где там у нас аннотации типов ввели?
Здравствуйте, Cyberax, Вы писали:
C>Пора присматриваться: http://www.i4u.com/article17560.html
Выглядит круто.
Но пака мало понятно что именно от него ждать.
Вот когда он мне попадет в руки вот тогда и посмотрим что он может.
И в каких сценариях работает хорошо, а в каких дохнет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>Ну так может мы сами и делаем специализированную БД.
В случае специализированной базы можно использую лазейки в задаче срезать углы.
Так что нам по любому нужна конкретная задача чтобы ее анализировать.
R>Лог операций пишем в журнал. Учитывая скорость винтов, мы можем писать сотни тысяч записей в секунду.
Тут нужно по любому один пишущий процесс. Иначе не видать нам и близко нужной производительности.
R>Так что вопрос остается открытым — как нам реализовать "программную часть".
Зависит от задачи.
Возможно что и никак. Те вобще никак. Ни тушкой ни чучелом ни кластером.
А если можно кластеризовать то с SMP и подавно проблем не будет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>Вообще интересно. Т.е. подсоединили к косумеру одного продьюсера — за кулисами создалась spsc очередь. Потом подключили второго — за кулисами очередь изменилась на mpsc. Потом убрали первого — очередь опять изменилась на spsc.
WH>Нет. В сингулярити каналы всегда spsc. WH>Другое дело что в зависимости от состояния канала производитель с потребителем иногда меняются местами. WH>Таким образом возможно создавать диалоги. WH>Временами оба конца могут находится в состоянии потребителя. Это случается когда один уже все сказал, а второй еще на все прочитал. Как только прочитает станет производителем. WH>А за тем чтобы оба не попытались говорить следит конечный автомат который проверяет система типов (в сингулярити сделано несколько тупее но такая система типов возможна).
Понятно... Но это опять же частный оптимизированный случай.
Не понятно как тут делать лоад-балансинг. Централизованные лоад-балансеры слишком дорогие, с ними не сделаешь элемент работы меньше десятка тысяч тактов. Децентрализованный на основе spsc очередей... задачка не тривиальная... и скорее всего тоже не имеющая эффективного решения. А на других типах очередей децентрализованный делается значительно легче...
Здравствуйте, Константин Л., Вы писали:
КЛ>а что нам мешает делать подобный системы на стат. тип. языках?
Ничего.
Но их пока нет.
Только и всего.
Вот когда будут тогда и посмотрем кто кого порвет.
.NET с жабкой не подходят.
Системой типов не вышли.
КЛ>ну это понятно. Хотя где там у нас аннотации типов ввели?
Бесполезно.
Нужна тотальная статическая типизация.
Максимум контролируемые касты к интерфейсам аля dynamic_cast.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>Ну так может мы сами и делаем специализированную БД.
WH>В случае специализированной базы можно использую лазейки в задаче срезать углы. WH>Так что нам по любому нужна конкретная задача чтобы ее анализировать.
Задачка приведена несколькими постами выше, там где увёл разговор в сторону на диски.
R>>Лог операций пишем в журнал. Учитывая скорость винтов, мы можем писать сотни тысяч записей в секунду.
WH>Тут нужно по любому один пишущий процесс. Иначе не видать нам и близко нужной производительности.
Ну пожалуйста-пожалуйста, пишет один. Но у нас же у сервера задача не только писАть, он ещё что-то потом должен делать.
Теперь попытаемся вернуться к исходной теме разговора. Сервер. Лицевые счета. Переводы со счёта на счёт...
R>>Так что вопрос остается открытым — как нам реализовать "программную часть".
WH>Зависит от задачи. WH>Возможно что и никак. Те вобще никак. Ни тушкой ни чучелом ни кластером.
Ну вот об этом я начал разговор, что на обмене сообщениями некоторые задачи решаются плохо. Теперь согласен?
Здравствуйте, remark, Вы писали:
R>Понятно... Но это опять же частный оптимизированный случай.
Достаточный в подавляющем большенстве случаев.
R>Не понятно как тут делать лоад-балансинг. Централизованные лоад-балансеры слишком дорогие, с ними не сделаешь элемент работы меньше десятка тысяч тактов. Децентрализованный на основе spsc очередей... задачка не тривиальная... и скорее всего тоже не имеющая эффективного решения. А на других типах очередей децентрализованный делается значительно легче...
Тут опять нужно смотреть что за балансер у нас.
Да никто и не говорил что нужно всегда жить только на spsc очередях.
mpsc + urlhash могут ой как сильно разгрузить систему.
А mpmc я что-то както побаиваюсь. Мутные они какието.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>Именно. Я ничего против очередей вообще и не говорил. Я наоборот говорил, что если их можно применить, то замечательно. На всякий случай процитирую себя: WH>Еще раз: В данном случае нам просто необходим ровно один процесс который пишет на винт. WH>Иначе мы получим просто дикую деградацию винта. WH>Я сам видел деградацию винта на 60М/С (точно не помню) до 0.5М/С. WH>И это еще кешь файловой системы использовался... а тут нужно писать мимо кеша сразу на винт.
Хорошо. Записываем из одного потока. А вся остальная работа (должна же быть какая-то) делается из всех потоков.
Тут мы просто отвлеклись и установили, что диск НЕ будет особо узким местом.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>А-а-а. Частично изменяемые структуры (PCOW, partial copy-on-write) это уже совсем другое. WH>Нет. ты не понял. WH>Они вобще неизменяемые. WH>Просто большая часть новой структуры это все таже старая. WH>При этом старая вобще не меняется. Ни на бит.
Ааа. Ну так опять оптимизация применимая для очень частного случая. Что-то типа — в голову списка добавляются новые элементы. Правильно?
Я могу ещё круче предложить. Все данные сводим в одному int'у. Далее читаем и пишем их из произвольного числа потоков. Никакой синхронизации не надо. Все задачи, которые не сводятся к int'у объявляем не решаемыми. Серебрянная пуля готова!
WH>Без мусорщика это не работает. Но кто сказал что нам нужно мучатся без мусорщика?
Это совершенно не проблема. Именно для таких задач существуют экстремально эффективные алгоритмы сборки мусора, с которыми GC общего назначения просто не может конкурировать. Причём можно выбрать и настроить алгоритм под конкретную ситуацию: кол-во записей, размер мусора и т.д. На С++ они реализуются достаточно тривиально. И я знаю прецедент реализации такого алгоритма в Java, в обход штатного GC, т.к. он с такой задачей справлялся плохо.
R>>Со списками и деревьями реализация более-менее понятна, а вот с произвольными графами становится значительно труднее. Т.к. надо вычленить часть графа, сделать для него обновленную копию и как-то атомарно подменить, и как-то решить вопрос, если кто-то ещё меняет эту же часть графа. WH>А с графами по любому звиздец. WH>Те что-бы мы не делали, а всеравно придется выкручитваться проблемнозависимыми методами.
Вот и нашли ещё один хороший пример.
А проблема такая, что нужен именно граф. Или ты хочешь сказать, что в программном обеспечении графы тоже вообще не применяются?
Здравствуйте, remark, Вы писали:
R>Задачка приведена несколькими постами выше, там где увёл разговор в сторону на диски.
Ну что поделать если она уходит на диски.
Ну в диски она по любому упирается, а не в кешь процессора.
R>Ну пожалуйста-пожалуйста, пишет один. Но у нас же у сервера задача не только писАть, он ещё что-то потом должен делать. R>Теперь попытаемся вернуться к исходной теме разговора. Сервер. Лицевые счета. Переводы со счёта на счёт...
Еще раз: Для того чтобы выжать из мурочки еще 100 грамм нужно знать задачу в мелочах.
В данном случае решение очень сильно начинает зависеть от того сколько этих счетов.
Как часто транзакции хотят иметь доступ к одному и томуже счету.
Какие еще действия нам нужны с этими счетами.
...
Скажем если у нас очень много коллизий то у нас просто нет выбора кроме как загнать все транзакции в один поток.
Хотя подготовительные (парсинг итп) действия можно и распаралелить.
R>Ну вот об этом я начал разговор, что на обмене сообщениями некоторые задачи решаются плохо. Теперь согласен?
Я сказал вобще ни как.
Те ни обменом сообщений, ни какими либо другими плясками с бубном.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>Ааа. Ну так опять оптимизация применимая для очень частного случая. Что-то типа — в голову списка добавляются новые элементы. Правильно?
Этих частных случаев сильно больше чем может показаться на первый взгляд.
R>Это совершенно не проблема. Именно для таких задач существуют экстремально эффективные алгоритмы сборки мусора, с которыми GC общего назначения просто не может конкурировать.
А ГЦ на неизменяемой куче?
R>Вот и нашли ещё один хороший пример. R>А проблема такая, что нужен именно граф. Или ты хочешь сказать, что в программном обеспечении графы тоже вообще не применяются?
Сферические в вакууме?
Думаю что нет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>а что нам мешает делать подобный системы на стат. тип. языках? WH>Ничего. WH>Но их пока нет. WH>Только и всего. WH>Вот когда будут тогда и посмотрем кто кого порвет. WH>.NET с жабкой не подходят. WH>Системой типов не вышли.
почему не подошли? что-то не вижу причин
КЛ>>ну это понятно. Хотя где там у нас аннотации типов ввели? WH>Бесполезно. WH>Нужна тотальная статическая типизация. WH>Максимум контролируемые касты к интерфейсам аля dynamic_cast.
Здравствуйте, WolfHound, Вы писали:
C>>Пора присматриваться: http://www.i4u.com/article17560.html WH>Выглядит круто. WH>Но пака мало понятно что именно от него ждать. WH>Вот когда он мне попадет в руки вот тогда и посмотрим что он может. WH>И в каких сценариях работает хорошо, а в каких дохнет.
Угу, я жду пока мне пришлют экземпляр. Жаль только, что они пока будут стоить порядка $5000.
Здравствуйте, Константин Л., Вы писали:
WH>>.NET с жабкой не подходят. WH>>Системой типов не вышли. КЛ>почему не подошли? что-то не вижу причин
Их системы типов дырявые как решето.
Неизменяемых данных нет.
Отсутствие возможности на этапе компиляции отловить рейскондишены.
Есть статические переменные.
...
Даже в сингулярити все плохо.
Например наличие выделенного меня очень растроело
public static int Main(String[] args)
{
ExtensionContract.Exp! ec = S3TrioResources.Values.ec.Acquire();
ServiceProviderContract.Exp! ve = S3TrioResources.Values.video.Acquire();
ServiceProviderContract.Exp! te = S3TrioResources.Values.console.Acquire();
// Create the device
device = new S3Device(S3TrioResources.Values);
device.Initialize();
// Signal I/O system that we are initialized.
ec.SendSuccess();
// create a set of all client endpoints connected to the video
// interface.
ESet<VideoDeviceContract.Exp:Ready> vs
= new ESet<VideoDeviceContract.Exp:Ready>();
// create a set of all client endpoints connected to the text
// interface.
ESet<ConsoleDeviceContract.Exp:Ready> ts
= new ESet<ConsoleDeviceContract.Exp:Ready>();
.....
// Close the device device.Finalize();
Tracing.Log(Tracing.Audit, "Shutdown");
delete ec;
delete te;
delete ve;
vs.Dispose();
ts.Dispose();
return 0;
}
}
Само оно должно закрываться.
Короче от системы типов аля жабка в нормальной ВМ ничего не останется.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
