Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не совсем так. Unix way (во всяком случае, в контексте этой дискуссии, как я её понимаю) не так мёртво завязан на синхронность вызовов. Что COM, что CORBA — одна и та же песня: синхронный вызов с непредсказуемой длительностью, с помощью которых ещё и эмулировать messaging приходится.
Ну вообще-то в CORBA можно описать асинхронные вызовы.
В CORBA-way делают так:
A --- msg_to_call_func(callback) -->
тишина...
callback <--- msg_with_result
Ведь тебе по-любому надо как-то заниматься диспечеризацией ответных сообщений, наличие callback делает это автоматически. Если же прямой вызов A-->B был асинхронным, то такая модель IMHO получается самой удобной для программирования того, о чем ты говоришь, ибо стандарты CORBA решают за разработчика кучу вещей, начиная от разбора/компоновки сообщений, диспечеризации и заканчивая балансировкой нагрузки на серверной стороне (с поддержкой пулов тредов и прочих технических "мелочей", которые вовсе не мелочи).
ГВ>Ну и поскольку здесь не притягивается семантика понятия "вызов функции" (имя функции, параметры, результат), то можно обойтись более простыми средствами, не так сильно влияют стереотипы. Или, говоря порезче: меньше лишнего хлама под ногами болтается.
Фиг его знает. Ведь любой свой протокол надо специфицировать. А IDL с коменнтариями сама по себе является неплохой докой.
ГВ>Опять таки, любой вызов DCOM/CORBA может завершиться исключением, а это уже требует в обязательном порядке обкладывать их обработкой исключений, с messaging всё проще — мы сразу честно признаёмся себе, что длительность вызова предсказать нельзя и ориентируемся на модель: "ждём сообщение", а не "должно сработать!".
Это верно для синхронных вызовов.
ГВ>Эмулировать RPC с помощью messaging — запросто (он и так на нём построен ), обратное — уже не так легко (минимум два варианта: polling или callback), плюс обязательная дополнительная загрузка канала связи. В случае callback (для CORBA) ещё нужно вставлять в клиенскую часть сугубо серверные приблуды итэдэ итэпэ.
В момент инициализации ORB-а добавить 5-6 лишних строк для установки его серверных св-в. В мессейджинге тебе ведь тоже надо как-то озаботиться приемом сообщений. В CORBA можно запустить ORB в отдельном потоке, либо регулярно вызывать у него нечто вроде do_messages(). Т.е. ничем не хуже обслуживание сокетов. Да еще код попереносимей будет.
ГВ> А простой messaging по IP: сокеты плюс простенькая сериализация. Да и то, в случае C можно структуры данных почти без изменений гонять (диспетчеризация только нужна и решение конфликта endian-ов).
Да, именно, речь о масштабировании. Если система взаимодействующих процессов предназначена для работы на одной машине, то от очень многого можно отказаться, и сэкономить на размерах бинарных исполняемых образов. Тогда вариант с перегонкой структур С по значению работает прекрасно.
ГВ>Одним словом, messaging — базовый механизм, на нём уже можно сделать всё.
От требований задачи зависит. Если вдруг начнет получаться, что самописный messaging превращается в CORBA или COM, то понятно, что делать надо.
Здравствуйте, Cyberax, Вы писали:
C>Кроме того, я только сейчас это заметил — при сканировании C>include-файлов они ищутся по именам, что немного медленнее перечисления C>findfirst/findnext'ом.
Ты спутал НТФС с ФАТ32 В нем перебор делается быстрее чем поиск по имени.
Как раз по именам в НТФС ищется быстрее, нежели перебором findfirst/findnext.
Все оттого, что поиск в дереве выполняется быстрее перебора всех элементов.
> Самый старый файл обновлялся 05.07.2006 09:37:49
Заметь, уже 1.3 секунды. Умножь это число на 5 — получим порядка 7 секунд.
С учетом твоего высказывания выше, можно 7 помножить еще на 1000 и прибавить 345, шоб больше було
>>> > XPCOM просто самопальный клон КОМ-а который можно использовать в любом >>> > компиляторе С++ при наличии соотвествующих библиотек. >> C>А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу >> C>ATLевских, всякие аналоги ATL/MFC Trace Tool? >> А что с Цигвином оно не работает? C>XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что C>кроме тулзов из Mozilla для XPCOM больше ничего почти и нет.
Plutonia Experiment wrote: > Ты спутал НТФС с ФАТ32 В нем перебор делается быстрее чем поиск по имени. > Как раз по именам в НТФС ищется быстрее, нежели перебором > findfirst/findnext. > Все оттого, что поиск в дереве выполняется быстрее перебора всех элементов.
Ничего я не перепутал. Почитай лучше про алгоритм "танцующих деревьев" в
Reiser4.
NTFS — это хорошая система для 90-х годов, но сейчас она уже устарела.
>> Самый старый файл обновлялся 05.07.2006 09:37:49 > Заметь, уже 1.3 секунды. Умножь это число на 5 — получим порядка 7 секунд. > С учетом твоего высказывания выше, можно 7 помножить еще на 1000 и > прибавить 345, шоб больше було
Мне просто лень было делать более точные замеры. Я уже как-то сюда писал
мини-бенчмарк: http://rsdn.ru/Forum/?mid=1710544
Plutonia Experiment wrote: > C>Драйверы *чего* обновлять? Все как поставилось с родного > C>установчного диска — так и стоит. > Ты винду и лялих запускаешь на одном и том же медленном ноутбуке ?
Ага. Хотя не такой уж он и медленный — я специально поставил винчестер
на 7200RPM.
Plutonia Experiment wrote: > C>Кстати, если тебе так нравится NTFS и Windows, то расскажи как сделать > C>аналог Линуксового laptop mode? > Элементарно. 2 гига памяти и отключаешь своп.
Мимо тазика. Каждый раз когда ты будешь жать ctrl-s в редакторе у тебя
будет происходить запись на диск, а значит диск должен работать.
Laptop-mode позволяет ВООБЩЕ выключить диск (его двигатель физически
останавливается) и накапливать изменения в памяти, а потом сбрасывать
одним куском.
Plutonia Experiment wrote: >> > *C>А тулзы для работы с его библиотеками типов, создания wrapper'ов > по типу** >> > C>ATLевских, всякие аналоги ATL/MFC Trace Tool?* >> > А что с Цигвином оно не работает? > *C>XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что > C>кроме тулзов из Mozilla для XPCOM больше ничего почти и нет.* > Выделил сообщения. Не могу понять логики
XPCOM — это языко-независимая система по своему дизайну, но де-факто с
ней работают только тулзы от Mozilla.
Здравствуйте, Cyberax, Вы писали:
C>Plutonia Experiment wrote: >> Ты спутал НТФС с ФАТ32 В нем перебор делается быстрее чем поиск по имени. >> Как раз по именам в НТФС ищется быстрее, нежели перебором >> findfirst/findnext. >> Все оттого, что поиск в дереве выполняется быстрее перебора всех элементов. C>Ничего я не перепутал. Почитай лучше про алгоритм "танцующих деревьев" в C>Reiser4.
при сканировании
include-файлов они ищутся по именам, что немного медленнее перечисления
findfirst/findnext'ом.
Узнаешь автора этих строк ? Так вот, это утверждение ложно для системы НТФС(и рейзер4) и истинно для фат32. Так понятнее ?
Здравствуйте, Cyberax, Вы писали:
C>Laptop-mode позволяет ВООБЩЕ выключить диск (его двигатель физически C>останавливается) и накапливать изменения в памяти, а потом сбрасывать C>одним куском.
Запись все равно будет, когда приложениям понадобится доп. память. В чем смысл этого ?
Plutonia Experiment wrote: > C>Laptop-mode позволяет ВООБЩЕ выключить диск (его двигатель физически > C>останавливается) и накапливать изменения в памяти, а потом сбрасывать > C>одним куском. > Запись все равно будет, когда приложениям понадобится доп. память. В чем > смысл этого ?
Вот если понадобится — тогда и запишется. Например, на 1Гб памяти
с CompressedCache патчем компиляция ядра Линукса проходит без единого
касания диска.
Plutonia Experiment wrote: > C>Ничего я не перепутал. Почитай лучше про алгоритм "танцующих деревьев" в > C>Reiser4. > при сканировании > include-файлов они ищутся по именам, что немного медленнее перечисления > findfirst/findnext'ом.
Для КАЖДОГО файла нужно сделать поиск по имени — получаем время
N*log(N), где N — число файлов.
В случае с findfirst/findnext нужно просто один раз перебрать все файлы,
что дает время N. Это и имелось в виду.
> C>Мне просто лень было делать более точные замеры. Я уже как-то сюда писал > C>мини-бенчмарк: http://rsdn.ru/Forum/?mid=1710544
Здравствуйте, Cyberax, Вы писали:
C>Вот если понадобится — тогда и запишется. Например, на 1Гб памяти C>с CompressedCache патчем компиляция ядра Линукса проходит без единого C>касания диска.
А для чего это ? что бы на форум сюда прийти и сказать об этом ?
Проекты, с которыми я работаю, создают временных файлов и всякой бряни от гигабайта и до трех. Не пойму, чем это режим мне лично поможет.
Здравствуйте, Cyberax, Вы писали:
C>Plutonia Experiment wrote: >> C>Ничего я не перепутал. Почитай лучше про алгоритм "танцующих деревьев" в >> C>Reiser4. >> при сканировании >> include-файлов они ищутся по именам, что немного медленнее перечисления >> findfirst/findnext'ом. C>Для КАЖДОГО файла нужно сделать поиск по имени — получаем время C>N*log(N), где N — число файлов.
C>В случае с findfirst/findnext нужно просто один раз перебрать все файлы, C>что дает время N. Это и имелось в виду.
Вобщем разъясни подробно, что ты имел ввиду когда говорил следующее
"при сканировании include-файлов они ищутся по именам, что немного медленнее перечисления findfirst/findnext'ом"
Plutonia Experiment wrote: > C>Вот *если* понадобится — тогда и запишется. Например, на 1Гб памяти > C>с CompressedCache патчем компиляция ядра Линукса проходит без единого > C>касания диска. > А для чего это ? что бы на форум сюда прийти и сказать об этом ? > Проекты, с которыми я работаю, создают временных файлов и всякой бряни > от гигабайта и до трех. Не пойму, чем это режим мне лично поможет.
"А для чего это ? что бы на форум сюда прийти и сказать об этом ?" (c) ты.
Для меня этот режим очень полезен, например. Так у меня не создаются
гигабайты временных файлов. Для многих других тоже может быть полезно.
Plutonia Experiment wrote: > C>В случае с findfirst/findnext нужно просто один раз перебрать все файлы, > C>что дает время N. Это и имелось в виду. > Вобщем разъясни подробно, что ты имел ввиду когда говорил следующее > "при сканировании include-файлов они ищутся по именам, что немного > медленнее перечисления findfirst/findnext'ом"
Сравнивалось однократное линейное сканирование каталога и многократный поиск в нем по имени.
Здравствуйте, Cyberax, Вы писали:
>> C>Мне просто лень было делать более точные замеры. Я уже как-то сюда писал >> C>мини-бенчмарк: http://rsdn.ru/Forum/?mid=1710544
>> Это не бенч. Это подгон под нужные результаты. C>Хочешь сказать, что цифры неправильные? Ну давай еще потестим.
Я хочу сказать, что сначала были цифры, а потом появился тест.
Такой тест, как компиляция, ничего не показывает. А именно ее ты пытался эмулировать.
Здесь узкое место не файловая система, а процессор.
Ну быстрее тут рейзер4 и что с того ?
Теперь по тесту.
Во первых, сравнивается только в одинаковых условиях. у тебя этого нет.
Во вторых, тест не полный — нужны тесты с различными размерами файлов — это очень важно.
Так вот, уважаемый, обе файловые системы заточены под ОС, а не абстрактые реализации неких хороших идей.
В силу особенностей линукса файловое пространство имеет одни особенности, НТ-ХП — другим способом (количество файлов, размеры файлов, особенности работы с файлами и тд и тд).
И файловые системы сделаны так, что бы в этих случаяъ и давать максимальную производительность.
С учетом того, что рейзер4 появилась на 10 лет позже НТФС, очевидно, что в рейзер4 учли опыт и ошибки НТФС. Следовательно можно ожидать что рейзер4 будет пошустрее. Но не в разы, как ты показал.
Теперь один вопрос — рейзер4 уже стал стабильной или все еще падает ?
А то журналирование есть, а данные теряются
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Теперь один вопрос — рейзер4 уже стал стабильной или все еще падает ? PE>А то журналирование есть, а данные теряются
Когда я на своей текущей работе спросил, а почему везде стоит ext3 ведь народ пишет что reiser4 быстрее... мне ответели:
reiser4 перманентно не стабилен.
Все.
Кроче reiser4 может выполнять какието операции хоть в 1000 раз быстрее но если она дает не верные результаты то она не работает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > Когда я на своей текущей работе спросил, а почему везде стоит ext3 ведь > народ пишет что reiser4 быстрее... мне ответели: > reiser4 перманентно не стабилен.
А я у сантехника спросил об окнах — он мне сказал, что лучше ставить
пластиковые. Сейчас вот думаю, как их заказать у Microsoft.
> Все. > Кроче reiser4 может выполнять какието операции хоть в 1000 раз быстрее > но если она дает не верные результаты то она не работает.
У меня на ноуте работает уже очень долгое время без проблем. На двух
корпоративных серверах — тоже без нареканий.
Reiser4 — пока в нестабильной ветке Линукса (-mm ядро), скоро собираются
мигрировать в mainline.
), обратное — уже не так легко (минимум два варианта: polling или callback), плюс обязательная дополнительная загрузка канала связи. В случае callback (для CORBA) ещё нужно вставлять в клиенскую часть сугубо серверные приблуды итэдэ итэпэ.
В нем перебор делается быстрее чем поиск по имени.
