24 февраля

Привет, Дмитрий.

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

Для затравки - вот первая мысль по поводу языка и эффективности в Фантоме. Итак.

Язык и эффективность.

Языков Phantom может быть много. Но для простоты будем сейчас говорить о неком базовом языке Phantom - интерпретируемом так или иначе - подземельем Фантома или непосредственно железом. Основная мысль заключается в следующем: Представляется разумным все-же держать наряду с интерпретатором некий язык (или языки) для вычислений, код которых является компилируемым.

Примечание для случая аппаратной интерпретации: Если код базового языка интерпретируется аппаратно, то компилятор должен уметь генерировать некий микрокод (по сравнению, конечно, с кодом базового языка). Соответственно, процессор должен уметь переключатся в режим микрокода.

Обоснование.

Сколько бы ни было ГГЦ, все равно всегда будет мало :-) Даже при наличии 3D-акселераторов, задачи не ограничатся Quake-v.10, всегда надо будет что-то считать быстро. На пределе скорости процессора. Всегда. Например, тот же Photoshop, с его обработкой изображений, не говоря уже о настоящих наукоемких вычислениях. Допустим, ограничение интерпретатора позволяет реализовать нормально работающий Photoshop только на процессоре с частотой 2 ГГЦ. Это значит, что мы, при нынешнем положении вещей, сознательно тормозим Фотошопный научно-технический прогресс. А это - нехорошо. И вообще, жалко терять пусть даже 50% времени на интерпретацию. Можно, конечно, интерпретировать на современном технологическом уровне - с конвейрами, кэшами и т.д. - то есть, полу-компилировать на этапе интерпретации/исполнения. Но! Во-первых, это представляется сложным, во-вторых, не имеет (ну почти не имеет) отношения к идее, которой я хочу поделиться. Итак, речь идет о компиляторе.

Однако, наличие полноценного компилирующего языка, такого как C++, губит всю идею Фантома на корню. И еще, прежде чем идти дальше, предлагаю подумать - а где конкретно нам нужна максимальная эффективность. Ответ первого приближения - только там, где надо вычислять и/или перелопачивать большие объемы данных. Числодробилка, так сказать. Всю, абсолютно всю остальную логику взаимодействия объектов можно и нужно оставить на уровне базового языка-интерпретатора. Ну, к примеру, я не думаю, чтобы обработчики событий в виндах сильно пострадали, если бы там был интерпретатор, а не C/C++. Да, собственно, они и есть сейчас интерпретаторы, Java, например. Но как же все-таки считать быстро? А надо просто встроить несложный, но достаточный язык, назовем его вычислительным.

Свойства и требования.

