https://www.ifixit.com/News/46884/m1-macbook-teardowns-something-old-something-new
Память не упакована прямо в чип, там четко видно две отдельных микросхемы памяти на подложке с чипом и можно даже посмотреть на маркировку и известно, что там LPDDR4X на 4233 МГц. То есть конечно она не медленная, но и ничего выдающегося и очень быстрого.
При этом можно заметить что все тесты в которых проблемы работают под Розеттой (но о чем в статье естественно не сказано, что есть серьезная проблема для таких обзоров). А если поискать информацию (тестов влияние розетты мало, к сожалению, я знаю только такой https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested/6) то можно увидеть что эмулятор хоть и хрошо в среднем работает, но есть задачи где просадка по скорости в 2+ раза.
На утверждения вида «которые уже не раз ловили на манипуляциях цифрами» можно же конечно увидеть пруфы? Потому что я, например, не слышал ни одного случая когда уважаемый бенчмарк так поступал (в данном случаи из статьи — geekbench).
К тому же не все бенчмарки в статье закрытые, тот же JetStream публикует исходный код своих тестов (а также так как он на js, всегда можно посмотреть что конкретно исполняется).
Касательно проблем с GPU тестами — в идеале надо смотреть на перцентили fps хотя бы или записывать frame render time для каждого кадра и анализировать эти результаты уже. Но тут я сомневаюсь, что под osx есть соответствующий туллинг, к тому же OpenGL под osx уже давно официально не обновляется и не рекомендуется к использованию (то есть баги там никто фиксить не будет) и запускать тесты 2012 года выпуска — ну такая себе идея на мой взгляд.
С FreeBSD не так просто все и говорить «основана на FreeBSD» не совсем корректно. От БСД взяли некоторую часть рантайма, который с тех пор методично переписывался по чуть-чуть и сейчас на BSD уже не очень похож.
Браузерные тесты вполне себе рассказывают что делают (в этой статье, например, приводили тесты интерпретации javascript'а, а не рисования графики). Также как это делают и стандартные бенчмарки, которые при наилчии специфических оптимизаций просто потеряют всю репутацию и источник заработка, поэтому так никто делать не будет. Final Cut — тут да, тут в общем смысл как раз в том что они должны оптимизировать под железо себя. Photoshop — в теории согласен, на практике Adobe так себе в это все умеет и на простые оптимизации под популярное железо они тратят годы...
Так что все это не более чем теория заговора, не выдерживающая никакой критики.
Примерно знаем — в начале лета, если разработчик готов был заплатить (DevKit который на A12Z). У очень крупных разработчиков возможно было чуть-чуть больше времени, но количество нативного софта говорит о том что все были в равных условиях.
И я уже говорил выше, проблема гипотезы про использование GPU в том, что GPU эффективно выполняют только малый класс задач и при наличии ручной оптимизации так сказать (по сути писать отдельный код, использующий GPU для задачи), а ощутимый прирост по тестам показан по всем задачам (см. тот же гикбенч)
Этот вылизанный браузер основан на вполне себе опенсорсном webkit'е и традиционно звезд с неба не хватает на тех же интелах.
Ну к тому же это в данной статье брали стандартные популярные бенчмарки, в других статьях брали приземленные вещи типа компилятора (притом не эплового варинта) и там картина та же самая.
Да и популярные бенчмарки как бы тоже намекают что никаких такого рода оптимизаций нет.
И к тому же с оптимизацией под GPU дело в том, что не любые задачи на нее хорошо ложатся, мягко говоря не любые (например браузеры — из рук вон плохо)
Не только в частоте дело, но и в архитектуре. Вот Cortex A53 — тоже RISC'и, даже те же ARMv8, но что-то они медленее да в общем даже Atom'ов равночастотных. А ну и конечно можно посмотреть на разные поколения x86 работающие на одниаковых частотах, но почему-то сильно отличающиеся по производительности :)
Эта гипотеза конечно звучит хорошо, но к сожалению нельзя просто взять произвольную задачу и переложить ее на встроенный GPU — слишком разные архитектуры, слишком сложно с точки зрения компилятора определить места когда накладные расходы будут того стоить и так далее и тому подобного.
По сути автор приложения должен сам решать в какой момент это надо и в каком объеме.
Ну смотри — кнопки так или иначе дергают скрипты, это все еще надо как-то отрендерить чтобы показать, а еще картинки и всякое такое. И это только то что напрямую влияет.
Отдельно есть много интересного о том, как работает выделение памяти в приципе.
Если упрощенно, то простой подход с выделением каждого байта через ядро ОС — дорого и бессмыслено и так не делают, потому что:
1. На каждый такой запрос произойдет переключение контекста, притом дважды, а это не самая быстрая операция, так как по сути надо будет сохранить состояние процесса, дать управление ядру, ядро там посмотрит что есть свободного и вернет управление процессу, восстановив его состояние. А состояние это значение всех регистров,.
2. Если процесс пришел с запросом «вот тут у меня был кусок памяти под массив, а я хочу чтоб массив стал вдвое больше», то придется копировать куски памяти, так просто довыделить память нельзя
Поэтому на практике делают более сложные механизмы работы с памятью. Например популярным подходом является аллокатор памяти, который у ОС запрашивает сразу много памяти, которую потом нарезает на более маленькие кусочки и когда процессу надо — отдает ближайший по размеру кусочек. При следующих обращениях от этого же процесса, аллокатор постарается дать память из нарезанного. Если нужного размера блоков больше нет, то он попросит у ОС еще кусок, нарежет его, и будет выделять память из того что есть теперь (в умном случаи аллокатор может попытаться перенарезать оставшиеся невыделенные блоки, но это не так важно).
Проблема в том, что тут нужен баланс между скоростью работы и количеством памяти которую не очень получается использовать: чем реже мы ходим за новой памятью тем лучше, но тем больше мы будем выделять ее за раз и больше будем терять, а также любые механизмы перенарезания памяти — естественно не бесплатные, но если так не делать совсем, то у ОС будет запрошено и получено много памяти, а по факту она будет использоваться не полностью. Впрочем в реальности все еще сложнее, это лишь очень упрощенное объяснение.
За подробным объяснениями можно сходить например сюда: https://habr.com/ru/post/473294/
LLVM — открытый проект, можно взять и посмотреть что там внутри и как оптимизировано :)
Касательно GPU — ну на самом деле нет, он на словах где-то равен младшим-средним ноутучным дискреткам от AMD/nVidia и на деле по тестам примерно этому соответствует. На anandtech довольно неплохой анализ на базе того что сейчас известно: https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested/3 — там в том числе погоняли некоторые игры через эмулятор.
Касательно x86 и частоты — это слишком большое упрощение и даже в истории x86 есть куча примеров когда процессор на более высокой частоте проигрывал процессору на более низкой (P4 vs AMD Ahtlon XP и позже Athlon 64 — как простой пример). Ну или даже посмотрите на текущие Core i и Ryzen'ы или разницу между поколениями Ryzen'ов :)
У nvidia, amd и intel давно есть аппаратные блоки декодирования и кодирования видео. У первых это nvdec/nvenc (соответственно), у вторых — vcn, у третьих — Quick Sync Video.
И я бы советовал относится чуть более скептически к высказываниям MrTO и как минимум фактически проверять его утверждения.
То есть по-вашему Эппл в процессоры запихнула железную оптимизацию под компиляторы? (в статье есть скриншотик LLVM сборки софта, а также был известный твитт от человека, у которого новый макбук собирал софт на rust'е быстрее чем 6-и ядерный ноутбучный i7)
p.s. в cinebench надеюсь вы также про оригинальную статью, на которую этот пост ссылается, а не про выдумку который распространяли пару дней назад? (где взяли DevKit на A12Z и выдали его за результаты на M1)
Не совсем так уже давно. Есть простой ответ в FAQ: https://www.intel.com/content/www/us/en/support/articles/000005597/processors.html
«Could my processor get damaged from overheating?
It's unlikely that a processor would get damaged from overheating, due to the operational safeguards in place. Processors have two modes of thermal protection, throttling and automatic shutdown. When a core exceeds the set throttle temperature, it will reduce power to maintain a safe temperature level. The throttle temperature can vary by processor and BIOS settings. If the processor is unable to maintain a safe operating temperature through throttling actions, it will automatically shut down to prevent permanent damage. „
Более подробно механизм описан в datasheet'ах.
Если вкратце — при превышении определенной температуры будет идти сброс частот (переход в более расслабленные режимы по мощности, сопровождаемый сбросом частот), а если и это не помогло и частота минимально возможная — будет пропуск тактов и позже выключение если и пропуск тактов не помог.
Только пропуск тактов был достаточно давно, кажется во времена P3/P4 и Core 2, а с приходом ранних Core i и Turbo Boost'а появился вот такой более веселый механизм защиты от перегрева.
А да, throttling еще бывает не только Thermal но и Power и у макбуков, как минимум у больших, именно мощность зарезана, а по температуре им достаточно ок (вот человеку, у кого они на коленях — не ок)
Перефразируя тебя: погугли.
Но вообще у меня есть Macbook Pro 15" 2018 года, я на нем собирал софт, где-то часа 4 к ряду и все это время он держал на всех ядрах частоту на 100 МГц больше базовой :)
Опять же, как ты любишь говорить: погугли. Эпл и интел отвечали пару лет назад как раз о таком вопросе. Просто макбук и макбук эир имели очень низкие базовые частоты.
А про «longer» такая штука что если написать «бесконечно», а потом вдруг окажется что не бесконечно (например устройство умрет через несколько лет такой работы), то будет судебный иск :) А с Longer — трактовка на усмотрение юристов.
Можно сравнить и сейчас, через другие их устройства, которые есть в тесте же, правда только для тестов что общие.
А так — ждем еще тестов от других обозревателей.
И тем не менее. Надо осознавать что boost частоты это не обязательно те частоты, на которых проц будет работать :)
Ну и там от ноута зависит, диапазоны от, кажется, 1.1 до 2.6, чтоб совсем честными быть
В данном случаи не так важно мы говорим про ноут или мак про. Если ты включишь требование размера то у тебя опций с таким же железом будет не то чтобы много и не то, чтобы сильно отличающихся по цене (тут уже другой вопрос почему для десктопа важен размер).
Ну и про троттлинг тоже фактически не правда. По определению Интела троттлинг это неспособность держать базовую частоту, а на базовую они (как и все тонкие ноуты) вполне способны, вот буст по сути на 1 ядро только, это увы да. И к тому же новые макбуки про на М1 как раз (судя по этой новости) не троттлят вообще.
Маки дойдут до других людей и будут сравнения по разным задачам, в том числе с деллами. Но секрет в том, что у ноутов похожей на старые маки конфигурации +- похожая производительность.
А пока косвенно можно косвенные сравнения делать, например найти похожую на интересную задачу на новом M1 и сравнение ее со старым Macbook Pro 16" а потом найти сравнение той же модели Macbook Pro 16" с каким-нибудь другим ноутом.
Хотя другой вопрос — а с чего в одной задаче будет какая-то принципиальная разница между макбуком на интеле и другим сопоставимым ноутом на интеле?
Память не упакована прямо в чип, там четко видно две отдельных микросхемы памяти на подложке с чипом и можно даже посмотреть на маркировку и известно, что там LPDDR4X на 4233 МГц. То есть конечно она не медленная, но и ничего выдающегося и очень быстрого.
На утверждения вида «которые уже не раз ловили на манипуляциях цифрами» можно же конечно увидеть пруфы? Потому что я, например, не слышал ни одного случая когда уважаемый бенчмарк так поступал (в данном случаи из статьи — geekbench).
К тому же не все бенчмарки в статье закрытые, тот же JetStream публикует исходный код своих тестов (а также так как он на js, всегда можно посмотреть что конкретно исполняется).
Касательно проблем с GPU тестами — в идеале надо смотреть на перцентили fps хотя бы или записывать frame render time для каждого кадра и анализировать эти результаты уже. Но тут я сомневаюсь, что под osx есть соответствующий туллинг, к тому же OpenGL под osx уже давно официально не обновляется и не рекомендуется к использованию (то есть баги там никто фиксить не будет) и запускать тесты 2012 года выпуска — ну такая себе идея на мой взгляд.
Браузерные тесты вполне себе рассказывают что делают (в этой статье, например, приводили тесты интерпретации javascript'а, а не рисования графики). Также как это делают и стандартные бенчмарки, которые при наилчии специфических оптимизаций просто потеряют всю репутацию и источник заработка, поэтому так никто делать не будет. Final Cut — тут да, тут в общем смысл как раз в том что они должны оптимизировать под железо себя. Photoshop — в теории согласен, на практике Adobe так себе в это все умеет и на простые оптимизации под популярное железо они тратят годы...
Так что все это не более чем теория заговора, не выдерживающая никакой критики.
И я уже говорил выше, проблема гипотезы про использование GPU в том, что GPU эффективно выполняют только малый класс задач и при наличии ручной оптимизации так сказать (по сути писать отдельный код, использующий GPU для задачи), а ощутимый прирост по тестам показан по всем задачам (см. тот же гикбенч)
Ну к тому же это в данной статье брали стандартные популярные бенчмарки, в других статьях брали приземленные вещи типа компилятора (притом не эплового варинта) и там картина та же самая.
Да и популярные бенчмарки как бы тоже намекают что никаких такого рода оптимизаций нет.
И к тому же с оптимизацией под GPU дело в том, что не любые задачи на нее хорошо ложатся, мягко говоря не любые (например браузеры — из рук вон плохо)
По сути автор приложения должен сам решать в какой момент это надо и в каком объеме.
Отдельно есть много интересного о том, как работает выделение памяти в приципе.
Если упрощенно, то простой подход с выделением каждого байта через ядро ОС — дорого и бессмыслено и так не делают, потому что:
1. На каждый такой запрос произойдет переключение контекста, притом дважды, а это не самая быстрая операция, так как по сути надо будет сохранить состояние процесса, дать управление ядру, ядро там посмотрит что есть свободного и вернет управление процессу, восстановив его состояние. А состояние это значение всех регистров,.
2. Если процесс пришел с запросом «вот тут у меня был кусок памяти под массив, а я хочу чтоб массив стал вдвое больше», то придется копировать куски памяти, так просто довыделить память нельзя
Поэтому на практике делают более сложные механизмы работы с памятью. Например популярным подходом является аллокатор памяти, который у ОС запрашивает сразу много памяти, которую потом нарезает на более маленькие кусочки и когда процессу надо — отдает ближайший по размеру кусочек. При следующих обращениях от этого же процесса, аллокатор постарается дать память из нарезанного. Если нужного размера блоков больше нет, то он попросит у ОС еще кусок, нарежет его, и будет выделять память из того что есть теперь (в умном случаи аллокатор может попытаться перенарезать оставшиеся невыделенные блоки, но это не так важно).
Проблема в том, что тут нужен баланс между скоростью работы и количеством памяти которую не очень получается использовать: чем реже мы ходим за новой памятью тем лучше, но тем больше мы будем выделять ее за раз и больше будем терять, а также любые механизмы перенарезания памяти — естественно не бесплатные, но если так не делать совсем, то у ОС будет запрошено и получено много памяти, а по факту она будет использоваться не полностью. Впрочем в реальности все еще сложнее, это лишь очень упрощенное объяснение.
За подробным объяснениями можно сходить например сюда: https://habr.com/ru/post/473294/
Касательно GPU — ну на самом деле нет, он на словах где-то равен младшим-средним ноутучным дискреткам от AMD/nVidia и на деле по тестам примерно этому соответствует. На anandtech довольно неплохой анализ на базе того что сейчас известно: https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested/3 — там в том числе погоняли некоторые игры через эмулятор.
Касательно x86 и частоты — это слишком большое упрощение и даже в истории x86 есть куча примеров когда процессор на более высокой частоте проигрывал процессору на более низкой (P4 vs AMD Ahtlon XP и позже Athlon 64 — как простой пример). Ну или даже посмотрите на текущие Core i и Ryzen'ы или разницу между поколениями Ryzen'ов :)
И я бы советовал относится чуть более скептически к высказываниям MrTO и как минимум фактически проверять его утверждения.
p.s. в cinebench надеюсь вы также про оригинальную статью, на которую этот пост ссылается, а не про выдумку который распространяли пару дней назад? (где взяли DevKit на A12Z и выдали его за результаты на M1)
«Could my processor get damaged from overheating?
It's unlikely that a processor would get damaged from overheating, due to the operational safeguards in place. Processors have two modes of thermal protection, throttling and automatic shutdown. When a core exceeds the set throttle temperature, it will reduce power to maintain a safe temperature level. The throttle temperature can vary by processor and BIOS settings. If the processor is unable to maintain a safe operating temperature through throttling actions, it will automatically shut down to prevent permanent damage. „
Более подробно механизм описан в datasheet'ах.
Если вкратце — при превышении определенной температуры будет идти сброс частот (переход в более расслабленные режимы по мощности, сопровождаемый сбросом частот), а если и это не помогло и частота минимально возможная — будет пропуск тактов и позже выключение если и пропуск тактов не помог.
Только пропуск тактов был достаточно давно, кажется во времена P3/P4 и Core 2, а с приходом ранних Core i и Turbo Boost'а появился вот такой более веселый механизм защиты от перегрева.
А да, throttling еще бывает не только Thermal но и Power и у макбуков, как минимум у больших, именно мощность зарезана, а по температуре им достаточно ок (вот человеку, у кого они на коленях — не ок)
Но вообще у меня есть Macbook Pro 15" 2018 года, я на нем собирал софт, где-то часа 4 к ряду и все это время он держал на всех ядрах частоту на 100 МГц больше базовой :)
Опять же, как ты любишь говорить: погугли. Эпл и интел отвечали пару лет назад как раз о таком вопросе. Просто макбук и макбук эир имели очень низкие базовые частоты.
А про «longer» такая штука что если написать «бесконечно», а потом вдруг окажется что не бесконечно (например устройство умрет через несколько лет такой работы), то будет судебный иск :) А с Longer — трактовка на усмотрение юристов.
А так — ждем еще тестов от других обозревателей.
Ну и там от ноута зависит, диапазоны от, кажется, 1.1 до 2.6, чтоб совсем честными быть
Ну и про троттлинг тоже фактически не правда. По определению Интела троттлинг это неспособность держать базовую частоту, а на базовую они (как и все тонкие ноуты) вполне способны, вот буст по сути на 1 ядро только, это увы да. И к тому же новые макбуки про на М1 как раз (судя по этой новости) не троттлят вообще.
А пока косвенно можно косвенные сравнения делать, например найти похожую на интересную задачу на новом M1 и сравнение ее со старым Macbook Pro 16" а потом найти сравнение той же модели Macbook Pro 16" с каким-нибудь другим ноутом.
Хотя другой вопрос — а с чего в одной задаче будет какая-то принципиальная разница между макбуком на интеле и другим сопоставимым ноутом на интеле?