AMD чисто формально до сих пор выпускает Opteron A1100, на арме (cortex a57 ещё). Представили его году в 13-14, правда устройств даже для разработчиков на нем было практически не достать, хотя желающих хватало.
А у нвидии с армами вроде все нормально, для самодвижущихся повозок достаточно популярные системы, да и nintendo switch нормальными тиражами расходится.
«которая может открыть дверь для атак с использованием отпечатков пальцев.»
«Это вторая уязвимость, обнаруженная в SoC Apple M1 за последние недели. В прошлом месяце исследователи обнаружили вредоносное ПО под названием Silver Sparrow.»
И т.п.
Такое ощущение что автор не понимает ничего в том, что переводил.
Были кстати попытки сделать стандарты под подобные диски где всю тяжёлую работу предлагалось переложить на ОС, назывались Open-Channel SSD и это является частью спецификации NVMe. Возможно тут Самсунг решит такой подход применить, но пока нет деталей — непонятно (в целом маловероятно). Но если решатся, возможно все не так плохо будет.
От того что ты продолжаешь повторять что я чушь не несу (а при этом ты не способен ни объяснить моменты, ни рассказать хотя бы стадии компиляции программ), твои слова не станут правдой.
Последний раз тебе повторяю:
1. Я не предполагаю, я знаю. Я тебе дал намеки о том что почитать, а еще в соседнем тредике описал на что тратится место. При реализации эквивалентного функционала на ассемблере размер бинарника получится таким же. Возьми дизассемблер, возьми hello world, прогляди что там внутри, узнаешь много для себя нового
2. Какая волшебная программы, ты о чем? И я про статическую линковку в том числе говорил.
3. А я тебе утверждаю что не больше, эквивалентеный код занимает эквивалентеный объем, что на Сях, что на плюсах, да в общем и на ассемблере тоже. Никакого «круто толще» нет и в помине. Почему? Есть отличные статьи об устройстве компиляторов, если ты хоть что-то об этом знаешь ты бы так не утверждал.
3. Про какое портирование апи? Ты вообще о чем? Я тебе говорил про то что оптимизация под микроархитектуру достаточно важна чтобы попадать под твое заявление о «капризности», которое по твоему отсутствует у ассемблера. Про АПИ ты начал говорить по какой-то причине и я тебе поэтому посоветовал почитать исходники того же квейка который ты в соседних тредиках приводил, и сравнить процент вызова апи к просто коду, так как ты сказал, цитирую, «вызов апи винды к оптимизации никакого отношения не имеет
это мс им занимается, а не программист, который просто складывает аргументы и делает вызов соответствующего апи».
1. Ну так посмотри мои ответы тебе выше, плюс ты на ассемблере напишешь не эквивалент тому что получишь от плюсового компилятора (но ты не понимаешь что делает компилятор, так что логично что несешь чушь). Напиши полный аналог, получишь примерно те же 90 кбайт как статический бинарник.
И ты упорно игнорируешь мой пример с микроконтроллером где почему-то код на плюсах занимает столько же сколько на Си. В обоих случаях статический. В случаи плюсов — использующий достаточно много из стандарта на 17-ые плюсы.
Короче я дал тебе ключевые слова для поиска, продолжим как прочитаешь.
2. А зачем ты его тогда постоянно суешь куда ни попадя?
1. Для микроконтроллеров код бывает ТОЛЬКО статическим и никаким иным. В случаи с «Hello world» естественно статическим собирал. Так что я подожду пока ты поймешь, что от языка тут мало зависит, есть зависимость от реализации стандартной библиотеки но тут даже для одного и того же языка есть несколько разных вариантов. Но чтобы тебе это понять тебе надо почитать базовую теорию о построении компиляторов хотя бы, достаточно понимать какие примерно шаги делает компилятор, на каких стадиях какого толка оптимизации применяются. Еще неплохо бы понимать что такое линкер.
2. Советую посмотреть на исходники того же квейка или дума (можно брать не из последних, а какие тебе проще почитать будет) и попытаться посчитать сколько там делается вызовов АПИ винды в отношении ко всему остальному коду. Удивишься.
1. А я тебе специально сказал, что я именно переписал на плюсах hello world, а не просто собирал один и тот же код. Занимает он при этом одинаково.
Пример с микроконтроллерами и почему там код с плюсами занимает столько же ты тоже, видимо, проигнорировал. И да, там конечно нет стандартной библиотеки, но шаблоны, классы и трейты я использовал по полной.
2. Ты сказал, цитирую: «к конфигурациям железа капризности не будет т.к.ассемлерный код будет использовать все те же api»
На что я тебя отправил читать мануалы по оптимизации под микроархитектуры. Да, это не «не запуск», но местами очень критично для производительности кода. Так что это имеет прямое отношение к тому что ты говорил.
Суть принципиально не меняется, большая часть этого overhead'а все равно будет обвязка для обработки всевозможных ошибок и информирования пользователя об этом.
1. Притом что я тебе толсто намекаю, что ты делаешь выводы о том, в чем не понимаешь примерно ничего. Например ты очевидно не в курсе, что функционал у обозначенных тобой движков игр (и версий офиса) — немного разный, отсюда и разница в размере (это часто так бывает, что небольшое увеличение видимого функционала вызывает рост кодовой базы в разы). Предлагаю тебе тогда объяснить почему я вот написал только что hello world на сях, потом написал такой же на плюсах, скомпилировал и результат — байт-в-байт совпадает по размеру? По твоей логике разница должна быть на порядок.
2. Притом что почитай ветку обсуждения и вспомни что ты писал в начале и что я тебе отвечал.
Я, кажется, понимаю что имеет в виду этот товарищ, но он проблема в том что он сам не понимает за счет чего получается разница.
Например если взять hello world и скомпилировать его статически, то действительно он будет занимать много место (среды разработки под windows у меня под рукой нет, но есть linux, суть в общем одна и та же), а конкретно несколько сотен кбайт это минимальный размер скомпилированного статически слинкованного бинарника, если у тебя glibc. Последнее тоже важно.
Дальше можно пойти по пути дизассемблирования, чтобы покопаться внутри и понять почему так. И будет достаточно легко выяснить что сам базовый код — пара сотен байт, остальное — обвзяка, например заголовки, например сообщения об ошибке на паре десятков языков о том, если попытаться его запустить не на 64-х битном линуксе, а на 32-х битном, вся логика по переводу этих сообщений и выборку языка на базе окружения, пачка оптимизированных функций для разных архитектур по выводу строк, по сравнению строк, логика выбора функций и так далее и тому подобное.
Можно ли сделать это все короче, ну или по простому — по прежнему писать на сях или плюсах но иметь меньшие по размеру бинарники? Само собой, если пожертвовать частью функционала, который появился не просто так.
Влияет ли такое на производительность? Да, в лучшую сторону.
Будет ли размер увеличиваться всегда одинаково? Нет, но начальный overhead будет.
Увы, MrTO этого всего не понимает, так как судя по всему никогда даже не пытался разобраться в том, о чем сейчас пишет.
Если по порядку:
1. Не будет, потому что Вы зачем-то смешали в одну кучу язык и его свойства с библиотеками (включая стандартную библиотеку языка). Поэтому пришли к некорректной оценке. Почитайте подробнее о том что происходит при компиляции и что такое стандартная библиотека языка и почему она большая.
2. Почитайте что такое макроассемблер и в сочетании с (1) думаю Вам станет понятнее почему это не повлияет на проблемы с оптимизацией под микроархитектуру, в отличии от более высокоуровневых языков и процесса компиляции.
Ну и чтоб было Вам еще более понятно — расскажите почему код на плюсах, собранный под какую-нибудь атмегу занимает крайне мало (единицы киллобайт на достаточно развесистую логику это нормально) и как это соотносится с Вашими утверждениями?
Ну что я могу сказать, раз важны только API предлагаю портировать ассемблерный код от x86 на ARM (напомню что офис есть для Android и Windows 10 на ARM, как минимум).
Дополнительно советую подумать о том, зачем же производители процессоров для каждой новой микроархитектуры выпускают многостраничные мануалы по оптимизации под конкретную микроархитектуру и вообще подумать о том, насколько весело будет писать код, использующий процессоро-зависимые расширения.
Ну и про 100 раз — советую почитать подробнее, а не блестать незнанием.
Мб мне повезло конечно, но у меня кабели взаимозаменяемые, когда отлаживал сломанный кабель перепробовал все возможные комбинации (а также сломанный кабель заменил на какой-то случайный usb-c кабель из магазина).
Про Affinity и DaVinci не скажу, но в C1, Photoshop и Lightroom — разница между разными GPU практически отсутствует.
Посмотрите на PugetBench, например. Для LR разницы между Intel UHD 630 и RTX 3090 там не заметно совсем. Это примерно все что нужно знать о том как работает ускорение в LR.
В Photoshop есть небольшая разница между оным UHD 630 и чем угодно лучше, в остальном разницы нет. Хоть какая-то разница заметна при использовании Enhance Detail, но даже там разница между средней картой (помним что тот же M1 эквивалент ~gtx 1050) и топовой — не такая большая (речь идет о 16 секунд против 4, а не о минутах против секунд). Ну и фича нишевая, не из тех что используется на каждом фото.
В ФШ примерно такая же история, разве что больше плагинов страдают на встроенном интеле, но принципиальной разницы нет.
В C1 ситуация похожая на ЛР.
Во многих — практически во всех новых не совсем дешевых мониторах. У меня дома — три монитора немного разных лет и разного класса — во всех трех оказался USB-С, хотя я его наличием не интересовался во всех случаях. Один — Dell P серии, одна Lenovo ThinkVision и Dell UP серии чуть более старый.
Переходники — всегда дают на работе, если рабочий ноутбук, либо если тебе нужен проектор для выступления — предоставляются организатором, так что проблем с этим нет. Если дома у тебя желание подключить к телевизору — то есть USB-C -> HDMI, стоит как и HDMI->HDMI провод.
Ну вот видимо и ответ, раз нужного софта под макось нет, то действительно мак рассматривать и не надо.
Так на маках и нвидиевских видеокарт тоже нет уже давно, в старых — AMDшки, в новых — свои.
Я конечно не тот, кто Вам отвечал, но Вы правели в пример игровой ноутбук. Логично же предположить, что приводя игровой ноут вам нужен ноут для игр?
Дальше — отталкивайтесь от софта, а то многие видеографы говорят что лучше Final Cut'а софта нет, а он только под макось есть, но я как просто фотограф ничего про это сказать не могу.
Касательно фото — да пойдет почти что угодно, увы мощная видеокарта в Photoshop, Lightroom и прочих CaptureOne'ах роли не играет.
Касательно экрана — тут сравнивать надо по одной методологии и смотреть что можно получить.
И в любом случаи стоит подождать новых ноутбуков что на интеле (11-ой серии), что от эпла (на М1 только 13" макбуки, что как мне кажется маловато, а смотреть на 16" текущую прошку сейчас достаточно глупо).
А у нвидии с армами вроде все нормально, для самодвижущихся повозок достаточно популярные системы, да и nintendo switch нормальными тиражами расходится.
А вот EF-M с RF не совместим совсем.
«Это вторая уязвимость, обнаруженная в SoC Apple M1 за последние недели. В прошлом месяце исследователи обнаружили вредоносное ПО под названием Silver Sparrow.»
И т.п.
Такое ощущение что автор не понимает ничего в том, что переводил.
Последний раз тебе повторяю:
1. Я не предполагаю, я знаю. Я тебе дал намеки о том что почитать, а еще в соседнем тредике описал на что тратится место. При реализации эквивалентного функционала на ассемблере размер бинарника получится таким же. Возьми дизассемблер, возьми hello world, прогляди что там внутри, узнаешь много для себя нового
2. Какая волшебная программы, ты о чем? И я про статическую линковку в том числе говорил.
3. А я тебе утверждаю что не больше, эквивалентеный код занимает эквивалентеный объем, что на Сях, что на плюсах, да в общем и на ассемблере тоже. Никакого «круто толще» нет и в помине. Почему? Есть отличные статьи об устройстве компиляторов, если ты хоть что-то об этом знаешь ты бы так не утверждал.
3. Про какое портирование апи? Ты вообще о чем? Я тебе говорил про то что оптимизация под микроархитектуру достаточно важна чтобы попадать под твое заявление о «капризности», которое по твоему отсутствует у ассемблера. Про АПИ ты начал говорить по какой-то причине и я тебе поэтому посоветовал почитать исходники того же квейка который ты в соседних тредиках приводил, и сравнить процент вызова апи к просто коду, так как ты сказал, цитирую, «вызов апи винды к оптимизации никакого отношения не имеет
это мс им занимается, а не программист, который просто складывает аргументы и делает вызов соответствующего апи».
И ты упорно игнорируешь мой пример с микроконтроллером где почему-то код на плюсах занимает столько же сколько на Си. В обоих случаях статический. В случаи плюсов — использующий достаточно много из стандарта на 17-ые плюсы.
Короче я дал тебе ключевые слова для поиска, продолжим как прочитаешь.
2. А зачем ты его тогда постоянно суешь куда ни попадя?
2. Советую посмотреть на исходники того же квейка или дума (можно брать не из последних, а какие тебе проще почитать будет) и попытаться посчитать сколько там делается вызовов АПИ винды в отношении ко всему остальному коду. Удивишься.
Пример с микроконтроллерами и почему там код с плюсами занимает столько же ты тоже, видимо, проигнорировал. И да, там конечно нет стандартной библиотеки, но шаблоны, классы и трейты я использовал по полной.
2. Ты сказал, цитирую: «к конфигурациям железа капризности не будет т.к.ассемлерный код будет использовать все те же api»
На что я тебя отправил читать мануалы по оптимизации под микроархитектуры. Да, это не «не запуск», но местами очень критично для производительности кода. Так что это имеет прямое отношение к тому что ты говорил.
2. Притом что почитай ветку обсуждения и вспомни что ты писал в начале и что я тебе отвечал.
Например если взять hello world и скомпилировать его статически, то действительно он будет занимать много место (среды разработки под windows у меня под рукой нет, но есть linux, суть в общем одна и та же), а конкретно несколько сотен кбайт это минимальный размер скомпилированного статически слинкованного бинарника, если у тебя glibc. Последнее тоже важно.
Дальше можно пойти по пути дизассемблирования, чтобы покопаться внутри и понять почему так. И будет достаточно легко выяснить что сам базовый код — пара сотен байт, остальное — обвзяка, например заголовки, например сообщения об ошибке на паре десятков языков о том, если попытаться его запустить не на 64-х битном линуксе, а на 32-х битном, вся логика по переводу этих сообщений и выборку языка на базе окружения, пачка оптимизированных функций для разных архитектур по выводу строк, по сравнению строк, логика выбора функций и так далее и тому подобное.
Можно ли сделать это все короче, ну или по простому — по прежнему писать на сях или плюсах но иметь меньшие по размеру бинарники? Само собой, если пожертвовать частью функционала, который появился не просто так.
Влияет ли такое на производительность? Да, в лучшую сторону.
Будет ли размер увеличиваться всегда одинаково? Нет, но начальный overhead будет.
Увы, MrTO этого всего не понимает, так как судя по всему никогда даже не пытался разобраться в том, о чем сейчас пишет.
1. Не будет, потому что Вы зачем-то смешали в одну кучу язык и его свойства с библиотеками (включая стандартную библиотеку языка). Поэтому пришли к некорректной оценке. Почитайте подробнее о том что происходит при компиляции и что такое стандартная библиотека языка и почему она большая.
2. Почитайте что такое макроассемблер и в сочетании с (1) думаю Вам станет понятнее почему это не повлияет на проблемы с оптимизацией под микроархитектуру, в отличии от более высокоуровневых языков и процесса компиляции.
Ну и чтоб было Вам еще более понятно — расскажите почему код на плюсах, собранный под какую-нибудь атмегу занимает крайне мало (единицы киллобайт на достаточно развесистую логику это нормально) и как это соотносится с Вашими утверждениями?
Дополнительно советую подумать о том, зачем же производители процессоров для каждой новой микроархитектуры выпускают многостраничные мануалы по оптимизации под конкретную микроархитектуру и вообще подумать о том, насколько весело будет писать код, использующий процессоро-зависимые расширения.
Ну и про 100 раз — советую почитать подробнее, а не блестать незнанием.
Посмотрите на PugetBench, например. Для LR разницы между Intel UHD 630 и RTX 3090 там не заметно совсем. Это примерно все что нужно знать о том как работает ускорение в LR.
В Photoshop есть небольшая разница между оным UHD 630 и чем угодно лучше, в остальном разницы нет. Хоть какая-то разница заметна при использовании Enhance Detail, но даже там разница между средней картой (помним что тот же M1 эквивалент ~gtx 1050) и топовой — не такая большая (речь идет о 16 секунд против 4, а не о минутах против секунд). Ну и фича нишевая, не из тех что используется на каждом фото.
В ФШ примерно такая же история, разве что больше плагинов страдают на встроенном интеле, но принципиальной разницы нет.
В C1 ситуация похожая на ЛР.
Статистика по использованию тут куда более объективная штука.
Переходники — всегда дают на работе, если рабочий ноутбук, либо если тебе нужен проектор для выступления — предоставляются организатором, так что проблем с этим нет. Если дома у тебя желание подключить к телевизору — то есть USB-C -> HDMI, стоит как и HDMI->HDMI провод.
Так на маках и нвидиевских видеокарт тоже нет уже давно, в старых — AMDшки, в новых — свои.
Дальше — отталкивайтесь от софта, а то многие видеографы говорят что лучше Final Cut'а софта нет, а он только под макось есть, но я как просто фотограф ничего про это сказать не могу.
Касательно фото — да пойдет почти что угодно, увы мощная видеокарта в Photoshop, Lightroom и прочих CaptureOne'ах роли не играет.
Касательно экрана — тут сравнивать надо по одной методологии и смотреть что можно получить.
И в любом случаи стоит подождать новых ноутбуков что на интеле (11-ой серии), что от эпла (на М1 только 13" макбуки, что как мне кажется маловато, а смотреть на 16" текущую прошку сейчас достаточно глупо).