Обсуждение

3. Аппаратная архитектура должна стать другой. Весь вопрос в том, что пока еще непонятно, что именно должна поддержать аппаратная архитектура (до тех пор, пока не решатся проблемы 1. и 2.) Вероятно, это будут архитектуры с ассоциативной памятью. На базе с ЦП и пассивной памятью рост сложности (который неизбежен) будет требовать экспоненциального роста вычислительной мощности ЦП. В эту стенку уперлись первые декларативно-логические языки наподобие пролога. Ассоциативная же память позволит работать в семантической сети вместо машины фон Неймана (на которой тоже можно работать с графом - но через эмуляцию и большие затраты).

до революции еще далеко - нужно, чтобы было куча недовольных в "верхах" и "низах" :) Пока закон Мура является законом (скорей из области права, чем из сферы физики), таких количество недовольных не наберет критическую массу.

Я даже соглашусь (и недавние статьи из vpri.org подтверждают это). Только архитектура этих ассоциаций и поддерживаемые языковые конструкции пока неясны. Ведь в процессорной архитектуре много чего и без ассоциативной памяти чего есть. Я думаю, что будет архитектура со многими разнотипными спецпроцессорами, между которыми будут мощные коммуникационные каналы -- мозги примерно так и устроены.

Далась Вам эта ассоциативная память... Она и так есть просто реализована на уровне софта (хэш-таблицы и пр), а не на уровне железа. Для того, чтобы работала быстрее - потому как софтверная реализация гораздо гибче и можно разные оптимизации реализовывать, заточенные под конкретную специфику.

Далась, и еще как. Исследуя простенькие семантические сети и метамодели обнаружил, что при росте числа связей между концептами, потребление процессорного времени растет как-то очень быстро. Причина, в общем, очевидна - чем больше связей, тем большую цепную реакцию вызывают действия над концептами. Плохо, что при этом какой-либо полезной работы (изменение зависимых концептов) не происходит, массу времени занимает проверка, что ничего делать не надо. В случае же ассоциативной памяти (именно железной), эта простая и малорезультативная работа будет лежать на ней, освобождая процессор для полезных дел.

С чего Вы взяли что в случае железной ассоциативной памяти, ситуация будет лучше? Тут проблема-то не в железе, а на уровне алгоритмов. На уровне железа Вы ничего принципиально не измените.

Мало про биологию мозга знаю, но успокаивает, что вроде никто ничего не знает. Во первых, тут есть огромная пропасть. Между "мозгом" и "микросхемами". (Хотел написать "между аналоговым и цифровым", но это не совсем точно). Я думаю, рассуждать о мозге с той же увереностью как об электронике люди очень нескоро смогут. С одной стороны всем известно что в затылке видяха, над ушами звуковухи, в висках речевые процессоры, во лбу управляющий цп. Но с другой стороны ещё раньше было известно, что человеку можно отрезать пол-мозга, заполнить спинно-мозговой жидкостью, и он будет жить и радоваться, ничего не замечая. Это я конечно в анекдот перевёл, но это важно - если например, даже повреждена височная доля, человек с трудом говорит, но важно что через время функции восстанавливаются. В мозге, всё-таки, нет "специализированных устройств", всё размыто в этом огромном поселении трилионов сложных биологических непредсказуемых существ нейронов. Т.е. у меня из размышлений о мозге гипотезы совсем обратные - одна универсальная реализованная "в железе" схема, с настраиваемой ("программируемой") апаратной специализацией. Т.е грубо говоря можно одинаковые карточки воткнуть вместо видяхи, звуковухи и цп - и они настроятся под оптимальное аппаратное выполнение своих задач. В остальном всё интересно, правильно, местами понятно.

Ну, давайте сначала уточню - ассоциативная не так, как в кэше (где «ассоциативность» - средство отображения адреса в оперативной памяти на адрес в кэше, что довольно просто), а ближе к нейронным сетям, где возбуждение в одном нейроне может вызвать реакцию в других и так по цепочке, в зависимости от некоторых параметров. Идеальным случаем будет возможность установить функционально-логическую связь двух ячеек памяти - тогда изменение в одной вызовет одновременное изменение в другой по заданному закону. Это упростит моделирование и подход к вычислениям, даст возможность преодолеть ограничение логического программирования. Не знаю, насколько это «принципиальные» изменения, но хотя бы «качественные» )

