Есть похожие на дальномерные камеры X-Pro серии, но они не дальномерные.
Собственно там есть просто прозрачный кусок стекла, где есть рамка и базовая информация о состоянии, рамка имеет коррекцию параллакса. Но самого дальномера нет.
Есть еще какие-то люди, которые на кикстартере собрали деньги на цифровую дальномерку с 16 мпикс матрицей (кажется) и почти ее вот-вот уже наверное выпустят, но это не точно (PIXII камера называется).
Ну не на Зенит-Е, а на другие Leica M и в целом на дальномерные камеры. Дизайн у них не меняется принципиально с 1950-х годов с выхода Leica M3 (M5 и CLE не в счет).
Ценник скорее всего там будет под 7-8 тысяч долларов.
Кому такое нужно -ну тем кому хочется либо немного элитарную камеру так сказать, либо тем кому хочется абсолютно уникальный в современном мире классический опыт (неспешную вдумчивую съемку как на пленке, но на цифру). То есть ниша есть своя собственная, за счет чего они и живы.
А никого не смущает, что банально цифры не сходятся и в табличке очень странные показатели указаны?
Например «18 Гббит/с» как скорость видеопамяти обычно не указывают одновременно с шиной.
К тому же 863 ГБ пропускной способности в даташите выглядит ужасно странно, ни с 320 битной шиной памяти, ни с 384 такие цифры просто не получить.
Слухи разные ходят, в том числе о том, что 6 ГБ из 10-и — не под видеопамять. На то они и слухи.
Тут дело в том, что когда ты расписываешь как оно будет, непонтяно откуда у тебя такие выводы. И при этом в ситуации когда о деталях консолей до сих пор только слухи, у тебя откуда-то полная уверенность.
К сожалению, я голословным утверждениям, как и гаданиям на кофейной гуще не склонен верить, уж извини.
Ну и почитай что ли текущие слухи про XBox Series X, если уж хочется. Там черным по белому сказано про то что для GPU будет доступно 10 ГБ ровно и 3.5 для игры (на меньшей скорости).
Так что оснований полагать что на ПК понадобится больше 10 ГБ видеопамяти по прежнему нет.
А про баг — да тут дело такое, что если код с утчеками, то условные 16 ГБ вместо 12 тебе позволят поиграть ну на 10 минут дольше, да и 24 ГБ тебе не сильно то помогут. Просто за такие игры надо тыкать в кнопочку «рефанд» пока производитель не снизойдет до того чтобы проводить нормальное тестирование перед продажей или хотя бы фиксить баги после.
Если оставить в стороне 8к, которого можно считать нет (и производительности карт в нем все равно недостаточно), в каких играх нужно больше 8 ГБ видеопамяти? (для профессионального применения отдельные карты так-то)
Не совсем так, AS/400 изначально выпускался на своих ЦПУ (система то старая, 1988 года, а Power относительно молодая архитектура — 1992 года).
Но да, не суть, мир мейнфреймов это совсем другой зверь где цена производства зачастую вообще не главное.
Но в целом программное отключение чего-то намного проще на уровне ОС и лицензий (в том числе аппаратных ключей) делать, чем иметь много разных вариантов микрокода.
Power/x86 стоит читать как «Power или x86». Мне казалось это очевидно в контексте.
Касательно MCM для zSeries — а можно пожалуйста ссылку или как это найти? Во всей документации что доступна — указано что там процессоры архитектуры z/Architecture а не Power. Какая конкретно модель или как это найти?
Как раз разные процессоры под задачу это нормально — это разные чипы в кремнии с разной ценой производства (показательно у ARMов с производительными ядрами и энергоэффективными). А вот микрокод не удешевлеят производства и странно тратить деньги на производство сложных чипов (Power'ы мягко говоря не маленькие, дорогие в производстве), когда часть чипа не используется.
RS/6000 — это название конкретного класса устройств, в их основе было несколько разных процессоров, включая PowerPC, зависит от конкретной модели.
AS/400 — также название класса мейнфрейфмов, где использовалось в зависимости от конкретной модели — разные ЦПУ на разных архитектурах.
Про millicode — да поищите по «millicode z15» например. Может и маркетинговый термин конечно, но по описанию прям похоже на описание выше про оптимизации под задачи.
Без особых проблем — это первые пару лет народ периодически сталкивался с косяками как раз из-за типов данных и длин указателей.
Про выравнивание — абсолютно серьезно. Простой пример — ты сделал структуру данных где есть char'ы, int'ы и еще что-нибудь, вот если ты как программист не подумал и расположил элементы в порядке: char, int, char *, то при попытке сделать atomic write на int на ARM выйдет очень неприятный сюрприз. О таком компилятор к сожалению или к счастью за программиста не думает. А программисты не привыкли думать что порядок элементов в структуре важен и может вызывать проблемы на других архитектурах. Так то сама структура конечно будет выровнена, но не элементы в ней.
Да по-разному. Портирование даже между близкими архитектурами зачастую интересная задача.
Очень простые примеры — размеры типов данных отличаются на разных архитектурах. Еще бывают всякие особенности, например работа с невыровненными указателями.
Например атомарные операции на переменной, адресс которой не выровнен по 4 байтам на 32-х разрядом ARM невозможен, а на 64-х разрядном может вызывать непредсказуемое поведение, для x86 же нет разницы в принципе. В целом чтение-запись по невыровненному адресу в ARM64 возможна, но очень дорогая, а для x86 опять же почти что все равно. Все связанное с SIMD требует переработки, потому что Neon в ARMе довольно странный и не имеет 1:1 соотношения с SSE/MMX даже.
Это только то что я с ходу вспомнил.
Архитектура сама по себе не оптимизирована под базы данных, это было бы очень странное решение. Это в целом такой же ЦПУ общего назначения как и другие.
Долгое время они были кстати очень популярны в суперкомпьютерах (по сути научные рассчеты), но сейчас их там потеснили Epyc'и и Xeon'ы.
Для Power/x86 только один микрокод и он служит не для оптимизации под задачу, а для исправления косяков.
Мейнфреймы слегка другая история и насколько я помню, IBMовские мейнфреймы (z15 например) вообще на своей архитектуре построены (z/Architecture собственно). Но и там вроде бы микрокод используется только для багфиксов в ЦПУ, но у них есть понятие Милликода, который может делать что-то похожее, но это не часть микрокода.
Очень много софта, который компилируется под конкретную архитектуру (так, как ни странно, ощутимо быстрее чем с любым интерпретируемым языком или с языками с виртуальной машиной). И это не говоря про то, что для очень критичных к производительности кусков приходится использовать ассемблер и зачастую знать особенности даже конкретной микроархитектуры (простой пример — декодеры и энкодеры видео, библиотеки по работе с шифрованием.и так далее).
В каких-то случаях достаточно просто пересборки будет, но не всегда.
Эмуляция — всегда потеря скорости, толкьо не надо забывать что на текущий момент то что ставят в ноутбуки с Windows 10 это довольно медленные варианты этого самого ARM (Snapdragon 8cx — по сути 855ый с чуть большей частотой, 4 «быстрых» ядра которые в лучшем случаи на уровне первого поколения Intel Core, я про i7-9xx серию, естественно на равной частоте, а остальные 4 ядра где-то на уровне Атомов). У Эпла ее A13 все же пошустрее — посмотрите как Photoshop и Lightroom на iPad'ах современных работает. Эмуляция это же не решение всех проблем, а лишь необходимость на переходный период, пока разработчики не портируют весь важный софт на новую платформу.
Но в целом поживем — увидим. Может особенно в начале и разделят, но никто не гарантирует что через 5 лет яблоки будут делать решения на x86 (поддерживать две платформы это сложно и дорого все таки)
Да, даже более плавный чем было с переходом с PPC. Ругань на «ваше приложение может не работать в новых версиях ОС» появилась чуть ли не с 10.11 или 10.12, разработчикам было рекомендовано еще раньше портировать свой софт под x86-64, да и в АппСтор 32-х битные приложения прекратили принимать задолго до релиза Каталины.
Собственно там есть просто прозрачный кусок стекла, где есть рамка и базовая информация о состоянии, рамка имеет коррекцию параллакса. Но самого дальномера нет.
Есть еще какие-то люди, которые на кикстартере собрали деньги на цифровую дальномерку с 16 мпикс матрицей (кажется) и почти ее вот-вот уже наверное выпустят, но это не точно (PIXII камера называется).
Ценник скорее всего там будет под 7-8 тысяч долларов.
Кому такое нужно -ну тем кому хочется либо немного элитарную камеру так сказать, либо тем кому хочется абсолютно уникальный в современном мире классический опыт (неспешную вдумчивую съемку как на пленке, но на цифру). То есть ниша есть своя собственная, за счет чего они и живы.
Например «18 Гббит/с» как скорость видеопамяти обычно не указывают одновременно с шиной.
К тому же 863 ГБ пропускной способности в даташите выглядит ужасно странно, ни с 320 битной шиной памяти, ни с 384 такие цифры просто не получить.
Тут дело в том, что когда ты расписываешь как оно будет, непонтяно откуда у тебя такие выводы. И при этом в ситуации когда о деталях консолей до сих пор только слухи, у тебя откуда-то полная уверенность.
Ну и почитай что ли текущие слухи про XBox Series X, если уж хочется. Там черным по белому сказано про то что для GPU будет доступно 10 ГБ ровно и 3.5 для игры (на меньшей скорости).
Так что оснований полагать что на ПК понадобится больше 10 ГБ видеопамяти по прежнему нет.
А про баг — да тут дело такое, что если код с утчеками, то условные 16 ГБ вместо 12 тебе позволят поиграть ну на 10 минут дольше, да и 24 ГБ тебе не сильно то помогут. Просто за такие игры надо тыкать в кнопочку «рефанд» пока производитель не снизойдет до того чтобы проводить нормальное тестирование перед продажей или хотя бы фиксить баги после.
А про батлфронт — типичный баг с утечкой памяти ж.
Но да, не суть, мир мейнфреймов это совсем другой зверь где цена производства зачастую вообще не главное.
Но в целом программное отключение чего-то намного проще на уровне ОС и лицензий (в том числе аппаратных ключей) делать, чем иметь много разных вариантов микрокода.
Касательно MCM для zSeries — а можно пожалуйста ссылку или как это найти? Во всей документации что доступна — указано что там процессоры архитектуры z/Architecture а не Power. Какая конкретно модель или как это найти?
Как раз разные процессоры под задачу это нормально — это разные чипы в кремнии с разной ценой производства (показательно у ARMов с производительными ядрами и энергоэффективными). А вот микрокод не удешевлеят производства и странно тратить деньги на производство сложных чипов (Power'ы мягко говоря не маленькие, дорогие в производстве), когда часть чипа не используется.
RS/6000 — это название конкретного класса устройств, в их основе было несколько разных процессоров, включая PowerPC, зависит от конкретной модели.
AS/400 — также название класса мейнфрейфмов, где использовалось в зависимости от конкретной модели — разные ЦПУ на разных архитектурах.
Про millicode — да поищите по «millicode z15» например. Может и маркетинговый термин конечно, но по описанию прям похоже на описание выше про оптимизации под задачи.
Про выравнивание — абсолютно серьезно. Простой пример — ты сделал структуру данных где есть char'ы, int'ы и еще что-нибудь, вот если ты как программист не подумал и расположил элементы в порядке: char, int, char *, то при попытке сделать atomic write на int на ARM выйдет очень неприятный сюрприз. О таком компилятор к сожалению или к счастью за программиста не думает. А программисты не привыкли думать что порядок элементов в структуре важен и может вызывать проблемы на других архитектурах. Так то сама структура конечно будет выровнена, но не элементы в ней.
Очень простые примеры — размеры типов данных отличаются на разных архитектурах. Еще бывают всякие особенности, например работа с невыровненными указателями.
Например атомарные операции на переменной, адресс которой не выровнен по 4 байтам на 32-х разрядом ARM невозможен, а на 64-х разрядном может вызывать непредсказуемое поведение, для x86 же нет разницы в принципе. В целом чтение-запись по невыровненному адресу в ARM64 возможна, но очень дорогая, а для x86 опять же почти что все равно. Все связанное с SIMD требует переработки, потому что Neon в ARMе довольно странный и не имеет 1:1 соотношения с SSE/MMX даже.
Это только то что я с ходу вспомнил.
Долгое время они были кстати очень популярны в суперкомпьютерах (по сути научные рассчеты), но сейчас их там потеснили Epyc'и и Xeon'ы.
Мейнфреймы слегка другая история и насколько я помню, IBMовские мейнфреймы (z15 например) вообще на своей архитектуре построены (z/Architecture собственно). Но и там вроде бы микрокод используется только для багфиксов в ЦПУ, но у них есть понятие Милликода, который может делать что-то похожее, но это не часть микрокода.
В каких-то случаях достаточно просто пересборки будет, но не всегда.
Но в целом поживем — увидим. Может особенно в начале и разделят, но никто не гарантирует что через 5 лет яблоки будут делать решения на x86 (поддерживать две платформы это сложно и дорого все таки)