Спроектировать процессор «на коленке». Возможно ли?

dmitrik> В том же фотошопе дофига математики которая была сделана (алгоритмы придуманы, теоремы доказаны) в последние 10-20 лет, что есть нормальный срок от академической теории до массового применения. Это уже разбирали в научно-техническом.

Ссылочку пожалуйста. "счас я и туда зайду"

Mishka> Не, ты не различаешь тогда динамику и статитку. Вот последнее — это чистая статика с отложенной линковкой. Никакого отношения к тому, что описал зиксман — не имеет.

Там вообще-то упоминается и статическая линковка.
И есть еще момент, который в С++ практически не применяется и который я также упоминал: в Лиспе, Форте, Перле вполне рядовое явление когда ты пишешь объектный код, а он твоей-же программой преобразуется в статику и статикой-же исполняется.

О! Кстати спасибо за напоминание - сейчас сделаю бенчмарк одной редко используемой объектной системы.

Mishka> ...И не надо на каждый объект по процессору. Проходили это.
Покажи, где это такое чудо было? Действительно, интересно.

Mishka> ... Пора бы понять, что объект не обязан соответствовать чему-то реальному. Это всего лишь метод управления сложностью.
Это у тебя всего лишь метод. А у меня - самая что ни на есть реальность. Привод двигателя, там, или рукоятка, ланпочка, человек... и метод тоже. Не обязан, да. Но мне очень удобно, когда соответствует.

Mishka> Вроде спросил понятно — как же без этого статического правило динамика не обошлась. Или не доходит?
А я чо, не ответил? Фиксирует это правило корень иерархии всего навсего. И все дела.
Заметь, оно единственное такое во всей системе. Но это не мешает системе помещать средства разработки и саму программу в один флакон, используя чистую динамику во всех остальных местах.
Я упомянул Форт не просто так.
Идеологически Forth и Smalltalk очень похожи. Программа на Forth - это слово в словаре, а программа на Smalltalk - это экземпляр класса в иерархии. И то, и другое доопределяется программистом, с точки зрения программирования они очень похожи. Похожи и с точки зрения исполнения, но не так сильно. Основная разница, с точки зрения машины, состоит в том, то где у Forth ссылка, там у Smalltalk запись, где Forth хватает регистра, Smalltalk требуется ОЗУ, где у Forth стек, у Smalltalk очередь.

Mishka> Писец просто, а не беседа. Если у метода произвольные возвращаемые данные и произвольные параметры, то как ты соотвествие установишь? По именам? А кто сказал, что семантика за ними та же?
Ты сначала определись, кто у тебя и чей метод вызывает. Кому ты собрался данные возвращать.
И вообще, ты говоришь про компиляцию и/или исполнение?

Mishka> НЕ, это ты предлагаешь так. В стат языках эта иерархия проверена однажды — на шаге компиляции. А ты хочешь всё проверять при каждом чихе.
Ты не понял. Я её хочу тоже проверять при компиляции. Динамической. И сам язык из-за этого не перестаёт быть динамическим.

Mishka> Не, ты не различаешь тогда динамику и статитку. Вот последнее — это чистая статика с отложенной линковкой.
Да хрен там чистая статика, чистая статика с отложенной линковкой - это только в недообъектных языках, где динамика притянута за уши к статической подоснове. А тут нету чистой статики никакой. Статика тут локальная и временная, и даётся она загрузчиком (а ему - динамическим компилятором) объекта, который и должен определить, какую часть методов объекта можно сделать статическими в данной загрузке (а не программе или модуле), а какую нужно вывести за пределы загружаемой части объекта, оставив динамическими.

И вообще, у меня есть подозрение, что динамикой ты называешь только костыль в стиле С++ под названием "виртуальные методы". Если так, тогда я встречно обвиню тебя в том, что ты не знаешь, что такое динамика.

