Редактировалось 1 раз(а), последний 2017-03-02 19:03:33

г. -MAV, я еще до шейдеров не добрался. Попробую по пунктам:

1. FPC - Не то чтобы меня не устраивал, но я видел в инете тесты где FPC проигрывал по скорости. Где-то слышал о том, что новый FPC уже быстрее работает (то-же я читал на нашем форуме), но всеравно, якобы, он не будет таким быстрым как C++.

PureBasic - наоборот хвалят, пишут, что его работа или такая-же или быстрее чем C++.

2. Страшновато. Сейчас, когда я собираю свою прогу под нашим, штатным, FPC она работает не стабильно и не долго При этом в фоне висят жуткие ошибки обработчика исключений - штук 8 . Кроме этого она работает медленнее, и намного дольше компилируется.(delphi работает стабильно, потому, что в программе только логика и openGL) Это настораживает, как-бы кажется, что эти люди в принципе не сильно талантливые(так кодят). Поэтому и в будущем будет чего-то постоянно вылетать.

Я еще не решил, мне надо потестить посидеть над Lazarusom, я только сегодня xUbuntu поставил, и первый раз чегото попробовал компилить в ней, в PureBasic.

p/s
А еще у меня сегодня день рожденья
Мне 32 года

Ухты... Поздравляю! Дарю тебе эту тачку


------------ Дoбавленo в 22.38:
Чтобы код твой с такой-же скоростью выполнялся!

login, поздравляем!

[flood]Спасибо [/flood]

[offtop]
Намного лучше
Так же, я постепенно будут отходить от прекомпилятора как только функционал RTCG позволит, а он уже позволяет делать некоторые операции над текстом, хотя я уже нашёл критические ошибки в реализации, которые мне не дали полностью уйти от прекомпилятора

Так же, по мере разработки скелета пакета, стараюсь учитывать различные варианты, к которым я могу прийти в ближайшее время.
Пункты которых я пытаюсь придерживаться:

1) Простота разработки будущих элементов, без углублений в реализацию пакета.
2) Предусматривать все возможные варианты, которые могут привести к краху HiAsm/кодогена или ошибке компиляции НО без ущерба производительности.
3) При разработке элементов, учитывать возможности ЯП. Т.е. если допускается в объявленном условии указать несколько и более арифметических операций, реализовать это и в элементе. (If, IfEx)
4) Пытаюсь не спешить с реализацией, т.к. планов очень много, но реализовать не решаюсь т.к. отсутствует информация о всех возможностях HiAsm 5 и того что планируют добавить в RTCG.
...

p.s. Пакет на данный момент не распространяется. Как только я реализую весь минимум который задумал, опубликую его на форуме...[/offtop]

Редактировалось 1 раз(а), последний 2017-03-02 19:03:34

Редактировалось 1 раз(а), последний 2017-03-02 19:03:33

MAV, спасибо.
Установил в Ubuntu, попробую потестить сам.

[offtop]login, кстати, можешь потестить производительность FPC и сам

Пакет Pascal на базе кодогенератора FTCG
Проверил, вроде работает[/offtop]

CriDos, спасибо, правда там компилятор 2.4
А маv посоветовал 2.6

CriDos, Еще я Вам личное сообщение написал, наверное не дошло.
Щас еще раз попробую.

Да, личные не отправляются. Выкладываю сюда текст:

[flood]
Сообщение принял, сейчас отвечу[/flood]

Начал читать книжки по PureBasic, удивительно, но нигде не сказано о том, что использование процедур замедляет код.

Я как-то читал, что вызов процедуры - это, всегда, сохранение состояния стека, передача новых параметров в процедуру, потом по окончании работы возврат стека. Это медленно, по сравнению с линейным кодом. (функции, наверное, тоже, туда тоже передаются параметры) Отчасти еще и поэтому процедурные языки медленнее работают. Просто это удобно.

Благо, в FTCG можно всё собирать линейно, в одной процедуре - много кода, удобство не важно.

PB это, конечно, не язык а песня

Декларация переменных, работа с ними - что может быть проще. На FTCG, можно писать элементы даже не используя блоки
Тупо выводить на лист всё подряд.

CriDos, в вашем старом пакете PB сразу нашел странную ошибку, в элементе "main" главное событие event(onStart) стояло до печати главного цикла формы. Передвинул ее "после" - код начал компилиться без pre-компилятора.
И компиляция теперь мгновенная

Ограничения по количеству строк в компиляторе нет:

Точное определение времени выглядит так:

Медленнее чего? "Процедурный" - в смысле "любое действие выполняющий через процедуры"? (сам я пока не интересовался PureBasic и его бесплатной альтернативой - FreeBasic, генерируемый код не смотрел) Паскаль такой же "процедурный" (правильнее - "функциональный"), как и большинство современных универсальных языков, всё зависит от того, как именно пишешь. Например, объектно-ориентированное программирование гораздо ужаснее в результирующем коде выглядит, там 90% времени тратится на "лишние" операции, непосредственно к логике приложения не относящиеся. Зато с точки зрения исходного кода всё "красиво". Вообще сейчас процессоры уже неплохо оптимизированы именно под функциональное и "процедурное" программирование. Равно как и под "объектное", которое на деле является ещё более процедурно-функциональным, да ещё в добавок перегруженным работой со вложенными структурами и косвенными адресациями.

1nd1g0, ну, что-то типа этого.
Да, точнее сказать, процедурный/функциональный стиль программирования замедляет. (просто обьектно/процедурный еще сильнее замедляет)
Если писать в Pascal-e все в одной процедуре - то это уже линейный язык.
Просто я говорю о том, что не предупреждают об этом.

PureBasic может создавать процедуры и подпрограммы, куда передаются переменные. И в теле процедуры он не видит линейных переменных (опять же из-за работы со стеком) А так он, типа, работает линейно.(понятное дело код я тоже не смотрел - просто прочитал)
------------ Дoбавленo в 09.37:
1nd1g0, да, оптимизируют, совершенствуют - это факт. Но никогда не достигнут скорости линейного потому, что операции сохранения/восстановления стека будут всегда. Еще я где-то читал статейку, о борьбе между обьемом программы и скоростью. Если повторять код процедур каждый раз, то скорость растет, но растет обьем программы. И есть фирмы на западе, которые сознательно настраивают компиляторы так, чтобы они раскрывали коды процедур линейно повторяя их тело. Там где важна скорость.

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