Фундаментальное исследование про мозг, отвечающее на вопрос "почему у человека мозг вырос"? http://matfuck.livejournal.com/7933.html

Тут проблема в алгоритмах. Железо будет всего лишь реализовывать какой-то алгоритм. Поддержанный со стороны железа, он конечно будет работать быстрее, но он будет менее гибким, более тупым. Так что будет ли в результате нетто-выигрыш - ответ не очевидный. Разумеется, какие-то поддержка со стороны железа была бы полезна для логическо-функциональных языков. Но какая конкретно - не вполне понятно. К примеру, есть SAT задачи. Казалось бы они идеально ложаться на железо - булева логика. А вот и нет. Дело в том что большие задачи - миллионы переменных - железо все равно не сможет полностью перебрать. А вот софтовые алгоритмы их решают, потому как они быстро отсекают лишние варианты. Но они уже на железо не ложаться очевидным образом. Возможно некоторые элементы можно будет переложить. То же касается и ассоциативной памяти - софтовые алгоритмы гибче, а значит в конечном итоге быстрее, ибо делают меньше работы (на порядки). Возможно, какая-то поддержка со стороны железа тут будет на пользу, типа легковесной многоядерности, быстрые переключения контекстов. А ту проблему, что Вы упоминали, так это просто разработчики софт реализовали неэффектиный алгоритм, вот он и тормозит на больших задачах. Это сплошь и рядом случается, железом это не лечится, это лечится только мозгами (т.е надо разработать эффективный алгоритм, ну или эффективно реализовать существующий).

Тут проблема в алгоритмах. Железо будет всего лишь реализовывать какой-то алгоритм. Поддержанный со стороны железа, он конечно будет работать быстрее, но он будет менее гибким, более тупым. Я бы не был так категоричен: наборы дополнительных команд в CPU и использование GPU для вычислений - едва ли делают алгоритмы «более тупыми». Просто появляется возможность сместить акценты и применять несколько другую архитектуру вычислений. Аналогично с ассоциативной памятью - она не целиком возьмет на себя все проблемы (помним о 5-м поколении ЭВМ), а только лишь обеспечит новые качественные возможности. А они нужны хотя бы потому, что сколько-нибудь очевидные алгоритмы СИИ не работают на обычных процессорах - они постоянно упираются в экспоненциальный рост сложности вычислений, либо в необходимость составлять излишне подробную программу (попросту перекладывая сложности на человека).

Дополнительные наборы команд безусловно могут помочь. И новые архитектуры тоже. Вопрос - какие это команды и архитектуры? Это непростой вопрос. Я могу сказать с большой долей уверенности, что дешевая многоядерность с быстрым переключением контекстов - поможет. Т.е. такая как в Ниагара (возможно в Лараби), и НЕ такая как в х86 процах. Точно помогла бы возможность конструирования конвееров (реализована в некоторых типах процов). На счет остального - не уверен. Скажем - это вопрос очень серьезных исследований. А они нужны хотя бы потому, что сколько-нибудь очевидные алгоритмы СИИ не работают на обычных процессорах - они постоянно упираются в экспоненциальный рост сложности вычислений, либо в необходимость составлять излишне подробную программу (попросту перекладывая сложности на человека). А на специализированных они будут точно так же упираться в экспоненциальный рост сложности. Ибо рост производительности на порядок съедается увеличением размерности задачи на 1-2-3 единицы. Максимум что можно ожидать от железа - рост на 2-3 порядка, что дает максимум +10 битов перебираемого пространства - смешное увеличение. На фоне того, что специализированные алгоритмы перебирают пространства в миллион битов (быстро отсекая хлам разумеется). Я же почему и пишу, про важность алгоритмов - да-да, речь идет именно о перекладывании сложности на человека - потому что спциализированное железо, может сделать процесс удобнее, но не более того. Просто немного расшириться класс доступных алгоритмов. Что уже неплохо. Но все равно, основная сложность останется на человеке. Пример: автоматический прувер доказал 90% теорем возникших в процессе верификации некоторого софта, при таймауте в 3 минуты. Он сумел доказать и 10% оставшихся, при бОльшем таймауте. Если увеличить скорость работы сего прувера на порядок другой, то он будет решать большинство проблем почти что в реальном времени. Т.е. система станет существенно более юзабельной для реального инженера. Но это должен быть хорошо подготовленный инженер - чтобы разобраться с оставшимися 10% проблем.