Zealint писал(а):
Я неявно предполагал, что уменьшение числа операций как раз позволит освободить место и сделать больше регистров, больше схем для независимых арифметических действий. Представьте, что если убрать весь мусор из x86, то на уровне микроархитектуры в тот же объём, наверное, можно будет всунуть ещё пару десятков регистров, увеличить кэш в разы и тогда одна из самых частых операций в моих программах (сумма чисел) будет работать быстрее именно за счёт того, что очень много регистров будут складываться параллельно.
Вы заблуждаетесь просто глубочайшим образом. Львиную долю площади кристалла современных мощных процессоров занимает именно кэш, поэтому сколько-нибудь значительно его нарастить не удастся. Поддержка же всякого мусора архитектуры IA-32 (а эта архитектура -- действительно одна из самых ужасных) требует лишь мизерных дополнительных затрат аппаратуры по сравнению с общим объёмом последней. Соответственно, ни о каком сколько-нибудь значительном выигрыше в производительности из-за отказа от неё говорить не приходится. (Собственно, именно поэтому среди процессоров общего назначения интеловские являются лидерами по производительности, несмотря на идиотскую систему команд -- наличие всякой дури усложняет их разработку и т.д., но не налагает принципиальных препятствий в достижении высокой производительности).
Цитата:
Не совсем понятно замечание по поводу модулярной арифметики. Если мы объединим в одну инструкцию сложение и взятие остатка, то разве не уменьшит это размер самой операции? Разве не станет от этого более эффективно работать кэш команд? И разве не сможет процессор исполнять больше таких независимых команд за одно действие?
Я не математик и не знаю, что такое модулярная арифметика, поэтому конкретно о ней сказать ничего не могу. Что же касается объединения нескольких операций в одну команду, то да, это позволяет поднять производительность -- и это одна из причин, почему CISC-процессоры архитектуры IA-32 (причём плохой CISC-архитектуры) оказываются в
общем случае существенно быстрей, чем RISC-процессоры -- правда, ценой усложнения самого процессора. По этой же причине в 1980-х -- начале 1990-х быстрей были RISC-процессоры -- тогдашний технологический уровень не позволял впихнуть сложные схемы, связанные с декодированием сложных команд и их суперскалярным исполнением на один кристалл, поэтому, пока CISC медленно и печально (из-за ограничений по количеству транзисторов) выполнял одну сложную команду, RISC действительно успевал выполнить несколько простых. Сейчас ситуация поменялась: хотя RISC, конечно, тоже можно усложнить и заставить выполнять несколько команд параллельно (это давно сделано, кстати), но они упираются в пропускную способность памяти и ёмкость кэша -- а эти вещи, в отличие от логической сложности управляющих или исполнительных блоков процессора, нарастить куда сложней, а иногда и невозможно.
Другое дело, что не всякое объединение нескольких операций в одну оказывается реально полезным на широком круге задач. К примеру, меня на ARMе сильно напрягает его единственная имеющая место быть RISC-особенность -- выполнение операций только и исключительно в регистрах. Из-за этого мне постоянно писать три команды там, где на CISC обычно достаточно одной -- например, для инкремента/декремента счётчика использования некоего объекта. Здесь наличие команд, работающих с операндами прямо в памяти, было бы очень полезным и для ручного программирования на ассемблере, и (потенциально) в плане повышения производительности. Однако вводить в процессор команду, которая нужна 0,0001% приложений, выполняемых на данном процессоре, обычно неразумно, особенно если она требует для своей реализации каких-то особых исполнительных блоков.
Цитата:
По поводу генератора простых чисел там не описка. Чтобы выполнить расчёты по модулю, нужны, как правило, простые числа (иногда хватает более слабых ограничений – попарно взаимно простых чисел, но простые более удобны по ряду причин). Почему бы не генерировать их аппаратно?
Повторюсь, я не математик, но, насколько понимаю, простые числа известны заранее? Это ж вроде 1, 3, 5, 7, 11, 13, 17 и т.д. (которые ни на что не делятся нацело, кроме как на 1 и на самого себя)? Но зачем нужен
генератор этих чисел? Понадобилось такое число -- возьмите да загрузите его из памяти в регистр и не тратьте в процессоре место на хранение констант, тем более нужных для очень узкого класса задач!
Цитата:
Мне почему-то этот стереотип по поводу быстроты аппаратной реализации над программной не кажется столь уж необоснованным. Я вижу это так, действуя по аналогии. Допустим, мы программируем алгоритм, состоящий из нескольких независимых операций А, Б и С. И вдруг оказывается, что у них есть что-то общее (хотя бы даже взятие операторов из памяти), мы это общее «выносим за скобки» - и упрощаем набор действий. Теперь, допустим, есть электронная схема, «зашитая» в процессор. Допустим, есть операции А и Б. Есть отдельная схема для А, есть отдельная схема для Б. Вот, мы решили, что нам нужна операция АБ (сумма + взятие остатка, например). Разве у них совсем нет общих элементов на уровне микроархитектуры? Я не знаю, как в процессоре устроены эти операции, но разве нельзя, посмотрев на схемы внимательно, объединить их в одну? С точки зрения математики, я не вижу такого способа, а с точки зрения электроники? Например, после операции сложения, не помещать промежуточные данные в регистр, чтобы потом вызвать операцию взятия по модулю для этого регистра, а сразу подсоединить выводы сумматора к блоку взятия модуля?
Можно, только скорость выполнения операций при этом соответствующим образом упадёт. Причём любых операций. Поэтому последовательное соединение нескольких блоков давным-давно никто не использует. Мощный процессор выполняет несколько разных (или не очень разных) операций параллельно, а его управляющая логика следит за тем, чтобы при этом не нарушалась концептуальная последовательность действий, определённая в программе. Более того, процессор может выполнять операции, следующие в программе после некоторой, до того, как эта некоторая операция закончится -- но, естественно, при условии, что они не пользуются данными, вырабатываемыми этой некоторой командой. Всё это называется внеочередным (out-of-order) исполнением и появилось ещё в конце 1960-х, но тогда, понятно, лишь на самых мощных машинах. Сейчас это есть в любом процессоре Intel Core, хотя отсутствует, например, в Атомах -- это одна из причин, почему они жрут намного меньше энергии, но при этом и работают существенно медленней.
В общем, хорошо построенный высокопроизводительный процессор сам сможет "спарить" те операции, которые реально можно выполнить параллельно, и не будет, например, лишний раз обращаться за операндами в памяти, если они уже оттуда были загружены. Так что только из-за этого вводить дополнительные инструкции смысла нет; это надо делать лишь тогда, когда за счёт введения новых инструкций удастся серьёзно увеличить плотность операций в программе (т.е. число элементарных операций, кодируемых в одном и том же объёме памяти) -- чтобы процессор как можно меньше простаивал из-за того, что нужных команд в кэше не оказалось (а кэш не резиновый и многократно увеличить его объём невозможно; повысить производительность подсистемы памяти также нельзя, иначе б это давно сделали).
Цитата:
Если бы я разбирался в этих схемах, то, может, нашёл бы возможность что-нибудь там упростить при таком объединении двух операций. Знаете, всё-таки я не верю, что эти операции совсем-совсем разные, что у них нет ничего общего
Знаете, на одном форуме по электронике некий человек никак не хотел поверить другим в то, что наличие в процессорных ядрах Cortex-M4 сопроцессора для операций с плавающей запятой одинарной точности (32 бита на число) абсолютно никак не может быть использовано для повышения производительности при обработке чисел с плавающей запятой двойной точности (64 бита). Дело как раз в том, что он понятия не имел, как числа представляются в двоичном виде и как они обрабатываются -- и при этом упорно не желал верить тем, кто эти вещи знает. (Это не в обиду Вам говорю, а как иллюстрацию заблуждений, связанных с незнанием предметной области).
Если на то пошло, у любой "железной" реализации любой операции есть общие вещи -- например, все они реализуются на транзисторах
Но такой общности обычно маловато будет, чтобы получить какой-то особый выигрыш. К примеру, операции сложения, вычитания и логические действительно выполняются одним и тем же арифметико-логическим блоком, но, во-первых, понятно, что в момент, когда этот блок выполняет, скажем, "логическое И", он не может одновременно выполнять сложение -- ведь обе операции выполняются, используя одни и те же логические элементы. Во-вторых, подобное совмещение не всегда позволяет получить наивысшую скорость, ведь приходится ориентироваться на самую медленную из выполняемых операций.
Цитата:
Мой второй аргумент в пользу объединения операций в одну состоит в следующем. Допустим, мы хотим сложить два числа, размером 64 бита. Мы можем вызвать одну команду add на 64-битовыми регистрами, а можем две add / adc над 32-битовыми. Первый способ будет быстрее, но второй, который, как Вы говорите, является комбинацией уже реализованных блоков, будет всё-таки медленнее.
В теории -- да, на практике -- не всегда. Более того, поддержка 64-разрядных операций может сделать процессор более медленным. Например, первые интеловские 64-разрядные процессоры архитектуры IA-32 (ядра Core 2) в 64-битном режиме работали медленнее, чем в 32-битном. Этому явлению может быть несколько причин. Принципиальной проблемой является одна: в логических операциях (AND, OR, NOT, XOR) пары битов операндов действительно обрабатываются параллельно и независимо от других пар, поэтому результат что для 1-разрядной операции, что для 100500-битной операции будет получен за одно и то же время, лишь бы у нас было 100500 однобитных устройств, выполняющих эту операцию и работающих параллельно. В вот в сложении и вычитании есть такая вещь, как перенос/заём, т.е. реально отдельные пары битов не могут быть обработаны независимо и подлинно параллельно друг от друга: приходится передавать перенос/заём от младших битов к старшим. Вычисление этого переноса/заёма, передача его наверх, учёт его там требуют определённого времени. Поэтому, чем более широкой является операция сложения или вычитания, тем медленнее она работает. Поэтому концептуально 64-разрядный сумматор будет в 2 раза медленнее 32-разрядного.
На практике используют так называемый ускоренный перенос, когда значения межразрядных переносов формируются и учитываются специальными схемами не последовательно, а параллельно. Но это требует очень большого объёма аппаратуры. Вот пример реальной схемы:
Эта схема микросхемы К1804ВР1, содранной в своё время с какой-то буржуйской из комплекта Am29xx. Одна изначально предназначена для соединения четырёх 4-битовых микропроцессорных секций для создания 16-разрядного вычислительного устройства, т.е. обеспечивает параллельную генерацию переносов для входов переноса каждой из трёх секций (кроме младшей, в которую перенос подаётся откуда-то снаружи). Выходами переносов здесь являются CX, CY и CZ. Легко заметить, что сложность схем нарастает: CX генерируется логическим элементом 2,2И-2ИЛИ-НЕ, CY -- 3,3,2И-3ИЛИ-НЕ, CZ -- 4,4,3,2И-4ИЛИ-НЕ. Точно такие же схемы потребуются для организации
быстрых межбитных переносов, хотя в реальности часто делался последовательный перенос внутри секции (2-битовой К589ИК02, 4-битовых К1800ВС1, К1804ВС1 и ВС2, 8-битовой К1802ВС1) и параллельный ускоренный между секциями. Понятно, что сейчас транзисторы -- не столь дефицитный ресурс, как раньше, и параллельный перенос можно использовать более широко, но по-любому приходится считаться с тем, что при увеличении разрядности в 2 раза объём аппаратуры возрастает куда более существенно, а отнюдь не тоже в 2 раза. Более того, с увеличением разрядности растут, понятное дело, геометрические размеры схемы, а значит, возрастает время распространения сигнала (он же не мгновенно передаётся). Всё это и приводит в итоге к тому, что наращивание разрядности элементарной операции далеко не всегда способствует реальному повышению производительности даже при обработке данных большой разрядности. Что же касается более частых случаев обработки данных малой разрядности, то с ними ситуация будет как раз хуже, и в результате итоговая производительность может оказаться ниже.
Цитата:
С какого размера операция сложения начинает тормозить?
С любого; вопрос лишь в том, до какого предела можно эффективно использовать схемы ускоренного переноса.
Цитата:
А умножения и деления?
Умножение в теории может выполняться параллельно: частичные произведения никак не зависят друг от друга и могут быть сформированы параллельно, а затем их надо всего лишь сложить. Формирование частичных произведений в двоичной системе элементарно: это либо 0, либо значение множимого в зависимости от значения текущего бита множителя. А вот сложение приходится выполнять уже не двух чисел, а стольки, какова разрядность сомножителей. 32-входовый сумматор -- вещь, допускаемая теоретически, но не практически. Поэтому реально умножение выполняется в той или иной степени последовательно. Например, в такте 1 производится формирование всех частных произведений (скажем, их 32 -- для 32-разрядного умножения), в такте 2 они складываются попарно и получается 16, в такте 3 -- опять попарно и получается 8... Ну, Вы поняли
Для повышения производительности это выполняется конвейерным образом: хотя одно умножение длится достаточно долго (пока не пройдёт через весь конвейер), каждый такт можно запускать новое умножение, поскольку в каждом такте используется лишь один набор сумматоров. В результате, хотя латентность операции велика (несколько тактов, и тем больше, чем выше разрядность), при следовании нескольких умножений подряд создаётся впечатление, что каждое выполняется за один такт. (Но понятно, что, если результат умножения требуется прямо в следующей операции, она вынуждена будет ждать, пока умножение не закончится, поэтому оптимизация кода программы здесь может оказаться очень полезной).
Что же до деления, то оно принципиально не может быть выполнено параллельно, ведь результат каждой следующей стадии операции зависит от результата предыдущей. Вспомните деление на бумажке в столбик: мы постепенно вычисляем цифры частного, каждый раз получая промежуточный остаток, чтобы на следующей итерации опять вычислить ещё одну цифру частного, и так до тех пор, пока остаток не станет меньше делителя. Точно так же вынуждена работать и машина -- это принципиальное ограничение. Разница лишь в том, что в слабых машинах (но где деление в виде отдельной команды таки было -- а ведь во многих деления нет вообще) деление выполняется с формированием лишь одного бита частного за такт, а в более мощных может формироваться несколько битов. Это достигается тем, что деление может выполняться не в двоичной, а в четверичной, восьмеричной, шестнадцатеричной системе... Но, понятно, всё это резко увеличивает объём аппаратуры. Так, для деления в двоичном виде достаточно сравнить текущие старшие разряды делимого с делителем, чтобы понять, нужно ли записать в частное 0 или 1; после этого выполняется либо вычитание и сдвиг, либо просто сдвиг (всё деление -- это последовательность сравнений, сдвигов и вычитаний). А в шестнадцатеричном виде надо провести одновременно 16 сравнений -- а значит, одних компараторов нужно 16 штук. По этой причине в большинстве ARMов, даже суперсовременных, команды деления нет: программная её реализация будет работать ненамного медленней простой аппаратной, а на сложную аппаратную требуется слишком много ресурсов, что больно бьёт и по цене процессора, и по его энергопотреблению (а одна из основных сфер применения ARMов -- мобильные штучки вроде телефонов и планшетов).
Цитата:
Я понимаю, что Вы имеете в виду, когда говорите, что мой ПМ (процессорный модуль) будет медленно взаимодействовать с ЦП, ведь они будут передавать друг другу данные по медленной шине. Но я предполагаю, что есть способ как-то «близко» подключить ПМ к ЦП, чтобы взаимодействие стало быстрым. Или это невозможно никак? Насколько я понимаю, раньше кэш L3 на многих процессорах был на отдельном кристалле, но он же не тормозил из-за этого. Или я не о том думаю?
В "древности" кэш выполнялся на отдельных микросхемах снаружи и всё равно давал прирост быстродействия. Но надо не забывать, что и сами процессоры тогда работали много медленней. Например, самые быстрые процессоры эпохи Intel 80486 имели тактовую частоту 133 МГц (это были AMD 586, насколько помню) -- ну а у современных процессоров той же архитектуры она превышает 3,5 ГГц (а, например, у мэйнфреймов IBM составляет 5,2 ГГц -- правда, там архитектура совсем другая, но в данном случае это не важно). Ну а чем выше частота, тем большую роль в качестве ограничителя быстродействия играет время распространения сигнала между двумя схемами. Кроме того, длинные связи означают наличие большого числа помех (ведь дорожки работают как антенны, собирая всевозможный радиошум). Именно эти два фактора и определяют весьма малую скорость передачи данных по любым внешним шинам по сравнению с внутрипроцессорными. Единственный способ заметно снизить время передачи -- объединить несколько устройств на одном кристалле, что и делается по мере возможности. Однако здесь мы упираемся и в допустимое число элементов на одном кристалле с точки зрения их физической вмещаемости (уже сейчас размер транзистора составляет всего несколько сотен атомов), и в проблемы с отводом тепла. Последняя, кстати, крайне важна. Именно из-за неё все современные процессоры делаются на КМОП-транзисторах, хотя сама по себе КМОП логика
крайне медленная. Это хорошо видно на микросхемах 70-х годов, где число транзисторов на кристалле было мало, а поэтому не было особых проблем с теплоотводом: выполненные по одинаковым технологическим нормам, т.е. имеющие близкий размер транзистора, логические элементы на КМОП-транзисторах имели задержки в 100-300 наносекунд, а на биполярных -- от нескольких десятков (ТТЛ) до нескольких (ЭСЛ) наносекунд. Это соотношение сохраняется и сегодня: ЭСЛ-логика по-прежнему самая быстрая, на втором месте идёт ТТЛ (точней, её вариант ТТЛШ -- на биполярных транзисторах Шоттки, а не на обычных, но сие для нас не играет особой роли), а в хвосте плетётся КМОП. Но при этом ЭСЛ жрёт очень много энергии, ТТЛ -- поменьше, но тоже много, а КМОП -- мизер (идеальный КМОП-транзистор вообще энергии не потребляет; реальные, естественно, её тратят, но в сотни или тысячи раз меньше, чем биполярные).
Цитата:
Вот я и думаю, почему бы не сделать сразу ОС и СКА одновременно, чтобы СКА была бы неотъемлемой частью ОС и диктовала бы её развитие
ОС и СКА -- это абсолютно разные задачи, не связанные между собой. Сваливая их в одну кучу, вы получите... Ну, получите в итоге кучу дерьма, не годящуюся вообще ни для чего. Ведь всё это дело придётся развивать, а развивать одну большую систему куда сложней, чем 2-3-5-10 систем поменьше, хотя в совокупности функционал последних может быть больше, чем одной большой. В общем, не надо валить совершенно разные задачи в одну кучу.
Цитата:
Либо систему должен разрабатывать профессиональный учёный
Знаете, с моей точки зрения, одна из причин отставания советской вычислительной техники от американской была связана как раз с тем, что у нас её разрабатывали учёные, а у них -- бизнесмены. В результате, когда академик Глушко, если мне не изменяет памяти, в середине 1960-х предложил озаботиться тотальным "асучиванием" (т.е. внедрением АСУ -- автоматизированных систем управления) народного хозяйства, чтобы кардинально повысить качество управления, неожиданно выяснилось, что аппаратной базы для этого у нас
нет вообще. Именно вообще: те машины, что были, годились лишь для научно-технических расчётов, да и то со сравнительно небольшими объёмами данных. В итоге это вылилось в копирование передовых на тот момент американских архитектур (IBM System/360, DEC PDP-11 и ещё парочки) -- но решение об этом тоже было принято с большим опозданием, в конце 1960-х. Ещё хуже было с элементной базой: наши гениальные учёные витали в облаках, а инженерам, которые реально что-то воплощали в жизнь, приходилось иметь дело со всяким дерьмом (ведь доступа в Политбюро у них не было, туда были вхожи лишь академики -- а эти академики совершенно не понимали реальных потребностей). У нас жутко нахваливают нашу БЭСМ-6 -- дескать, аж целый миллион операций в секунду! Но она пошла в серию в 1967 году и была сделана на дискретных транзисторах, а у американцев уже вовсю выпускались мэйнфреймы на микросхемах, делающие 6-7 миллионов операций в секунду. Про архитектуру я вообще промолчу: у нас она была попросту ужасна (хотя, естественно, и иностранные не без изъянов -- идеальной архитектуры пока что никто не придумал).
В общем, академическая братия, за редким исключением, не видит дальше собственного носа и очень плохо представляет себе всякие низменные материи вроде тех же транзисторов и их энергопотребления. Кроме того, для любого человека свойственно считать свою работу самой важной и т.д., но в реальной-то жизни это не так. Лично Вам и Вашим коллегам по науке "гигаразрядные" операции, наверное, действительно важны -- но подавляющему большинству народа приходится решать совершенно другие задачи, где и требования совершенно другие. Возможно, Вы бы (ну, не лично Вы, а инженеры по Вашему техническому заданию) смогли бы сделать машину, которая удовлетворяет Вашим требованиям -- но она, по всей вероятности, оказалась бы абсолютно бесполезной для 99,99% других людей. Ну а отвратительная архитектура IA-32, несмотря на всю свою кривизну, всё ж в состоянии удовлетворить требования пускай не 99,99% людей, но хотя бы 70-80% -- т.е. на практике она оказывается целесообразней Вашей архитектуры.
Цитата:
Да, свежесть была не первой. Но я и сам удивился, ведь наш «научный» центр заказал этот кластер в 2009 году. Сказать, что уже тогда это было ведро с гвоздями – это ничего не сказать. Более того, недавно, буквально год-два назад, наш университет тоже купил ведро с гвоздями, причём подержанное из 90-х! И, что самое безответственное с их стороны, они даже не проконсультировались со мной, как с единственным на тот момент человеком, который мог бы что-то подсказать из своего опыта, хотя именно мою команду собирались на этот кластер посадить. Потом меня выбросили, а ведро с гвоздями теперь ржавеет. Я пытался понять, зачем его купили, и выяснил, что оказывается, в рейтинге вузов есть такой пункт «наличие кластера». Вот руководство и решило выполнить этот пункт. Бестолочи : )
Они не бестолочи -- они выполняют свои личные задачи. Просто их задачи (повыситься в рейтинге и распилить бабло) отличаются от Ваших задач
Цитата:
Такой ситуации не может быть, если у нас миллионбитные регистры, значит они сначала полностью загружаются слагаемыми, а затем складываются без проблем
Как я уже говорил (а если не верите мне, то можете поискать информацию сами), кэш сейчас занимает основную часть площади кристалла. Суммарная ёмкость кэшей всех уровней во всех ядрах, а также внутренних регистров процессора (их отнюдь не 8 или 16, как то видит программист -- их в высокопроизводительных процессорах сотни или тысячи) составляет порядка 20 Мбайт, т.е., грубо говоря, порядка 100 млн. бит. Соответственно, если у Вас в процессоре регистры имеют размер миллион бит, то Вы сможете впихнуть в процессор порядка сотни таких регистров -- при этом не останется места под кэши. Какая у Вас будет производительность, а?
В общем, громадные числа можно хранить только в оперативной памяти -- а одна намного медленнее, чем кэши и тем более чем регистры внутри процессора. И это ограничение является фундаментальным, с которым ничего поделать нельзя. Позволю себе поддеть Вас и вообще "математиков": разница между теорией и практикой на практике намного больше, чем в теории
Цитата:
Сама концепция свопа мне как-то не очень нравится. Нужна возможность выделять память так, чтобы помечать её как запрещённую к сбросу на диск и пусть лучше ОС даёт отказ в выделении памяти в таких случаях
Концепция очень правильная и полезная в большинстве случаев. Другое дело, что не всегда она хороша. Не знаю, как Винда и Линух (не интересовался), а в OS/360 была возможность на уровне прикладного кода закрепить страницы в физической памяти. Реализовать это можно в любой системе, если там этого ещё нет. Например, в Винде можно написать свой типа драйвер, который будет заниматься не вводом-выводом, а лишь закрепит страницы задачи. В общем, принципиальной эта проблема не является.
Цитата:
«Резиновый» регистр заводить не обязательно и даже слишком большой тоже, но хотелось бы иметь что-то побольше, чем 64 бита.
А зачем? Вам это нужно, но 99,99% пользователей -- нет. Но, если сделать большие регистры (и, естественно, обрабатывающие блоки -- иначе зачем большие регистры), окажется, что изрядная их часть не используется. Точней, используется, но "механически" -- тупо хранит/складывает нули или единицы, а не реальную информацию, поскольку подавляющее большинство задач успешно обходится 32-разрядными данными, и даже адреса в 64 бита далеко не всегда востребованы. (Даже на современных мэйнфреймах объём физически установленной ОЗУ составляет, если не изменяет память, всего лишь 2 Тбайта).
Цитата:
Но там я подразумевал, что вся архитектура вычислительной машины будет выполнена по единому стандарту, то есть нужно делать что-то одно, что всегда со всем совместимо. Кроме того, я предполагал, что стоимость их не будет уж слишком высокой.
Опять подход учёного-теоретика (не в ругательном смысле, естественно), а не инженера-практика. То, что сегодня является передовым стандартом, уже завтра безнадёжно устареет -- и совместимость либо вообще не сохранить, либо лишь ценой кучи костылей и подпорок, которые мешают улучшать технику. Что же до стоимости, то Вы хотя б представляете, сколько стоит производство микросхем? Чтобы запустить в производство даже простейший кристалл, требуются сотни тысяч или даже миллионы долларов, а ведь процессор -- это отнюдь не простейшая вещь. И это -- лишь запуск в производство, а не разработка самой схемы. А сколько надо потратить денег на разработку, несколько запусков в производство для получения опытных образцов (которые, естественно, будут работать не так, как надо -- потому и придётся выполнить несколько итераций)? Вполне возможно, что уйдёт и миллиард.
Обычные процессоры дёшевы для потребителя по той причине, что их разрабатывают (и тратят кучу денег) один раз, а потом штампуют десятками и сотнями миллионов -- т.е. затраты на разработку раскладываются на огромный тираж. Ну а Вам нужны уникальные изделия, которые, кроме Вас и небольшого числа Ваших коллег, никто не купит, поскольку они никому не нужны даже даром. Как думаете, сколько всё это будет стоить? И такие ли идиоты те, кто делают вычислительные кластеры на обычных интеловских процессорах или невидийных графических процессорах, изначальное предназначение которых -- игровая графика?
Цитата:
Цитата:
Берём отладочную карту с мощным FPGA и PCI-E слотом, устанавливаем в комп и программируем наши функции непосредственно в железе.
Можете ли Вы подробнее описать этот процесс? Где берём и что конкретно делать? Какую дисциплину для повышения квалификации изучать?
ПЛИС (FPGA по-буржуйски) не позволит получить достаточно высокую производительность, которая Вас бы удовлетворила. Они хороши либо для прототипирования (собственно, процессоры так и разрабатывают: сначала реализуют и отлаживают логику на ПЛИС и лишь затем начинают разработку собственно микросхемы процессора, когда логически уже ясно, что оно работает), а также для решения специфических задач, где плохо подходят стандартные процессоры, но нет уж каких-то совсем запредельных требований к производительности. Платой за универсальность ПЛИС является весьма невысокая скорость их работы. Кроме того, они весьма дороги. Возможно, мощная ПЛИС и позволит решать Вашу задачу быстрей, чем обычный процессор, но она будет стоить несколько тысяч или даже десятков тысяч долларов (в конце концов, Вам же не сама микросхема ПЛИС нужна, а всё в комплексте -- ПЛИС, память, всё это смонтировано на плате, плата установлена в компьютер и т.д.).
Ну а чтение можно начинать с Википедии. А так вообще -- это электроника. То, что ПЛИС -- это "программируемая логическая интегральная схема", не должно обманывать: это программирование кардинально отличается от обычного "компьютерного". Да, часто к решению задач на ПЛИС подходят так же, как к их решению на обычном компьютере -- но результаты, скажем так, весьма плохие получаются (в частности, для решения задачи почему-то требуется очень мощная ПЛИС, хотя реально можно решить и на слабенькой -- но это если понимать, как оно работает, и соответствующим образом подходить к разработке, а не тупо и прямолинейно переносить опыт разработки программ для ПК на разработку логики функционирования электронной схемы).
Цитата:
Правда? Я гляну в руководство по командам. Не знал, что rep можно использовать в таких случаях.
Мне кажется, что нельзя использовать...
------------
В общем, возможно, Вы -- очень хороший математик (а может, даже гений -- говорю без всякой иронии; сам-то я математической подготовки не имею, так что и судить хоть сколько-нибудь объективно не могу -- это дурака, знающего несколько "умных" слов, довольно легко определить, просто послушав некоторое время). Однако во всяких более "призимлённых" материях вроде реальной электроники Вы не разбираетесь, отсюда и нереальные предложения, и непонимание (не)осуществимости или цены тех или иных решений. Так что либо миритесь с тем, что есть, либо серьёзно углубляйтесь в изучение совсем нематематических аспектов нашего бытия, чтобы попробовать создать-таки что-то своё, лучше подходящее для Вашей задачи