1. Самое главное свойство/требование языка заключается в том, что... ему запрещено быть объектным. В принципе запрещено. Вся объектность существует на уровне базового языка. В компилируемом - только примитивные (встроенные) типы данных
2. Второе свойство языка - ни одного системного вызова, ни одной функции API, будь то святая святых - malloc/free. Из языка не доступно ничего! И нитей внутри одного модуля тоже нет.
3. На первый взгляд, предыдущее свойство не означает, что нельзя использовать хотя-бы структурную декомпозицию - функции внутри модуля. Хотя может быть и запрещено - иначе почему-бы тогда не иметь в нем и некую внутреннюю объектную парадигму. Но пойти по этому пути - значит начинай разговор о Фантоме сначала :-) Лучше уж пусть будет запрещено. Тогда вся логическая часть взаимодействия между отдельными компилируемыми модулями возлежит на базовом языке. Богу - богово, кесарю - сечение. Итак, свойство - нет функций.
4. Отсюда вытекает четвертое свойство языка - изначальная, я бы сказал, природная инкапсулированность. Компилируемый модуль не доступен ни кому, кроме класса, непосредственно им владеющим.
5. Следующее свойство - дистрибутивность в исходном коде. 100% переносимости между разными аппаратными платформами. Вопрос защиты авторских прав явлется частью системы доступа в самом Фантоме, то есть, практически отпадает. Переносимость, кстати, хорошо согласуется со свойством 2.
6. Компиляция "на лету". Модули компилируются тогда и только тогда, когда это действительно необходимо. Например, при создании объекта, и то - только в случае, если еще нет точно такого-же объекта с уже скомпилированным кодом. Или даже при вызове модуля.
7. Быстрая компиляция. При таком построении очевидно, что язык должет быть настолько прост, что бы не надо было тратить много ресурсов на компиляцию. Типа С. Или Pascal. Или FORTRAN - из него можно взять, например, встроенные комплексные числа.
8. Взаимодействие на уровне оъектов. Скажем, я написал на нашем языке вот такую классную обработку вооот такой матрицы, и некий математик от этого затащился, заплатил мне кучу денег и хочет поиметь. Никаких проблем. Обработка матрицы представляет собой класс, низкоуровневый модуль в котором закапсулирован напрочь, открыт лишь внешний интерфейс, доступный в свою очередь только из базового языка. Хочу - дистрибутирую, хочу - даю пользоваться только с моего компьютера.
9. Стандартные библиотеки. Понятно, что при таком подходе ни sin, ни log баз средств языка посчитать нельзя - функций нет. А если-бы и были - см.п.4. Значит надо реализовать некий встроенный набор. Так же, кстати, как и для строк. Жесткая встроенность - это плохо. Однако, возможность дистрибуции "глобальных" функций, разработанных левым (например, мной :) разработчиком - на мой взгляд, еще хуже. Хотя, может, не так и плохо, если проработать соответствующий механизм. Но! для этого нужен именно специальный механизм Фантома. Посудите сами - наделать фантомовских классов типа sin, cos, log - не проблема, но как их использовать из компилируемого модуля? Ведь нам принципиально запрещено вызывать (а значит и создавать объекты) Фантома внутри модуля. А даже если бы и было можно - что толку? Накладные расходы все равно велики. С другой стороны, функции посложней и более ресурсоемкие, не грех и в виде отдельных объектов оформить. И использовать их только из базового языка. В общем здесь нужно определить грань - что встроено, а что и так можно. Где эта грань - вопрос открытый.
10. Память. Памятью для языка является только локальный стек в котором можно заводить данные, а так же та память, которая ему дана при вызове модуля. Язык не имеет средств для выделения и освобождения памяти типа malloc/free. При этом никогда не возникнет memory leaks и прочего мусора. Если же сущность модуля такова, что ему необходимо оперировать с большими массивами памяти, пусть об этой памяти заранее позаботится базовый язык.
11. Не вижу причин отказываться от адресной арифметики. Ведь язык-то относительно низкоуровневый. В случае "пропарывания" памяти - мгновенно по рукам в виде exception.
12. Передача данных. Увы, поскольку язык оперирует только примитивными типами данных, то перед тем, как вызвать модуль, придется преобразовать представление в понятные для него структуры. После возврата - обратно. Мутноватый вопрос, но в общем-то довольно рутинный. Поскольку язык не предназначен для глобальной обработки, то нечего и передавать в него по 20 параметров.

Философия

Не пахнет-ли все это столетней пылью? Возможно. Но, прочтите еще раз "обоснования". Нам не нужен мощный и универсальный язык с объектами и прочими там... операторами ввода-вывода. Нам нужно средство, чтобы посчитать что-либо с ураганной скоростью и интерпретировать дальше. Так можно будет и quake программироавть и все что угодно. Единственное взаимодействие, которое лично мне хотелось бы иметь - это иногда узнать из соседней нити, типа а сколько еще примерно считать осталось? Думаю, что это не проблема, да и то она возникает в особо специфических случаях. А то и вообше не возникает, поскольку я сейчас подумал и пришел к выводу, что не могу себе представить такой вычислительной задачи, в которой был бы один-единстваенный цикл на триллион итераций. Такие вещи всегда вложенные, а если и нет - то их можно вложить :-) А раз вложить - тогда внешние циклы реализуются базовым языком. Эффективность при этом практически не страдает.

McSeem