Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 101
как такой процессор будет производить математические вычисления?
если я в калькуляторе наберу «6x9» я получу ответ «ну примерно 50-55»?
если я в калькуляторе наберу «6x9» я получу ответ «ну примерно 50-55»?
В статье же написано, что есть задачи, на которые точность, близкая к 100% необязательна.
Задачи может есть, но планшет то для людей. Представьте себя на месте человека, который зарабатывает не много и наконец решил купить планшет. Каково будет Ваше удивление когда калькулятор будет считать «примерно»?
Добавить мат. сопроцессор
Скорее наоборот: «неточный процессор» будет чем-то вроде сопроцессора для выполнения определенного класса задач. Сомневаюсь, что современные ОС могут работать на подобном железе. А вот использование их для ускорения декодирования видео на мобильных устройствах — самое то.
Как раз кодирование и декодирование видео — процесс, не требующий особой точности, и даже заведомо понижающий эту точность в процессе (я имею ввиду потери при кодировании).
Например, при декодировании можно «слегка промазать» и исказить mv или какой-нибудь из коэффициентов dct, картинка конечно исказится, но при ошибке 0.5% такие искажения будут происходить достаточно редко и будут достаточно малы, чтобы никто их не заметил.
Кстати, минимум в одном из аспектов обработки видео от 100%-й точности уже отказались несколько технологических поколений назад (примерно 15 лет назад). DV-tape ни в одной своей ипостаси не гаратировала отсутствия ошибок, и практически всегда при нескольких повторых считываниях одной и той же ленты вы могли получить слегка разные результаты. Это было возможно потому, что сам формат потока позволял — что dv, что mpeg (использовавшийся в hdv) быстро восстанавливается после ошибки.
Например, при декодировании можно «слегка промазать» и исказить mv или какой-нибудь из коэффициентов dct, картинка конечно исказится, но при ошибке 0.5% такие искажения будут происходить достаточно редко и будут достаточно малы, чтобы никто их не заметил.
Кстати, минимум в одном из аспектов обработки видео от 100%-й точности уже отказались несколько технологических поколений назад (примерно 15 лет назад). DV-tape ни в одной своей ипостаси не гаратировала отсутствия ошибок, и практически всегда при нескольких повторых считываниях одной и той же ленты вы могли получить слегка разные результаты. Это было возможно потому, что сам формат потока позволял — что dv, что mpeg (использовавшийся в hdv) быстро восстанавливается после ошибки.
Да ладно… Кроме преобразования Фурье в любом алгоритме кодирования и декодирования применяется ещё и сжатие без потерь, доступ к памяти по указателям, поиск по таблицам и т.д. Так что, не очень понятно, что означает: «декодирование видео не требует особой точности»?
JPEG — это определённый формат данных. Как вы будете обеспечивать этот формат, если запись байта по адресу A будет осуществляться с вероятностью ошибки 0.54%?
Короче, топикстартеру нужно было бы поискать ссылки не на рекламные буклеты, а на техническое описание процессора.
А то история напоминает потуги SUN сделать асинхронный процессор.
Короче, топикстартеру нужно было бы поискать ссылки не на рекламные буклеты, а на техническое описание процессора.
А то история напоминает потуги SUN сделать асинхронный процессор.
> JPEG это алгоритм. Алгоритм «сжатия»
Ну так этот алгоритм предполагает сохранение данных в определённом формате. Разве нет? Вы почитайте про алгоритм-то, там же не только преобразование Фурье, но ещё и сжатие по хэммингу и форматирование данных.
И потом, зачем так злобно реагировать. Я всего лишь написал, что нельзя говорить, что сжатие не требует «высокой точности вычислений». Оно в некоторых местах очень даже требует, при чём абсолютной. И просто сообщил, что ализару надо бы бросить уже привычку писать новости без ссылок на техническую документацию.
Потому что сейчас можно только догадываться, как работает этот процессор.
Ну так этот алгоритм предполагает сохранение данных в определённом формате. Разве нет? Вы почитайте про алгоритм-то, там же не только преобразование Фурье, но ещё и сжатие по хэммингу и форматирование данных.
И потом, зачем так злобно реагировать. Я всего лишь написал, что нельзя говорить, что сжатие не требует «высокой точности вычислений». Оно в некоторых местах очень даже требует, при чём абсолютной. И просто сообщил, что ализару надо бы бросить уже привычку писать новости без ссылок на техническую документацию.
Потому что сейчас можно только догадываться, как работает этот процессор.
Непонятно, почему минусуют. Ведь отчасти это правда.
Кодирование — декодирование ведется в основном целочисленной арифметикой для максимальной предсказуемости результата.
Да, во времена mpeg-1, когда кадры кодировались независимо, 0.5% погрешности были бы абсолютно не заметны. Но сегодня подавляющее большинство кодеков используют компенсацию движения и записывают разницу между двумя соседними кадрами, а ключевые кадры вставляются раз в несколько секунд (через сотни кадров).
А это значит, что если каждый кадр будет декодироваться с точностью 0.5%, то к следующему ключевому кадру картинка превратится в кашу (сам столкнулся с этим, когда делал декодер на MMX).
При этом ничто не мешает использовать такие процессоры для покадровой «Обработки» и «Анализа» видео а также в первой части алгоритма кодирования и последней части алгоритма декодирования, где искажения не принципиальны.
Кодирование — декодирование ведется в основном целочисленной арифметикой для максимальной предсказуемости результата.
Да, во времена mpeg-1, когда кадры кодировались независимо, 0.5% погрешности были бы абсолютно не заметны. Но сегодня подавляющее большинство кодеков используют компенсацию движения и записывают разницу между двумя соседними кадрами, а ключевые кадры вставляются раз в несколько секунд (через сотни кадров).
А это значит, что если каждый кадр будет декодироваться с точностью 0.5%, то к следующему ключевому кадру картинка превратится в кашу (сам столкнулся с этим, когда делал декодер на MMX).
При этом ничто не мешает использовать такие процессоры для покадровой «Обработки» и «Анализа» видео а также в первой части алгоритма кодирования и последней части алгоритма декодирования, где искажения не принципиальны.
Задачи есть, но непонятно при чем тут планшет, даже если он бюджетный. Исполняемый код прикладных программ вряд ли относится к таким задачам.
Сфера применения этих процессоров немного другая
Принуипиально по другому подойти к конструкции схем.
Процессор с обычной точностью отвечающий за математические вычисления, плюс процессор с пониженной точностью отвечающий за вывод видео (картинка будет немного глючной) и звука (звук будет иметь немного белого шума) получив примерно аналогичное нынешним китайским планшетам по качеству устройство с более чем в разы большей энергоэффективностью и дешевое.
Процессор с обычной точностью отвечающий за математические вычисления, плюс процессор с пониженной точностью отвечающий за вывод видео (картинка будет немного глючной) и звука (звук будет иметь немного белого шума) получив примерно аналогичное нынешним китайским планшетам по качеству устройство с более чем в разы большей энергоэффективностью и дешевое.
Математика на таких процессорах строится немного на других алгоритмах. Вычисления выполняются множество раз. Результат выполнения операции 6*9 будет «примерно» 54. Потом из этих результатов вычисляется среднее арифметическое, к примеру. Это число будет с большей точностью равно 54.
Проблема в том, что мы можем ошибиться и при подсчете среднего.
Конечно, можно, как в квантовых вычислениях, исправлять ошибки на лету. Но во-первых еще непонятно, достаточно ли их мало для этого, во-вторых — мы скорее всего потеряем на этом больше, чем сэкономим.
Конечно, можно, как в квантовых вычислениях, исправлять ошибки на лету. Но во-первых еще непонятно, достаточно ли их мало для этого, во-вторых — мы скорее всего потеряем на этом больше, чем сэкономим.
Потеряем — это да. Но эти процессоры созданы не для детерминированных случаев, все соль в вероятностях. Поэтому если вы хотите работать с четкими детерминированными значениями — вам придется поступиться производительностью.
Проблема в следующем.
«Обычные» вероятностные алгоритмы имеют очень простую модель — на вход, кроме входных данных, подаются результаты бросания монетки. И вероятность берется именно по бросаниям монетки: мы с вероятностью, например, 2/3 дадим правильный ответ. Тут можно очень легко повышать вероятность: запустим алгоритм много раз, и возьмем majority. Вероятность ошибки тут падает экспоненциально по числу запусков.
В квантовом компьютере, помимо того, что там все алгоритмы по своей природе вероятностны, еще и накапливаются ошибки при каждой операции (ибо линейные операторы на практике можно применить лишь с некоторой конечно точностью). При этом, если точность лежит в пределах границы Шора, можно (за счет хитрой конструкции квантовой схемы) исправлять эти ошибки «на лету». Но это требует существенного (хотя и полиномиального) усложнения схемы. Для квантовых компьютеров это усложнение непринципиально, ибо они нередко дают экспоненциальный выигрыш по времени.
Элементарная задача: посчитать дизъюнкцию 1000 переменных. Если результат операции с вероятностью 1% оказывается неправильным, то даже для тождественно нулевого входа мы с огромной вероятностью ответим «1».
И примерно такая же ситуация будет для большинства функций. На выходе мы получаем распределение, очень слабо зависящее от входа. *Каждый* бит выхода будет очень слабо зависеть от входа.
Мы же обычно хотим получать правильный ответ для любого (или хотя бы для почти любого) входа с большой вероятностью.
«Обычные» вероятностные алгоритмы имеют очень простую модель — на вход, кроме входных данных, подаются результаты бросания монетки. И вероятность берется именно по бросаниям монетки: мы с вероятностью, например, 2/3 дадим правильный ответ. Тут можно очень легко повышать вероятность: запустим алгоритм много раз, и возьмем majority. Вероятность ошибки тут падает экспоненциально по числу запусков.
В квантовом компьютере, помимо того, что там все алгоритмы по своей природе вероятностны, еще и накапливаются ошибки при каждой операции (ибо линейные операторы на практике можно применить лишь с некоторой конечно точностью). При этом, если точность лежит в пределах границы Шора, можно (за счет хитрой конструкции квантовой схемы) исправлять эти ошибки «на лету». Но это требует существенного (хотя и полиномиального) усложнения схемы. Для квантовых компьютеров это усложнение непринципиально, ибо они нередко дают экспоненциальный выигрыш по времени.
Элементарная задача: посчитать дизъюнкцию 1000 переменных. Если результат операции с вероятностью 1% оказывается неправильным, то даже для тождественно нулевого входа мы с огромной вероятностью ответим «1».
И примерно такая же ситуация будет для большинства функций. На выходе мы получаем распределение, очень слабо зависящее от входа. *Каждый* бит выхода будет очень слабо зависеть от входа.
Мы же обычно хотим получать правильный ответ для любого (или хотя бы для почти любого) входа с большой вероятностью.
Добавив к ошибкам программистов ошибки аппаратуры — получится хороший аппарат для швыряния об стену.
А вдруг они конпенсируют друг друга!
Теория надежности смотрит на вас укоризненно… )
Не смогут. Под одной простой причине.
> такие процессоры станут базой для бюджетных планшетов I-slate, которые появятся в продаже к 2013 году
К 2020 году в каждом втором устройстве будет стоять «китайский noname процессор».
К 2020 году в каждом втором устройстве будет стоять «китайский noname процессор».
Ваше письмо художественно пересказано и примерно успешно наверное доставлено наверное тому адресату, что вы писали.
Большенство математический операций с вещественными числами (float, double, ...) и сейчас выполняются «примерно», и при этом инженерные и графические расчеты хорошо работают. Идея имеет смысл, а игры может даже пореалистичней будут
Я теперь из-за этой фотографии спать не смогу :(
Гет взят (144144)
И всё-таки я не очень представляю, как это можно использовать. Вероятность правильного срабатывания же падает экспоненциально по числу операций. Т.е. при надежности 99% и 100 последовательных операциях на выходе мы получаем практически равномерное распределение.
Ну, например, при редактировании видео. Чтобы не загружать центральный процессор, мы можем временно перекинуть декодирование кадров на такой «плохой» процессор, чтобы получить примерную картинку. Также, можно использовать при генерации миниатюр, или при быстрой прокрутке видео.
Проблема в том, что если при каждой операции бит искажается с шансом 1%, то после 1000 (да, 100 тут мало, я ошибся) последовательных операциях мы получим результат, очень слабо зависящий от того, что было в начале.
А операция «найти цвет точки» далеко не атомарная — она требует многих сотен ассемблерных операций. А значит, то, что мы получим в результате, будет равномерно распределенной случайной величиной, не зависящей от правильного результата.
Даже редкие ошибки на уровне элементарных операций будут очень быстро накапливаться, и практически мгновенно приведут систему в совершенно случайное состояние. Просто в силу количества этих операций.
А операция «найти цвет точки» далеко не атомарная — она требует многих сотен ассемблерных операций. А значит, то, что мы получим в результате, будет равномерно распределенной случайной величиной, не зависящей от правильного результата.
Даже редкие ошибки на уровне элементарных операций будут очень быстро накапливаться, и практически мгновенно приведут систему в совершенно случайное состояние. Просто в силу количества этих операций.
«операция «найти цвет точки» далеко не атомарная — она требует многих сотен ассемблерных операций»
неужели то, что называется «аппаратное декодирование видео» с точки зрения ЦП выглядит как «сотня инструкций для каждой точки»? Я думал, там всё проще — я ему показываю на кусок ОЗУ с потоком и указываю кусок ОЗУ куда надо положить результат, даю одну команду — вуаля, вот он, кадр или хотя бы макроблок
я вполне удовлетворюсь, если такой макроблок будет отличаться от «совершенно точно рассчитанного» на 0.5%
неужели то, что называется «аппаратное декодирование видео» с точки зрения ЦП выглядит как «сотня инструкций для каждой точки»? Я думал, там всё проще — я ему показываю на кусок ОЗУ с потоком и указываю кусок ОЗУ куда надо положить результат, даю одну команду — вуаля, вот он, кадр или хотя бы макроблок
я вполне удовлетворюсь, если такой макроблок будет отличаться от «совершенно точно рассчитанного» на 0.5%
За одну команду процессор может обработать может только несколько байт информации. И, соответственно, не может полностью рассчитать кадр.
Более того, раскодирование происходит не state-less. Т.е. нельзя взять 8 байт, обработать их одним-двумя тактами, выдать результат на выход. Глубина схемы, отображающей раскодирование, очень велика. А значит, почти наверняка к каждому пути к выходу будут ошибки.
Более того, раскодирование происходит не state-less. Т.е. нельзя взять 8 байт, обработать их одним-двумя тактами, выдать результат на выход. Глубина схемы, отображающей раскодирование, очень велика. А значит, почти наверняка к каждому пути к выходу будут ошибки.
>операция «найти цвет точки» далеко не атомарная
Да, операция «построить ракету» тоже далеко не атомарная, и все физические измерения тех же болтов и гает отнюдь не без погрешностей, да, они, как ни странно, накапливаются. Однако при правильно построенном алгоритме ракета летает, а не превращается в равномерно-раздробленную массу металла.
Нас еще в старые добрые времена на черчении учили правильно проставлять размеры с учетом погрешностей, дабы в результате вытачивания детали она была похожа на то, что задумал конструктор, а не на кучу хлама. Тут главное подумать и правильно применить идею, а не говорить о невозможности реализации, иначе ничего в принципе реализовать нельзя.
Да, операция «построить ракету» тоже далеко не атомарная, и все физические измерения тех же болтов и гает отнюдь не без погрешностей, да, они, как ни странно, накапливаются. Однако при правильно построенном алгоритме ракета летает, а не превращается в равномерно-раздробленную массу металла.
Нас еще в старые добрые времена на черчении учили правильно проставлять размеры с учетом погрешностей, дабы в результате вытачивания детали она была похожа на то, что задумал конструктор, а не на кучу хлама. Тут главное подумать и правильно применить идею, а не говорить о невозможности реализации, иначе ничего в принципе реализовать нельзя.
Тем не менее, дерево операции «построить ракету» имеет гораздо меньшую глубину, чем дерево вычислений по любому нетривиальному алгоритму. И там всё непрерывно, а не дискретно. И накапливаются ошибки медленнее.
Для квантовых компьютеров есть граница Шора (ошибки ниже границы => их можно исправлять на лету и устраивать сколь угодно длинные вычисления, выше => максимальная длина вычисления ограничена). Скорее всего, что-то подобное можно сделать и для классических вычислений.
Вот только вопрос, насколько дорого обойдется это исправление на практике…
Для квантовых компьютеров есть граница Шора (ошибки ниже границы => их можно исправлять на лету и устраивать сколь угодно длинные вычисления, выше => максимальная длина вычисления ограничена). Скорее всего, что-то подобное можно сделать и для классических вычислений.
Вот только вопрос, насколько дорого обойдется это исправление на практике…
Человек на третьей фотографии, как зомби выглядит, жуть.
Как вообще это можно реализовать на уровне инструкций?
Понятно, что большинство вычислительных схем из численных методов здесь не применимы. На ум приходит только — заполнение памяти. Но и там же есть управляющие биты? Если ошибка придётся на них?
Понятно, что большинство вычислительных схем из численных методов здесь не применимы. На ум приходит только — заполнение памяти. Но и там же есть управляющие биты? Если ошибка придётся на них?
Что-то какая-то ерунда. Зачем аппаратно плодить ошибки точности, если почти всегда можно предложить программный алгоритм с потерей точности и большей скоростью. А тут жертвуем универсальностью процессора, но, допустим, даже при использовании как сопроцессора, чем он лучше GPGPU?
Энергопотреблением? Не?
Прочитайте пост еще раз
Переписывать весь софт, реализуя алгоритмы? Или оставить те же, но заменив некоторые «детальки» на более дешевые?
FLAC декодирование с «потерями» в самом декодере. Почему бы и нет.
FLAC декодирование с «потерями» в самом декодере. Почему бы и нет.
спасибо за минусы, вы, похоже больше чем я написали алгоритмов декодирования видеопотока, фильтров обработки изображений, звуковых кодеков, и конечно, прекрасно понимаете, что все используемые алгоритмы сойдутся, даже при наличии недетерминированных погрешностей. например алгоритм поиска локальных экстремумов методом Ньютона — прекрасно сойдется при наличии ошибок. и, конечно, же, ошибки в процессе вычисления не накапливаются, и при относительной погрешности в 1% за 100 циклов результат не превратится в случайную величину.
а это я к чему, что при ситуации, как она описана в статье, под этот процессор алгоритмы придется переписывать полностью. а под обычный x86 достаточно будет уменьшить количество итераций некоторых методов, уменьшить размер ядра фильтров и т.п… при той же, причем детерминированной погрешности.
а это я к чему, что при ситуации, как она описана в статье, под этот процессор алгоритмы придется переписывать полностью. а под обычный x86 достаточно будет уменьшить количество итераций некоторых методов, уменьшить размер ядра фильтров и т.п… при той же, причем детерминированной погрешности.
а под обычный x86 достаточно будет уменьшить количество итераций некоторых методов, уменьшить размер ядра фильтров и т.п…Это уменьшит размеры и энергоэффективность процессора в разы?
К тому же, они там уже планшет собираются на нём выпустить, так что вполне возможно, что допуск ошибок в 0,25% не вредит большинству алгоритмов. И учтите, что допуск ошибок != погрешность.
Этот процессор вполне подойдет для решения задачи определения правильного маневра на сверх-звуковых истребителях, когда менее чем за секунду нужно принять решение, какой маневр выполнить. Обычные электронные подсказки не успевают помогать, а этот вполне справится. Всего делов-то — оценить обстановку и вывести стрелочку на стекло шлема.
Раз в 400 раз будет показывать не туда (при допуске 0,25%).
Или же раз в 12 раз (8%)
Или же раз в 12 раз (8%)
Просто погрешность в 8% при определении опасности не так важна, как скорость. Пусть он даже ошибается один из 10, это все равно огромная помощь пилоту. В каждом маневре нет показателя его правильности, есть ожидаемая ситуация при определенных действиях, поэтому важно просто быстро принять решение, а если оно еще и улучшит положение, вообще шикарно. Лет 10 назад пилоты еще сами определяли, что делать, на основании приборов (поскольку часто ощущения подводят при перегрузках) и выигрывали бои. Небольшая подсказка просто даст знать, что советует компьютер, и не факт, что пилот примет эту подсказку.
А как угадывать, в данной ситуации верно или неверно? Может компьютер так ошибся, что поведёт пилота, следующего этой подсказке, прямо в пике, из которого уже нельзя будет выйти?
Никак не угадывать. Неверных шагов в принципе нет. Есть шаги, приводящие к более выгодной ситуации и к менее выгодной. Пилот сам принимает решения, иначе был бы давно построен идеальный компьютерный пилот. Просто бывают моменты, когда пилоту сложно достоверно оценить ситуацию и принять решение (в момент перегрузок или в субъективно равноценных ситуациях), в этом случае пилот может обратить внимание на подсказку компьютера.
Пусть пять, десять, двадцать таких процессоров мгновенно оценивают ситуацию, а собирает от них данные обычный компьютер с точным процессором и уже делает вывод, какую подсказку дать.
Пилотирование истребителей, это не программирование, где каждый шаг можно просчитать. Увы. Поэтому просто быстрый анализ ситуации с рекомендованным маневром (да пусть даже простую стрелочку рисует ) — уже подспорье.
Насколько я знаю, сейчас выводится диагностика текущей ситуации, а с такими процессорами можно успеть и прогнозировать вперед на пяток секунд.
Пусть пять, десять, двадцать таких процессоров мгновенно оценивают ситуацию, а собирает от них данные обычный компьютер с точным процессором и уже делает вывод, какую подсказку дать.
Пилотирование истребителей, это не программирование, где каждый шаг можно просчитать. Увы. Поэтому просто быстрый анализ ситуации с рекомендованным маневром (да пусть даже простую стрелочку рисует ) — уже подспорье.
Насколько я знаю, сейчас выводится диагностика текущей ситуации, а с такими процессорами можно успеть и прогнозировать вперед на пяток секунд.
Ализар, удали последнее предложение.
Напомнает язык программирования Entropy esolangs.org/wiki/Entropy
Если допускать до 99-100% ошибок, то процессоры можно делать из дерева! Экологично и стильно.
И всё же программы работают именно в таких условиях. Есть вероятность, что пролетающая частица изменит какой-нибудь бит. Правда, вероятность этого всё же не 1%, а намного, намного ниже — на поверхности. А вот в авиации и особенно в космосе это уже проблема, которую, впрочем, решают аппаратными, а не программными методами.
Любая схема срабатывает правильно лишь с определенной вероятностью. Другое дело, что как правило эта вероятность *очень* близка к единице.
Любая схема срабатывает правильно лишь с определенной вероятностью. Другое дело, что как правило эта вероятность *очень* близка к единице.
Но в любом случае, любая схема на практике работает правильно лишь с некоторой меньшей единцы вероятностью.
Другое дело — что да, обычно аппартаными средствами делают это отличие столь малым, чтобы его можно было не учитывать при разработке схем и написании программ.
Если я правильно Вас понял, то Вы утверждаете именно что любая современная мат. модель классических вычислений не учитывает ошибок на уровне схемы. С этим я согласен.
Другое дело — что да, обычно аппартаными средствами делают это отличие столь малым, чтобы его можно было не учитывать при разработке схем и написании программ.
Если я правильно Вас понял, то Вы утверждаете именно что любая современная мат. модель классических вычислений не учитывает ошибок на уровне схемы. С этим я согласен.
>Если я правильно Вас понял, то Вы утверждаете именно что любая современная мат. модель >классических вычислений не учитывает ошибок на уровне схемы. С этим я согласен.
Да.
Почему? Такие модели существуют. Какая-нибудь вероятностная машина Тьюринга. Нет?
Да.
Почему? Такие модели существуют. Какая-нибудь вероятностная машина Тьюринга. Нет?
В вероятностной машине Тьюринга случайность только в одном: ей дается на вход дополнительная лента, содержащая случайные биты. Функционирование самой машины выглядит как обычно.
Вообще бывают конечные автоматы со случайностью — т.е. для каждая пара (входной символ, состояние) задает распределение на множестве {(выходной символ, состояние)}. Но вряд ли это можно будет использовать в этих задачах.
Вообще бывают конечные автоматы со случайностью — т.е. для каждая пара (входной символ, состояние) задает распределение на множестве {(выходной символ, состояние)}. Но вряд ли это можно будет использовать в этих задачах.
Затаил дыхание: до реализации вероятностного двигателя осталось совсем немного :)
errare robotum est
Еще не запостили?
— Папа, сколько будет пятью шесть?
— (прикинув на НЛке) где-то 28-31.
На следующий день:
— Папа, мне математичка 2 поставила, сказала, что правильный ответ — 30!
— (Поточнее прикинув на НЛке) Ну да, 30. Но нахуя такая точность?
одному мне название поста напомнило «невероятностный двигатель» из «автостопом по галактике»?
Чем-то это напоминает мозг человека. Невероятные возможности по распознаванию и обработки видео, звука, но посчитать что-то вроде 569*482 в уме очень сложная задача.
Почему-то вспоминаются чуть плавающие концы полигонов в первой Playstation.
Тег: британские учёные
Если я не ошибаюсь, то как раз пакет расширенных инструкций 3DNOW! от AMD обеспечивал вычисления с меньшей точностью, которая была менее важна для 3D игр, что на время дало не хилый профит для процессоров AMD. Допускаю, что и сейчас могут найтись применения подобным технологиям.
Странный камень канечно, интересно почитать спеки. И вот еще интересно — если он ваще «полностью» не точный, то можно будет поиметь много лулзов наблюдая за тем, как камень молотит рандомную дату по рандомному адресу в памяти ))) Логично было бы сделать все операции сравнения, записи/чтения в память, счетчик инструкций и тд — точными, как в обычных процессорах, а вот команды деления/умножения и прочие «медленные» операции — с погрешностью. Тогда может что-то и будет. А еще лучше какую-нить управляющую команду, которая будет переключать с точных вычислений на неточные и наоборот, флаг какой-нить. Ибо иногда все-же точно считать надо, даже в большинстве случаев, имхо.
На сколько я понял из статьи, а конкретно из вот этого места: «Slash power use by allowing processing components — like hardware for adding and multiplying numbers — to make a few mistakes. By cleverly managing the probability of errors and limiting which calculations produce errors, the designers have found they can simultaneously cut energy demands and dramatically boost performance.» — не все вычисления были сделаны «неточными». Условно, перемножать матрицы из чисел с плавающей запятой, чтобы произвести обработку видеосигнала — это одно, а складывать целые, чтобы потом осуществлять переходы — это другое. Во втором точность критична, и даже 0.0001% ошибок неприемлем, а во втором может быть и 5% незаметные для пользователя.
Меня одного до смерти пугает этот мужик на фотке?
Так вот откуда в нашей вселенной принцип неопределенности Гейзенберга! Если мир был создан, похоже, создатели сэкономили на питании))
а у меня идея! а что если на неточном процессоре написать программу которая будет сама себя копировать?? программка будет себя копировать и иногда будут появляется ошибки, чтоб приведет к появлению более лучших программ, это эволюцию в чистом виде! программы будут эволюционировать!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создан прототип неточного процессора