Вот я тебе расскажу, чем Инженер отличается от IT-шника.
Второму нужны доказательства, для того, чтобы делать лучше.
А первому - доказательства, чтобы делать хуже.
Первая культура давно существовала, когда еще и компьютеров не было.
Существуют некие цеховые правила, паттерны разработки, наконец. Опробованные веками.
Зато именно вторая считает себя носителем Истины, закручивая пальцы веером.
По смыслу - IT должна бы быть инженерной культурой. И, может быть, когда нибудь ей и станет.
Когда образованность ее носителей поднимется до уровня, позволяющего познакомиться с опытом предков.
А вот тебе пример из нашего случая (применение философии на практике)
Ну показал же я тебе
#pas
CmdPush: // [val:real] просто число
begin
inc(Fsp);
Fsp^ := PReal(Fpc)^;
inc(Fpc,sizeof(real));
end;
А оставаясь к концепции интерпретатора? Мне кажется, что нет. Но предложения принимаются.
А может у кого есть иная оригинальная концепция?
И поскольку я Инженер, а не IT-шник, то спрашиваю: Где доказательства, что надо делать ХУЖЕ (оборачивать это дело всякими там классами-дурасами)
И вовсе НЕ СОБИРАЮСЬ доказывать, что надо делать лучше (эффективнее). А просто делаю.
Где та Великая Причина, заставляющая писать на 200 строк кода больше, и терять в эффективности. Мало или много - даже считать не буду, потому что все равно терять.
Где та Великая Причина, заставляющая меня (Читателя) ломать башку над использованием какого-нибудь FAlloced.
Вопросы были риторические. Просто знаю, как обычно IT-народ отвечает: звучат религиозные лозунги, никакой связи не имеющие с поставленной целью.
И вообще, парадигма работы Инженера предполагает обсуждение этих вопросов (размышление над этими вопросами) ДО кодинга, а не ПОСЛЕ.
Сочиняется (придумывается) несколько вариантов развития. Несколько - это обязательно. Выбирается оптимальный по вышеозначенным критериям.
И получается быстрее и эффективнее.
Чего делают программисты, спрашивается.
Они придумывают какой-то один вариант. Жутко гордятся, что они его придумали - работает же!
Потом начинают профилировать. Где-то чего-то исправлять. Отлаживать. Ловить свежевнесенные баги в течении многих лет.
И получается, что высококвалифицированный (!!!) программист больше 10000 строк кода за год написать не может. Обычно - не больше 3000.
Нарушают один из основных принципов (из тех, которые опробованы веками) работы Инженера: Не планируй себе проблем, попробуй сначала справиться с теми, которые возникнут (а они возникнут) и без твоего планирования
Конечно, это эмпирика. Но она всегда работала, и работает. Даже если ты ей не веришь
Я понятно объясняю
------------ Дoбавленo в 12.25:
Про конкретику: теперь буду "цепляться за фразы"
Assasin писал(а):
Galkov, мне кажется, что выжимать максимум производительности из MathParseEx не стоит, все же когда нужен максимум, тогда уже есть готовый FastMathParseНе надо выжимать. Выжимать - это и есть FastMathParse. И у него есть ограничения в функциональности.
Надо просто не делать глупости. Это не трудно. Разве я этого тебе не показал
Assasin писал(а):
то я начну заниматься микрооптимизациями, которые на практике вообще за меня будет решать компилятор (заинлайниванием вызовов функций)Ага, ЩАЗ. Разогнался и подпрыгнул.
Потом догнал, и еще раз соптимизировал.
Вообще-то, я коды смотрел (в дизасме)
Assasin писал(а):
А вот расширить классы для оптимизации отдельных операций (например, не гонять переменную со стека и обратно) - это можноА еще можно не создавать себе проблему, и не придется ее решать.
Assasin, еще один принцип Инженера: он работает не только для компьютера, но и для своего Коллеги. И второе, обычно более важно, чем просто "работает же"
В этом коде:
#pas
x2 := Fsp^; dec(Fsp);
Fsp^ := Fsp^ + x2;
А вот если ты "расширишь классы для оптимизации отдельных операций", то полазить по файлу - очень даже придется. Может и не один раз. А может там и ашипка закрадется.
Причем, я сначала буду полдня думать (может это я дурак), перед коллективной разборкой.
И всего этого могло не быть.
Assasin писал(а):
По поводу алгоритма - так до конца и не получилось понять, где мы резервируем, где режем лишнееДавай тогда говорить на языке знакомых букв и цифр...
А вот твой же Dump для вышеупомянутой формулы (меня задрал CmdDbgLine, и я его заблокировал)
(1 + %2 + (%1 - 2))/2 Program:
1 push 1
2 read 1
3 add
4 read 0
5 push 2
6 sub
7 add
8 push 2
9 div
10 end
Вот, возвращаемся к Level1b (копировать не буду - смотри в код сам)
Чего получается после первого вызова Level2 ???
Это первая строка в дампе (push 1). И мы как-то там, через еще недодуманную структуру Titem должны получить реальный адрес (скорее - индекс в массиве) этих 9-ти байт
Дальше, следующий вызов Level2 добавляет нам вторую строку (read 1). И мы сами добавлям третью (add).
Спрашивается, чего дает третий вызов Level2 ???
Он дает сразу три строки - 4-ю, 5-ю, и 6-ю.
Вот, и мы себе думаем (точнее, пытаемся придумать), что при этом вернутся два адреса (или индекса) в переменной tmp (см. код). Первый показывает (в нашем случае) на 9 байт для 5-й строки (push 2), а второй - на 1 байт команды (в нашем случае) в 6-й строке (sub).
Каков должен быть наш план в этом случае. Чтобы вернуть то, что мы потребовали (его же вернул такой же Level1b, но на более глубоком уровне рекурсии).
Мы должны в аргумент item (см. код) занести адрес первой встреченной константы (в нашем случае это строка 1) и первого оператора, к ней примененного (в нашем случае это строка 3)
ТОДЫ
Отнимаем (ибо sub, а в формуле при этом стоит +) от константы, зафиксированной уже в item - двоечку (ибо push 2).
Удаляем строки 5 и 6 (на самом деле, полученные в tmp после 3-его Level2).
Должны получить:
Так КУ, или не КУ ??? Program:
1 push -1
2 read 1
3 add
4 read 0
5 add
6 push 2
7 div
8 end
Повторюсь, пока это "мысли вслух"
Поиск
Друзья
Администрация