Здравствуйте, VladCore, Вы писали:

VC>Ну и зачем этот big.LITTLE?

Рискуя окунуться в конспироложество, предположу со своей дилетантской колокольни: ARM долго позиционировался (некоторыми) (фанатами) как "intel без исторических наслоений", "вот смотрите, у нас сейчас производительность почти как у Intel'а, а энергопотребелние в 100500 раз меньше, вот мы Intel догоним а энергоэффективность будет ВАХ!". Но, вдруг, откуда не возьмись, оказывается что рост производительности с какого-то момента повышает энергопотребление совсем даже не линейно и с наскока обогнать Intel не получится — начинают плодится и размножатся ядра (вспомните, когда-то даже 2-х ядерный телефон был предметом шуток). Но рост производительности самих ядер не так высок, как хотелось бы и предел не за горами. Как быть, маркетологи держат за... горло, и говорят что 4-х ядерный процессор будет продаваться хуже восьмиядерного, пусть даже он быстрее, а 8-ми ядерный, с другой стороны, сможет поджарить не только яичницу. Вот и пришло красивое решение — делаем часть ядер быстрыми, а остальные обрезанными — и можно почти честно написать что у нас есть 8-ми ядерный процессор нового поколения. Покупатели радостно несут деньги, производители счастливы, всем весело.

(Статья, кстати, 3-х летней давности — интересно как в итоге всё сложилось)

Здравствуйте, Mamut, Вы писали:

_>>По мне, просто не осилили биг-литл
M>В пятый раз повторю: big.little им не нужен. Почему он им не нужен, см. в моих сообщениях.
А что, у Apple какая-то особенная, уличная магияфизика?

Ещё как он им нужен, но они ниасилили пока что его сделать. У Apple A9 примерно такое же потребление, как и у больших ядер Samsung'ов.

Apple пока что выезжает за счёт жёсткого ограничения фоновых процессов в ОС — большую часть времени в режиме ожидания процессор выключен от слова "совсем". Даже для фоновых загрузок трафик буферизуется в аппаратных кольцах сетевой карты (прмиерно до 2 секунд времени в обычном режиме).

Там где такие трюки не прокатывают из-за необходимости иметь фоновые real-time задачи — Apple опадает на землю и превращается в компост. Основной пример — собственно режим разговора:
Apple iPhone 5S — 8 часов
Galaxy S6 — 25 часов

"Почуствуй разницу" (тм)

Здравствуйте, VladCore, Вы писали:

VC>Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.

Современные intel core iN умеют выключать ядра (и при этом разгонять только одно ядро) для энергоэффективности. Почему бы для пущей энергоэффективности не выключить более энергоемкое мощное ядро и использовать более энергоэффективное маломощное ядро? Не всем же нужна simd-"плавающая точка", а жрет она не мало, даже в простое. То что несимметричная многопроцессорность это еще одна головная боль для (планировщика) операционной системы, это уже проблемы операционной системы.

C>Вполне возможно, что там какой-нибудь пост-процессинг. Причём часто бывает, что современные CPU вполне себе нормально считают его сами по себе, но уже есть 100500 тонн ассемблерного кода для DSP, и потому банально проще его воткнуть.

Там еще иногда оказывается, что меньше батарейку и жрет если иметь слабый CPU и еще DSP, чем один большой CPU.
Плюс real-time проще, чем когда один CPU, а он нужен когда это например много спикеров.
Ну а с handset и mp3 это все конечно не нужно.

S>Цифры.

4-6 mA в режиме 1 Гц, и что-то совсем микроскопическое при фиксе раз в минуту.

Тот же MTK M5 в часах Garmin (ЕМНИП 350 мАч батарейка) работает с непрерывной записью и показом кучи параметров на экране в течение 20 часов при 1 Гц записи, и до 60 часов при записи раз в минуту.

S>"заканчивая torrent'ами в бэкграунде" на фоне работы с сетью, особенно с сотовой, выйгрыш от мелкого ядра будет выглядеть бледно.

Я больше про WiFi. Но также постоянная синхронизация с BTLE устройствами или ANT+ датчиками.

Непонятна мотивация этих big.LITTLE:

Анализируя работу приложений, компания ARM пришла к выводу, что повсеместно использовать мощные вычислительные ядра зачастую невыгодно
Подробнее: http://www.overclockers.ru/hardnews/50477/Arhitektura_ARM_big.little_vpolovinu_umenshit_potreblenie_processorov.html

Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.

Похоже на то что в ARM искуственно хотят просто площадь чипа увеличить что бы теплоотвод повысить. Бред наверно Но других объяснений не могу придумать.

Ну и зачем этот big.LITTLE?

Здравствуйте, Stanislaw K, Вы писали:

SK>Здравствуйте, Somescout, Вы писали:

S>>(Статья, кстати, 3-х летней давности — интересно как в итоге всё сложилось)

SK>Толком ничем. Сделали Big.LITTLE Processing with ARM Cortex™-A15 & Cortex-A7 на том и успокоились.

SK>https://www.arm.com/products/processors/technologies/biglittleprocessing.php

Неплохо так успокоились
http://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php
https://en.wikipedia.org/wiki/ARM_big.LITTLE#Implementations

Здравствуйте, VladCore, Вы писали:

[]

VC>Ну и зачем этот big.LITTLE?

1. Нормальный "темный кремний" ниасилили
2. Лицензиаты платят за йадра
э. ???
4. ПРОФИТ!!11

Здравствуйте, Stanislaw K, Вы писали:

SK>>>Это скорее продолжение НИОКР, снизили потребление, перешли на новый техпроцесс. Будем надеяться что допилят.
_>>Неплохой такой НИОКР на популярных смартах, типа: гугл нексус, самсунг гелегси и тп.

SK>Обычное дело. Выпустить опытную партию, и смотреть как оно себя ведет в реальной эксплуатации. Лабораторные крысы гики в наблюдения и модель использования вносят искажения и результат недостоверен. Только дикий пользователь, только реальная жизнь.

Опытная партия в 10ки-сотни миллионов. Какой-то слабый НИОКР, вообще ниачом.

_>>>>https://en.wikipedia.org/wiki/ARM_big.LITTLE#Implementations

SK>>>Ну да. три девайса в год, да еще и не популярными ограниченными сериями. Я бы сказал что в широкие массы оно как то "не пошло".
_>>Тебя Тим Кук нежно покусал?

SK>В каком смысле?

10-100 миллионов — ограниченная серия. Просто замечательно. Буду знать новое название для таких величин.

Здравствуйте, VladCore, Вы писали:

VC>>>о том и речь. в аппле нет таких извратов. там посчитали что не нужен, но вы предложите вашу идею куку.

_>>Если в эппле куку-инженьёры, не могут запилить в ядре открыто сворованной ОС поддержку несимметричной многопроцессорности, то известно кто "не нужен". В андроиде, что на линухе, биг-литл рабтает искаробки.

VC>Тяжело с вами дискутировать. Apple "своровал" ядро у стива джобса. точнее его некста.

VC>см. икона и став джобс. это названия книжек.

Микроядро Mach не свое, наняли команду, за одно и код прихватизировали. При этом Мащ — это слегка доработанный БСД. Сетевой стек, ввод-вывод и другие системно важные модули прихватизированs из БСД систем. Грубо, свое там только ОбжектСи. И Джобс там только как эффективный менеджер, без кавычек и искажений.

Здравствуйте, fin_81, Вы писали:


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

не хочу обдеть, но big.LITTLE ортогональна производительности.

_>Если тебе нужна производительность, тебе точно не нужен литл, бери только биг. А лучше кластер из 2^N GPU.

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

Mamut, сорри что вмешался.

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

Не то же

