АццкоМото wrote:Абсолютно все равно это и для сервера. Чтобы наш цикл с экономией в 7 микросекунд наэкономил аж 7 секунд процессорного времени, он должен выполниться миллион раз. В предположении о выполнении на сервере мы можем предположить, что это миллион запросов. Ну ОК, сократим в 10 раз. Пусть на один запрос цикл выполняется 10 раз. Итак, 100 тыс запросов. Ну и сколько раз будет работать GC? Ваш пойнт был изначально "ой, это просто цикл, мы память там не выделяем, GC работать не будет". Теперь появляется "сервер под загрузкой". Я все еще должен верить, что GC не сожрет на порядки больше времени?
в моем гейте, который соединяет торговый сервер с ФОРТСом, правда написанном на C# (поток данных на ФОРТС сильно меньше, чем на ММВБ + это клиентский торговый сервер (без роботов)) на полной загрузке GC вызывается 1 раз в примерно 2.5-3 минуты (структуры позволяющие все добро держать на стеке рулят + все что можно преаллоцировано), и это сборка 0 поколения, сборка 2 поколения - где-то раз в 10-15 минут
даже если бы он вызывался чаще, скажем 10 раз в секунду (что дофига великого), т.е. временное расстояние между двумя вызовами GC равно 0.1 секунды, на процессоре Core i-7 3ГГц в идеальном состоянии - это 3*10^(9-1 /*количество тактов в секунде разделили на 10*/) * 4 (в идеальных условиях 4 команды за цикл) т.е. 1.2^9 операций можно совершить за время между сборками мусора
- для процессора - это вечность
путем ухищрений можно добиться примерно 80-85% пропуской способности памяти
при произвольном доступе - дай бог 20% (причем это в лучшем случае), т.е. в 4 раза
предположим, что сборка длится 1 миллисекунду
вот цитата для C#
Microsoft’s performance tests show that it takes less than 1 millisecond to perform a
garbage collection of generation 0. Microsoft’s goal is to have garbage collections take no more
time than an ordinary page fault.
т.е. 10 раз по миллисекунде = 10 миллисекунд и 990 миллисекунд нормальной работы
возьмем для gc 100 миллисекунд (нужно же время на переключение контекста (700-1000 тактов) и т.д. и т.п.)
получается что 9/10 полезной работы при которой производительность будет в 4 раза больше (тут еще нужно учесть тот факт, что на машине обычно 4 камня, а gc собирается 1им (остальные потоки просто тормозятся), так что кеш остальных потоков не "попортится")
так что далеко не все равно для сервера
и последнее: все равно сколько занимают "вынужденные остановки" - полезной работы от этого не уменьшается и есть разница сделать ее за X или за 4X, даже иногда прерываясь на GC
АццкоМото wrote:Какой нафиг туман? Все перечисленное прерывает процесс на неопределенное время. Точка.
А если занудствовать, то прервать может - сюрпрайз - только прерывание. Hence, the name. И какое время это прерывание займет, никто гарантировать не может
ну да, вы правы, я вам написал во что эти прерывания могут выливаться, отношение работы сервера над "нашей" задачей к общему времени все равно будет стремиться к примерно чуть меньше 100%, приоритеты потокам дать побольше и прибить каждый поток к определенному камню, чтобы не сьежал на другие - вот и все "чудеса"
вы были бы правы в своих расчетах, если бы "что-то другое" прерывало наш поток очень и очень очень очень очень часто и при этом гадило в кеш, но этого не будет по причинам обсуждаемым 10ю страницу
АццкоМото wrote:Вроде бы это не я начал гнуть пальцы в стиле "ой, вот на нормальные позиции и интервью бодрые, но это там, где платят аж 150 тыр и тебя не возьмут"
я про вас вообще ничего не говорил, потому как я вас просто не знаю, хоть и могу составить какой-никакой портрет по вашим постам (кстати сказать неплохой, несмотря на грызню не первый раз, но эт фигня)
наше бурное обсуждение началось с того, что вы посчитали, что вопросы, который задали очередному парню сходившиму на собеседование дурацкими,
а я лишь сказал, что нет не дурацкие, а нормальные вопросы, ну и выразил банальную мысль, что чем больше денег, тем больше и глубже спрашивают (кандидатов то надо отсеивать, да и для задач оно надо)
если поговорить за жизнь, то из 100 кандидатов подойдут 90, а взять нужно максимум 3