При бесконечной производительности должно быть пофиг на эффективность.

Способность выполнять неограниченное количество операций за единицу времени

И что увеличение мощности железа не помогает?

Не противоречит. При бесконечной не лагает.
При увеличении лаги уменьшаются и пропадают не позже чем при бесконечной производительности.

Добавлено спустя 2 минуты 40 секунд:

Мне пофиг на задействование ресурсов проца.
Мне пофиг на то, насколько загружен проц.
Мне важно лагает или нет.
Если проц супер мощный, но софт не может его нагрузить, то мне не нужен такой проц.

Играть можно... но в некоторых случаях лагает так, что уже не хочется.

все игры когда-то были новыми

да, при бесконечной производительности пофиг на эффективность, там любой быдло код летать будет, но где её взять? возьми дум 3 и последний дум, сравни их по производительности, а юзать некродвижки в наше время нонсенс

Кстати, бенчмарк в последнем думе на вулкане и опенГЛе даёт крайне интересный результат


Процессоры перестают боттлнечить видеокарты

что за бред? есть проц, его мощность утилизирует ПО, а не как наоборот

К сожалению я не могу выбрать какой движок юзать. Я могу выбрать только проц.

Добавлено спустя 55 секунд:

а я что написал?

AnatoliyBelkin

Такого не бывает.



Нет. А как тебе поможет увеличение мощности железа, если затык происходит не на уровне железа, а на уровне программной-аппаратной среды?



Не лагает - это отсутствие лагов
Не уменьшает лагов - это присутствие лагов.

Эти два предложения друг другу противоречат.



При увеличении чего? Бесконечной производительности? Как можно увеличить бесконечность, если она и так бесконечная?

И как могут пропадать лаги там, где они не зависят от мощности железа?



Забавная формулировка. "Если у меня много здоровья, но мне некуда его применить, то мне не нужно такое здоровье".

прочитай внимательно

если софт не может нагрузить, то мне не нужен такой супер мощный проц.

А что, Zeppelin нельзя было бы использовать в двух и четырехкристальных конфигурациях, если бы внутри Zeppelin было не два CCX а один? Носителем базовой архитектуры в любом случае предполагался именно кристалл Zeppelin, зачем было его делать двухблочным?
Вот эта двухблочная структура Zeppelin, она и не объяснима с точки зрения стремлений сделать лучше и быстрее. Но объяснима с точки зрения того что не шмогли и сделали то, что получилось.
Если изучить матчасть ссылку на которую я приводил https://fuse.wikichip.org/news/1064/iss ... packaging/
То тоже станет ясно что IFIS и IFOP используют разные функциональные блоки.

k2viper ну наверно выпуск 4 ядернего проц моветон?

А кстати, как развитие многопоточности АМД простимулирует разработчиков лучше оптимизировать код?
Я вот вижу эту ситуацию совершенно иначе. Да, с одной стороны в распоряжении разработчика появится больше потоков и свободных процессорных ресурсов, но ключевая мысль которая непременно посетит голову разработчика (и группу управления решениями в разработке), будет о том что потоков хватает, продукт на таком количестве ресурсов не лагает, а значит вопросом его оптимизации можно заняться когда-нибудь потом, а лучше никогда. Приоритетность задач по оптимизации выполнения кода непременно снизится с ростом доступных ресурсов.

Добавлено спустя 2 минуты 26 секунд:


Не знаю, может и не моветон, но мы же видим что даже в 4-ядерных R3 АМД оставляет ядра по схеме 2+2.
Цельный полноценный одиночный CCX нигде не используется - кроме APU, где всё равно отдельный кристалл отличный от Zeppelin.
А теперь ещё раз вопрос и хорошенько подумай прежде чем отвечать: почему Zeppelin - базовый носитель архитектуры - двухблочный а не цельный с тем же набором IFIS?

k2viper а что сейчас кто-то занимается оптимизацией? посмотри ААА игры, сплошь малопочное г..., пилят движки моей молодости.