_>По мне, просто не осилили биг-литл

В пятый раз повторю: big.little им не нужен. Почему он им не нужен, см. в моих сообщениях.

_>, и при проектирования железа, и на уровне софта. Решили сэкономить на всяких лицензиях, пусть лучше другие раскошеливаются на закругленные углы. Сами не смогли, а чужое взять гордость "эффективных манагеров" мешает. Но пипл хавает.

Ты продолжаешь что-то вещать про «не осилили» при том, что есть объективная реальность: максимум, что может сделать big.little, это с трудом догнать ядра Apple'а по производительности. И то, для того, чтобы догнать два ядра по производительности, им нужно восемь ядер.

И да. Производительность + энергопотребление — это ровно то, зачем нужны процессоры.

_>Я не понимаю, ты не понимаешь зачем нужен биг-литл или тебя точно кто-то покусал.

Нет. Я не понимаю, зачем нужен big.little. Вернее, я понимаю, что он нужен людям, которые не осилили сделать нормальные ядра.

Здравствуйте, Mamut, Вы писали:

C>>У нас есть устройство с правильным big.LITTLE и минимальной RTOS.
M>Ахахахахаха. Классика. «У вас Линукс неправильный» ©
Так и iOS тоже неправильный. Сейчас никто нормально для общего случая его использовать не умеет. Для частного случая мы руками сделали переключение.

Но работа ведётся, ситуация улучшается:
https://lwn.net/Articles/655479/

C>>Ну значит в Android всё плохо внутри в текущих версиях. Вполне верю.
M>Ну то есть мое утверждение остается верным: Apple'у big.LITTLE нафиг не сдался.
Я почти уверен, что сейчас внутри Apple над ним работают. Чтобы потом с помпой объявить: "Apple изобрёл фоновые процессы!"

Здравствуйте, Cyberax, Вы писали:

C>Даже в этом режиме big.LITTLE выгоден, если пользователь не совершает активных действий, а просто смотрит на страничку.

Да ради бога. Только той выгоды — единицы процентов.

Здравствуйте, Mamut, Вы писали:

C>>Так и iOS тоже неправильный. Сейчас никто нормально для общего случая его использовать не умеет. Для частного случая мы руками сделали переключение.
M>Внезапно до меня дошел весь цимес разговора.
M>Cyberax: big.LITTLE рулит, Apple просто не осилили
Угу.

M>Mamut: Apple'у просто не нужно
Нужно.

M>Cyberax: Apple сосет на фоновых задачах, вот сравни Андроид 2015-го года с Айфоном 2013-го!
M>Mamut: Ну, вообще-то сравнивать надо с айфонами 2015-го года.
Ну так фоновых задач в iOS нет.

M>Cyberax: Ну, эта... А, вот. Андроид говно, они не умеют, а вот у нас есть специальная ОСЬ, в которой все работает, как надо!
Именно так.

M>- нафига этот big.LITTLE вообще сдался, если, как оказалось, его вообще никто не умеет, а для каких-то сугубо частных случаев надо пилить руками
Только ведь ниасилуемость — это временное состояние. Работа по нормальной интеграции в ядро и ОС уже идёт, так что результаты появятся уже к следующему Андроиду.

M>- к чему эти вопли про «Apple не осилили», если оказалось, что: a) не осилили вообще все и б) apple'у это просто не нужно (см. бенчмарки и т.п.)
Станет ВНЕЗАПНО нужно уже скоро.

Здравствуйте, Mamut, Вы писали:

M>

M>Сейчас никто нормально для общего случая его использовать не умеет. Для частного случая мы руками сделали переключение.

Ты правда считаешь, что "не умеет" в этом контексте это тоже самое что "не знает"? Мне так кажется, что в данном случае "не умеет" означает "не реализовано", если что Cyberax поправит.

VC>Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.
VC>Похоже на то что в ARM искуственно хотят просто площадь чипа увеличить что бы теплоотвод повысить. Бред наверно Но других объяснений не могу придумать.
VC>Ну и зачем этот big.LITTLE?

Интел делала подобные прототипы еще лет 15 назад.

Здравствуйте, Somescout, Вы писали:

S>(Статья, кстати, 3-х летней давности — интересно как в итоге всё сложилось)

Толком ничем. Сделали Big.LITTLE Processing with ARM Cortex™-A15 & Cortex-A7 на том и успокоились.

https://www.arm.com/products/processors/technologies/biglittleprocessing.php

Все проблемы от жадности и глупости

Здравствуйте, fin_81, Вы писали:

_>Здравствуйте, VladCore, Вы писали:

VC>>Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.

_>Современные intel core iN умеют выключать ядра (и при этом разгонять только одно ядро) для энергоэффективности. Почему бы для пущей энергоэффективности не выключить более энергоемкое мощное ядро и использовать более энергоэффективное маломощное ядро? Не всем же нужна simd-"плавающая точка", а жрет она не мало, даже в простое. То что несимметричная многопроцессорность это еще одна головная боль для (планировщика) операционной системы, это уже проблемы операционной системы.

о том и речь. у Аппла тоже кстати big.LITTLE нету. они два чипа суют в соответствии с best practice. A-"серия" и М-"серия".

Сорри за повтор. Ну и зачем этот big.LITTLE?

Здравствуйте, VladCore, Вы писали:

VC>о том и речь. у Аппла тоже кстати big.LITTLE нету. они два чипа суют в соответствии с best practice. A-"серия" и М-"серия".

VC>Сорри за повтор. Ну и зачем этот big.LITTLE?

В смысле о чем речь? Разные типы ядер сидят на одном и том же окружении (кеш, модули работы с памятью, портами и тп). Любая задача может мигрировать между ядрами с минимумом накладных расходов (например, копированием состояния регистров).
Выполняется задача в фоне на слабом ядре, ждет сигнала; пришел сигнал и начал перемалывать данные на сильном ядре.

А как соединены "А" и "М" в эплле без понятия.

Здравствуйте, fin_81, Вы писали:

_>Здравствуйте, VladCore, Вы писали:

VC>>о том и речь. у Аппла тоже кстати big.LITTLE нету. они два чипа суют в соответствии с best practice. A-"серия" и М-"серия".

VC>>Сорри за повтор. Ну и зачем этот big.LITTLE?

_>В смысле о чем речь? Разные типы ядер сидят на одном и том же окружении (кеш, модули работы с памятью, портами и тп). Любая задача может мигрировать между ядрами с минимумом накладных расходов (например, копированием состояния регистров).

а насколько это проще частоту понизить?

_>Выполняется задача в фоне на слабом ядре, ждет сигнала; пришел сигнал и начал перемалывать данные на сильном ядре.

о том и речь. в аппле нет таких извратов. там посчитали что не нужен, но вы предложите вашу идею куку.

_>А как соединены "А" и "М" в эплле без понятия.

тоненькими "проводами" по плате соеденены а зачем вам как они соединены в контексте потребления энергии?

Здравствуйте, fin_81, Вы писали:

_>Здравствуйте, VladCore, Вы писали:

VC>>Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.

_>Не всем же нужна simd-"плавающая точка", а жрет она не мало, даже в простое.

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

Здравствуйте, fin_81, Вы писали:

S>>>(Статья, кстати, 3-х летней давности — интересно как в итоге всё сложилось)
SK>>Толком ничем. Сделали Big.LITTLE Processing with ARM Cortex™-A15 & Cortex-A7 на том и успокоились.
SK>>https://www.arm.com/products/processors/technologies/biglittleprocessing.php

_>Неплохо так успокоились
_>http://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php

As well as running 64-bit applications, the Cortex-A53 seamlessly and efficiently runs legacy ARM 32-bit applications. It is highly scalable, from a single multi-core CPU cluster, to a dual-cluster big.LITTLE CPU subsystem in combination with the Cortex-A72 or Cortex-A57 processor,

