Хотел бы я такую фичу. Вообще говоря, как по мне, математическая программа должна перемалывать числа. Объектный подход кушает очень много ресурсов, причём эти ресурсы в главном рассчитаны на универсальный подход к построению описания модели "математическая программа", чем на сами вычисления. Тому доказательство - тормоза в работе математических программ. Если пользователь что-то запрограммировал, то это интерпретируется - по-моему это одна из основных причин, почему инженеру всё-равно нужно изучать ЯВУ, чтобы получить _реальные_ результаты.

Так вот, мне кажется, что можно перевести код программы (функции) прямо в машинные команды. Хочу сам попробовать это сделать на примере функции implicitplot3d(). Если у меня будет доступ к нативной записи функции в виде ОПЗ, то я могу налету сгенерить код для процессора и всунуть её в неуправляемую dll как тело функции.

Я уже давно об этом подумывал, т.к. внутри программы нет способов заставить работать функцию с приемлемым качеством, т.е. с количеством треугольников у модели больше нескольких десятков тысяч. Никакая оптимизация не уберёт интерпретацию. Очень здорово, что низкоуровневая обработка доступна пользователю. Не знаю уж как автор догадался дать такую возможность пользователю, но это супер вещь.

План у меня очень простой:
Шаг 1. Пишу на ассемблере код алгоритма implicitplot3d(), причём, прежде чем работать с функцией нужно будет инициализировать массивы.
Шаг 2. Этот код компилируется в неуправляемую dll. Эта dll будет состоять из нескольких секций. Одна из секций (кода) будет содержать шаблон функции и точку входа для её вызова.
Шаг 3. Пишем плагин для SMath. Этот плагин должен перевести ОПЗ функции в опкод процессора. Вставить этот код в dll в то место, где находится шаблон. Потом инициализировать память для работы с функцией и вызвать функцию через механизм работы с неуправляемым кодом.

Вот так всё просто. Т.о. самые нудные вычисления будут выполняться на уровне ассемблера, а всё остальное - лишь обёртки для этого.

Думается мне, что такой механизм, но встроенный в код SMath, был бы очень интересен для практических целей. Ведь все эти красивости на самом деле никому не нужны. Реальные задачи грузят проц не по-детски. Можно было бы ввести галочку - "использовать откомпилированную версию". Не оптимизированную, а именно откомпилированную.

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

П.С. Но это на очень далёкое будущее. Только не думайте, что новые процессоры будут быстрее, памяти больше и тому прочая ерунда. Процы уже быстрее, а памяти не меряно... просто микрософт ищёт всё время чем же это всё занять, чтобы продажи не падали.... спираль однако.

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

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

Потому я говорю, что вполне реально компилировать код прямо в опкод процессора. Не обязательно всего листа. Можно отладить какую-нить функцию или семейство функций и скомпилировать из них библиотеку с доступным интерфейсом для ЯВУ или каких других средств, где эти "кирпичики" могут использоваться для сооружения большой системы. По моему мнению, сейчас делается двойная работа при использовании мат. пакета: сначала моделируется система, а потом пишется быстродействующий код для среды выполнения. Думается мне, что можно это объединить.

Да, это будет зависеть от аппаратной платформы, но а как иначе то? Алгоритмы реально исполняются в конкретном девайсе, а не в .Net'овском окружении. Здорово было бы накидать код при помощи формул в SMath и компильнуть его для работы в контроллере. Вот эта затея достойная.

Даже не так. Компилировать функции в исходные тексты для разных моделей процессоров.

Отредактировано пользователем 2 ноября 2010 г. 15:52:38(UTC)  | Причина: Не указана

Это неправда.
Маткад перешёл на .Net полностью и все отметили - тормозов больше и больше ничего.

Это где это вы такого начитались? .Net использует стандартизированный посредник - IL - промежуточный ассемблер. Он никогда не будет работать быстрее, чем его аппаратный аналог, т.к. выполняется на виртуальной машине. В любой технической идее (запомните это на всю жизнь, так учат в технических вузах) всегда есть плюсы и минусы. Это закон сохранения такой. Только в рекламе одни плюсы, а в жизни всегда есть минусы. Микрософт подмяла под себя стандарт и навязала его всем, обладая монополией на продажи. Это принцип такой, чтобы всегда иметь прибыль (баснословную) нужно навязывать товар - это спираль Билла Гейтса из его книги "Дорога в будущее".

.Net может использовать неуправляемый код, т.к. иначе никто бы его всерьёз не рассматривал - старые разработки никто не выкинет просто так в корзину.


Вы меня не поняли. Код на асме я предлагал писать самой программе SMath, т.к. она владеет ОПЗ для записи выражений. Эта запись несложно переводится хоть в код ассемблера, хоть на язык паскаля, хоть на си, но в случае ЯВУ нужен сторонний компилятор. Если же самому переводить код в инструкции процессора, то такого компилятора со стороны не надо.

Случай с Си, Паскалем и прочим уводит в сторону. Среды разрабортки и сами эти языки заточены под любое почти применение. SMath можно посчитать такой же средой и языком для сознание небольших блоков кода, но "заточен" этот инструмент именно может для математических разработок. Ведь написание программы для взятия интеграла может быть не так увлекательно для Си или Паскаль - программера, да и работа с такими математическими библиотеками тоже выглядит неестественно.

В нет есть компилятор jit:
http://ru.wikipedia.org/wiki/.NET_Framework