Отрезано от: https://linuxforum.ru/viewtopic.php?id=40341
[quote=ZhuK]Аthlon II не способен Full hd? Что-то новенькое на горизонте замаячило.
Способен, но при этом будут лёгкие подтормаживания.[/quote]
Добро пожаловать в Линукс!
У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов. Модель настолько убогая, что даже разгону не подлежала. И тем не менее.
У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов.
А причём тут проц, в винде работает аппаратное декодирование на видюхе в браузерах.
И в Linux на свежих видюхах nvidia, аппаратное ускорение видео работает в chromium-vaapi.
[quote="ZhuK"]У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов.
А причём тут проц, в винде работает аппаратное декодирование на видюхе в браузерах.
И в Linux на свежих видюхах nvidia, аппаратное ускорение видео работает в chromium-vaapi.[/quote]
"Видюха" с тех пор так и не поменялась. Radeon 4670. Заоблачный и свежий декодер всего, что ни попадя. Ну и ОС 8 - ми летней давности на тот момент.
Пардон, но было сказано, что под атлоном 2, хд будет подтормаживать. А потом вы спрашиваете - при чем тут проц к хд?
Я запутался. :D
[quote=Wolfenberg][quote=ZhuK]Аthlon II не способен Full hd? Что-то новенькое на горизонте замаячило.
Способен, но при этом будут лёгкие подтормаживания.[/quote]
Добро пожаловать в Линукс!
У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов. Модель настолько убогая, что даже разгону не подлежала. И тем не менее.[/quote]
У меня - нет :)
Отключал видеокарту и переходил на встроенное - процессор вис намертво на Full HD. Были такие порясающие артефакты, что словами не передать.
Добавлено: 25.05.2020 07:06:18
[quote=Wolf][quote="ZhuK"]У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов.
А причём тут проц, в винде работает аппаратное декодирование на видюхе в браузерах.
И в Linux на свежих видюхах nvidia, аппаратное ускорение видео работает в chromium-vaapi.[/quote]
"Видюха" с тех пор так и не поменялась. Radeon 4670. Заоблачный и свежий декодер всего, что ни попадя. Ну и ОС 8 - ми летней давности на тот момент.
Пардон, но было сказано, что под атлоном 2, хд будет подтормаживать. А потом вы спрашиваете - при чем тут проц к хд?
Я запутался. :D[/quote]
При том, что в документации указано, что данный процессор поддерживает лишь минимальную графику, т.к. сокет разработан для параллельной ветки процессоров с графическим ядром :P
А потом вы спрашиваете - при чем тут проц к хд?
Проц AMD Athlon(tm) X4 840
При том, что в документации указано, что данный процессор поддерживает лишь минимальную графику, т.к. сокет разработан для параллельной ветки процессоров с графическим ядром :P
Что значит минимальную графику?
АМ3 разработан для параллельной ветки.... Тут запутался ещё сильнее. Что за источники информации у вас?
Добавлено: 25.05.2020 18:50:20
Проц fx 4300 загрузка при просмотре хд 13-23%. Опера. Винда 7. Видео radeon 4670.
Добро пожаловать в Линукс!
Если я вас правильно понял.
Разница в производительности между этими процами выявляется только бэнчмарками. На глаз не заметите.
Что то явно в оптимизации не то.
ZhuK,
Что значит минимальную графику?
SD 320 максимум. В основном, так любимый вами DivX.
АМ3 разработан для параллельной ветки.... Тут запутался ещё сильнее. Что за источники информации у вас?
У меня сокет FM2+ он поддерживает два вида процессоров: с возможностью обработки графики (серия AMD A) и без оной (серия Athlon II)
Понял, спасибо. Но все равно не ясно, как процессор не имеющий графического ядра может поддерживать минимальную графику. Но в любом случае это не важно. Ибо, как я понимаю, Ютуб явно divx не использует и процессор работает насколько это требуется.
Другими словами: 4670 это не та видеокарта, которая что то способна. Атлон 250 тоже не шедевр. Но не тормозило с Ютуб. Думаю загвоздка в ОС. И это видно по загрузке схожих процессоров.
Но есть и хорошая новость. Линус пересел на процессор от АМД. Есть шанс на более качественную оптимизацию ядра под АМД.
Мои любимые кодеки h264 и h265.
Понял, спасибо. Но все равно не ясно, как процессор не имеющий графического ядра может поддерживать минимальную графику.
Тут уже идёт в помощь микропроцессор материнской платы (преобразование потоков). AMD создала довольно интересный инженерный проект, впоследствии заброшенный из-за гневных воплей "геймеров", которым подавай 100500 ядер и турбину в пятую точку.
из-за гневных воплей "геймеров", которым подавай 100500 ядер и турбину в пятую точку.
Ну не будем так с горяча. :D Линус Торвальдс пересел на АМД именно из за количества ядер и потоков. Под которыми его задачи выполняются быстрее. Так что не только геймеры.
Линус Торвальдс пересел на АМД именно из за количества ядер и потоков.
Он это сделал также ради престижа!
У старшего - старшая модель проца и компа.
Хотя, скорее всего, будет оптимизировать ядро под многоядерные системы.
Хотя, скорее всего, будет оптимизировать ядро под многоядерные системы.
А что это такое - многоядерные системы?
[quote=ValentinK]
Хотя, скорее всего, будет оптимизировать ядро под многоядерные системы.
А что это такое - многоядерные системы?[/quote]
Уточняю. Многоядерные и многопоточные процессора хотел сказать.
А Вы могли бы и догадаться.
Я предполагал, но решил уточнить.
А не поздно начинать оптимизацию? Многоядерные на рынке лет 13 уже. :D
Я не специалист, но мне кажется, что приложений использующих многоядерность/многопоточность не так уж много. Может с них начать?
Я предполагал, но решил уточнить.
ОК!
А не поздно начинать оптимизацию? Многоядерные на рынке лет 13 уже. ag
Я не специалист, но мне кажется, что приложений использующих многоядерность/многопоточность не так уж много. Может с них начать?
Так ведь ядер много, а сокет на плате один.
Хотя в процессоре имеется несколько контроллеров доступа к памяти.
Но системная шина одна.
Задачи выполняются параллельно, но данные скидываются по очереди.
Ещё, если система многозадачная, то может каждой задаче выделять процессорное ядро.
Или из-за одного сокета всё равно получается система с разделением времени?
Ну, скажем, есть главный процесс-супервизор, рапределяющий процессам время процессора и память.
Вот интересно, как он работает со многими ядрами.
Это ведь совсем нетривиальная задача.
А при чем тут системная шина и как она мешает вычислительном процессу?
А при чем тут системная шина и как она мешает вычислительном процессу?
По системной шине передаются данные от процессора к памяти и контроллерам периферии и обратно.
Она одна и поэтому это узкое горлышко для многоядерных систем - вычислительных потоков много, а данные они передают через системную шину по очереди.
Насколько я помню, по системной шине процессор уже давно не обменивается с памятью. HT в помощь ему.
И каким образом периферия влияет на производительность?
Все, что нуждается в обмене большими объемами данных уже давно обзавелось своими путями отличными от FSB.
Вот интересно, как он работает со многими ядрами.
Это ведь совсем нетривиальная задача.
Эта задача упрощается до вполне понимабельного уровня в акторной модели выполнения -
так работают, например, Erlang, и Akka - для Java-мира.
То бишь процессы, сообщения (а именно запросы и ответы),
и все разделяемые ресурсы - тоже процессы, хоть ты тресни.
Над всей этой красотой надзирает супервизор (не более чем ещё один процесс :)) -
и, если он располагает адекватной системой ранжирования процессов по приоритетам,
даже и конкуреннтые системы работают ожидаемым и предсказуемым образом.
Отдельно следует отметить проблему времени при согласовании работы процессов -
чтобы система была актуальной в каждый момент времени и давала релевантные ответы именно
для текущего состояния "обрабатываемого мира" -
чтобы не вышло так, что выдан ответ по текущему состоянию какой-нибудь структуры,
а через мгновение в эту структуру прилетает нечто,
требующее дать совершенно другой ответ на тот же самый запрос.
Но! Так выглядит работа с зелёными, легковесными, в отличие от процессов ОС, процессами.
На более низком уровне, внутри BEAM, JVM, ядер ОС -
треша и угара ещё больше. Борются с ними и вышеприведёнными методами, и более врукопашную.
Но так мой пост никогда не кончится :)
Насколько я помню, по системной шине процессор уже давно не обменивается с памятью. HT в помощь ему.
И каким образом периферия влияет на производительность?
Все, что нуждается в обмене большими объемами данных уже давно обзавелось своими путями отличными от FSB.
Всё равно путь один. Сокет процессора один. Дорожки на плате для обмена данными одни для всех ядер вместе.
Добавлено: 30.05.2020 12:52:53
Эта задача упрощается до вполне понимабельного уровня в акторной модели выполнения -
так работают, например, Erlang, и Akka - для Java-мира.
Акторы - это UML?
То бишь процессы, сообщения (а именно запросы и ответы),
и все разделяемые ресурсы - тоже процессы, хоть ты тресни.
Над всей этой красотой надзирает супервизор (не более чем ещё один процесс ab) -
и, если он располагает адекватной системой ранжирования процессов по приоритетам,
даже и конкуреннтые системы работают ожидаемым и предсказуемым образом.
Это очень интересно!
Отдельно следует отметить проблему времени при согласовании работы процессов -
чтобы система была актуальной в каждый момент времени и давала релевантные ответы именно
для текущего состояния "обрабатываемого мира" -
чтобы не вышло так, что выдан ответ по текущему состоянию какой-нибудь структуры,
а через мгновение в эту структуру прилетает нечто,
требующее дать совершенно другой ответ на тот же самый запрос.
Но! Так выглядит работа с зелёными, легковесными, в отличие от процессов ОС, процессами.
На более низком уровне, внутри BEAM, JVM, ядер ОС -
треша и угара ещё больше. Борются с ними и вышеприведёнными методами, и более врукопашную.
Но так мой пост никогда не кончится
Получается, супервизор один, а процессов десятки и сотни и тысячи.
Одно дело, это деление времени процессора между процессами.
Другое дело - распределение процессов по ядрам процессора.
А сокет на плате один для всех ядер и дорожки на плате между процессором и памятью одни,
хоть и многоразрядные. Вот и проблема, как равномерно нагрузить все ядра,
чтобы и процессы отрабатывали и чтобы они не ждали, пока надо скинуть результат работы в память.
Я сам не гуру в этом вопросе но очень благодарен Вам за подробный ответ.