Это скорее продолжение НИОКР, снизили потребление, перешли на новый техпроцесс. Будем надеяться что допилят.

_>https://en.wikipedia.org/wiki/ARM_big.LITTLE#Implementations

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

Все проблемы от жадности и глупости

_>Выполняется задача в фоне на слабом ядре, ждет сигнала; пришел сигнал и начал перемалывать данные на сильном ядре.

В Apple спросили: нафига? И впиливает нормальные ядра без ограничений.

Здравствуйте, watchyourinfo, Вы писали:

VC>>Ну и зачем этот big.LITTLE?
W>Интел делала подобные прототипы еще лет 15 назад.

Эмм... а официальные пруфы есть?
А то intel времён 2k — это willamette, больше гигагерц и всё в таком духе. Про "производительность на ватт" стали вспоминать слегка попожже

Здравствуйте, VladCore, Вы писали:

_>>В смысле о чем речь? Разные типы ядер сидят на одном и том же окружении (кеш, модули работы с памятью, портами и тп). Любая задача может мигрировать между ядрами с минимумом накладных расходов (например, копированием состояния регистров).

VC>а насколько это проще частоту понизить?

Раз перешли на уровень "не нужен", то есть симметричный ответ.
Если понижение частоты не дает необходимый результат, то понижение частоты не нужно.

_>>Выполняется задача в фоне на слабом ядре, ждет сигнала; пришел сигнал и начал перемалывать данные на сильном ядре.

VC>о том и речь. в аппле нет таких извратов. там посчитали что не нужен, но вы предложите вашу идею куку.
Если в эппле куку-инженьёры, не могут запилить в ядре открыто сворованной ОС поддержку несимметричной многопроцессорности, то известно кто "не нужен". В андроиде, что на линухе, биг-литл рабтает искаробки.

_>>А как соединены "А" и "М" в эплле без понятия.

VC>тоненькими "проводами" по плате соеденены а зачем вам как они соединены в контексте потребления энергии?
Очень содержательный ответ. Это отдельные полноценные процессоры или ядра с общим модулем работы с памятью, портами, кешем?
А тоненькие провода позолоченные или из алюминия с покрытием из окисла алюминия?

Здравствуйте, Mamut, Вы писали:

M>В Apple спросили: нафига? И впиливает нормальные ядра без ограничений.

Согласен, Эппл умеет пилить, потому и "нафига".

Здравствуйте, Stanislaw K, Вы писали:

SK>Это скорее продолжение НИОКР, снизили потребление, перешли на новый техпроцесс. Будем надеяться что допилят.

Неплохой такой НИОКР на популярных смартах, типа: гугл нексус, самсунг гелегси и тп.

_>>https://en.wikipedia.org/wiki/ARM_big.LITTLE#Implementations

SK>Ну да. три девайса в год, да еще и не популярными ограниченными сериями. Я бы сказал что в широкие массы оно как то "не пошло".

Тебя Тим Кук нежно покусал?

Здравствуйте, fin_81, Вы писали:

SK>>Это скорее продолжение НИОКР, снизили потребление, перешли на новый техпроцесс. Будем надеяться что допилят.
_>Неплохой такой НИОКР на популярных смартах, типа: гугл нексус, самсунг гелегси и тп.

Обычное дело. Выпустить опытную партию, и смотреть как оно себя ведет в реальной эксплуатации. Лабораторные крысы гики в наблюдения и модель использования вносят искажения и результат недостоверен. Только дикий пользователь, только реальная жизнь.

_>>>https://en.wikipedia.org/wiki/ARM_big.LITTLE#Implementations

SK>>Ну да. три девайса в год, да еще и не популярными ограниченными сериями. Я бы сказал что в широкие массы оно как то "не пошло".
_>Тебя Тим Кук нежно покусал?

В каком смысле?

Все проблемы от жадности и глупости

Здравствуйте, fin_81, Вы писали:


VC>>о том и речь. в аппле нет таких извратов. там посчитали что не нужен, но вы предложите вашу идею куку.

_>Если в эппле куку-инженьёры, не могут запилить в ядре открыто сворованной ОС поддержку несимметричной многопроцессорности, то известно кто "не нужен". В андроиде, что на линухе, биг-литл рабтает искаробки.

Тяжело с вами дискутировать. Apple "своровал" ядро у стива джобса. точнее его некста.

см. икона и став джобс. это названия книжек.

VC>>о том и речь. в аппле нет таких извратов. там посчитали что не нужен, но вы предложите вашу идею куку.
_>Если в эппле куку-инженьёры, не могут запилить в ядре открыто сворованной ОС поддержку несимметричной многопроцессорности, то известно кто "не нужен".

Ты, я так понимаю, про это: https://en.wikipedia.org/wiki/Asymmetric_multiprocessing

Asymmetric multiprocessing (AMP) was a software stopgap for handling multiple CPUs before symmetric multiprocessing (SMP) was available.

_>В андроиде, что на линухе, биг-литл рабтает искаробки.

Зачем им big.little, если:

1. На десктопах им доступны полноценные ядра
2. В мобильных устройстав они разрабатывают собственные процессоры, которые рвут big.little на запчасти или, как минимум равны ему?

Samsung’s Exynos 7420 and Apple A9 both are based on 14nm FinFET technology. Apple A9 has also been manufactured by Samsung. This makes us little confused that how they manufacture Apple’s chip to perform that fast in dual-core, and how they make their own? Samsung Galaxy S6 Edge features an octa-core Exynos 7420 SoC and 3GB RAM, but it performs quite similar to Apple 9 chip in multi-core performance. However, Apple A9 SoC with 2GB RAM in iPhone 6s and 6s plus performs almost 90 percent faster compared to S6 edge.

Здравствуйте, Mamut, Вы писали:


VC>>>о том и речь. в аппле нет таких извратов. там посчитали что не нужен, но вы предложите вашу идею куку.
_>>Если в эппле куку-инженьёры, не могут запилить в ядре открыто сворованной ОС поддержку несимметричной многопроцессорности, то известно кто "не нужен".

M>Ты, я так понимаю, про это: https://en.wikipedia.org/wiki/Asymmetric_multiprocessing

M>

M>Asymmetric multiprocessing (AMP) was a software stopgap for handling multiple CPUs before symmetric multiprocessing (SMP) was available.

А теперь научи эту древнюю асимметрию, которая не могла симметрию в гомогенных системах, правильной асиметрии в гетерогенной системе.

_>>В андроиде, что на линухе, биг-литл рабтает искаробки.

M>Зачем им big.little, если:

M>1. На десктопах им доступны полноценные ядра
M>2. В мобильных устройстав они разрабатывают собственные процессоры, которые рвут big.little на запчасти или, как минимум равны ему?

M>

M>Samsung’s Exynos 7420 and Apple A9 both are based on 14nm FinFET technology. Apple A9 has also been manufactured by Samsung. This makes us little confused that how they manufacture Apple’s chip to perform that fast in dual-core, and how they make their own? Samsung Galaxy S6 Edge features an octa-core Exynos 7420 SoC and 3GB RAM, but it performs quite similar to Apple 9 chip in multi-core performance. However, Apple A9 SoC with 2GB RAM in iPhone 6s and 6s plus performs almost 90 percent faster compared to S6 edge.

Пошло сравнение теплого с мягким. Меряем скорость, когда разговор идет про экономичность. При этом этот андроид работает как виртуальная машина Жабы.

Здравствуйте, Patalog, Вы писали:

P>Здравствуйте, VladCore, Вы писали:

P>[]

VC>>Ну и зачем этот big.LITTLE?

