login, Оптимизирующие компиляторы вместо вызовов с передачей параметров часть процедур напрямую вклеивают в код. Основная расплата - растущий размер программы. Именно этот трюк позволяет фанатично расхваляемым кое-кем виртуальным машинам с компиляцией реального времени "обгонять" на некоторых участках предварительно скомпилированный код - они тупо заваливают оперативную память "линейными", как Вы говорите, блоками. Например, вместо цикла могут размножить десять раз подряд один кусок кода, вклеить функции и процедуры прямо в него, избегая вызовов и операций со стеком. Вот большой вопрос, насколько Pure и Free бейсики оптимизируют код, первый, если не ошибаюсь (в живую ни разу не видел), вообще как компилятор использует FASM, то есть заранее составлены блоки на ассемблере под каждый оператор, как элементы в HiAsm, и потом вклеиваются в код с подстановкой переменных параметров. (Опять же, нужно проверить на практике)
------------ Дoбавленo в 09.43:
Сами себе ответили, пока я писал
Этот топик читают: Гость
Ответов: 3889
Рейтинг: 362
|
|||
карма: 1 |
|
Ответов: 1429
Рейтинг: 50
|
|||
1nd1g0, заочно пришли к консенсусу
http://ru.wikipedia.org/wiki/Процедурное_программирование Еще, как я понял, у процедурных языков код может находится только внутри тела процедуры и никак иначе. С обязательным синтаксисом для этого. В PureBasic можно написать на листе только a=1+1 И это уже исполняется. |
|||
карма: 0 |
|
Ответов: 3889
Рейтинг: 362
|
|||
login писал(а): В PureBasic можно написать на листе только a=1+1 И это уже исполняется.А там часом нельзя посмотреть FASM-листинг результата? Может там всё на функциях в ассемблере |
|||
карма: 1 |
|
Ответов: 1429
Рейтинг: 50
|
|||
1nd1g0, можно, просто я еще не посмотрел. Там нужно указать опцию, сохранять FASM код. Пока ищу ее.
------------ Дoбавленo в 10.11: Нашел Вот код для a=1+1 на чистом листе :
ТОлько я не понимаю его (нет это с 1 формой, на чистом листе пока не получается сделать, это надо в родной среде прописать ключ, а я не знаю где там его прописать) да, тут не на что смотреть, это с дебагером, инлайном, формой и всяким бредом. Приложение без формы занимает 3 кб. Надо будет как-то разобраться как его посмотреть. Сделал: Вот код:
Размер exe 2кб.
А вот код теста скорости темы топика, тот самый, который за 1 мс выполняется.
|
|||
карма: 0 |
|
Ответов: 3889
Рейтинг: 362
|
|||
login, Так не интересно, он делает предрасчёт констант. Попробуйте нечто вроде
X=X+1 X=X+256 X=X+65536 X=X-123456789 X=X*X Z=X-X Y=X+Z |
|||
карма: 1 |
|
Ответов: 1429
Рейтинг: 50
|
|||
1nd1g0,
code_27371.txt Интересно глянуть тот-же код в Delphi и FPC. ------------ Дoбавленo в 13.09: Язы конечно заманчивый, я бы уже сейчас сел в нем работать, но как всегда есть подводный камень - OpenGL В рекламе написано, что он напрямую поддерживается, во всех 3х платформах. Но это полу-ложь, на самом деле у OpenGL есть только около трети функций. Нет GLOrtho2D, и нет тех функций из которых MAV собрал 2D текст. (то есть опять назад, в лес с голой ж..пой, к моему дурацкому методу рисования букв на текстурах 32x32 + артефакты и т. п.) Для 2D они предлагают библиотеку Engine3D.dll которая работает через игровой движок OGRE. Но и тут есть подводный камень, пользоваться подобным - не советую. Я протестил примитивы которые идут напрямую в OpenGL и через Engine3D, так вот, в OpenGL реакция - мгновенная! С Engine3D есть ощутимая, постоянная, задержка реакции от мышки. И не важно, даже если на поле всего один примитив, мышка работает с задержкой. Еще, для 2D они предлагают DirectX, но я не знаю насколько он быстр, и что будет на других платформах, надо проверять, потому, что он вообще-то только под винду. |
|||
карма: 0 |
| ||
файлы: 1 | code_27371.txt [2.3KB] [257] |
Ответов: 3889
Рейтинг: 362
|
|||
login, судя по коду, компилятор-то туповат, то есть насчёт блочной сборки из кусочков я, похоже, угадал. Если x+1 он догадался инкрементом заменить, то вот постоянная работа с памятью вместо того, чтобы работать с одним единственным (!) регистром процессора - мозга уже не хватило на очевидную и простейшую оптимизацию. Даже паскалевский неназываемый компилятор, если в нём писать необъектный "линейный" код, даёт на порядок лучшую (оптимизацию), умеет кэшировать данные в регистрах и оптимально оперировать ими. А уж что умеют вытворять компиляторы от Intel ...
|
|||
карма: 1 |
|
Ответов: 1429
Рейтинг: 50
|
|||
1nd1g0, вроде логично рассуждаете.
Надо б сравнить этот код и код из топика: code_27372.txt с "неназываемым" компилятором, и поглядеть глазами, почему он выполянется медленнее. Я так-же видел в инете много критики паскаля, с примерами кусочков асма где он чудит, добавляя по 8 шагов там где можно делать 3 и т. д. Ну или я могу сделать миллиард операций вашего приемра там и там И поглядеть. |
|||
карма: 0 |
| ||
файлы: 1 | code_27372.txt [244B] [196] |
Разработчик
Ответов: 26158
Рейтинг: 2127
|
|||
login, не забывай, что в "неназываемом" компиляторе ты весь код можешь сам на ассемблере написать, пример тому KOL
|
|||
карма: 22 |
|
Ответов: 1429
Рейтинг: 50
|
|||
nesco, но в PureBasic - тоже (асм-втавки)
------------ Дoбавленo в 14.50: Итак, я сравнил: 10 000 000 последовательностей 1nd1g0, = 11 миллисек в PB и Delphi поровну И 44 - FPC (хорошо, уже что он вообще смог скомпилить) Это значит, что "Неназываемый" тоже не оптимизирует, а работает с памятью Завтра, в линуксе, в FPC Lazarus попробую эту последовательность. ------------ Дoбавленo в 15.26: Нашел причину задержки мыши у Engine3D.dll, она работает через DirectX, который был настроен на большую степень сглаживания в дровах карты. Так что зря я на нее наехал, нормальная библиотека. С виндой проблема решена. Теперь только надо протестить в Linux. |
|||
карма: 0 |
|
Ответов: 1731
Рейтинг: 68
|
|||
[offtop]Хе-Хе
Уже блин слюнки потекли. Я блин на кодах помешан [/offtop] |
|||
карма: 1 |
|
Ответов: 1841
Рейтинг: 369
|
|||
login писал(а): CriDos, в вашем старом пакете PB сразу нашел странную ошибку, в элементе "main" главное событие event(onStart)Я тогда только начал изучать FTCG и сам PB, с блоками у меня вообще была проблема, я с трудом понимал как они работают и что они могут наследоваться... А прекомпилятор я создавал на время изучения, он во всех строках заменял:
Но на FTCG это мне в то время вынесло мозг login писал(а): Точное определение времени выглядит так:Учти, если ты планируешь кросс-компиляцию, забудь про API - только внутренние функции (ElapsedMilliseconds()), или делай в элементе переключалку между пуриковской либой и API |
|||
карма: 1 |
|
Ответов: 1429
Рейтинг: 50
|
|||
CriDos, спасибо, учту. Просто прочитал, что ElapsedMilliseconds() менее точный.
Мда, я конечно, был в шоке когда, почитал, что такое 3Д движек, OGRE и другие. Там выполняется куча ненужного следящего кода, (три следящих класса), и только потом, отправляется дирек-иксу или в OpenGL. Прийдется, наверное, пробовать текст на текстурах 32x32 выводить тем скудным набором OpenGL, что там есть.. CriDos писал(а): Сейчас это всё можно реализовать в RTCG hiSys.hwsа как же матпарсер и строковые элементы в FTCG работают? Всё собирают. Находится позиция вхождения и заменяется. [offtop](правда я и сам грешу, такого накручиваю с FTCG, что мама не горюй)[/offtop] [offtop](да и бейсику не нужны никакие блоки, он и так работает )[/offtop] ------------ Дoбавленo в 09.23: Тест в Lazarus на Линуксе не сделал, по многим причинам, но в сумме их можно выразить одной простой фразой Linux(любой, я поставил 5 разных дистрибутивов) - Это чушь.. На ближайшие 10 лет я могу, спокойно, о нем забыть, им никто не будет пользоваться. Поскольку его интерфойс делали идиоты. По поводу IDE Lazarus хотелось бы тоже высказать много мата, но я сдержусь, для меня тоже больше не существует такого компилятора. Люди сделавшие такое IDE понятия не имеют ни о чем, и находятся на уровне развития обезьян. Даже если моя прога будет востребована, то люди пользующиеся Linux мне не нужны. Мне интересны только такие как я. С такой-же адекватностью и логикой мышления. |
|||
карма: 0 |
|
Ответов: 8926
Рейтинг: 823
|
|||
login,
|
|||
карма: 19 |
|
Ответов: 3889
Рейтинг: 362
|
|||
[offtop]login, хорошо Автор форум редко читает [/offtop]
|
|||
карма: 1 |
|