Сообщение Re[5]: Вопрос по boost lockfree queue от 26.04.2015 21:51
Изменено 26.04.2015 22:07 antropolog
Здравствуйте, Engler, Вы писали:
A>>я ещё раз повторюсь, представьте что у вас запустился producer и поместил миллион объектов в очередь очень быстро, скажем за 0 секунд,
E>А так не получится. Во-первых, что значит за 0 секунд? Мы же только перед отправкой сообщения получаем timestamp текущий с точностью до наносекунд ( да-да, про погрешность системы знаю, не real time).
пардон, но я уже устал повторять. просто смоделируйте у себя в голове ситуацию, когда consumer стартует на N миллисекунд позже. При этом скорость с которой producer кладёт элементы и consumer достаёт — одинакова, или (я надеялся что вам лучше будет понятно в экстремуме) бесконечно велика (это значит что отработают за 0 секунд).
E>всегда дадут разницу в N наносекунд (хотя бы из за самого вызова ).
да, и это может быть объяснено в разнице между времени старта producer'а и consumer'а. При этом даже если они отрабатывают бесконечно быстро, ваш sum получит гигантские значения.
E>Даже если consumer стартанет раньше, то читать будет нечего. И соответсвенно t2 ( т.е время когда мы получили сообщение ) будет ВСЕГДА больеш t1 (т.е время когда мы записали сообщение).
то что оно всегда больше это очевидно.
попробую аналогией:
Аналогия 1:
100 человек пришло на почту отправить письмо, но почта открылась только через 30 мин. Обслужила 100 человек за 100 секунд ( по секунде на человека ). Для каждого человека разница между его приходом на почту и уходом составляет ~31 минуту ( 30мин + 1 секунда для первого, 30мин + 2 секунды для второго, и т.д., в среднем ~31 минута ). Вы зачем-то взяли это число и умножили на 100, получили какое-то большое число и ужаснулись. Хотя по факту ужасаться нечему, т.к. скорость обслуживания была 1 человек в секунду, что очень быстро.
Аналогия 2:
100 человек пришло на почту отправить письмо, почта открылась сразу. Обслужила 100 человек за 100 секунд ( по секунде на человека ). Для каждого человека разница между его приходом на почту и уходом составляет в среднем 50 секунд ( 1 секунда для первого, 2 секунды для второго, и т.д., в среднем 50 секунд ). Вы зачем-то взяли и просуммировали разницу для каждого человека, получили какое-то большое число ( 1 + 2 + 3 ... + 99 = 100 * 50 = 5000 секунд ) и ужаснулись, хотя по факту очередь была обслужена за 100 секунд и скорость обслуживания была 1 человек в секунду, что очень быстро.
A>>я ещё раз повторюсь, представьте что у вас запустился producer и поместил миллион объектов в очередь очень быстро, скажем за 0 секунд,
E>А так не получится. Во-первых, что значит за 0 секунд? Мы же только перед отправкой сообщения получаем timestamp текущий с точностью до наносекунд ( да-да, про погрешность системы знаю, не real time).
пардон, но я уже устал повторять. просто смоделируйте у себя в голове ситуацию, когда consumer стартует на N миллисекунд позже. При этом скорость с которой producer кладёт элементы и consumer достаёт — одинакова, или (я надеялся что вам лучше будет понятно в экстремуме) бесконечно велика (это значит что отработают за 0 секунд).
E>всегда дадут разницу в N наносекунд (хотя бы из за самого вызова ).
да, и это может быть объяснено в разнице между времени старта producer'а и consumer'а. При этом даже если они отрабатывают бесконечно быстро, ваш sum получит гигантские значения.
E>Даже если consumer стартанет раньше, то читать будет нечего. И соответсвенно t2 ( т.е время когда мы получили сообщение ) будет ВСЕГДА больеш t1 (т.е время когда мы записали сообщение).
то что оно всегда больше это очевидно.
попробую аналогией:
Аналогия 1:
100 человек пришло на почту отправить письмо, но почта открылась только через 30 мин. Обслужила 100 человек за 100 секунд ( по секунде на человека ). Для каждого человека разница между его приходом на почту и уходом составляет ~31 минуту ( 30мин + 1 секунда для первого, 30мин + 2 секунды для второго, и т.д., в среднем ~31 минута ). Вы зачем-то взяли это число и умножили на 100, получили какое-то большое число и ужаснулись. Хотя по факту ужасаться нечему, т.к. скорость обслуживания была 1 человек в секунду, что очень быстро.
Аналогия 2:
100 человек пришло на почту отправить письмо, почта открылась сразу. Обслужила 100 человек за 100 секунд ( по секунде на человека ). Для каждого человека разница между его приходом на почту и уходом составляет в среднем 50 секунд ( 1 секунда для первого, 2 секунды для второго, и т.д., в среднем 50 секунд ). Вы зачем-то взяли и просуммировали разницу для каждого человека, получили какое-то большое число ( 1 + 2 + 3 ... + 99 = 100 * 50 = 5000 секунд ) и ужаснулись, хотя по факту очередь была обслужена за 100 секунд и скорость обслуживания была 1 человек в секунду, что очень быстро.
Re[5]: Вопрос по boost lockfree queue
Здравствуйте, Engler, Вы писали:
A>>я ещё раз повторюсь, представьте что у вас запустился producer и поместил миллион объектов в очередь очень быстро, скажем за 0 секунд,
E>А так не получится. Во-первых, что значит за 0 секунд? Мы же только перед отправкой сообщения получаем timestamp текущий с точностью до наносекунд ( да-да, про погрешность системы знаю, не real time).
пардон, но я уже устал повторять. просто смоделируйте у себя в голове ситуацию, когда consumer стартует на N миллисекунд позже. При этом скорость с которой producer кладёт элементы и consumer достаёт — одинакова, или (я надеялся что вам лучше будет понятно в экстремуме) бесконечно велика (это значит что отработают за 0 секунд).
E>всегда дадут разницу в N наносекунд (хотя бы из за самого вызова ).
да, и это может быть объяснено в разнице между времени старта producer'а и consumer'а. При этом даже если они отрабатывают бесконечно быстро, ваш sum получит гигантские значения.
E>Даже если consumer стартанет раньше, то читать будет нечего. И соответсвенно t2 ( т.е время когда мы получили сообщение ) будет ВСЕГДА больеш t1 (т.е время когда мы записали сообщение).
то что оно всегда больше это очевидно.
попробую аналогией:
Аналогия 1:
100 человек пришло на почту отправить письмо, но почта открылась только через 30 мин. Обслужила 100 человек за 100 секунд ( по секунде на человека ). Для каждого человека разница между его приходом на почту и уходом составляет ~31 минуту ( 30мин + 1 секунда для первого, 30мин + 2 секунды для второго, и т.д., в среднем ~31 минута ). Вы зачем-то взяли это число и умножили на 100, получили какое-то большое число и ужаснулись. Хотя по факту ужасаться нечему, т.к. скорость обслуживания была 1 человек в секунду, что очень быстро.
Аналогия 2:
100 человек пришло на почту отправить письмо, почта открылась сразу. Обслужила 100 человек за 100 секунд ( по секунде на человека ). Для каждого человека разница между его приходом на почту и уходом составляет в среднем 50 секунд ( 1 секунда для первого, 2 секунды для второго, и т.д., в среднем 50 секунд ). Вы зачем-то взяли и просуммировали разницу для каждого человека, получили какое-то большое число ( 1 + 2 + 3 ... + 99 = (1+99) + (2+98) ... = 100 * 50 = 5000 секунд ) и ужаснулись, хотя по факту очередь была обслужена за 100 секунд и скорость обслуживания была 1 человек в секунду, что очень быстро.
A>>я ещё раз повторюсь, представьте что у вас запустился producer и поместил миллион объектов в очередь очень быстро, скажем за 0 секунд,
E>А так не получится. Во-первых, что значит за 0 секунд? Мы же только перед отправкой сообщения получаем timestamp текущий с точностью до наносекунд ( да-да, про погрешность системы знаю, не real time).
пардон, но я уже устал повторять. просто смоделируйте у себя в голове ситуацию, когда consumer стартует на N миллисекунд позже. При этом скорость с которой producer кладёт элементы и consumer достаёт — одинакова, или (я надеялся что вам лучше будет понятно в экстремуме) бесконечно велика (это значит что отработают за 0 секунд).
E>всегда дадут разницу в N наносекунд (хотя бы из за самого вызова ).
да, и это может быть объяснено в разнице между времени старта producer'а и consumer'а. При этом даже если они отрабатывают бесконечно быстро, ваш sum получит гигантские значения.
E>Даже если consumer стартанет раньше, то читать будет нечего. И соответсвенно t2 ( т.е время когда мы получили сообщение ) будет ВСЕГДА больеш t1 (т.е время когда мы записали сообщение).
то что оно всегда больше это очевидно.
попробую аналогией:
Аналогия 1:
100 человек пришло на почту отправить письмо, но почта открылась только через 30 мин. Обслужила 100 человек за 100 секунд ( по секунде на человека ). Для каждого человека разница между его приходом на почту и уходом составляет ~31 минуту ( 30мин + 1 секунда для первого, 30мин + 2 секунды для второго, и т.д., в среднем ~31 минута ). Вы зачем-то взяли это число и умножили на 100, получили какое-то большое число и ужаснулись. Хотя по факту ужасаться нечему, т.к. скорость обслуживания была 1 человек в секунду, что очень быстро.
Аналогия 2:
100 человек пришло на почту отправить письмо, почта открылась сразу. Обслужила 100 человек за 100 секунд ( по секунде на человека ). Для каждого человека разница между его приходом на почту и уходом составляет в среднем 50 секунд ( 1 секунда для первого, 2 секунды для второго, и т.д., в среднем 50 секунд ). Вы зачем-то взяли и просуммировали разницу для каждого человека, получили какое-то большое число ( 1 + 2 + 3 ... + 99 = (1+99) + (2+98) ... = 100 * 50 = 5000 секунд ) и ужаснулись, хотя по факту очередь была обслужена за 100 секунд и скорость обслуживания была 1 человек в секунду, что очень быстро.