P>1. Нормальный "темный кремний" ниасилили
P>2. Лицензиаты платят за йадра
P>э. ???
P>4. ПРОФИТ!!11

Если без шуток, то для понижения частоты нужны дрова/модуль ядра (у меня такое чудо дома на проце Allwinner H3 = 4*Cortex-A7)

а вдруг в big.LITTLE не нужны дрова и прочий софт для переключения режимов экономии?!!!!

Кто вкурсе?

Здравствуйте, VladCore, Вы писали:

VC>Если без шуток, то для понижения частоты нужны дрова/модуль ядра (у меня такое чудо дома на проце Allwinner H3 = 4*Cortex-A7)
VC>а вдруг в big.LITTLE не нужны дрова и прочий софт для переключения режимов экономии?!!!!
VC>Кто вкурсе?

А какая принципиально разница? У разработчиков устройств есть доступ ко всем драйверам/модулям. Только может для любителей кастомных прошивок может быть проблемой, но там и без этого проблем хватает.

Здравствуйте, fin_81, Вы писали:

_>Современные intel core iN умеют выключать ядра (и при этом разгонять только одно ядро) для энергоэффективности. Почему бы для пущей энергоэффективности не выключить более энергоемкое мощное ядро и использовать более энергоэффективное маломощное ядро? Не всем же нужна simd-"плавающая точка", а жрет она не мало, даже в простое.

А можно какие-нибудь цифры, доказывающие существование такой проблемы (большое потребление энергии незадействованными блоками процессора) в Intel? А то весь последующий спор исходит из того, что старое/урезанное решение энергоэффективнее, а это ни разу не очевидно. (Графики в статье доказывают существование такой проблемы в ARM'е, ну так это проблемы ARM'ов).

_>То что несимметричная многопроцессорность это еще одна головная боль для (планировщика) операционной системы, это уже проблемы операционной системы.
Если, как пишут, там используются именно старые ядра в качестве little, то вполне может всплыть проблема с меньшим набором инструкций. А это уже и проблемы программистов, пишущих под платформу.

Здравствуйте, VladCore, Вы писали:

VC>Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.
Нет, не достаточно. Современные "большие" ARM — это полноценные процессоры с out-of-order исполнением, предсказением переходов, prefetching'ом и прочим. И даже при уменьшении частоты это всё продолжает работать (не говоря уж о том, что частоту тоже не бесконечно можно понижать). Добавим сюда ещё то, что частоту нельзя совсем мгновенно изменять.

В результате, у LITTLE-ядра потребление примерно в 10 (десять) раз меньше "большого" ядра.

Проблемы с их использованием как раз в софте — все современные ОС рассчитаны на примерно одинаковые ядра. В Линуксе первоначальная поддержка big.LITTLE была реализована очень прикольно — через регулятор частоты. LITTLE-ядро выглядело для системы "пониженной частотой" большого ядра.

Однако, это всё очень криво, потому на практике big.LITTLE-процессоры не достигают теоретической экономии. В последних ядрах постепенно допиливают power-aware scheduling и big.LITTLE становится более привлекателен. Вдобавок, в Android 6 есть уже и поддержка уровня приложений для подобных сценариев.

Здравствуйте, VladCore, Вы писали:

VC>Ну и зачем этот big.LITTLE?

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

_>А теперь научи эту древнюю асимметрию, которая не могла симметрию в гомогенных системах, правильной асиметрии в гетерогенной системе.

Я тебя не понял.

_>>>В андроиде, что на линухе, биг-литл рабтает искаробки.

_>Пошло сравнение теплого с мягким. Меряем скорость, когда разговор идет про экономичность. При этом этот андроид работает как виртуальная машина Жабы.

Ты опять говоришь загадками. Говорю просто и по-русски: Apple'у big.little нафиг не вперся, потому что они прекрасно умеют делать полноценные высокопроизводительные ядра. Максимум, на что способен big.little — это быть может догнать яблочные ядра по производительности (и то, если взять 8 big.little ядер против двух яблочных).

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, watchyourinfo, Вы писали:

VC>>>Ну и зачем этот big.LITTLE?
W>>Интел делала подобные прототипы еще лет 15 назад.

S>Эмм... а официальные пруфы есть?
S>А то intel времён 2k — это willamette, больше гигагерц и всё в таком духе. Про "производительность на ватт" стали вспоминать слегка попожже

Например, тогда были такие "светлые будущие":
https://en.wikipedia.org/wiki/Transmeta

Здравствуйте, Mamut, Вы писали:

_>>А теперь научи эту древнюю асимметрию, которая не могла симметрию в гомогенных системах, правильной асиметрии в гетерогенной системе.

M>Я тебя не понял.

Это нормально.

_>>>>В андроиде, что на линухе, биг-литл рабтает искаробки.

_>>Пошло сравнение теплого с мягким. Меряем скорость, когда разговор идет про экономичность. При этом этот андроид работает как виртуальная машина Жабы.

M>Ты опять говоришь загадками. Говорю просто и по-русски: Apple'у big.little нафиг не вперся, потому что они прекрасно умеют делать полноценные высокопроизводительные ядра. Максимум, на что способен big.little — это быть может догнать яблочные ядра по производительности (и то, если взять 8 big.little ядер против двух яблочных).

Вообще-то, это я тебя не понимаю. Зачем ты требуешь от биг-литла высокую производительность? Если тебе нужна производительность, тебе точно не нужен литл, бери только биг. А лучше кластер из 2^N GPU.

M>>Ты опять говоришь загадками. Говорю просто и по-русски: Apple'у big.little нафиг не вперся, потому что они прекрасно умеют делать полноценные высокопроизводительные ядра. Максимум, на что способен big.little — это быть может догнать яблочные ядра по производительности (и то, если взять 8 big.little ядер против двух яблочных).

_>Вообще-то, это я тебя не понимаю. Зачем ты требуешь от биг-литла высокую производительность? Если тебе нужна производительность, тебе точно не нужен литл, бери только биг. А лучше кластер из 2^N GPU.


Все началось с твоих заявлений про то, что кто-то где-то что-то не осилил. На что я и VladCore тебе справедливо заметили: «неосиляторам» big.little не нужен, от слова совсем. big.little нужен тем, кто не осилил реализовать нормальные ядра с нормальным энергопотреблением без потери мощности.

Здравствуйте, Mamut, Вы писали:

M>Все началось с твоих заявлений про то, что кто-то где-то что-то не осилил. На что я и VladCore тебе справедливо заметили: «неосиляторам» big.little не нужен, от слова совсем. big.little нужен тем, кто не осилил реализовать нормальные ядра с нормальным энергопотреблением без потери мощности.

Не люблю обсуждать людей за их спиной, но не я первый начал.
Он вообще заявил что биг-литл не нужен, но зато у нас есть какие-то А и М, соединенные тоненькими проводами. По мне это те же яйца, только в профиль. По мне, просто не осилили биг-литл, и при проектирования железа, и на уровне софта. Решили сэкономить на всяких лицензиях, пусть лучше другие раскошеливаются на закругленные углы. Сами не смогли, а чужое взять гордость "эффективных манагеров" мешает. Но пипл хавает.
Я не понимаю, ты не понимаешь зачем нужен биг-литл или тебя точно кто-то покусал. Зачем боксеру собирать облепиху, если с этим лучше справляется пятиклассница? И есть меньше, фигуру соблюдает.

Всем спасибо, я устал, я ухожу ... из обсуждения.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Например, тогда были такие "светлые будущие":

Так transmeta тож ничего не представляла похожего на big.little. Пик — одноядерный Crusoe — не прожил и двух лет емнип и был медленней даже чипов от via. Вдвое.

Кроме того, речь про

