Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>Ааа. Ну так опять оптимизация применимая для очень частного случая. Что-то типа — в голову списка добавляются новые элементы. Правильно?
WH>Этих частных случаев сильно больше чем может показаться на первый взгляд.
Кстати, это ведь уже не обмен сообщениями, правильно? Это уже разделяемая структура? Или я чего-то не понимаю?
R>>Это совершенно не проблема. Именно для таких задач существуют экстремально эффективные алгоритмы сборки мусора, с которыми GC общего назначения просто не может конкурировать.
WH>А ГЦ на неизменяемой куче?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
WH>>>.NET с жабкой не подходят. WH>>>Системой типов не вышли. КЛ>>почему не подошли? что-то не вижу причин WH>Их системы типов дырявые как решето.
в каком плане?
WH>Неизменяемых данных нет.
будут в с# вроде
WH>Отсутствие возможности на этапе компиляции отловить рейскондишены.
будут неизменяемые, может и это придет
WH>Есть статические переменные. WH>... WH>Даже в сингулярити все плохо. WH>Например наличие выделенного меня очень растроело WH>
WH> public static int Main(String[] args)
WH> {
WH> ExtensionContract.Exp! ec = S3TrioResources.Values.ec.Acquire();
WH> ServiceProviderContract.Exp! ve = S3TrioResources.Values.video.Acquire();
WH> ServiceProviderContract.Exp! te = S3TrioResources.Values.console.Acquire();
WH> // Create the device
WH> device = new S3Device(S3TrioResources.Values);
WH> device.Initialize();
WH> // Signal I/O system that we are initialized.
WH> ec.SendSuccess();
WH> // create a set of all client endpoints connected to the video
WH> // interface.
WH> ESet<VideoDeviceContract.Exp:Ready> vs
WH> = new ESet<VideoDeviceContract.Exp:Ready>();
WH> // create a set of all client endpoints connected to the text
WH> // interface.
WH> ESet<ConsoleDeviceContract.Exp:Ready> ts
WH> = new ESet<ConsoleDeviceContract.Exp:Ready>();
WH>.....
WH> // Close the device
WH> device.Finalize();
WH>
WH> Tracing.Log(Tracing.Audit, "Shutdown");
WH> delete ec;
WH> delete te;
WH> delete ve;
WH> vs.Dispose();
WH> ts.Dispose();
WH>
WH> return 0;
WH> }
WH> }
WH>
WH>Само оно должно закрываться.
Что это за язык ? а где же using???
WH>Короче от системы типов аля жабка в нормальной ВМ ничего не останется.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>Задачка приведена несколькими постами выше, там где увёл разговор в сторону на диски.
WH>Ну что поделать если она уходит на диски. WH>Ну в диски она по любому упирается, а не в кешь процессора.
Да где ж она упирается? Пишем из одного потока 10^6 записей в секунду в журнал. А вся основная обработка идёт в разных потоках параллельно.
R>>Ну пожалуйста-пожалуйста, пишет один. Но у нас же у сервера задача не только писАть, он ещё что-то потом должен делать. R>>Теперь попытаемся вернуться к исходной теме разговора. Сервер. Лицевые счета. Переводы со счёта на счёт... WH>Еще раз: Для того чтобы выжать из мурочки еще 100 грамм нужно знать задачу в мелочах. WH>В данном случае решение очень сильно начинает зависеть от того сколько этих счетов. WH>Как часто транзакции хотят иметь доступ к одному и томуже счету. WH>Какие еще действия нам нужны с этими счетами. WH>...
Счетов — 10^6.
Операции:
Получение баланса по номеру л/с — 56%
Добавление л/с — 2%
Удаление л/с — 2%
Изменение баланса л/с — 20%
Перевод с одного л/с на другой — 20%
Считаем, что операции распределены равномерно по л/с, т.е. коллизии редки.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Константин Л., Вы писали:
КЛ>>Что это за язык ? а где же using??? C>А using ничего не меняет — его тоже можно забыть поставить.
т.е. проблема в том, что нам нужно гарантировать детерминированное удаление, или в том, что оно нужно само по себе? При чем здесь система типов?
R>>Ну вот об этом я начал разговор, что на обмене сообщениями некоторые задачи решаются плохо. Теперь согласен? WH>Я сказал вобще ни как. WH>Те ни обменом сообщений, ни какими либо другими плясками с бубном.
По крайней мере 3 способа РЕШЕНИЯ:
1. Крупнозернистые блокировки (применяется более 30 лет)
2. Мелкозернистые блокировки (применяется более 30 лет)
3. Программная транзакционная память (применяется более 5 лет)
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>Так бы и сказал, что нужен реалистичный пример. R>>Ну вот допустим сервер онлайн игры. Надо хранить модель мира. Игроки постоянно модифицируют модель своими действиями, плюс модификации по таймерам. Взаимодействия хаотичны, т.е. игроки постоянно взаимодействуют с разными частями мира. Потенциально возможно взаимодействие любого игрока с любой частью мира. R>>Если есть статическая неизменяемая часть мира, то она нас сейчас не интересует. Допустим, что она реализована как неизменяемая и бог с ней.
WH>В данном случае речь может идти только о кластере. Ибо если сервер не масштибируется то игра сдохнет как только станет хоть скольконибудь популярной.
Не MMO, просто онлайн игра — надо держать максимум сотни игроков, ну хотя впрочем — чем больше получается, тем лучше. Пользователям говорится — если хотите больше, то покупайте более мощный SMP.
WH>А в случае кластера нам ну никак без обмена сообщениями не обойтись.
Даже если есть обмен сообщениями между машинами, то внутри машин как? Допустим машины — 2-процессорные, 4-ядерные xeon'ы, сами по себе серьёзные звери. И не загрузить их как следует просто не вариант.
Внутри машины-то как будем делать?
WH>Ибо шарить нам нечего. WH>С произвольными частями мира игроки не взаимодействуют ни в одной из извесных мне игр. (хотя я не особо любитель MMORPG) WH>Везьде есть либо деление на сектора. Либо под группу просто создают клон вселенной.
Ну вот, хорошо. Есть сектор. Его держит один 2-процессорный, 4-ядерный xeon.
Надо хранить модель мира. Игроки постоянно модифицируют модель своими действиями, плюс модификации по таймерам. Взаимодействия хаотичны, т.е. игроки постоянно взаимодействуют с разными частями мира. Потенциально возможно взаимодействие любого игрока с любой частью мира.
Если есть статическая неизменяемая часть мира, то она нас сейчас не интересует. Допустим, что она реализована как неизменяемая и бог с ней.
Здравствуйте, Константин Л., Вы писали:
КЛ>т.е. проблема в том, что нам нужно гарантировать детерминированное удаление, или в том, что оно нужно само по себе? При чем здесь система типов?
При том что только на уровне системы типов можно гарантировать что объекты определенных типов будут детерминированно финализированны.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Константин Л., Вы писали:
WH>>Их системы типов дырявые как решето. КЛ>в каком плане?
В прямом.
Хрен программу проанализируешь.
WH>>Неизменяемых данных нет. КЛ>будут в с# вроде
Позно.
Вся стандартная библиотека пропитана изменяемыми данными.
WH>>Отсутствие возможности на этапе компиляции отловить рейскондишены. КЛ>будут неизменяемые, может и это придет
Не придет.
Чтобы их исключить нужно очень сильно систему типов поменять.
Например нужно раз и навсегда запретить статические переменные.
Это необходимое условие.
Но ни из C# ни из жабы их никогда не уберут.
КЛ>Что это за язык ? а где же using???
В топку этот костыль.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
WH>>Этих частных случаев сильно больше чем может показаться на первый взгляд. R>Кстати, это ведь уже не обмен сообщениями, правильно? Это уже разделяемая структура? Или я чего-то не понимаю? Неизменяемая структура данных.
WH>>А ГЦ на неизменяемой куче? R>А GC будет несколько в приложении?
Да.
В любом случае ГЦ на неизменяемой куче может быть совсем паралельным.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>А ГЦ на неизменяемой куче? R>>А GC будет несколько в приложении? WH>Да. WH>В любом случае ГЦ на неизменяемой куче может быть совсем паралельным.
Он и на обычной куче может быть совсем параллельным. Тут вообще проблем нет.
Здравствуйте, WolfHound, Вы писали:
R>>Для кэшей вот например как бывает. Можно взять N = 100, но тогда и кэшировать сможем в 100 раз меньше информации. А если взять N = 1, то тогда кэшировать сможем в 100 раз больше информации. WH>Для кешей ооочень хорошо работает url-хешь. WH>И этот самый url-хешь очень легко разрешает данную делему.
Здравствуйте, WolfHound, Вы писали:
КЛ>>т.е. проблема в том, что нам нужно гарантировать детерминированное удаление, или в том, что оно нужно само по себе? При чем здесь система типов? WH>При том что только на уровне системы типов можно гарантировать что объекты определенных типов будут детерминированно финализированны.
Это ты вообще никак не гарантируешь с GC. Он тебе прикончит объекты только когда ему захочется.
А ещё шутки с:
public void finalize()
{
Thread.sleep(50000000); //Happy new year!
}
Тут уж либо подход С++ нужен со статическими деструкторами хотя бы для подмножества объектов.
Здравствуйте, Константин Л., Вы писали:
КЛ>>>Что это за язык ? а где же using??? C>>А using ничего не меняет — его тоже можно забыть поставить. КЛ>т.е. проблема в том, что нам нужно гарантировать детерминированное удаление, или в том, что оно нужно само по себе? При чем здесь система типов?
Обе проблемы. См. ниже..
Здравствуйте, Cyberax, Вы писали:
C>Это ты вообще никак не гарантируешь с GC. Он тебе прикончит объекты только когда ему захочется.
Есть варианты.
C>А ещё шутки с:
В топку финалайзеры.
C>Тут уж либо подход С++ нужен со статическими деструкторами хотя бы для подмножества объектов.
Плохой подход.
Есть лучше.
Сейчас думаю 2 варианта. У одного одни неудобства при использовании, у другого другие.
При этом в отличии от объектов с деструкторами они оба совместимы с замыканиями и оптимизацией хвостовой рекурсии.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>Что такое "url-хешь"? Не могу нагуглить...
В общем случае это считаем от запроса или его части хешь и по остатку от деления хеша на N отправляем одному из N обработчиков.
В случае с HTTP считаем от url. Отсюда и пошло.
В частности это позволяет очень сильно повысить кешхит.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
WH>>>Их системы типов дырявые как решето. КЛ>>в каком плане? WH>В прямом. WH>Хрен программу проанализируешь.
ну, ишь че захотел
[]
КЛ>>Что это за язык ? а где же using??? WH>В топку этот костыль.
хе-хе. помню совсем недавно всем известные личности чуть-ли не молились на него
Здравствуйте, Константин Л., Вы писали:
КЛ>да, черт возьми, именно к этому я клоню. Однако сейчас WolfHound вспомнить про using, хотя в данном контексте я не стал бы
Не угадал.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Это ты вообще никак не гарантируешь с GC. Он тебе прикончит объекты только когда ему захочется. WH>Есть варианты.
С GC — никаких вариантов. В принципе, можно дать какую-то верхнюю границу времени финализации, но и это уже составляет проблемы.
C>>А ещё шутки с: WH>В топку финалайзеры.
Точно.
C>>Тут уж либо подход С++ нужен со статическими деструкторами хотя бы для подмножества объектов. WH>Плохой подход. WH>Есть лучше. WH>Сейчас думаю 2 варианта. У одного одни неудобства при использовании, у другого другие. WH>При этом в отличии от объектов с деструкторами они оба совместимы с замыканиями и оптимизацией хвостовой рекурсии.
А можно хотя бы крактое описание?
? а где же using???
