Здравствуйте, Morpheus_, Вы писали:
M_>и сколько же времени тратится на переключение?
Если по одному рабочему потоку на процессор, то вообще не тратится
M_>А сколько уйдет на проектирование машины состояний?
А зачем её проектировать вручную?
M_>Вы серьезно думаете что код использующий машину состояний легко читать и модифицировать, а следовательно и легко сделать эффективным?
Да, реализация ввода-вывода в виде конечного автомата не только более эффективна в плане производитености, но и в конечном итоге легче поддерживается. Говорю по собственному опыту.
Здравствуйте, adontz, Вы писали:
M_>>и сколько же времени тратится на переключение?
A>Если по одному рабочему потоку на процессор, то вообще не тратится
Чтото я еще не видел Windows работающий с одним потоком...
M_>>А сколько уйдет на проектирование машины состояний?
A>А зачем её проектировать вручную?
вопрос в том что если задача достаточно сложная, то разобраться чтобы внести какието изменения тяжело, да и осмыслить всю цепочку выполнения тоже...
M_>>Вы серьезно думаете что код использующий машину состояний легко читать и модифицировать, а следовательно и легко сделать эффективным?
A>Да, реализация ввода-вывода в виде конечного автомата не только более эффективна в плане производитености, но и в конечном итоге легче поддерживается. Говорю по собственному опыту.
я видел другой сценарий, когда нужно было внести изменения появлялись костыли, в конце концов все было так запущено что сама мысль о том что нужно разобраться что там происходит вызывала дикий ужас
Здравствуйте, Morpheus_, Вы писали:
A>>А зачем её проектировать вручную? M_>вопрос в том что если задача достаточно сложная, то разобраться чтобы внести какието изменения тяжело, да и осмыслить всю цепочку выполнения тоже...
Вообще-то она неплохо решается в полуавтоматическом режиме. Существует куча программ-генераторов конечных автоматов по некоторому описанию.
M_>я видел другой сценарий, когда нужно было внести изменения появлялись костыли, в конце концов все было так запущено что сама мысль о том что нужно разобраться что там происходит вызывала дикий ужас
Здравствуйте, Morpheus_, Вы писали:
A>>Ну насчёт серьёзного ты загнул. Всего-то конечный автомат написать. M_>ну да, а потом чтоб какуюто функцию добавить сидеть разбираться в нем и писать его заново
Здравствуйте, adontz, Вы писали:
A>>>А зачем её проектировать вручную? M_>>вопрос в том что если задача достаточно сложная, то разобраться чтобы внести какието изменения тяжело, да и осмыслить всю цепочку выполнения тоже...
A>Вообще-то она неплохо решается в полуавтоматическом режиме. Существует куча программ-генераторов конечных автоматов по некоторому описанию.
видел, пользовал, редактировать то диаграмму состояний всеравно надо, да и код генерится не достаточно эффективный
Здравствуйте, Morpheus_, Вы писали:
M_>видел, пользовал, редактировать то диаграмму состояний всеравно надо, да и код генерится не достаточно эффективный
Здравствуйте, mrozov, Вы писали:
M>P.S. Я-то многопоточные серверные приложения пишу регулярно, работа у меня такая. Рихтер у меня любимый писатель после Чехова. Темой в целом владею.
Кстати по поводу Рихтера, полностью согласен с Олег Михайлик, Рихтер копает как ускорить переключение задач и т.п., хотя на самом деле это не является проблемой, а люди начитавшись Рихтера считают что переключение задач это и есть проблема многопоточности На деле это не так, переключение задач занимает не так уж и много времени чтобы уделять этому такое пристальное внимание
Здравствуйте, adontz, Вы писали:
M_>>видел, пользовал, редактировать то диаграмму состояний всеравно надо, да и код генерится не достаточно эффективный
A>Да ну, чего это switch вдруг стал не эффективным?
если уж об этом говорить, тогда не switch, а большое кол-во call и других джампов, которые действительно пожирают время и я думаю не меньше чем переключение потоков
и код читается тяжело
Здравствуйте, Morpheus_, Вы писали:
M_>Кстати по поводу Рихтера, полностью согласен с Олег Михайлик, Рихтер копает как ускорить переключение задач и т.п., хотя на самом деле это не является проблемой, а люди начитавшись Рихтера считают что переключение задач это и есть проблема многопоточности На деле это не так, переключение задач занимает не так уж и много времени чтобы уделять этому такое пристальное внимание
Не надо сводить переключение потоков к 300 тикам загрузки TSS. Разные потоки обращаются к разным данным, а это перезагрузка кучи разных кешей, от L2 до дискового. Так что вообще говоря переключение между что-то делающими потоками это довольно дорогая операция.
Здравствуйте, Morpheus_, Вы писали:
M_>если уж об этом говорить, тогда не switch, а большое кол-во call и других джампов, которые действительно пожирают время и я думаю не меньше чем переключение потоков M_>и код читается тяжело
Ну-ну. Ты ещё скажи что надо от виртуальных методов отказыватся. Пашутил, панимаешь. CALL/JMP это пара тиков, загрука TSS около 300. Ну и я рядом уже ответил, что этими тремья стами дело не ограничивается.
Здравствуйте, adontz, Вы писали:
M_>>если уж об этом говорить, тогда не switch, а большое кол-во call и других джампов, которые действительно пожирают время и я думаю не меньше чем переключение потоков M_>>и код читается тяжело
A>Ну-ну. Ты ещё скажи что надо от виртуальных методов отказыватся. Пашутил, панимаешь. CALL/JMP это пара тиков, загрука TSS около 300. Ну и я рядом уже ответил, что этими тремья стами дело не ограничивается.
ты забыл о том что call/jmp потенциально может сбить кэш что заставит процессор остановиться до поступления данных с кодом (на который произведен jmp) из памяти в кэш, а это очень не быстрая операция
Здравствуйте, adontz, Вы писали:
M_>>Кстати по поводу Рихтера, полностью согласен с Олег Михайлик, Рихтер копает как ускорить переключение задач и т.п., хотя на самом деле это не является проблемой, а люди начитавшись Рихтера считают что переключение задач это и есть проблема многопоточности На деле это не так, переключение задач занимает не так уж и много времени чтобы уделять этому такое пристальное внимание
A>Не надо сводить переключение потоков к 300 тикам загрузки TSS. Разные потоки обращаются к разным данным, а это перезагрузка кучи разных кешей, от L2 до дискового. Так что вообще говоря переключение между что-то делающими потоками это довольно дорогая операция.
Windows изначально не однопоточная система, так что переключения задач будут происходить в любом случае, хотите вы этого или нет...
M_>ты забыл о том что call/jmp потенциально может сбить кэш что заставит процессор остановиться до поступления данных с кодом (на который произведен jmp) из памяти в кэш, а это очень не быстрая операция
процессоры, не смотря на наличие хитрых блоков предсказания, не любят call/jmp и мстят за их использование низкой производительностью
Здравствуйте, Morpheus_, Вы писали:
M_>>ты забыл о том что call/jmp потенциально может сбить кэш что заставит процессор остановиться до поступления данных с кодом (на который произведен jmp) из памяти в кэш, а это очень не быстрая операция
M_>процессоры, не смотря на наличие хитрых блоков предсказания, не любят call/jmp и мстят за их использование низкой производительностью
вобщем приходим к выводу что серверы лучше всего делать без Windows, без многозадачных ядер, с исполнением кода в одном потоке и линейным кодом без всяких джампов, функций, подпрограмм и т.п.
а вообще спор глупый, я согласен что чем меньше потоков в сервере тем лучше, но на практике получается что чем меньше потоков тем более зубодробильным получается код и больше времени уходит на его разработку. Пожалуй для сферического сервера с одним потоком код этот наверняка вызовет рак мозка
M_>не убедительный вывод, например фреймворк 1.1 не поддерживает критическую финализацию, что в частности может грозить неприятностями при DoS атаках...
Просветите что есть критическая финализация и чем эта функциональность помогает при DoS атаках..., если не секрет в двух словах будет достаточно ?
Здравствуйте, Jericho113, Вы писали:
J>Здравствуйте, Morpheus_, Вы писали:
M_>>не убедительный вывод, например фреймворк 1.1 не поддерживает критическую финализацию, что в частности может грозить неприятностями при DoS атаках...
J>Просветите что есть критическая финализация и чем эта функциональность помогает при DoS атаках..., если не секрет в двух словах будет достаточно ?
критическая финализация гарантирует вызов вызов деструктора для классов хранящих unmanaged хэндлы, при большой нагрузке на систему без критической финализации будет происходить утечка хэндлов, что достаточно быстро приведет к падению приложения или всей Win
Hello, "Morpheus_" > > критическая финализация гарантирует вызов вызов деструктора для классов > хранящих unmanaged хэндлы, при большой нагрузке на систему без критической > финализации будет происходить утечка хэндлов, что достаточно быстро > приведет к падению приложения или всей Win
А можно по подробнее про критическую финализацию?
В MSDN написано следующее:
In classes derived from the CriticalFinalizerObject class, the common
language runtime (CLR) guarantees that all critical finalization code will
be given the opportunity to execute, provided the finalizer follows the
rules for a CER, even in situations where the CLR forcibly unloads an
application domain or aborts a thread. If a finalizer violates the rules
for a CER, it might not successfully execute. In addition, the CLR
establishes a weak ordering among normal and critical finalizers: for
objects reclaimed by garbage collection at the same time, all the
noncritical finalizers are called before any of the critical finalizers.
Первый выделенный фрагмент говорит о том, что критический финализатор будет
выполнен даже в случае "не нормального" завершения приложения. С другой
стороны, это никак не соотносится с ситуацией, если приложение не должно
падать "в принципе". Второй выделенный фрагмент говорит о том, что
"критические финализаторы" будут отрабатывать после "не критических" т.е.
фактически, в случае DDoS атаки критические финализаторы будут последними в
очереди "на очистку". Что не соотносится с утверждением, что критический
финализатор это панацея от "утечки хендлов" в случае DDoS атаки. Более того,
они ей только способствуют.
Posted via RSDN NNTP Server 2.0
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
TK>objects reclaimed by garbage collection at the same time, all the
TK>noncritical finalizers are called before any of the critical finalizers.
TK>Первый выделенный фрагмент говорит о том, что критический финализатор будет TK>выполнен даже в случае "не нормального" завершения приложения. С другой TK>стороны, это никак не соотносится с ситуацией, если приложение не должно TK>падать "в принципе". Второй выделенный фрагмент говорит о том, что TK>"критические финализаторы" будут отрабатывать после "не критических" т.е. TK>фактически, в случае DDoS атаки критические финализаторы будут последними в TK>очереди "на очистку". Что не соотносится с утверждением, что критический TK>финализатор это панацея от "утечки хендлов" в случае DDoS атаки. Более того, TK>они ей только способствуют.
хм... предположу что благодаря тому что CLR не гарантирует вызов обычных финализаторов, CLR может со спокойной совестью забить на обычные и начать вызывать критические...
На практике не пробовал, исключительно мое предположение
Здравствуйте, Morpheus_, Вы писали:
M_>хм... предположу что благодаря тому что CLR не гарантирует вызов обычных финализаторов, CLR может со спокойной совестью забить на обычные и начать вызывать критические... M_>На практике не пробовал, исключительно мое предположение
На обычные финализаторы CLR может забить только в случае завершения работы приложения.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
