Тут правильнее посмотреть по тестам. Есть M1 который в однопотоке в тестах потребляет порядка 15 Вт (Mac Mini) в пике (вся железка целиком, так как замеры на уровне розетки). Есть с другой стороны Ryzen 5950X который на строго однопоточной нагрузке потребляет 49 Вт (цпу целиком, включая кэш, I/O Die и т.п.) при этом по синетическим тестам они показывают сопоставимую производительность в однопоточном режиме.
Так то да, можно сделать энергоэффективный ноутбук на интелах или амдшках, который будет жить долго, но только в ряде тестов M1 показывает примерно втрое более лучшую производительность на Ватт. Поэтому он сейчас так и привлек внимание людей.
На Anandtech'е разбор достаточно подробный именно в плане низкоуровневых тестов. Чуть больше теоретических деталей было в статье где анализировали A14: https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2
И если им верить, то у Apple просто очень жирный процессор во всем — много кэша, жирный декодер, много АЛУ, большой Reorder Buffer и просто в целом хорошо спроектирован он (задержки кэшей лучше чем у x86, например, при большем их размере, что достаточно сложно получить). И никакой в общем-то магии.
Правда все это базируется на анализе кучи тестов, так как эпл детали про микроархитектуру не публикует.
На это тоже есть ответ: https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested
График в секции «Memory Differences». Для RAM там 90 с небольшим ns в full random против ~80 у Zen 3 или ~70 у i9-10900k при использовании стандартной DDR4-3200 CL15 (из статей с того же anandtech)
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 — слишком разные архитектуры, слишком сложно с точки зрения компилятора определить места когда накладные расходы будут того стоить и так далее и тому подобного.
По сути автор приложения должен сам решать в какой момент это надо и в каком объеме.
У 3090 а 1 фазу больше, потому что чипов памяти больше, поэтому конфигурация питания памяти чуть-чуть другая и требует +1 фазу.
Эти данные обычно берутся либо из пресс-релизов (если там указано), либо народ по дорожкам смотрит куда и от каких мосфетов они идут.
p.s. и да, у палита их 17. Там 14 на GPU и 3 на Memory, но одну фазу многие обзорщики упустили потому что она повернута на 90 градусов )
Вот играешь ты в игру, у тебя FPS обычно не статичен, а колеблется в каких-то пределах. Фактически при тестировании снимаешь множество точек (пусть будет раз в секунду в течении тестового прогона), а затем находишь среди всех значий такой ФПС, чтобы он был больше 0.1% только (или по другому — чтобы 99.9% всех остальных значений были больше этого). Также с 1% low. По сути замеряются все фризы и странные просадки.
Вот в случаи с нехваткой памяти будут просадки (вероятно очень сильные) в момент подгрузок. Конечно они должны и на AVG сказаться, но если что-то не то то на 0.1/1% FPS будет прям очень сильно заметно (советую посмотреть обзор 3080 на gamersnexus, где они объясняли почему разгон памяти довольно странно работает на новых картах и показывали конкретные числа в конкретных играх).
И если совсем интересно почитать, то все это называют перцентилями или квантилями. В данном случаи 1% low будет 1-ый перцентиль, 0.1% low — 0.1-ый. Из общепринятого — медиана это 50-ый перцентиль (50%).
1. По статье абсолютно непонятно в какой момент проводился тест камеры, а значит невозможно сказать какая была последняя прошивка на тот момент. И лучше указать явно версию, чтобы читатель не бегал по сайту производителя камеры в поисках какая же была свежая на момент публикации. А потом еще и не гадал, если был апдейт за несколько дней до выхода статьи.
2. Посмотрел, перечитал. Информация размазана тонким слоем по нескольким разделам. Очень неудобно ее воспринимать в таком контексте.
3. Дело в том, что сейчас в статье есть только тест автофокуса в идеальных для него условиях (отсутствие быстрого движения и необходимости следить за объектом). А у камер как раз основные проблемы когда объект в кадре двигается относительно быстро. Без найма дополнительных людей тут к сожалению простой способ проверить один — покривляться на камеру автору обзора. И нет, я не перепутал ничего, потому что это тоже один из режимов работы камеры, который попросту не покрыт статьей.
4. Просто я считаю, что если заказчик не может обеспечить условия для качественного выполнения работы, лучше поменять заказчика, чем портить репутацию делать как получается в поставленных условиях. Но тут конечно вопрос приоритетов для Вас и для редакции.
Опять же претензий было бы заметно меньше если бы обзор был в районе выхода камеры, а не спустя примерно год. И да, все понятно, что никто раньше камеру не давал, но чем позже вышел обзор тем больше с него спрос, вне зависимости от причин задержки.
Я понимаю, что все это требует работы. Но я более чем уверен, что можно создать или усовершенствовать именно методологию тестирования за пределами статей в целом. Впрочем да, это конечно вложение времени автора, но я тут делаю допущение, что автору именно за это платят.
И конкретно по пунктам:
1. Посмотреть версию прошивки занимает примерно 1 минуту (если знаком с камерами конкретного вендора и примерно 3 минуты с интернетом, если не знаком), но даст всем читающим статью четкое понимание в каком состоянии была камера на момент тестирования, так как можно будет посмотреть на список изменений между прошивкой в обзоре и прошивкой сейчас и прикинуть будет ли чем-то текущий опыт отличаться от опыта автора статьи. Поправьте, если я не прав в этом месте.
2. Ок, допустим у автора нет atomos'а и редакция не предоставляет его. Тут претензий нет, но справедливо было бы в процессе подготовки статьи перечислить теоретически возможные характеристики с внешним устройством. Тут я время оценить затрудняюсь, но это можно сделать без самого устройства и я предпологаю, что автору статьи за это платит редакция.
3. Требуется вложение в размере 2-х штативов — один на котором камера, второй — на котором телефон. Затем автор может попрыгать и побегать перед камерой несколько минут. То есть я бы оценил что можно уложится в час, при наличии двух штативов.
4. Ну тут да, наверное нужно подумать заранее где найти животных и это может занять какое-то время.
И в общем и целом, я бы просто предполагал что у автора статьи и редакции ixbt есть какой-то вес и возможность сказать «если вы не дадите нам камеру на Х времени, мы вообще не будем делать на нее обзор, так как иначе он не будет соответствовать нашим стандартам качества» и если компания или магазин не готовы предоставить камеру на желаемый срок, то просто не делать на нее обзор. На мой взгляд звучит просто и решает все проблемы одним махом. Так как обзор плохого качества, независимо от причин, будет вредить репутации данного сайта.
Выше был сарказм, на всякий случай.
В моем представлении, если Вы позиционируете себя профессионала. А раз так то и спрос с Вас выше чем с блоггера. Ок, допустим редакция не дает денег на Atmos, но остальные пункты это все проблемы методики тестирования, которые можно решить просто лучше ее продумав. Так что честно говоря мотив за Вашим ответом мне абсолютно непонятны, звучит как «делаю плохо, потому что мне недостаточно платят».
Даже Average пострадает, просто менее заметно.
Кстати, посмотрите на поведение 0.1% low при разгоне 3080, там очень интересное поведение при переразгоне памяти, которое отлично ловится именно этим показателем.
Ты путаешь потребляемую память и выделенную.
То что измеряет сторонний софт это только то, что игра запросила, но ряд движков запрашивает всегда все, но использует только малую часть. Поэтому в общем случае ФПС корректный способ измерения — если памяти не хватает, будут просадки и микрофризы.
То есть сравнивая 1%/0.1% low + average FPS можно получить достаточно адекватную картину о том, хватает ли памяти (если фпс практически не изменился — то хватает).
Иначе попрошу предложить свою собственную методику как определить движок ли у игры кривой (просит больше памяти чем нужно) или память реально нужна игре для работы.
Так то да, можно сделать энергоэффективный ноутбук на интелах или амдшках, который будет жить долго, но только в ряде тестов M1 показывает примерно втрое более лучшую производительность на Ватт. Поэтому он сейчас так и привлек внимание людей.
И если им верить, то у Apple просто очень жирный процессор во всем — много кэша, жирный декодер, много АЛУ, большой Reorder Buffer и просто в целом хорошо спроектирован он (задержки кэшей лучше чем у x86, например, при большем их размере, что достаточно сложно получить). И никакой в общем-то магии.
Правда все это базируется на анализе кучи тестов, так как эпл детали про микроархитектуру не публикует.
График в секции «Memory Differences». Для RAM там 90 с небольшим ns в full random против ~80 у Zen 3 или ~70 у i9-10900k при использовании стандартной DDR4-3200 CL15 (из статей с того же anandtech)
Память не упакована прямо в чип, там четко видно две отдельных микросхемы памяти на подложке с чипом и можно даже посмотреть на маркировку и известно, что там LPDDR4X на 4233 МГц. То есть конечно она не медленная, но и ничего выдающегося и очень быстрого.
На утверждения вида «которые уже не раз ловили на манипуляциях цифрами» можно же конечно увидеть пруфы? Потому что я, например, не слышал ни одного случая когда уважаемый бенчмарк так поступал (в данном случаи из статьи — geekbench).
К тому же не все бенчмарки в статье закрытые, тот же JetStream публикует исходный код своих тестов (а также так как он на js, всегда можно посмотреть что конкретно исполняется).
Касательно проблем с GPU тестами — в идеале надо смотреть на перцентили fps хотя бы или записывать frame render time для каждого кадра и анализировать эти результаты уже. Но тут я сомневаюсь, что под osx есть соответствующий туллинг, к тому же OpenGL под osx уже давно официально не обновляется и не рекомендуется к использованию (то есть баги там никто фиксить не будет) и запускать тесты 2012 года выпуска — ну такая себе идея на мой взгляд.
Браузерные тесты вполне себе рассказывают что делают (в этой статье, например, приводили тесты интерпретации javascript'а, а не рисования графики). Также как это делают и стандартные бенчмарки, которые при наилчии специфических оптимизаций просто потеряют всю репутацию и источник заработка, поэтому так никто делать не будет. Final Cut — тут да, тут в общем смысл как раз в том что они должны оптимизировать под железо себя. Photoshop — в теории согласен, на практике Adobe так себе в это все умеет и на простые оптимизации под популярное железо они тратят годы...
Так что все это не более чем теория заговора, не выдерживающая никакой критики.
И я уже говорил выше, проблема гипотезы про использование GPU в том, что GPU эффективно выполняют только малый класс задач и при наличии ручной оптимизации так сказать (по сути писать отдельный код, использующий GPU для задачи), а ощутимый прирост по тестам показан по всем задачам (см. тот же гикбенч)
Ну к тому же это в данной статье брали стандартные популярные бенчмарки, в других статьях брали приземленные вещи типа компилятора (притом не эплового варинта) и там картина та же самая.
Да и популярные бенчмарки как бы тоже намекают что никаких такого рода оптимизаций нет.
И к тому же с оптимизацией под GPU дело в том, что не любые задачи на нее хорошо ложатся, мягко говоря не любые (например браузеры — из рук вон плохо)
По сути автор приложения должен сам решать в какой момент это надо и в каком объеме.
Эти данные обычно берутся либо из пресс-релизов (если там указано), либо народ по дорожкам смотрит куда и от каких мосфетов они идут.
p.s. и да, у палита их 17. Там 14 на GPU и 3 на Memory, но одну фазу многие обзорщики упустили потому что она повернута на 90 градусов )
Вот в случаи с нехваткой памяти будут просадки (вероятно очень сильные) в момент подгрузок. Конечно они должны и на AVG сказаться, но если что-то не то то на 0.1/1% FPS будет прям очень сильно заметно (советую посмотреть обзор 3080 на gamersnexus, где они объясняли почему разгон памяти довольно странно работает на новых картах и показывали конкретные числа в конкретных играх).
И если совсем интересно почитать, то все это называют перцентилями или квантилями. В данном случаи 1% low будет 1-ый перцентиль, 0.1% low — 0.1-ый. Из общепринятого — медиана это 50-ый перцентиль (50%).
2. Посмотрел, перечитал. Информация размазана тонким слоем по нескольким разделам. Очень неудобно ее воспринимать в таком контексте.
3. Дело в том, что сейчас в статье есть только тест автофокуса в идеальных для него условиях (отсутствие быстрого движения и необходимости следить за объектом). А у камер как раз основные проблемы когда объект в кадре двигается относительно быстро. Без найма дополнительных людей тут к сожалению простой способ проверить один — покривляться на камеру автору обзора. И нет, я не перепутал ничего, потому что это тоже один из режимов работы камеры, который попросту не покрыт статьей.
4. Просто я считаю, что если заказчик не может обеспечить условия для качественного выполнения работы, лучше поменять заказчика, чем портить репутацию делать как получается в поставленных условиях. Но тут конечно вопрос приоритетов для Вас и для редакции.
Опять же претензий было бы заметно меньше если бы обзор был в районе выхода камеры, а не спустя примерно год. И да, все понятно, что никто раньше камеру не давал, но чем позже вышел обзор тем больше с него спрос, вне зависимости от причин задержки.
И конкретно по пунктам:
1. Посмотреть версию прошивки занимает примерно 1 минуту (если знаком с камерами конкретного вендора и примерно 3 минуты с интернетом, если не знаком), но даст всем читающим статью четкое понимание в каком состоянии была камера на момент тестирования, так как можно будет посмотреть на список изменений между прошивкой в обзоре и прошивкой сейчас и прикинуть будет ли чем-то текущий опыт отличаться от опыта автора статьи. Поправьте, если я не прав в этом месте.
2. Ок, допустим у автора нет atomos'а и редакция не предоставляет его. Тут претензий нет, но справедливо было бы в процессе подготовки статьи перечислить теоретически возможные характеристики с внешним устройством. Тут я время оценить затрудняюсь, но это можно сделать без самого устройства и я предпологаю, что автору статьи за это платит редакция.
3. Требуется вложение в размере 2-х штативов — один на котором камера, второй — на котором телефон. Затем автор может попрыгать и побегать перед камерой несколько минут. То есть я бы оценил что можно уложится в час, при наличии двух штативов.
4. Ну тут да, наверное нужно подумать заранее где найти животных и это может занять какое-то время.
И в общем и целом, я бы просто предполагал что у автора статьи и редакции ixbt есть какой-то вес и возможность сказать «если вы не дадите нам камеру на Х времени, мы вообще не будем делать на нее обзор, так как иначе он не будет соответствовать нашим стандартам качества» и если компания или магазин не готовы предоставить камеру на желаемый срок, то просто не делать на нее обзор. На мой взгляд звучит просто и решает все проблемы одним махом. Так как обзор плохого качества, независимо от причин, будет вредить репутации данного сайта.
В моем представлении, если Вы позиционируете себя профессионала. А раз так то и спрос с Вас выше чем с блоггера. Ок, допустим редакция не дает денег на Atmos, но остальные пункты это все проблемы методики тестирования, которые можно решить просто лучше ее продумав. Так что честно говоря мотив за Вашим ответом мне абсолютно непонятны, звучит как «делаю плохо, потому что мне недостаточно платят».
Кстати, посмотрите на поведение 0.1% low при разгоне 3080, там очень интересное поведение при переразгоне памяти, которое отлично ловится именно этим показателем.
То что измеряет сторонний софт это только то, что игра запросила, но ряд движков запрашивает всегда все, но использует только малую часть. Поэтому в общем случае ФПС корректный способ измерения — если памяти не хватает, будут просадки и микрофризы.
То есть сравнивая 1%/0.1% low + average FPS можно получить достаточно адекватную картину о том, хватает ли памяти (если фпс практически не изменился — то хватает).
Иначе попрошу предложить свою собственную методику как определить движок ли у игры кривой (просит больше памяти чем нужно) или память реально нужна игре для работы.