С точки зрения С++ статика - это указатель на процедуру, а динамика - вход в таблице виртуальных методов. Не так?
С точки зрения чистых объектных языков и статика не существует. С точки зрения их исполнительных машин она может существовать, но не обязана.

"Чистая динамика" - это когда обект вызывает напрямую только те методы, которые определены непосрественно в нём. Все остальные методы, включая наследованные, он не вызывает, а отправляет сообщение соответствующему классу или объекту. Для того класс-предок, кстати, тоже должен быть объектом, чего в С++ нет, потому виртуальные методы в С++ - это именно костыль.
Ещё раз отмечу, что это "чистая динамика". Да, в её реализации на одной машине посыл сообщений предкам во время выполнения становится слишком неэффективным, поэтому в такой динамической реальности при выполнении тоже происходят вызовы. Но с точки зрения программиста всё выглядит так, что посылаются именно сообщения.

Потому ты и не можешь принять мой ответ на твой вопрос
Mishka> Вроде спросил понятно — как же без этого статического правило динамика не обошлась. Или не доходит?
Идеологически, некому больше слать сообщения-то, если мы решили, что корень тут и дальше простирается чистое ничто. Вот в чём корень корня, если не вдаваться в бесконечную рекурсию.
Примерно то же ограничение есть в совершенно другой области - DNS. Там тоже всегда есть статический объект - корневой домен.

Так вот и хочется сделать такой кремний, чтобы он окончательно ушёл в "чистую динамику", не ограничееный тормозом обмена сообщениями. Это даёт замечательное свойство - границы системы перестают быть заданными машиной и даже кластером. Ни что не мешает, в таком случае, запросто подключиить дополнительные ядра для объектов в виде вставного модуля типа DIMM или, вовсе, удалённый аппаратный ресурс.
Да, при таком подходе может потребоваться делать объект процессом, но только тогда, когда в системе не хватает ядер для слишком активных объектов и своппинг объектов занимает значительно больше времени, чем переключение процессов. Чем больше ядер, подходящих объектам по калибру, тем такая ситуация нах.

И вот ведь, интересно, на одном ядре люди уже давно применяют методы частичного "статирования" динамических языков:
"Один из основных методов оптимизации, применяемых в Strongtalk - это полиморфный кэш подстановок (PIC). Суть его состоит в том, что в месте, где часто посылаются полиморфные сообщения, посылка заменяется вызовом процедуры PIC. В этой процедуре проверяется настоящий тип получателя сообщения и для часто встречающихся типов делается прямой вызов соответствующего обработчика. В конце цепочки проверок осуществляется обычная полиморфная посылка."
Для агрегата из многих ядер этот механизм становится чрезвычайнно важным, поскольку позволяет разгрузить общую шину ядер и межъядерный коммутатор сообщений. К слову, он упрощает и механизм формирования селекторов сообщений. Это я всё о кремнии...

Блин....как всегда оказывается, что ничего нового я не придумал:
"Алан Кей, Squeak mailing list.
"Хочу намекнуть, что на последней OOPSLA я пытался напомнить всем, что Smalltalk это НЕ ТОЛЬКО синтаксис или библиотека классов, это даже не классы вообще. Я прошу прощения, что давным давно выдумал термин "объекты" для этой темы, потому что большинство людей сосредоточились на менее важной идее.
Более важная идея это "обмен сообщениями", то есть то, что лежит в основе Smalltalk/Squeak (и именно то, что никогда не было полностью доделано во время работы в Xerox PARC). В японском языке есть маленькое слово "мэ", означающее "то, что лежит между". Возможно, что наиболее близкий эквивалент — "промежуточный".
Для создания мощной и способной развиваться системы нужно сосредоточиться больше на проектировании того, как модули взаимодействуют между собой, чем на внутренних для модулей свойствах и поведении. Подумайте об интернете. Чтобы жить, он, во-первых, должен допускать существование множества различных идей и реализаций единого стандарта, и, во-вторых, допускать в той или иной степени взаимодействие между этими идеями.
Если вы сосредоточитесь на обмене сообщениями (и поймёте, что хорошая метасистема может использовать позднее связывание между различными архитектурами второго уровня, которые используются в объектах), то большинство дискуссий о языках, интерфейсах с пользователем, операционных системах, которые были подняты в этом треде становятся действительно спорными.

