Я им сам не пользовался, но вроде бы он работает и на AMD. Покажет не совсем FPS, но среднее время рассчета кадра в средний-же FPS прекрасно конвертируется. К тому же там вроде бы можно включить логгирование и провести корректные рассчеты перцентилей и посмотреть не только на FPS, но на стабильность FPS, что в соревновательных играх, на мой взгляд, чуть ли не важнее среднего значения.
Ну ТФлопсы в играх не всегда играют решающую роль, но лишний признак неравенства карт и некорректности сравнения. Я бы в данном случаи, если честно, на обе системы поставил что-нибудь в духе хотя бы RX480/RX580, чтоб шанса что оно упирается в видеокарту было около нуля. И да, одинаковая ОС тоже важна в случаи vulkan рендера и AMD карт.
Судя по различным тестам (например wccftech.com/nvidia-evga-gtx-960-ssc-amd-xfx-r9-380-oc), эти видеокарты могут, в зависимости от теста, отличаться процентов на 15 (см. Ashes of the Singularity, например), так что в целом честно было бы взять везде R9 380 и посмотреть уже на нем, иначе конечно разницу в 1.5 раза не объяснить, а вот 83 против 70 фпс — вполне можно было бы.
Звучит как домыслы и приписывание изначальному утверждению про длительность жизни конфедераций смысла, который был не высказан.
Про «военный союз зависимых от других государства земель» — тут дело в том, что этот союз считается конфедерацией в современном понимании. Дальше можете общаться с историками или какие там ученые занимаются вот этим вот всем на тему определения и несогласия с ним, но тут уж я ни при чем.
И еще раз — твое утверждение что конфедерации долго не живут по сути ложное, остальное уже софистика и попытка подменить тему (как в примере с монархией и племенами).
Ну так ты сам опроверг свои слова же (а не я подтвердил их).
А конкретно:
До 1848 года страна была конфедерацией, после этого стала федеративной республикой.
Если посмотреть историю вокруг, то Швейцарская Конфедерация началась в 1291 году и продлилась до 1848 года (и в общем в более-менее стабильном виде до 1798 года, после чего Наполеон немного внес коррективы в стабильность, так что я б отсчитывал до 1798, но если ты настаиваешь, то готов считать до 1848 года), что, кажется, достаточно очевидно опровергает ваше утверждение про «конфедерации долго не живут». Вот исторический пример чистой конфедерации прожившей 557 лет.
Уважаемый, Вы же, надеюсь, понимаете, что Вас минусуют в первую очередь за то, что вместо фактов Вы излагаете собственные эмоции и систематически пытаетесь обобщить Ваш собственный опыт на всех?
Например, почему Вы уверены, что то что в Вашем круге общения люди считают каждый евро и никто не поднялся (что бы это ни значило), то это не проблемы Вашего круга общения или даже Вашего восприятия Вашего же круга общения?
А намекаю, что ваши ответы без конкретики «как это вообще провернуть» больше напоминают про вмешательство на уровне законов природы. Ну а что, подправил закон и порядок.
В моем предыдущем ответе Вы можете найти несколько названий статей с конкретикой по вопросу. Почитайте их, вопросы должны сами отпасть после этого.
Теперь докажите, что это можно сделать в автоматическом режиме под произвольную архитектуру на лету.
В общем-то я уже какое-то время намекаю Вам, что это Ваше дело доказать что так сделать нельзя.
Но даже отвечая на этот коркнетный вопрос — в обоих статьях, которые я привел, рассматриваются методики автоматического внедрения вредоносных кусков схемы. Они не зависят от архитектуры, а как раз осуществимы на момент генерации заказа на фабирку. Оба метода не требуют никакого ИИ в прицнипе и даже нейронок не нужно.
На примитивы в основном (транизстор, цепь, блоки и/или и т.п.), как понимаю, потому что архитектурные моменты — ты создашь библиотеки сам, плюс на внедряемые покупные блоки, ну там ентернет, например.
Под библиотеками в данном случаи обычно имеются в виду не IP-блоки с покупной реализацией кэша или там Ethernet'а, а то что выдается конкретной фабрикой для синтеза этого всего дела в уже вполне конкретные транзисторы-соединения.
Но так как я отвечаю на всю претензию, зачем свои процы, то я и указываю на комплекс проблем с чужими чипами.
Я никаких претензий не высказывал, я эту тему вполне обхожу стороной, я лишь подкинул кое что на подумать, так как у вас двоих на мой взгляд дискуссия зашла в тупик в этом месте. У меня нет намерений занимать какую либо четкую позицию в рамках данной дискуссии.
Тут вопрос наверное не в том, было такое событие или не было, а в том чтобы разобраться что произошло, что потом было с человеком, что было на судах и так далее.
Но писать человеку я сам конечно не буду, потому что я даже не уверен что у меня есть аккаунт на ЖЖ, чтобы это сделать, а заводить его немного лень.
Кстати про «если 16С уже на руках». Если верить youtube каналу imaxai (он вроде в МЦСТ работает), то «есть на руках» только ранние инженерные образцы, но финального дизайна нет и не будет еще минимум полгода, соответственно еще минимум год до получения на руки первых серийных чипов. А потом еще неизвестное время до первого коммерческого устройства на них (если экстраполировать прошлые сроки то еще год-полтора). Так что до компьютеров на базе Эльбрус-16С минимум год, а более вероятно что 2 года.
В роадмапах МЦСТ похоже указывает датой выпуска дату когда они отправляют заказ на производство, а не дату получения первых чипов или дату получения плат с этими чипами.
А что, любой пенёк можно запустить на своём чипе южного моста? Самому сделать мамку и накидать туда только своих чипов?
Еще раз, вы точно МНЕ отвечаете? Я лишь написал что внедрение «закладок» может быть на уровне синтеза, а не на уровне производства, чтобы заставить задуматься о такой возможности. Я про Intel/AMD/ME и прочее дискуссию не начинал и не вижу какое отношение это имеет к моему ответу. Моя цель чтобы Вы задумались о векторах атаки, не использующих подмену маски на заводе.
Ну, без полноценного ИИ сделать это будет весьма трудно. Вам нужно не просто кинуть куда-то блок, но встроит его в работу всей системы и сделать его «логичным», чтоб при анализе полученного никто не смог бы ничего понять. Причём, сделать это на заранее неизвестной вам архитектуре. Автоматически. Не подключить в работе отдел супер-пупер спецов с подобной целью, а внедрить на этапе автогенерации у заказчика.
Смотрите, чтобы начать разрабатывать чип нужно купить ПО, а чтобы произвести чип нужно договорится с заводом и получить набор библиотек. Чисто формально никто не мешает продавать ПО или библиотеки, которые будут включать «if количество транзисторов больше X, добавить блок вот сюда». Да, это не code execution, но что-нибудь что может просто сделать процессор нерабочим при определенных импульсах — почему бы нет? Никакого ИИ и даже нейронок не нужно, только немного логики.
По поводу возможности такого — есть теоретические изыскания, которые показывают что возможно добавить бэкдоры, которые не обнаружить при сравнении схем с эталоном. Например есть статья от 2014 года, опубликованная в Journal of Cryptograpic Engineering (принадлежит Springer'у) с названием «Stealthy dopant-level hardware Trojans: extended version». Правда кажется кроме Abstract'а все остальное по традиции платное. Или «Defeating UCI: Building Stealthy and Malicious Hardware» (2011 год) — теоретическое изыскание о том как обойти UCI (это как раз уже про добавление зловредной цепи.
Так что есть теоретические изыскания, пусть и не самой первой свежести, значит их возможно использовать и возможно используют.
Достаточно, чтобы понимать, что все что не задизайнено с прицелом на доступ через jtag не будет через него доступно. Поэтому его наличие не отменяет потенциальной возможности внедрения какой-то схемы где-то сбоку, которая будет делать что-то странное при строго заданных внешних условиях, которые, например, в обычной жизни не будут встречаться.
И я еще раз повторюсь — вероятность этого мала, но факт ее наличия сводит все описанные идеи о верификации дизайна на нет, потому что вероятность такого события несколько больше, чем простой подмены масок (как раз потому что это сложная схема где нужно иметь несколько масок и успешно избегать выборочных проверок, а тут все проверки покажут что все выглядит также как было отправлено в производство, не надо подкупать производителя микросхем и делать прочие сложные штуки)
Мне кажется Вы ответили не в тот тредик, потому что я написал про то, что все конечно в Ваших рассуждениях хорошо, но процессоры проектируют на неподконтрольном ПО, используя довольно таки закрытые библиотеки, которые предоставляет завод, а значит нет гарантий что при синтезе финальной схемы не появляется что-то чего быть не должно.
Потому что как раз если вы разрабатываете маску, то найти внедренный элемент — возможно.
Чтоб подлить масла в огонь паранойи: а Вы можете гарантировать, что иностранный софт по проектированию, который вам продали не добавляет бэкдоры на этапе создания маски? Тогда производителю в общем и не надо две маски иметь будет, все уже готово, так сказать встроено. А так как Вы сами сказали — поди там проверь все миллиарды транзисторов :)
По указанной ссылке недостаточно информации чтобы найти какие-либо протоколы по данному делу, заседания и решения судов и так далее. Можете, пожалуйста, привести больше информации, чтобы любой желающих мог убедится в правдивости истории и в том что все было именно так? Ну там ссылки на соц-сети героя истории где было бы видно по его постам что он и как делал, какие-нибудь заметки местных СМИ, ну или там linkedin'ы героя истории чтоб было тоже видно что и как.
Или можно взять в пример Эльбрус-8С, который был запланирован на 2016 год, но первое известное устройство на нем пошло в серию в октябре 2018 только (согласно вики).
Эльбрус-8СВ — запланирован на 2018 год и акт приемки там стоит декабрь 2018 года (инфа из вики), но при этом продажа устройств на нем запланирована только на 2021 год.
Так что roadmap у них хороший, но указанная дата видимо какой-то бумажной приемки или формальных окончаний работ, а до реальных устройств — +2.5-3 года как показывает практика.
Не понимаю связь «любой платформы» с «только на CPU».
Мне как не сведующему в томографии человеку кажется, что если у вас вычислительно-интенсивная задача и требование скорости, то логично делать рассчеты на видеокартах. Я не вижу при этом чтобы это накладывало принципиальные ограничения на платформу, даже наоборот, кажется что будь все это сделано на OpenCL можно было бы поддерживать еще большее их число и сразу оптимально (просто требовать наличия поддержки OpenCL платформой или наличие PCIe шины куда можно воткнуть какой-нибудь FirePro) без необходимости делать архитектурно-специфические оптимизации. Но да, придется делать оптимизации под различные видеокарты, что тоже в общем-то ограничение, просто другое.
gitlab.freedesktop.org/mesa/mesa/-/tree/master/src/vulkan/overlay-layer
По идее он в отличии от MangoHud должен показывать более адекватные результаты, да и в целом давать больше статистики (он в меса с версии 19.1)
Про «военный союз зависимых от других государства земель» — тут дело в том, что этот союз считается конфедерацией в современном понимании. Дальше можете общаться с историками или какие там ученые занимаются вот этим вот всем на тему определения и несогласия с ним, но тут уж я ни при чем.
А конкретно:
Если посмотреть историю вокруг, то Швейцарская Конфедерация началась в 1291 году и продлилась до 1848 года (и в общем в более-менее стабильном виде до 1798 года, после чего Наполеон немного внес коррективы в стабильность, так что я б отсчитывал до 1798, но если ты настаиваешь, то готов считать до 1848 года), что, кажется, достаточно очевидно опровергает ваше утверждение про «конфедерации долго не живут». Вот исторический пример чистой конфедерации прожившей 557 лет.
Например, почему Вы уверены, что то что в Вашем круге общения люди считают каждый евро и никто не поднялся (что бы это ни значило), то это не проблемы Вашего круга общения или даже Вашего восприятия Вашего же круга общения?
В моем предыдущем ответе Вы можете найти несколько названий статей с конкретикой по вопросу. Почитайте их, вопросы должны сами отпасть после этого.
В общем-то я уже какое-то время намекаю Вам, что это Ваше дело доказать что так сделать нельзя.
Но даже отвечая на этот коркнетный вопрос — в обоих статьях, которые я привел, рассматриваются методики автоматического внедрения вредоносных кусков схемы. Они не зависят от архитектуры, а как раз осуществимы на момент генерации заказа на фабирку. Оба метода не требуют никакого ИИ в прицнипе и даже нейронок не нужно.
Под библиотеками в данном случаи обычно имеются в виду не IP-блоки с покупной реализацией кэша или там Ethernet'а, а то что выдается конкретной фабрикой для синтеза этого всего дела в уже вполне конкретные транзисторы-соединения.
Я никаких претензий не высказывал, я эту тему вполне обхожу стороной, я лишь подкинул кое что на подумать, так как у вас двоих на мой взгляд дискуссия зашла в тупик в этом месте. У меня нет намерений занимать какую либо четкую позицию в рамках данной дискуссии.
Но писать человеку я сам конечно не буду, потому что я даже не уверен что у меня есть аккаунт на ЖЖ, чтобы это сделать, а заводить его немного лень.
В роадмапах МЦСТ похоже указывает датой выпуска дату когда они отправляют заказ на производство, а не дату получения первых чипов или дату получения плат с этими чипами.
Еще раз, вы точно МНЕ отвечаете? Я лишь написал что внедрение «закладок» может быть на уровне синтеза, а не на уровне производства, чтобы заставить задуматься о такой возможности. Я про Intel/AMD/ME и прочее дискуссию не начинал и не вижу какое отношение это имеет к моему ответу. Моя цель чтобы Вы задумались о векторах атаки, не использующих подмену маски на заводе.
Смотрите, чтобы начать разрабатывать чип нужно купить ПО, а чтобы произвести чип нужно договорится с заводом и получить набор библиотек. Чисто формально никто не мешает продавать ПО или библиотеки, которые будут включать «if количество транзисторов больше X, добавить блок вот сюда». Да, это не code execution, но что-нибудь что может просто сделать процессор нерабочим при определенных импульсах — почему бы нет? Никакого ИИ и даже нейронок не нужно, только немного логики.
По поводу возможности такого — есть теоретические изыскания, которые показывают что возможно добавить бэкдоры, которые не обнаружить при сравнении схем с эталоном. Например есть статья от 2014 года, опубликованная в Journal of Cryptograpic Engineering (принадлежит Springer'у) с названием «Stealthy dopant-level hardware Trojans: extended version». Правда кажется кроме Abstract'а все остальное по традиции платное. Или «Defeating UCI: Building Stealthy and Malicious Hardware» (2011 год) — теоретическое изыскание о том как обойти UCI (это как раз уже про добавление зловредной цепи.
Так что есть теоретические изыскания, пусть и не самой первой свежести, значит их возможно использовать и возможно используют.
И я еще раз повторюсь — вероятность этого мала, но факт ее наличия сводит все описанные идеи о верификации дизайна на нет, потому что вероятность такого события несколько больше, чем простой подмены масок (как раз потому что это сложная схема где нужно иметь несколько масок и успешно избегать выборочных проверок, а тут все проверки покажут что все выглядит также как было отправлено в производство, не надо подкупать производителя микросхем и делать прочие сложные штуки)
А причем тут ME?
И если что нет, я не очень верю что такое делают, но это все же аргумент в то что либо полный цикл, либо нельзя гарантировать безопасность.
Чтоб подлить масла в огонь паранойи: а Вы можете гарантировать, что иностранный софт по проектированию, который вам продали не добавляет бэкдоры на этапе создания маски? Тогда производителю в общем и не надо две маски иметь будет, все уже готово, так сказать встроено. А так как Вы сами сказали — поди там проверь все миллиарды транзисторов :)
Эльбрус-8СВ — запланирован на 2018 год и акт приемки там стоит декабрь 2018 года (инфа из вики), но при этом продажа устройств на нем запланирована только на 2021 год.
Так что roadmap у них хороший, но указанная дата видимо какой-то бумажной приемки или формальных окончаний работ, а до реальных устройств — +2.5-3 года как показывает практика.
Мне как не сведующему в томографии человеку кажется, что если у вас вычислительно-интенсивная задача и требование скорости, то логично делать рассчеты на видеокартах. Я не вижу при этом чтобы это накладывало принципиальные ограничения на платформу, даже наоборот, кажется что будь все это сделано на OpenCL можно было бы поддерживать еще большее их число и сразу оптимально (просто требовать наличия поддержки OpenCL платформой или наличие PCIe шины куда можно воткнуть какой-нибудь FirePro) без необходимости делать архитектурно-специфические оптимизации. Но да, придется делать оптимизации под различные видеокарты, что тоже в общем-то ограничение, просто другое.