И правда, 8 потоков не задействуется. Всего лишь 7
Почему-то.
#77

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




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

Согласен. Больше 4 ядер не юзает. Но больше 4 потоков- юзает

на "встройке" конечно же, в профиле прописана

wertmur Да уже не важно, мне лень гуглить за кого-то, дабы найти прямо железобетонные пруфы, да и есть ли смысл, когда люди верят консольной команде и только ей одной, вера штука такая...

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

Почему типичный юзер всегда считает, что возможно распараллеливать что угодно до бесконечности, был бы лишь скил и желание в виде оплаты труда и адекватных сроков? А если прилага не задействует 8 потоков на полную - программисты говно.
Фактически, то, что видно сейчас, это в первую очередь вынесение разных процессов в разные потоки - рендер, AI, физика.. Самих по себе этих изолированных процессов набрать сколько угодно не получится, к тому же всегда выйдет ситуация, что один, быстро выполнившийся, будет ждать все остальные (результаты то в итоге надо увязать в одной сцене), в итоге вроде как все ядра задействованы, а толку нет (проявление сего отлично видны на всяких там диаграммах загруженности, когда половина ядер вроде и задействованы, но болтаются на уровне 20% загрузки). Одного лишь выхода приставок с возможностью прокручивать больше потоков недостаточно, чтобы случилась магия.
Даже в сраном вебе можно распараллелить отрисовку фронтенда и выборку из базы, выиграв немного в скорости, но отображение этой самой выборки все равно упрется в скорость одного изолированного потока с эти самым запросом в базу, распараллелить который невозможно в принципе.
В UE конечно отлично придумали со стримингом текстур, которые параллельно подтягиваются и рисуются, когда это возможно, а не когда нужно. Но наблюдание обтягивания сцены текстурками обычно не самое приятное зрелище и какую-нибудь физику уже аналогично отвязать не получится.

А если эти 2-3 игры основные?

Поделись и с нами !?
О великий внук Ванги !

Тогда ваш выбор fx-8xxx

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



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




Браво!

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

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

Я какб тоже конкретно об играх говорил. Все же попробуйте В студию скрин с каким-нибудь примером практически полной загрузки 12 потоков в любой игре. Ну или хотя бы 8.

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

dragonheart
вам нужно больше практики... при чем тут серверная сторона?

примеры - БФ3/3, Кризис 3. но текущие методы и алгоритмы еще не на столько совершенны, а программисты в большинстве своем такие как вы, то есть любят работать по набитому 10 лет назад шаблону, поэтому о массовом внедрении и оптимизации говорить не приходится - надо учить уже в ВУЗе мыслить по-другому. а если учесть, что многих современных программистов готовят в Китае и Индии за 3 недели, то тут вообще атас.

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

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

i5 2500K @4.8Ghz спокойно делает i5 4670K @4.3Ghz)

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

Только на практике никто это использовать не будет. Надо тестить реальные ситуации, а не "640х480 noAA"

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

Дык статья без намёка на практику. Я сам всеми руками за, но тут специально подобраны условия. Всё равно что сравнивать спортивную машину на треке и в Питере. Трек - аналогия с данной статьёй и " идеальными " условиями, а общественные дороги в центре Питера - это затык в видяху и частичная загрузка проца.
P.S Вот этих самых "трековиков" стоящих в сплошных почти сплошных питерских пробках я дёргаю на своём двухколёсном коне как детсадовских. Потому что все условия для скоростного и манёвренного велика.

Это не так.

aisuite Ну что же ты пропал !?

Это один я такой, или диаграммы километровой длины совершенно нечитаемы? Переварить это на глаз - невозможно, накидали всё в кучу. И это во многих статьях так.