Называли уже, те же виртуалки, веб-сервера, сетевые устройства - там 100500 слабых ядер уровня калькулятора будут много быстрее любого одного ядра. Далее, очевидная истина - 8 ядер на 2ггц банально меньше потребляют, чем 4 на 4ггц и уж тем более чем 2 на 8ггц.zoog: Так назовите такую задачу...
ну это уже отдельная историяbotva:ага, или i3-10100f. т.е. ло-енд экономически нецелесообразен.
имхо, в таком виде (2С/2Т) эти целероны вообще нужно было упразднить в 10-ой серии, т.к. *овно 
таки даzoog: Иногда кажется, что это делается для сугубых бухгалтеров, которым 5% цены достойная альтернатива 50% функционала.
Примеры тестов, где 2 ядра давали бы -60% по сравнению с 4мя. На многих потоках 20 PR-1000 ядер будут быстрее 1го с PR-10000, это очевидно, ведь 20*1000=20000>10000.lokkiuni:Называли уже, те же виртуалки, веб-сервера, сетевые устройства - там 100500 слабых ядер уровня калькулятора будут много быстрее любого одного ядра.zoog: Так назовите такую задачу...
Потребление здесь причём? Чай не экстремальный разгон, а бытовуха.Далее, очевидная истина - 8 ядер на 2ггц банально меньше потребляют, чем 4 на 4ггц и уж тем более чем 2 на 8ггц.
Нет, не читал, расскажите.Про то, что прирост от 2го ядра был местами больше 100% думаю рассказывать не надо - вы ж давно в интернете и читали причину
Привёл выше задачи, тесты потрудитесь сами поискать.zoog: Примеры тестов, где 2 ядра давали бы -60% по сравнению с 4мя.
Любая задача требующая своевременного ответа.zoog:Так назовите такую задачу...
Добавлю так же:lokkiuni:Прирост больше 100% - фоновые процессы причина как минимум
Производительность уменьшилась строго пропорционально, а вот способ её оценки некорректен, это всё равно, что считать/сравнивать не ФПС, а (ФПС-60) - так можно получить любой коэффициент, вплоть до бесконечности или отрицательного значения.dead_rat: Берем условный сервер, пусть у него 4 ядра и каждое может обрабатывать 10 запросов в секунду. Для удобства счета.
Итого при нагрузке 40 запросов в секунду у нас равновесие, ни один запрос не займет больше секунды.
Теперь оставляем 2 ядра и ту же нагрузку. Какое будет среднее время ожидания?
Практический пример для не сварщшиков можно?Прирост более 100% - ожидание ресурсов, локов, долгие задачи в одном пуле потоков, переключение контекста(когда он не помещается в кеш)...
Производительность пропорционально, а вот произведенный результат - непропорционально.zoog:Производительность уменьшилась строго пропорционально, а вот способ её оценки некорректен, это всё равно, что считать/сравнивать не ФПС, а (ФПС-60) - так можно получить любой коэффициент, вплоть до бесконечности или отрицательного значения.
Я привел выше, вы ниасилили прикинуть результат.zoog:Практический пример для не сварщшиков можно?
Аааа, ну-ну.zoog:Или движок игры работает с потоком данных, требующих обязательной обработки? Вродн нет, если производительность снижается - просто увеличивается время кадра, никакие запросы не дропаются.
Не могу согласиться. Если человек ожидает минФПС 100, то условные ртх3060 и 3080 для него будут отличаться как 0 и 1, хотя реальная разница лишь 2 раза.Пример АБСОЛЮТНО реалистичный и правильный.
Пример реальной задачи. Я что, должен был найти "долгие задачи в одном пуле потоков"?Я привел выше, вы ниасилили прикинуть результат.
Передёргиваете.Берем сетевую игру, мы не успеваем просчитать кадр, а между кадрами получаем сигнал, что нас пристрелили.
Web сервер - абсолютно реально.zoog:Пример реальной задачи.
Где я передергиваю?zoog:Передёргиваете.
Но некорректно)Web сервер - абсолютно реально.
Как при этом замена на х2 ядер с х0,5 частотой сможет ускорить ожидание?В игре так же реально - ожидание ответа от другого потока.
Берёте отклик сетевой задачи и сравниваете с ФПС сингла.Где я передергиваю?
Это никак не связано с производительностью рендеринга да и порядки времени - даже не рядом, 1/50с и 1/5000000000с.Что мы делаем? Продолжаем рендер или выбрасываем и рендерим новый?
Ресурсов с диска? Опять же, код исполняется в масштабе нс, а ЖД - мс.Игра с открытым миром, в котором подгрузкой данных занимаются несколько потоков.
Допустим, 4 ядра грузят ресурсы за 10мс (хотя делать это в момент перед самым выводом кадра, когда "нужно уже вчера" - это равшининг и джамшутинг, и/о должен завершаться заранее и лежать в кэше (дисковом, в ОЗУ)), тогда 2 ядра грузят за 20мс в худшем случае (т.к. многопотоковое чтение ломает скорость в десятки раз) и время кадра ухудшится в 1,5 раза примерно. Где тут мучительный выбор и фризы? Кстати, это реальный пример и кто-то читает с диска в несколько потоков? Совсем ********...Движку надо решить, если ядер не хватает и подгрузка не успевает, нам останавливать игру на фриз в пол секунды или рендерить что успеваем(создавая баги как киберпанке?)
Мы про теорию в вашей голове или про практику? Ответ очевиден.zoog:Где тут мучительный выбор и фризы?
Вы не шутите? Сервер - должен гарантированно реагировать за определённое время и в идеале не допускать выпадания пакетов - это уже нештатный режим и считай фейл. Игра же каждый кадр обрабатывает данные (ИИ, мир, вершины, раскраска) и время кадра может быть любым в нашем примере - важна лишь пропорциональность к-ву ядер.На любой пример отвечать Не корректно.
Убеждать вас в чем-то не интересно.
Нет, я просто не допонял логику Вашего примера. Поясните, плз.Мы про теорию в вашей голове или про практику? Ответ очевиден.
Вы рассуждаете логично, но слишком упрощенно. Вы не представляете сложность системы обработки реального времени(а игра именно такая система и есть)zoog:Нет, я просто не допонял логику Вашего примера. Поясните, плз.
Но у неё нет жёстких рамок на время ожидания, не так ли?Игра использующая несколько ядер это такая же distributed system как и сервер и она точно так же должна не терять данные, отвечать во время и так далее.
С механикой сервера всё ясно (есть внешняя нагрузка, еоторую необходимо обработать или всё пропало), а что в игре (или любой другой задаче) может дать такой же эффект?Как сервер при нехватке мощности начинает замедляться непропорционально, точно так же и игра, может давать непропорциональный рост времени кадра.
Вы не гиперболизируете, реально реального времени, под не RT-OS? Или симуляция всё же?системы обработки реального времени(а игра именно такая система и есть)
Ну, на всё можно ответить "врач/программист/ВВП лучше знает, сказал в морг - значит, в морг"...Вы не представляете сложность
1. Время, ведь вы же хотите связать скорость игры с реальным временем. Чтобы в таймер в игре совпадал с реальным.zoog:С механикой сервера всё ясно (есть внешняя нагрузка, еоторую необходимо обработать или всё пропало), а что в игре (или любой другой задаче) может дать такой же эффект?
Так же можно сказать, что чтобы понимать проблемы распределенных систем надо хотябы просмотреть вводные лекции по теме.zoog:Ну, на всё можно ответить "врач/программист/ВВП лучше знает, сказал в морг - значит, в морг"...
Вы имеете в виду жёсткие затупы, когда время в игре реально замедляется? Я плохо понимаю, как на это влияет наличие лишних ядер, по идее внутреннее синхро работает в каком-то мастер-треде с более высоким приоритетом, на который не влияют всякие подгрузки и инпут юзера.1. Время, ведь вы же хотите связать скорость игры с реальным временем. Чтобы в таймер в игре совпадал с реальным.
Для клавиатуры уже не хватает 2х ядер?%)2. Ввод от игрока
Что игровые события?3. Игровые события
Это вообще не связано с производительностью, кривейший код (вернее, упрощённый под некоторый набор железа) просто.Вы же хотите чтобы скорость игры была постоянной, а не при 30 фпс все двигалось медленно, а при 300 фпс в 10 раз быстрее - как в играх 90х когда игры писались под фиксированный фпс и при незватке мощности марио прыгал вдвое медленней
Я как-то читал курс "основы ОС", понял не столь много, помню ещё меньше( Если Вы уверены, что это нельзя объяснить на пальцах - это ещё не значит, что действительно нельзя) уметь доносить - отдельное искусство.Так же можно сказать, что чтобы понимать проблемы распределенных систем надо хотябы просмотреть вводные лекции по теме.
Сам я тех лид, отвечаю за 4 команды, работаем в лавке принадлежащей eBay на их инфраструктуре. Больше финтех, distributed systems и иже с ними.zoog:Сами подобным занимаетесь, реально наблюдали то, что доказываете?
Я стараюсь вникать, но многие Ваши слова на веру не могу принимать, пардон;)во-вторых собеседник не читает а лишь отмахивается, в третьих собеседник тоже должен иметь понимание процессов.
Не подумал.. а что там такого сложного? За 1ю секунду не обработается 20 запросов, за 2ю - ещё столько же, зависнет ли он, отбросит первые 20 или вторые - это уже зависит от его организации, а не от производительности.Когда я привел простейший пример с веб сервером вы над ним хоть 30 секунд подумали?