"Основная проблема в сообществе программистов на С++, это попытки использовать стандартный С++ либо как облагороженный С, либо как Smalltalk для бедных."
-- Бьярн Страуструп

Ф-ф-ф-ффуууу... во я накропал-то.
и под занавес: Критика Си++. Виртуальные функции
...."

ПыСы. Только не надо думать, что я ненавижу С++, просто он очень характерен.

dmitrik>> В том же фотошопе дофига математики которая была сделана (алгоритмы придуманы, теоремы доказаны) в последние 10-20 лет, что есть нормальный срок от академической теории до массового применения. Это уже разбирали в научно-техническом.
zyxman> Ссылочку пожалуйста. "счас я и туда зайду"
Конкретно про фотошоп не скажу, поскольку им практически не пользуюсь (чукча не читатель, чукча писатель ) но в целом в обработке изображений прорыв огромный. Поинтересуйтесь для начала когда вышел стандарт JPEG. И как насчет JPEG2000? Погуглите скажем статьи в научных журналах на тему "unsharp mask", "blind deconvolution", "wavelet" и т.д., посмотрите на даты. Названия конечно были известны и раньше но математика под ними продвинулась сильно вперед. Обратите внимание на "digital watermarking" (в фотошопе кстати есть для этого плагин).
А начать можно здесь: efg's Image Processing:  Algorithms

dmitrik>>> В том же фотошопе дофига математики которая была сделана (алгоритмы придуманы, теоремы доказаны) в последние 10-20 лет, что есть нормальный срок от академической теории до массового применения. Это уже разбирали в научно-техническом.
zyxman>> Ссылочку пожалуйста. "счас я и туда зайду"
dmitrik> Конкретно про фотошоп не скажу, поскольку им практически не пользуюсь (чукча не читатель, чукча писатель ) но в целом в обработке изображений прорыв огромный. Поинтересуйтесь для начала когда вышел стандарт JPEG. И как насчет JPEG2000?...

Ну пока я ничего не встретил, где основы не были-бы заложены позднее 1980-го года (то есть практически 30 лет назад).
Да, wavelet серьезно проработали только в 1990-х, но просто раньше смысла не было - по сути это преобразование из той-же оперы что и Фурье, только базисные функции не гармонические.
Математика используемая в практических реализациях wavelet полностью из более ранних преобразований (те преобразование Фурье, корреляционные функции и тп).
Поэтому я считаю wavelet Великим достижением, но не революцией а эволюцией. - Во времена Фурье врядли было много людей даже среди математиков, которые бы независимо дошли до преобразования Фурье, но зная о преобразовании Фурье можно было предположить что возможны преобразования не только с гармоническими базисными функциями; а уже с накопленным к 1990-м годам практическим опытом применения ПФ уже можно было предполагать какие свойства будут иметь преобразования с негармоническими функциями в сравнении с ПФ.

Ну а дата выхода стандарта это вообще ни о чем не говорящая в данной дискуссии цифра, поскольку стандарт имеет не научный а экономический смысл, и повернись история по-другому (допустим если-бы в СССР двигали компьютеры в своем направлении а не стали копировать запад), стандарт JPEG вообще мог не появиться.

PS кстати, вчера нашел еще один метод решения "задачи коммивояджера", названный "метод муравьев" - общий смысл что по путям случайным образом двигаются муравьи, и по принципам эволюционных алгоритмов затем вычисляется оптимальная траектория.
Алгоритм очень хорош тем что распараллеливается почти идеально, но можно ли это считать революцией?