AMD FX-8320 (FD8320FRW8KHK)

bilet посмотрите здесь

Если для вас это не авторитетный ресурс, то лично я более авторитетных не знаю.Ссылка тут А приведенный алгоритм Vadim1242 действительно простейший, как 2+2 его не распараллелишь, но ведь вопрос стоял о распараллеливании однопоточного кода вообще. По поводу WinRar автор, который совсем не Феникс , поднял правильную тему. Как получилось ,что проц вдруг стал показывать на 30% худшие результаты , причем программа осталась прежней, ладно если бы была другая версия WinRar, но нет она была той же .

Vadim1242:

lucull,

Вы противоречите сами себе. Этот пример лишь доказывает, что код должен распаралелить программист. И только когда програмист сделает два потока, тошлько тогда можно задействовать HT.

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

Хорошо , представим такую ситуацию. Вот у вас есть однопоточный код на двух процессорной системе с отключенной Hyper-Threading. При включении Hyper-Threading у вас производительность выросла на 15% .Спрашивается откуда? Однопоточный код ведь програмист не разбивал.

Dimenice:

Скорее, упала на 5%, если код был нормальный и грузил ядра по полной, без учета существования HT и оптимизации под неё)
п.с. не поднимется, даже хуже может стать ,если планировщик винды кинет на HT_ядро выполнение вместо физического.

Доводы правильные, но Hyper-Threading то появилась во времена однопроцессорного Pentium 4 , и прирост там был.

Начнём с того , что это утверждает сайт 3dnews

Ссылка тут А единственной логикой выполняющей это может быть только Hyper-Threading .

Возможно, но мне понравился пример работы здесь. Ссылка тут

Я всё к тому , что не оптимизированный программный код в среднем загружает блоки процессора на 33%.А оптимизированный намного больше.Беда в том , что практически все программы имеют оптимизацию под Интеловские процессоры. С Амд же беда в том , что под их процы оптимизации как правило нет, потому как разработчики ориентируются на продукцию Интел, которая предоставляет им все условия для этого.Это самая главная ошибка Амд. Я просто хочу сказать , что при оптимизации программы под Fx они способны на большее , чем показывают сейчас. В этом весь мой интерес к Амд, не более.
P.S Да Амд вообще хочет отказаться от FPU в процессоре и перенести его на GPU , на котором они выполняются намного быстрее( где-то читал , что до 7 раз) свой блок FPU имеют только Radeon 7хх серии,но как они собираются всё это увязать хз, на такое способна только Интел. У неё огромный опыт в программном обеспечении . А FX это был переходный вариант, с сильно ослабленным FPU (привет играм из-за этого)

почуствую ли раницу взяв его??, у меня GTX 660+965BE, явно проца не хватает...

Vadim1242:

SmT_Barkas:

почуствую ли раницу взяв его??, у меня GTX 660+965BE, явно проца не хватает...

Ага. денег меньше станет.

Для чего проца не хватает то?

например кризис3 на средних забивает часто проц на 100%, фпс падает, причём фпс почти одинаковый как на высоких так и на средних

Vadim1242, прав. распаралеливание должен делать программист и сделать его можно не везде.

а что касается WinRAR - вчера проводил тесты и результат довольно таки интересен и вопиющЪ.
надо было мне сжать образ дьябло3, который немного не влазил на DVD-DL болванку. 8.7Гб, болванка 8.5.
я естественно ткнулся в винрар, мультипоточность включена, камень FX6100, загрузка камня 50-53%. как так спрашиваю я себя. естественно первая мысль - расколоть образ пополам и сжать, бо быстрее. для этого я решил сделать два батничка, из которых запустил бы консольную версию RAR и начал разбираться с ключами. оказалось, что есть ключ задающий не просто использование многопоточности, как в GUI, а задающий число потоков.
и о чудо, задав там 6+ загрузка камня стала 79-83%. так что сами по себе GUI WinRAR не дают пользователю корректно настроить многоядерность, при этом генерируя не верное количество потоков. порылся в реестре, думал может этот параметер записан там, все пересмотрел, но не нашел.
вот и думаю теперь, а не накатать ли мелкую оболочку для консольного RAR под себя.

альзо. исходный объем 8 742 258 688 байт.
сжатие console rar 9:36. загрузка 80%, 54 градуса. объем 8 469 831 466 байт.

сжатие 7z 15:44. загрузка 100%, 59 градусов. объем 8 374 468 824 байт.

параметры 7z

я уже как то пытался перейти на 7Z. и лет 6 назад пришел точно к такому результату.
сжатие 7Z выше, если даешь словарь большого размера. при этом 7z требует много больше ОЗУ, чем рар. грузит камень на 100%(правда и тут с нюансом. потребление камня при этом почему-то 65 Вт, вместо 95, что как бы намекает).
сжал он на целый 1 процент лучше, чем рар. правда и времени на это затратил ощутимо больше. 9:36 против 15:44.
бОльше же размеры словаря удавалось выставить установив количество потоков < 4, что автоматом еще увеличивает время упаковки.
исходная задача решена и в одном, и в другом случае, но в раре еще, например, можно допилить информацию для восстановления, причем в свеженькой 5й версии это уже таки Соломон-Рид.
так шта...
"очередная хорошая попытка 7z, но я все равно не буду тобой пользоваться"

встройка в контекстное меню виндовс походу не потребует даже чего-либо писать.