Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Например, тогда были такие "светлые будущие":
S>Так transmeta тож ничего не представляла похожего на big.little. Пик — одноядерный Crusoe — не прожил и двух лет емнип и был медленней даже чипов от via. Вдвое.
S>Кроме того, речь про S>
VC>>>Ну и зачем этот big.LITTLE?
W>>Интел делала подобные прототипы еще лет 15 назад.
при чём тут transmeta?
похоже никто не в курсе что big.LITTLE на языке домохозяек — это типа Core i7 и одноядерный atom на одном чипе. Одновременно только один работает.
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, и потому банально проще его воткнуть.
C>Вполне возможно, что там какой-нибудь пост-процессинг. Причём часто бывает, что современные CPU вполне себе нормально считают его сами по себе, но уже есть 100500 тонн ассемблерного кода для DSP, и потому банально проще его воткнуть.
Там еще иногда оказывается, что меньше батарейку и жрет если иметь слабый CPU и еще DSP, чем один большой CPU.
Плюс real-time проще, чем когда один CPU, а он нужен когда это например много спикеров.
Ну а с handset и mp3 это все конечно не нужно.
Re[12]: big.LITTLE vs Понижение частоты процессора
_>Не люблю обсуждать людей за их спиной, но не я первый начал. _>Он вообще заявил что биг-литл не нужен, но зато у нас есть какие-то А и М, соединенные тоненькими проводами. По мне это те же яйца, только в профиль.
Не то же
_>По мне, просто не осилили биг-литл
В пятый раз повторю: big.little им не нужен. Почему он им не нужен, см. в моих сообщениях.
_>, и при проектирования железа, и на уровне софта. Решили сэкономить на всяких лицензиях, пусть лучше другие раскошеливаются на закругленные углы. Сами не смогли, а чужое взять гордость "эффективных манагеров" мешает. Но пипл хавает.
Ты продолжаешь что-то вещать про «не осилили» при том, что есть объективная реальность: максимум, что может сделать big.little, это с трудом догнать ядра Apple'а по производительности. И то, для того, чтобы догнать два ядра по производительности, им нужно восемь ядер.
И да. Производительность + энергопотребление — это ровно то, зачем нужны процессоры.
_>Я не понимаю, ты не понимаешь зачем нужен биг-литл или тебя точно кто-то покусал.
Нет. Я не понимаю, зачем нужен big.little. Вернее, я понимаю, что он нужен людям, которые не осилили сделать нормальные ядра.
Здравствуйте, Mamut, Вы писали:
_>>По мне, просто не осилили биг-литл M>В пятый раз повторю: big.little им не нужен. Почему он им не нужен, см. в моих сообщениях.
А что, у Apple какая-то особенная, уличная магияфизика?
Ещё как он им нужен, но они ниасилили пока что его сделать. У Apple A9 примерно такое же потребление, как и у больших ядер Samsung'ов.
Apple пока что выезжает за счёт жёсткого ограничения фоновых процессов в ОС — большую часть времени в режиме ожидания процессор выключен от слова "совсем". Даже для фоновых загрузок трафик буферизуется в аппаратных кольцах сетевой карты (прмиерно до 2 секунд времени в обычном режиме).
Там где такие трюки не прокатывают из-за необходимости иметь фоновые real-time задачи — Apple опадает на землю и превращается в компост. Основной пример — собственно режим разговора:
Apple iPhone 5S — 8 часов
Galaxy S6 — 25 часов
"Почуствуй разницу" (тм)
Sapienti sat!
Re[14]: big.LITTLE vs Понижение частоты процессора
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 часов
M>Зачем им big.little, если: M>1. производительность у big.little в лучшем случае такая же, как у A9
Ты действительно не понимаешь? Big.little на производительность не влияет. Little выключен когда полная загрузка.
M>2. энергопотребление у Apple такое же, как у big.little
А это не факт. Где тесты? Ты надеюсь понимаешь что big.little может быть лучше только в определенных сценариях, и проблема разбивается на 2 части:
1. Тестовый сценарий. Например периодическая задача с относительно большими интервалами между активными фазами и малое количество вычислений в активной фазе.
2. Насколько сценарий часто случается на практике и готов ли софт.
Извини, но от тебя сплошные эмоции как обидели твой любимый аппл. От твой родственник что ли?
Re[16]: big.LITTLE vs Понижение частоты процессора
M>>2. энергопотребление у Apple такое же, как у big.little
G>А это не факт. Где тесты? Ты надеюсь понимаешь что big.little может быть лучше только в определенных сценариях, и проблема разбивается на 2 части: G>1. Тестовый сценарий. Например периодическая задача с относительно большими интервалами между активными фазами и малое количество вычислений в активной фазе. G>2. Насколько сценарий часто случается на практике и готов ли софт.
Кстати, вот Cyberax упоминал фоновые процессы. Как раз там big.little может себя показать. И если iOS избегает их, то аппл просто режет фунциональность и получает выгоду в потреблении.
И дело не в осилили или не осилили. Я считаю, что аппл просто выжидает как оно покажет себя. Они так постоянно делают, резкие рискованные изменения в устоявшемся продукте это не их стиль.
Re[16]: big.LITTLE vs Понижение частоты процессора
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?
Sapienti sat!
Re[15]: big.LITTLE vs Понижение частоты процессора
Здравствуйте, 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 всё плохо внутри в текущих версиях. Вполне верю.
Sapienti sat!
Re[16]: big.LITTLE vs Понижение частоты процессора
Здравствуйте, Cyberax, Вы писали:
C>Ну значит в Android всё плохо внутри в текущих версиях. Вполне верю.
У андроида, конечно, все плохо, но дело не только в этом. Основные сценарии телефона — работающий экран, который поедает больше чем CPU. Поэтому даже при идеальной работе ОС огромных выгод от сабжа не будет.