VC>>Ну и зачем этот big.LITTLE?
W>Интел делала подобные прототипы еще лет 15 назад.

при чём тут transmeta?

VC>Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.
Феерический бред. ARM позволяет иметь до 16 сопроцессоров в том числе и DSP.
"Музыка в плееере" обрабатывается своим DSP, векторные вычисления — другим сопроцессором, когда сопроцессор ничего не делает то и #почтиничегонежрет.

PS: Сопроцессор это именно сопроцессор, а не "ядро", хотя может находится на одном кристале вместе с CPU. Ядра же считаются отдельно.

Здравствуйте, Pzz, Вы писали:

VC>>Ну и зачем этот big.LITTLE?
Pzz>Я вот тоже не могу понять. Конечно, медленный процессор жрет меньше, но и думает дольше. Непонятно, почему быстрее прокрутить задачу на быстром процессоре получается выгоднее, чем дольше на медленном.
Переключение большого процессора из режима сна в активный режим не происходит мгновенно.

Здравствуйте, Mamut, Вы писали:

M>Все началось с твоих заявлений про то, что кто-то где-то что-то не осилил. На что я и VladCore тебе справедливо заметили: «неосиляторам» big.little не нужен, от слова совсем. big.little нужен тем, кто не осилил реализовать нормальные ядра с нормальным энергопотреблением без потери мощности.
Это примерно вообще все. Да-да, включая и Apple.

Здравствуйте, eskimo82, Вы писали:

VC>>Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.
E>Феерический бред. ARM позволяет иметь до 16 сопроцессоров в том числе и DSP.
Феерический бред.

E>"Музыка в плееере" обрабатывается своим DSP, векторные вычисления — другим сопроцессором, когда сопроцессор ничего не делает то и #почтиничегонежрет.
Музыка в плеере давно считается в софте. Железом обрабатываются только видеокодеки, которые работают обычно вместе с включенным экраном.

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

Здравствуйте, eskimo82, Вы писали:

VC>>Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.

E>Феерический бред. ARM позволяет иметь до 16 сопроцессоров в том числе и DSP.

всего 16 сопроцессоров? почему так мало?

E>"Музыка в плееере" обрабатывается своим DSP, векторные вычисления — другим сопроцессором, когда сопроцессор ничего не делает то и #почтиничегонежрет.

E>PS: Сопроцессор это именно сопроцессор, а не "ядро", хотя может находится на одном кристале вместе с CPU. Ядра же считаются отдельно.

вы уверены в том что такое сопроцессор, тогда не плохо для начала.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Например, тогда были такие "светлые будущие":

S>Так transmeta тож ничего не представляла похожего на big.little. Пик — одноядерный Crusoe — не прожил и двух лет емнип и был медленней даже чипов от via. Вдвое.

S>Кроме того, речь про
S>

VC>>>Ну и зачем этот big.LITTLE?
W>>Интел делала подобные прототипы еще лет 15 назад.

при чём тут transmeta?

похоже никто не в курсе что big.LITTLE на языке домохозяек — это типа Core i7 и одноядерный atom на одном чипе. Одновременно только один работает.

C>Музыка в плеере давно считается в софте.
Феерический бред, впрочем от тебя и не такое можно ожидать.

VC>всего 16 сопроцессоров? почему так мало?
RTFM. Наверно тебе должно быть стыдно что я произношу такие слова.

M>Ты опять говоришь загадками. Говорю просто и по-русски: Apple'у big.little нафиг не вперся

Apple консервативен.
Например в моей области (WiFi) — компания поставляет чипы для Apple и Samsung, ну и кучи других помельче.
Самые новые технологии берет как правило Samsung.
Я думаю здесь дело в том же — сначала посмотрим как оно будет показывать себя.

C>Музыка в плеере давно считается в софте. Железом обрабатываются только видеокодеки, которые работают обычно вместе с включенным экраном.

Не всегда. У меня есть пример когда DSP. SoC на современном Cortex R4, но customer ставит свой DSP и гоняет на нем какие-то свои алгоритмы, без понятия что именно. Customer — одна из рскрученных компаний делающий разные аудио учтройства.

C>И процессор не #почтиничегонежрет, а вынужден оставлять включенным всю машинерию для предсказания перехода, когерентности кэшей и т.д.

Куда утекает энергия. В первую очередь в момент переключения логического элемента из одного состояния в другое, в стационарном состоянии токи утечки малы. Т.е. чем выше частота и больше элементов участвует — практически прямо пропорционально — тем больше потребление.

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

Big процессор выполняет инструкцию, это сложный процессор — много всяких блоков, кеша. Наверное это очевидно что очень сложно обеспечить clock gating таким образом чтобы количество активных логических элементов было не больше чем у Little более простого процессора.

Вот и вся идея наверное. Вопрос насколько практически выгоду это все даст.

Здравствуйте, eskimo82, Вы писали:

C>>Музыка в плеере давно считается в софте.
E>Феерический бред, впрочем от тебя и не такое можно ожидать.
Можешь ткнуть пальчиком в драйвер декодера для mp3 в ядре для Samsung Galaxy S5, например?

Здравствуйте, gardener, Вы писали:

C>>Музыка в плеере давно считается в софте. Железом обрабатываются только видеокодеки, которые работают обычно вместе с включенным экраном.
G>Не всегда. У меня есть пример когда DSP. SoC на современном Cortex R4, но customer ставит свой DSP и гоняет на нем какие-то свои алгоритмы, без понятия что именно. Customer — одна из рскрученных компаний делающий разные аудио учтройства.
Вполне возможно, что там какой-нибудь пост-процессинг. Причём часто бывает, что современные CPU вполне себе нормально считают его сами по себе, но уже есть 100500 тонн ассемблерного кода для DSP, и потому банально проще его воткнуть.

M>>В пятый раз повторю: big.little им не нужен. Почему он им не нужен, см. в моих сообщениях.
C>А что, у Apple какая-то особенная, уличная магияфизика?

C>Ещё как он им нужен, но они ниасилили пока что его сделать. У Apple A9 примерно такое же потребление, как и у больших ядер Samsung'ов.

Зачем им big.little, если:
1. производительность у big.little в лучшем случае такая же, как у A9
2. энергопотребление у Apple такое же, как у big.little

?

C>Apple пока что выезжает за счёт жёсткого ограничения фоновых процессов в ОС

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

C>Там где такие трюки не прокатывают из-за необходимости иметь фоновые real-time задачи — Apple опадает на землю и превращается в компост. Основной пример — собственно режим разговора:
C>Apple iPhone 5S — 8 часов
C>Galaxy S6 — 25 часов

GSM Arena с тобой не согласна:

http://www.gsmarena.com/apple_iphone_6s_plus-7243.php vs http://www.gsmarena.com/samsung_galaxy_s6-6849.php

[upd.] А стоп. Ты что-то там про 5S.

http://www.gsmarena.com/apple_iphone_5s-5685.php
Non-removable Li-Po 1560 mAh battery

http://www.gsmarena.com/samsung_galaxy_s6-6849.php
Non-removable Li-Ion 2550 mAh battery

Ну и вообще весьма показательно, что ты сравниваешь iPhone 5S, выпущенный в 2013-м году, с Samsung S6, выпущенным в 2015-м году.

Ведь не дай бог надо будет сравнить с iPhone'ом, выпущенном в 2015-м году. Ой, я сравнил. Выше, по ссылкам.

Здравствуйте, eskimo82, Вы писали:

VC>>всего 16 сопроцессоров? почему так мало?
E>RTFM. Наверно тебе должно быть стыдно что я произношу такие слова.

хорошо что напомнили про RTFM: https://ru.wikipedia.org/wiki/Сарказм