в математических доказательствах используется дофига того, что не бывает. Это не мешает им быть доказательствами.

Затык кончится в N раз быстрее. Если N будет достаточно велико, то затык не увеличится.

уменьшение лагов=уменьшение фреймтайма. После определённого фреймтайми лагов нет. Количество переходит в качество.

Увеличивая не бесконечную производительность, мы стремимся к ситуации с бесконечной производительностью.

Если лаг длится одну секунду, то сколько он будет длится на полностью идентичном железе, но работающем вдвое быстрее?
Какая разница для ПО прошла одна секунда на медленном железе или пол секунды на более быстром, если количество операций одинаковое?


Именно так. Если у меня сильно здоровое сердце, но я помираю из-за убитой печени, то здоровое сердце мне не нужно.

В смысле нафига мне 100500 ядер, если софт умеет использовать только 4?

Добавлено спустя 2 минуты 58 секунд:

распараллелить может оказаться проще, чем повышать производительность(количество операций для определённого действия) кода.

А теперь ещё раз вопрос и хорошенько подумай прежде чем отвечать: ЗАЧЕМ?! 2200г ничем не лучше/хуже в плане игровой производительности, чем 1200, хотя там единый ССХ

Проблема не в кол-ве ССХ, а в самой работе инфинити фабрик. МОжет частота низкая, может ещё что.

Добавлено спустя 2 минуты 34 секунды:
Потому что 4-ядерники это отбраковка от 6-ядерников, которые отбраковка от 8-ядерников

Стимулировать будут не АМД, а сони и майкрософт в приставках от которых и будут стоять процессоры от АМД

Неважно, насколько широкая и просторная дорога (крутой процессор) у тебя впереди, если все стоят в пробке на участке с одной полосой (программа). Именно это демонстрирует Warcraft 3, начиная просаживать фреймрейт при большом лимите, нагружая процессор чуть менее чем никак.



Увеличивая ширину дороги впереди до бесконечности, мы никак не влияем на пробку на участке с одной полосой.



Если лаг длится по причине движка, который не умеет отправлять большое число запросов на процессор, то ничего не изменится.



Какая разница для процессора, на какой частоте ему работать, если программа не способна его загрузить?

Тест интересный, спасибо. Подумаю о продаже топовых процев

А Вы не допускаете мысли, что все так и было задумано?
Может в качестве кирпичика был выбран 4 ядерный CCX блок вполне обдуманно.
С одной стороны есть возможность собирать из кирпичиков более крупные конструкции, Ryzen\Threadripper\EPYC, что мы и видим.
С другой стороны блок достаточно прост, чтобы спроектировать и отладить за ограниченное время. Вот не верю я, что менеджмент не дрючил разработчиков со сроками!
Опять же есть возможность роста не только в ширь, но можно увеличить и размер кирпичика до 6 или 8 ядер!
А "лучше и быстрее" обычно соседствует с "К заданной дате" и "Определенный бюджет".
Вообщем не вижу здесь никакой проблемы!

программа и железо это разные уровни. Они не могут быть друг за другом. Одно работает на другом.

такая, что при большей частоте он быстрее выполнит хоть какие-то операции(пусть и не нагружающие его на 100%), и быстрее получит следующие.

есть софт который использует более 4 ядер, а если программист не хочет использовать больше 4 ядер, то и возникают лаги и прочие причины быдлокода

и много нарастили частоты с сандика по каби? сколько реальный прирост составил? быстрей получит следующие лаги...
советую почитать как исполняется игра на процессоре, тогда многие вопросы отпадут

Они не работают друг на друге, они работают друг с другом. Программа отправляет задачу процессору, процессор ее выполняет и возвращает ответ. А между ними еще всякие прослойки, вроде API.



Он не получит ничего быстрее, потому что это не зависит от него.

https://forums.tripwireinteractive.com/ ... -on-the-pc