Здравствуйте, VladCore, Вы писали:
VC>>>о том и речь. в аппле нет таких извратов. там посчитали что не нужен, но вы предложите вашу идею куку.
_>>Если в эппле куку-инженьёры, не могут запилить в ядре открыто сворованной ОС поддержку несимметричной многопроцессорности, то известно кто "не нужен". В андроиде, что на линухе, биг-литл рабтает искаробки.
VC>Тяжело с вами дискутировать. Apple "своровал" ядро у стива джобса. точнее его некста.
VC>см. икона и став джобс. это названия книжек.
Микроядро Mach не свое, наняли команду, за одно и код прихватизировали. При этом Мащ — это слегка доработанный БСД. Сетевой стек, ввод-вывод и другие системно важные модули прихватизированs из БСД систем. Грубо, свое там только ОбжектСи. И Джобс там только как эффективный менеджер, без кавычек и искажений.
VC>>о том и речь. в аппле нет таких извратов. там посчитали что не нужен, но вы предложите вашу идею куку. _>Если в эппле куку-инженьёры, не могут запилить в ядре открыто сворованной ОС поддержку несимметричной многопроцессорности, то известно кто "не нужен".
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.
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.
Пошло сравнение теплого с мягким. Меряем скорость, когда разговор идет про экономичность. При этом этот андроид работает как виртуальная машина Жабы.
Здравствуйте, 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, больше гигагерц и всё в таком духе. Про "производительность на ватт" стали вспоминать слегка попожже
Здравствуйте, Mamut, Вы писали:
_>>А теперь научи эту древнюю асимметрию, которая не могла симметрию в гомогенных системах, правильной асиметрии в гетерогенной системе.
M>Я тебя не понял.
Это нормально.
_>>>>В андроиде, что на линухе, биг-литл рабтает искаробки.
_>>Пошло сравнение теплого с мягким. Меряем скорость, когда разговор идет про экономичность. При этом этот андроид работает как виртуальная машина Жабы.
M>Ты опять говоришь загадками. Говорю просто и по-русски: Apple'у big.little нафиг не вперся, потому что они прекрасно умеют делать полноценные высокопроизводительные ядра. Максимум, на что способен big.little — это быть может догнать яблочные ядра по производительности (и то, если взять 8 big.little ядер против двух яблочных).
Вообще-то, это я тебя не понимаю. Зачем ты требуешь от биг-литла высокую производительность? Если тебе нужна производительность, тебе точно не нужен литл, бери только биг. А лучше кластер из 2^N GPU.
Re[10]: big.LITTLE vs Понижение частоты процессора
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 назад.
VC>Что бы играть музыку в плейере или "слушать" новые push/mail сообщения, достаточно же частоту уменьшить в 3-N раз, а не совать в чип лишние ядра/транзисторы.
Феерический бред. ARM позволяет иметь до 16 сопроцессоров в том числе и DSP.
"Музыка в плееере" обрабатывается своим DSP, векторные вычисления — другим сопроцессором, когда сопроцессор ничего не делает то и #почтиничегонежрет.
PS: Сопроцессор это именно сопроцессор, а не "ядро", хотя может находится на одном кристале вместе с CPU. Ядра же считаются отдельно.
Здравствуйте, Pzz, Вы писали:
VC>>Ну и зачем этот big.LITTLE? Pzz>Я вот тоже не могу понять. Конечно, медленный процессор жрет меньше, но и думает дольше. Непонятно, почему быстрее прокрутить задачу на быстром процессоре получается выгоднее, чем дольше на медленном.
Переключение большого процессора из режима сна в активный режим не происходит мгновенно.
Sapienti sat!
Re[11]: big.LITTLE vs Понижение частоты процессора
Здравствуйте, 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. Ядра же считаются отдельно.
вы уверены в том что такое сопроцессор, тогда не плохо для начала.
Re[10]: big.LITTLE vs Понижение частоты процессора
_>Вообще-то, это я тебя не понимаю. Зачем ты требуешь от биг-литла высокую производительность?
не хочу обдеть, но big.LITTLE ортогональна производительности.
_>Если тебе нужна производительность, тебе точно не нужен литл, бери только биг. А лучше кластер из 2^N GPU.
вообщето Mamut похоже заколебался писать что наилучшая производительность при хорошем энергопотреблении без big.LITTLE процветает. у надкушенных яблок.