M>Зачем им big.little, если:
M>1. производительность у big.little в лучшем случае такая же, как у A9

Ты действительно не понимаешь? Big.little на производительность не влияет. Little выключен когда полная загрузка.

M>2. энергопотребление у Apple такое же, как у big.little

А это не факт. Где тесты? Ты надеюсь понимаешь что big.little может быть лучше только в определенных сценариях, и проблема разбивается на 2 части:
1. Тестовый сценарий. Например периодическая задача с относительно большими интервалами между активными фазами и малое количество вычислений в активной фазе.
2. Насколько сценарий часто случается на практике и готов ли софт.

Извини, но от тебя сплошные эмоции как обидели твой любимый аппл. От твой родственник что ли?

M>>2. энергопотребление у Apple такое же, как у big.little

G>А это не факт. Где тесты? Ты надеюсь понимаешь что big.little может быть лучше только в определенных сценариях, и проблема разбивается на 2 части:
G>1. Тестовый сценарий. Например периодическая задача с относительно большими интервалами между активными фазами и малое количество вычислений в активной фазе.
G>2. Насколько сценарий часто случается на практике и готов ли софт.

Кстати, вот Cyberax упоминал фоновые процессы. Как раз там big.little может себя показать. И если iOS избегает их, то аппл просто режет фунциональность и получает выгоду в потреблении.

И дело не в осилили или не осилили. Я считаю, что аппл просто выжидает как оно покажет себя. Они так постоянно делают, резкие рискованные изменения в устоявшемся продукте это не их стиль.

M>>Зачем им big.little, если:
M>>1. производительность у big.little в лучшем случае такая же, как у A9
G>Ты действительно не понимаешь? Big.little на производительность не влияет. Little выключен когда полная загрузка.

Тогда на что он влияет и для чего он нужен?

M>>2. энергопотребление у Apple такое же, как у big.little

G>А это не факт. Где тесты? Ты надеюсь понимаешь что big.little может быть лучше только в определенных сценариях

в каких?

G>Извини, но от тебя сплошные эмоции как обидели твой любимый аппл. От твой родственник что ли?

Извини, но эмоции пока только от людей, которые верещат (по другому назвать это не могу) про big.LITTLE и про то, как кто-то где-то что-то не осилил.

Засовывают его почти исключительно в мобильные процессоры. Поэтому выше я напримводил кучу ссылок на сравнение собственно мобильных

Что нужно от мобильного процессора? Производительность. Энергопотребление.

— по производительности big.LITTLE в лучшем случае на том же уровне
— по энергопотреблению все, что «неэмоциональные» оппоненты смогли осилить — это сравнить модель 2015-го года с моделью 2013 года с меньшим аккумулятором. При том, что в сравнении с прошлогодними моделями энергопотребление на том же уровне.



ЗЫ. На самом деле все упирается не в «осилили-не осилили», а в нормальную конкуренцию. big.LITTLE предлагает один подход, с комбинацией слабых и сильных ядер. Apple предлагает другой — с равнозначными ядрами.

C>Можешь ткнуть пальчиком в драйвер декодера для mp3 в ядре для Samsung Galaxy S5, например?
С таким говном не работаю, к счастью. Ты можеш взять любой корейский код — отличий будет мало.

Здравствуйте, eskimo82, Вы писали:

C>>Можешь ткнуть пальчиком в драйвер декодера для mp3 в ядре для Samsung Galaxy S5, например?
E>С таким говном не работаю, к счастью. Ты можеш взять любой корейский код — отличий будет мало.
Ну так где же там аппаратный декодер mp3?

Здравствуйте, Mamut, Вы писали:

M>Зачем им big.little, если:
M>1. производительность у big.little в лучшем случае такая же, как у A9
M>2. энергопотребление у Apple такое же, как у big.little
M>?
Не такое же.

A9 (да и любой другой CPU) почти не тратит энергию в режиме сна, но стоит только потребоваться запустить простенькую фоновую задачку — и батарейка утекает на глазах.

У нас есть устройство с правильным big.LITTLE и минимальной RTOS. Малое ядро следит за низкоскоростным, но при этом realtime потоком событий, большое ядро включается при необходимости тяжёлой обработки. Оно реально может работать неделями от небольшой батареи.

M>Ну и вообще весьма показательно, что ты сравниваешь iPhone 5S, выпущенный в 2013-м году, с Samsung S6, выпущенным в 2015-м году.
Ну значит в Android всё плохо внутри в текущих версиях. Вполне верю.

Здравствуйте, Cyberax, Вы писали:

C>Ну значит в Android всё плохо внутри в текущих версиях. Вполне верю.

У андроида, конечно, все плохо, но дело не только в этом. Основные сценарии телефона — работающий экран, который поедает больше чем CPU. Поэтому даже при идеальной работе ОС огромных выгод от сабжа не будет.

НС>Основные сценарии телефона — работающий экран, который поедает больше чем CPU.

Наоборот. Основной сценарий — выключенный экран, ожидание каких-то событий. Прихода e-mail, SMS, голосового вызова, включения экрана и т.п.. Это у большинства. Иначе только у отдельных индивидуумов, кто пялится в экран телефона по 2-3 часа в день.
Кстати, некоторые телефоны эту статистику покавают. Что сколько жрет. Например, телефоны Huawei. Вот прямо сейчас: с утра зарядил (было 100%). К вечеру осталось 74%. Из выжранных 26%:

* 42% скушало железо (14% — mobile standby, суть сотовая сеть, 14% WiFi, еще 12% — phone idle, и лишь 1.8% экран, хотя он был включен 1:19 минут!)
* 58% скушал софт (в основном firefox, garmin connect, google maps и почему-то CPU-Z — наверное, плохо написан)

C>У нас есть устройство с правильным big.LITTLE и минимальной RTOS.

Ахахахахаха. Классика. «У вас Линукс неправильный» ©

M>>Ну и вообще весьма показательно, что ты сравниваешь iPhone 5S, выпущенный в 2013-м году, с Samsung S6, выпущенным в 2015-м году.
C>Ну значит в Android всё плохо внутри в текущих версиях. Вполне верю.

Ну то есть мое утверждение остается верным: Apple'у big.LITTLE нафиг не сдался.

Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Ну значит в Android всё плохо внутри в текущих версиях. Вполне верю.
НС>У андроида, конечно, все плохо, но дело не только в этом. Основные сценарии телефона — работающий экран, который поедает больше чем CPU. Поэтому даже при идеальной работе ОС огромных выгод от сабжа не будет.
Даже в этом режиме big.LITTLE выгоден, если пользователь не совершает активных действий, а просто смотрит на страничку.

Но больше всего big.LITTLE выгоден для фоновых задач.

C>>>У нас есть устройство с правильным big.LITTLE и минимальной RTOS.
M>>Ахахахахаха. Классика. «У вас Линукс неправильный» ©
C>Так и iOS тоже неправильный. Сейчас никто нормально для общего случая его использовать не умеет. Для частного случая мы руками сделали переключение.

Внезапно до меня дошел весь цимес разговора.

Cyberax: big.LITTLE рулит, Apple просто не осилили
Mamut: Apple'у просто не нужно
Cyberax: Apple сосет на фоновых задачах, вот сравни Андроид 2015-го года с Айфоном 2013-го!
Mamut: Ну, вообще-то сравнивать надо с айфонами 2015-го года.
Cyberax: Ну, эта... А, вот. Андроид говно, они не умеют, а вот у нас есть специальная ОСЬ, в которой все работает, как надо!
Mamut: «У вас Линукс неправильный». Его пихают в мобильную сферу, а там он себя не показывает никак
Cyberax: его просто никто не умеет. «Правильный линукс», который у нас, тоже не умеет. Но мы сделали ручками!

