Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

Работа ядер "разного поколения" не возможна впринципе (в концепции и схеме работы биг.литл имеется ввиду), планировщик относительно легко перкидывает нагрузку с слабых на сильных, потому что А15 и А7 разрабатывались в одно время и как связка и они ядра одного поколения с идентичными наборами инструкций, только первый с ОоО, а второй поочередное исполнение команд (как в атоме). Следующий набор у АРМа А57 и А53, вот связка А9+А15 или А57+А15 ядра разных поколений и они работать не будут в тандеме.
А в новости следовало бы написать ядро архитектуры A15 и т.д.

этот режим называется - big.LITTLE MP model

7ая, седьмая!!! седьмая про планшеты и прочую лабуду. Оверы, вернитесь к истокам

А чем вам не нравятся темы по процессоры? Истоки - это когда было по 7 новостей про эппл в день?
Лучше уж про планшеты и процессоры, чем про эппл.

верно


Первоначально связка была A9+А7, потом вышло А15 с той же архитектурой ARMv7, сейчас идут А57+А53.


Суть новости, что ОС научат включать оба кластера и распределять задачи по какому-то признаку.
Тогда всякий фоновый софт будет пожизненно работать на LITTLE, и только некоторые программы получат доступ к big.

вы мне объясните как можно без резких скачков производительности (аки фризы) перекидывать рабочий код который в данный момент исполняется с быстрый на медленные и наоборот?

Добавлено спустя 1 минуту 7 секунд:
я мож дурак но чет в голову ничего не идет.

Суть "новости" была известна больше года назад, но написана она кривовато, не более того.

А причем тут фриз? Фриз это остановка выполнения на заметное человеческому глазу время.
Сохранить состояние регистров и загрузить в другое ядро это на порядки быстрее.

При общем то кэше тем паче.

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

Хех, что, уже упёрлись в потолок производительность / ватт? .... Что-то беспокоюсь за состояние ARM фагов и их поп.

mag_ai
Вы что не знакомы с вытесняющей многозадачностью? Приостановка задачи на одном ядер и запуск на другом при одинаковых ядрах решена черте сколько лет назад, почему вы думаете, что между ядрами с разным уровнем производительности разница будет принципиально отличаться?
У ядер разное количество регистров? Другой объем кеша нижнего уровня? Разные наборы инструкций? Вроде бы нет.
Я не очень разбираюсь в ядрах ARM и если вы видите серьезные проблемы, пишите яснее пожалуйста.
Электрическое включение и отключение ядра, там где система под это заточена, занимает очень малое время. Я подозреваю, что это даже не милисекунды, а микро. Перенос задачи на другое ядро в современном процессоре - это тоже микросекунды по смыслу. Каких-то сверхвычислений для этого требоваться не должно.
С полным выключением и сильным понижением энергопотребления (быстрый переход в нормальный режим) x86 ядер Intel вроде как раз во всю играет последние годы (в лабораториях) и имеет определнные успехи в этом деле.

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

Добавлено спустя 22 минуты 28 секунд:
вообще если кто понимает что сказал по этой теме директор квалкома? он назвал окта 5 от самсунга - фигней. и я верю ему а не самсунгу который например недавно обсуждали втыкает некие костыли виде "опенсл фулл профайл" не понятно чем фулл профайл отличается и как даже вот такой вроде милый костыль реально применить! не говоря уже о неком легком переносе исполняемого кода с одного ядра на другое.
Я так поясню свои опасения моим виденьем проблемы:
и так у нас есть некий окта 5 от самсунга в котором есть 4 ядра а7 и 4 а15 причем работать одновременно они не могут (на последнее условия я забил) в нем есть некий контроллер шины и некий множитель причем для каждых 4 ядер он разный имею ввиду множитель. есть некое видео ядро которое работает через системную шину в процессоре.
условие задачи определись алгоритм переноса рабочего кода с медленных ядер а7 на быстрые ядра а15 установить алгоритм необходимости такого перехода.
и так у нас работают а7 в некий момент их загрузка достигает 99% и есть нехватка производительности и они включают переход на а15, но тут есть первая проблема если алгоритм перехода строится на нагрузке то и обратный переход строится на ней, а это значит что если он упадет до некой н величины он начнет миграцию обратно, но вы не рассматриваете такую возможность что приложение в некий момент не требуется столько производительности (или ей только изредка не хватает производительности а7) и он что будет скакать с ядер на ядра? это на мой взгляд не логично я придумал другой алгоритм скажем если процессор определяет не хватки производительности для н приложения он перескакивает и сохраняет это стояние (до того момента как приложение не будет выгружено из памяти), но оно может быть и вообще не выгружаемое и тогда он будет молотить на своих а15 до конца то есть где тогда экономия в такой технологии?
теперь об алгоритме перехода. я предполагаю что в этот момент исполнение новых инструкций приостановлено запоминаются регистры (ну то есть открываются на других ядрах) изменяется информация в планировщике задач происходит запуск ядер и отключение тех, но есть фишечка видеокарта не может обращаться к ядрам на "паузе" то есть ее то тож ставят на паузу. и она весит в ожидании (на системной шине) ответа от новых ядер. то есть я реально замечу фриз при совершении моим телефоном таких операций.
более того нафиг все это плодить если можно сделать как пошли на х86 архитектуре - умение процессора снижать частоту и гибко ее наращивать умение отключать и включать ядра, но не с полным выключением, а частично ядро отключено но доступно из системы. по такой технологии скажем идет аппл ее А6 может гибко изменять свою частоту и все... причем экономии в разы больше - вот почему я думаю что все эти бил литалы и окта 5 полный трешак! надеюсь вы меня поняли?