В итоге возникает закономерные вопросы:
— нафига этот big.LITTLE вообще сдался, если, как оказалось, его вообще никто не умеет, а для каких-то сугубо частных случаев надо пилить руками
— к чему эти вопли про «Apple не осилили», если оказалось, что: a) не осилили вообще все и б) apple'у это просто не нужно (см. бенчмарки и т.п.)

Здравствуйте, Mamut, Вы писали:

M>- нафига этот big.LITTLE вообще сдался, если, как оказалось, его вообще никто не умеет, а для каких-то сугубо частных случаев надо пилить руками
M>- к чему эти вопли про «Apple не осилили», если оказалось, что: a) не осилили вообще все и б) apple'у это просто не нужно (см. бенчмарки и т.п.)

Яблоко работает в том же самом направлении, просто сделали более простое в разработке, но менее универсальное решение — М сопроцессор. BIG.little более универсален, но требует более сложной поддержки как в железе, так и со стороны софта.

НС>Яблоко работает в том же самом направлении, просто сделали более простое в разработке, но менее универсальное решение — М сопроцессор.

В итоге оно работает, рулит и бибикает.

НС>BIG.little более универсален, но требует более сложной поддержки как в железе, так и со стороны софта.

В итоге «никто не может реализовать правильно» ©



Так в чем выгода и применимость этого самого big.LITTLE?

Здравствуйте, Mamut, Вы писали:

НС>>Яблоко работает в том же самом направлении, просто сделали более простое в разработке, но менее универсальное решение — М сопроцессор.
M>В итоге оно работает, рулит и бибикает.

Знаешь, в свое время и PocketPC работал. Так что работает — фиговый аргумент. Мы же все таки инженеры в большинстве тут.

НС>>BIG.little более универсален, но требует более сложной поддержки как в железе, так и со стороны софта.
M>В итоге «никто не может реализовать правильно» ©

Это больше беда андроида — BIG.little до недавнего времени только в топовых процессорах был, да и то не во всех (у Qualcomm, к примеру, только в последней линейке он появился). Поэтому, ввиду фрагментации платформы, существенные доработки в ядре неторопливы.

M>Так в чем выгода и применимость этого самого big.LITTLE?

В том что он позволяет делать тоже самое, что эппловый М, но при этом не ограничен тем набором задач, на который М жестко захардкожен. Причем, потенциально, для этого софт переделывать во многих случаях не нужно, только железо и ОС.

M>>В итоге оно работает, рулит и бибикает.
НС>Знаешь, в свое время и PocketPC работал. Так что работает — фиговый аргумент. Мы же все таки инженеры в большинстве тут.

Я в курсе. Пока что «инжинеры» мне тут рассказывают про «неосилили»

НС>>>BIG.little более универсален, но требует более сложной поддержки как в железе, так и со стороны софта.
M>>В итоге «никто не может реализовать правильно» ©

НС>Это больше беда андроида — BIG.little до недавнего времени только в топовых процессорах был, да и то не во всех (у Qualcomm, к примеру, только в последней линейке он появился). Поэтому, ввиду фрагментации платформы, существенные доработки в ядре неторопливы.

In October 2011, big.LITTLE was announced along with the Cortex-A7, which was designed to be architecturally compatible with the Cortex-A15.[3] In October 2012 ARM announced the Cortex-A53 and Cortex-A57 (ARMv8-A) cores, which are also compatible with each other to allow their use in a big.LITTLE chip.[4] ARM later announced the Cortex-A12 at Computex 2013 followed by the Cortex-A17 in February 2014, both can also be paired in a big.LITTLE configuration with the Cortex-A7

Архитектуре уже 4 года.


M>>Так в чем выгода и применимость этого самого big.LITTLE?

НС>В том что он позволяет делать тоже самое, что эппловый М, но при этом не ограничен тем набором задач, на который М жестко захардкожен. Причем, потенциально, для этого софт переделывать во многих случаях не нужно, только железо и ОС.

Но при этом никто не знает, как его заставить это делать?

Здравствуйте, Mamut, Вы писали:

НС>>Знаешь, в свое время и PocketPC работал. Так что работает — фиговый аргумент. Мы же все таки инженеры в большинстве тут.
M>Я в курсе.

Раз в курсе, то не стоит подобные аргументы в техническом споре применять.

M>Архитектуре уже 4 года.

Ты понимаешь разницу между наличием в архитектуре и распространенностью в реальных чипах?

M>Но при этом никто не знает, как его заставить это делать?

Почему ты решил что никто не знает?

M>>Но при этом никто не знает, как его заставить это делать?
НС>Почему ты решил что никто не знает?

Ну вот рядом Cyberax это в итоге сказал прямым текстом

Здравствуйте, Mamut, Вы писали:

M>Ну вот рядом Cyberax это в итоге сказал прямым текстом

Можно цитату?

M>>- к чему эти вопли про «Apple не осилили», если оказалось, что: a) не осилили вообще все и б) apple'у это просто не нужно (см. бенчмарки и т.п.)
C>Станет ВНЕЗАПНО нужно уже скоро.

Ровно так.
Как это было с copy-and-paste и многозадачностью.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Mamut, Вы писали:

M>>Ну вот рядом Cyberax это в итоге сказал прямым текстом

НС>Можно цитату?

http://rsdn.ru/forum/flame.comp/6224639.1

Автор: Cyberax
Дата: 25.10.15

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

Здравствуйте, SkyDance, Вы писали:

SD>Ровно так.
SD>Как это было с copy-and-paste и многозадачностью.

Ой не факт. Всякие мелкие применения в Эппл традиционно обзовут ненужными, а если появится что то существенное они просто допилят М, благо и ОС и железо под их полным контролем.

SD>>Ровно так.
SD>>Как это было с copy-and-paste и многозадачностью.

НС>Ой не факт. Всякие мелкие применения в Эппл традиционно обзовут ненужными, а если появится что то существенное они просто допилят М, благо и ОС и железо под их полным контролем.

Можно ссылки на то, как Apple называли многозадачность и copy-paste ненужными?

M>>

M>>Сейчас никто нормально для общего случая его использовать не умеет. Для частного случая мы руками сделали переключение.

НС>Ты правда считаешь, что "не умеет" в этом контексте это тоже самое что "не знает"? Мне так кажется, что в данном случае "не умеет" означает "не реализовано", если что Cyberax поправит.

Скорее всего, комбинация того и другого.

Здравствуйте, Mamut, Вы писали:

SD>>>Ровно так.
SD>>>Как это было с copy-and-paste и многозадачностью.
НС>>Ой не факт. Всякие мелкие применения в Эппл традиционно обзовут ненужными, а если появится что то существенное они просто допилят М, благо и ОС и железо под их полным контролем.
M>Можно ссылки на то, как Apple называли многозадачность и copy-paste ненужными?

Да что ж такое то с навыками понимания прочитанного? Речь шла про big.LITTLE, а не про многозадачность и copy-paste.

SD>>>>Ровно так.
SD>>>>Как это было с copy-and-paste и многозадачностью.
НС>>>Ой не факт. Всякие мелкие применения в Эппл традиционно обзовут ненужными, а если появится что то существенное они просто допилят М, благо и ОС и железо под их полным контролем.
M>>Можно ссылки на то, как Apple называли многозадачность и copy-paste ненужными?

НС>Да что ж такое то с навыками понимания прочитанного? Речь шла про big.LITTLE, а не про многозадачность и copy-paste.

А да, сорри. Глаз просто зацепился за копипейст По поводу допиливания вполне согласен.

Здравствуйте, SkyDance, Вы писали:

C>>Станет ВНЕЗАПНО нужно уже скоро.
SD>Ровно так.
А с чего вдруг? Вот действительно не понимаю, чем это лучше какого-нибудь режима энергопотребления, когда будет включено только одно ядро на низкой частоте?

НС>Ой не факт. Всякие мелкие применения в Эппл традиционно обзовут ненужными

Уже не смогут. Нету у них Джобса, чтобы иконы ставить.
А Кук сотоварищи включился в общую игру в догонялки.

S>А с чего вдруг? Вот действительно не понимаю, чем это лучше какого-нибудь режима энергопотребления, когда будет включено только одно ядро на низкой частоте?

С того, что это наконец-то даст существенную фичу: выполнение фоновых задач.

Здравствуйте, Somescout, Вы писали:

S>А с чего вдруг? Вот действительно не понимаю, чем это лучше какого-нибудь режима энергопотребления, когда будет включено только одно ядро на низкой частоте?

С того что little ядро способно работать с выключенным экраном неделями на обычном современном смарте с типовой батарейкой.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>С того что little ядро способно работать с выключенным экраном неделями на обычном современном смарте с типовой батарейкой.

И с выключенным GSM? Очень типовое использование.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Somescout, Вы писали:

S>>А с чего вдруг? Вот действительно не понимаю, чем это лучше какого-нибудь режима энергопотребления, когда будет включено только одно ядро на низкой частоте?

НС>С того что little ядро способно работать с выключенным экраном неделями на обычном современном смарте с типовой батарейкой.

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

и сколько сколько недель оно проживет?

пока не померяете, сами понимаете.

Здравствуйте, SkyDance, Вы писали:

S>>А с чего вдруг? Вот действительно не понимаю, чем это лучше какого-нибудь режима энергопотребления, когда будет включено только одно ядро на низкой частоте?

SD>С того, что это наконец-то даст существенную фичу: выполнение фоновых задач.

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

Здравствуйте, VladCore, Вы писали:

VC>Может хватит фантазии писАть? Возмите уже самсунг S4 и старше с биг.литтл, включите пуш уведомления только на один почтовый ящик и отправляйте на него по письму раз в N часов.
VC>и сколько сколько недель оно проживет?
У нас примерно в таком же режиме на небольшой батарейку устройство как раз реально неделями живёт. Фоновое потребление реально можно сократить в несколько раз (у нас около 10 раз получилось).

Здравствуйте, Somescout, Вы писали:

SD>>С того, что это наконец-то даст существенную фичу: выполнение фоновых задач.
S>А режим энергосбережения какой-нибудь с отключением всех лишних ядер не даст такой возможности?
Нет, так как даже одно обычное ядро потребляет уже заметно.

S>Более того, о каких фоновых задачах вообще речь, которые использовали бы только процессор — без GPS, к примеру, и при этом постоянно?
Например, шагомер или распознаватель голосовых команд. Ещё производители для оптимизации расходов постепенно начинают постепенно выносить части LTE-стека из чистых ASIC'ов на LITTLE-ядра.

Здравствуйте, Mamut, Вы писали:

НС>>BIG.little более универсален, но требует более сложной поддержки как в железе, так и со стороны софта.
M>В итоге «никто не может реализовать правильно» ©
Пока не может. Фундаментальных проблем нет, просто задача нетривиальная и требующая рефакторинга нескольких сложных подсистем в Линксе.

S>А режим энергосбережения какой-нибудь с отключением всех лишних ядер не даст такой возможности?

Все равно это будет менее экономично.

S>Более того, о каких фоновых задачах вообще речь, которые использовали бы только процессор — без GPS, к примеру, и при этом постоянно?

GPS практически "бесплатен" с точки зрения ужора батарейки. Задачи — любые фоновые: начиная от фонового сбора данных о перемещениях владельца и заканчивая torrent'ами в бэкграунде.

Здравствуйте, Cyberax, Вы писали:

SD>>>С того, что это наконец-то даст существенную фичу: выполнение фоновых задач.
S>>А режим энергосбережения какой-нибудь с отключением всех лишних ядер не даст такой возможности?
C>Нет, так как даже одно обычное ядро потребляет уже заметно.
Цифры пожалуйста.

S>>Более того, о каких фоновых задачах вообще речь, которые использовали бы только процессор — без GPS, к примеру, и при этом постоянно?
C>Например, шагомер или распознаватель голосовых команд.
Принимается, хотя цифры всё ещё интересны.

Здравствуйте, SkyDance, Вы писали:

S>>А режим энергосбережения какой-нибудь с отключением всех лишних ядер не даст такой возможности?
SD>Все равно это будет менее экономично.
"Верую ибо нелепо"?

SD>GPS практически "бесплатен" с точки зрения ужора батарейки.
Цифры.

SD>Задачи — любые фоновые: начиная от фонового сбора данных о перемещениях владельца и заканчивая torrent'ами в бэкграунде.
"заканчивая torrent'ами в бэкграунде" на фоне работы с сетью, особенно с сотовой, выйгрыш от мелкого ядра будет выглядеть бледно.

Здравствуйте, SkyDance, Вы писали:

S>>Цифры.

SD>4-6 mA в режиме 1 Гц, и что-то совсем микроскопическое при фиксе раз в минуту.

SD>Тот же MTK M5 в часах Garmin (ЕМНИП 350 мАч батарейка) работает с непрерывной записью и показом кучи параметров на экране в течение 20 часов при 1 Гц записи, и до 60 часов при записи раз в минуту.
Я не знаю это устройство, оно работает с сетью, или просто опрашивает датчики, сохраняет и выводит данные на экран?

SD>Я больше про WiFi. Но также постоянная синхронизация с BTLE устройствами или ANT+ датчиками.

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

Куда более реальное применение (как отметил Cyberax) — непрерывное распознавание голоса, тут да, нужна постоянная обработка данных, и отдельный DSP не бесполезен. Хотя, имхо, нужно смотреть как это всё в итоге смогут реализовать, ведь в принципе тот же intel, отключающий лишние ядра и кэш процессора понижают энергопотребление в несколько десятков раз, а на реальном телефоне при таком одна только работа с базовыми станциями сделает дальнейшее уменьшение потребление не заметным. И, опять же, смотреть нужно на реальные сценарии использования и какой в них будет выйгрыш.

Здравствуйте, Somescout, Вы писали:

S>>>А режим энергосбережения какой-нибудь с отключением всех лишних ядер не даст такой возможности?
C>>Нет, так как даже одно обычное ядро потребляет уже заметно.
S>Цифры пожалуйста.
На нашем железе целиком разница получается в 5 раз по сравнению с просто big-процессором, который работает урывками. Причём основное питание уже съедает периферия, т.е. в самом процессоре оптимизировать уже почти нечего.

Здравствуйте, Somescout, Вы писали:

SD>>GPS практически "бесплатен" с точки зрения ужора батарейки.
S>Цифры.
Современные GPS-модули — около 10-20 миллиампер.

Здравствуйте, Somescout, Вы писали:

НС>>С того что little ядро способно работать с выключенным экраном неделями на обычном современном смарте с типовой батарейкой.
S>И с выключенным GSM?

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

Здравствуйте, VladCore, Вы писали:

НС>>С того что little ядро способно работать с выключенным экраном неделями на обычном современном смарте с типовой батарейкой.
VC>Может хватит фантазии писАть?

Это правда.

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

Тут же уже неоднократно писали — андроед пока что всю малину портит.

Здравствуйте, Somescout, Вы писали:

S>А режим энергосбережения какой-нибудь с отключением всех лишних ядер не даст такой возможности?

Не даст. Разница между BIG и little ядром по ужору — в разы.

S> Более того, о каких фоновых задачах вообще речь

https://en.wikipedia.org/wiki/Apple_motion_coprocessors