Изучаю Паскаль. Присоединяйтесь.

[Павел Васильев]

Другие языки Borland с "Turbo" в названии, такие как Turbo C, даже отдаленно не соответствовали скорости компиляции Turbo Pascal. Даже Turbo Assembler был медленнее, отчасти из-за того, что обычно приходилось запускать компоновщик. Так что же сделало Turbo Pascal таким быстрым?

А что чуть что, сразу старик Турбо Паскаль? В современных Дельфи и Фри Паскаль та же самая технология. Более того, компиляторы не стоят на месте, как то лет пять назад мне понадобилось обновить старую программу, написанную ещё на TP,  потом переделанную на Delphi 1. Установил на win7 delphi 7, сделал компиляцию, потом запустил на Rad Studio delphi 10. Так скорость сборки теперь гораздо выше, не замерял, но раза в 3 точно. По сравнению с компилятором Delphi 7 на том же компьютере и в той же OS.

[yacc]

А что чуть что, сразу старик Турбо Паскаль? В современных Дельфи и Фри Паскаль та же самая технология.

Если есть, в чем я скорее сомневаюсь, то проигрыш оптимизированным компиляторам по скорости исполнения генерируемого кода в EXE будет всегда - и Фортрану и С - такова цена однопроходного компилятора сразу с генерацией кода в рекурсивном спуске разбора.

[Павел Васильев]

то проигрыш оптимизированным компиляторам по скорости исполнения генерируемого кода в EXE будет всегда - и Фортрану и С

Вот эти мантры взахлёб твердят сишники когда возразить просто больше нечего. А насколько быстрее знаете? И кому это нужно на многоядерных компах с навороченными видеокарточками? А быстрая компиляция, срочная отладка и сборка бинарников нужны всем, в том числе вам, если вы не только утилиты пишите.

[yacc]

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

Это вообще-то теория компиляторов: для оптимизатора нужно абстрактное дерево разбора. Если его нет - нет оптимизатора кроме самых простых случаев в конечных ветках разбора.  А от того, как это написано, будет напрямую зависеть работа конвейера процессора - оптимизатора же нет.
С тут не причем - оптимизирующие компиляторы есть и для других языков - и Фортран и Go и Rust.

Программирование GPU вообще в стороне как таковое: CUDA - это библиотека. Написанная НЕ на паскале - к ней только мостик к dll в паскале.

[Павел Васильев]

такова цена однопроходного компилятора сразу с генерацией кода

Кстати, вот вы взяли накодировали прогу на с++, скомпилировали с оптимизацией и она стала на 3% быстрее в Windows 11 работать,  чем тот же проект на  Delphi. Отлично, алгоритмы и либы решают всё. Если надо быстрее, то в Delphi есть модуль поддержки многопоточности и параллельных вычислений на ядрах, Thread.Parallel library. Не считая возможности подключения внешних либ для GPU, cudа/opencl. Ускоряйте и будет вам счастье, а  скорость компиляции и сборки на порядок выше, чем в сиподобных языках. Вся сила в правде, коллега.

[Vladimir3621]

А если уж совсем все критично, то в Delphi можно и на ассемблере писать. Хоть КС, хоть целиком и полностью - самое то для тонких знатоков и ценителей

[yacc]

Если надо быстрее, то в Delphi есть модуль поддержки многопоточности и параллельных вычислений на ядрах

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

Thread.Parallel library это просто библиотека поддержки многопоточности -  программист САМ должен создать нити. Без нее приложение будет просто однопоточным. Причем это просто мостик к API ОС работы с нитями. Во времена турбо паскаля вообще нитей не было в ОС.

[Павел Васильев]

Thread.Parallel library это просто библиотека поддержки многопоточности -  программист САМ должен создать нити. Без нее приложение будет просто однопоточным. Причем это просто мостик к API ОС работы с нитями. Во времена турбо паскаля вообще нитей не было в ОС.

Вот и я о том же, не во всех задачах это надо, но для big data с большими циклами это распараллеливание хорошо работает. А в старике TP много чего не было, а теперь есть, но язык называется по прежнему Паскаль. И на нём гораздо быстрее  можно собирать бинарники, как ни крути.

[yacc]

Либо программист сам бьет большой цикл на меньшие параллельные, либо это делает оптимизатор.
Оптимизатор всегда принимает на вход абстрактное дерево разбора и его выход - тоже абстрактное дерево разбора, только модифицированное.

[Павел Васильев]

Либо программист сам бьет большой цикл на меньшие параллельные, либо это делает оптимизатор

Ну не все же такие опытные сишные программисты как вы, а в Паскале такую оптимизацию, как вы описали, можно сделать вдобавок и вручную, manually, с помощью потоков и parallel library. И никаких проблем.

[yacc]

Ручная оптимизация требует знания приемов и доступна на любом языке.
К слову, лучшие оптимизаторы для алгоритмических языков это не к С - это к Фортрану.
Потому что синтаксис языка простой и предсказуемый в отличии даже от классического паскаля - нет ни рекурсивных функций, ни вложенных функций, нет арифметики с указателями как у С и всяких sizeof.
Если моего мнения недостаточно, то вот и Даниэл Даффи, создатель Datasim, который еще в 80х продвигал С++ и который написал несколько книг по С++, говорит об этом на форуме
https://quantnet.com/threads/which-programming-language-for-faster-optimization-and-iterative-processes.5161/#post-42665
что самый быстрый язык для числодробилок - Фортран.

Причем этот оптимизатор вылизали когда еще никаким TP не пахло, как и не пахло x64 с ядрами - на Cray и CDC, где SMP было уже задолго, как попало на PC.

Распараллеливание на нити без выделения независимых блоков не дает никакого преимущества, потому что надо будет синхронизировать нити с блокировками и будет тормознутее чем тупо однопотоковое.

[Павел Васильев]

что самый быстрый язык для числодробилок - Фортран.

Не агитируйте, нам не нужны числодробилки, при необходимости что-то из Фортрана в виде dll можно подключить, не спорю, но писать на нём систему моделирования с многооконным GUI это знаете ли, что-то ... Спасибо, не надо. Мы по простому, на Паскале всё сделаем. 

[yacc]

Многооконное GUI можно написать на чем угодно что удобно для этого - например на VB, который имел палитру визиуальных компонентов, визуальный редактор форм и средства для быстрого перехода к обработчикам событий еще ДО появления дельфи - в той же второй версии.

Причем я подозреваю, что он вовсе не первый такой визуальный - концепцию придумал не он и тем более не дельфи, которая появилась позже.
 
Можно и на дельфи, можно на Qt Creator - любое, что поддерживает быстрое создание GUI и имеет связку с dll.

[Vladimir3621]

Многооконное GUI можно написать на чем угодно что удобно для этого - например на VB, который имел палитру визиуальных компонентов, визуальный редактор форм и средства для быстрого перехода к обработчикам событий еще ДО появления дельфи - в той же второй версии.

Да накласть всем на то, что, кто, когда и кого имел. Если вы не заметили, на дворе 2026, все палитры, редакторы, оптимизаторы и все остальное в Delphi есть давным давно. И Delphi, кстати, в отличие от VB очень даже живой язык, который продолжает использоваться в промышленной разработке. Вы вообще что хотите сказать своими постами, если не секрет? Что у кого-то длиннее? Ну, жизнь так устроена. Как показывает опыт миллиардов людей в самых разных областях, длина только создает проблемы. И, самое главное, чтобы когда это оно встает, чтоб владелец не падал

[yacc]

И Delphi, кстати, в отличие от VB очень даже живой язык, который продолжает использоваться в промышленной разработке.

Также продолжает использоваться и VB.
И дельфи было конкурентом вовсе не плюсам - а именно VB - в плане быстрого накидывания формочек и кода к ним.

Вы вообще что хотите сказать своими постами, если не секрет? Что у кого-то длиннее?

Что у дельфи вовсе не самое длинное, как его фанаты пытаются представить.
В особенности за цену его коммерческой лицензии.

Любителям Паскаля я бы рекомендовал не ее, а Лазарус.

[Vladimir3621]

Также продолжает использоваться и VB.

VB VBA - две огромные разницы

И дельфи было конкурентом вовсе не плюсам - а именно VB - в плане быстрого накидывания формочек и кода к ним.

А, формошлепство... Семен Семеныч... Это совсем низкий уровень, примерно как школотрона с последней парты. Чета слышал, чета отложилось, чета из отложенного вслух повторил, но... Заслуженный банан в журнале Делфи - это не про накидывание, делфи - это совсем другое. Но, да, когда по делу сказать нечего, аргументы крыть нечем, начинают накидывать про формочки Вы вообще разработкой, кстати, занимались? Я не про скрипты на VBA, я про серьезную разработку. У меня ощущение, что примерно как с динамическими массивами и динамическим выделением памяти - слова знаете но и только. Без обид, у вас везде примерно одинаково все. Вот LeftUser, Павел Васильев - видно, что разработчики, по вам - увы, это сказать сложно даже с большой натяжкой.

Что у дельфи вовсе не самое длинное, как его фанаты пытаются представить.

Да ладно, где это такое было? У вас - в каждом посте "делфи - кака, а вот ... - неописуемый рулез, у него такое... (дальше идет закатывание глаз в экстазе и плевки в сторону делфи)", а вот у "фанатов" делфи-то где такое?

[yacc]

VB VBA - две огромные разницы

На VB может накидать любой, кто знает VBА - принцип ровно тот же. На VBA ровно также делаются формочки если надо.

А, формошлепство... Семен Семеныч... Это совсем низкий уровень

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

Вы вообще разработкой, кстати, занимались?

Коммерческой разработкой я занимаюсь с 90-х и поэтому смотрю на тех, кто говорит " а вот тут коммьюнити бесплатная" как на студентов.
Первое, что делается в коммерческой разработке - внимательно смотрится на лицензию, а не на "ой, да халява же".

Вот LeftUser, Павел Васильев - видно, что разработчики

Вот не вижу понимания коммерческой разработки у Павла Васильева.  И внимания к лицензиям.
Хотя свой проект - да, тут молодец.

У вас - в каждом посте "делфи - кака

Вы читайте внимательнее.
И да, еще раз повторю - в целом пофиг на чем писать GUI -  можно на дельфи, можно на VB, можно на чем еще - что удобнее. Это не значит что это только на дельфи можно написать.
Для опенсорсных проектов полагаться на "халавную" дельфи - не очень разумно. Тот же ASTAP - под Лазарус.

Заметим - Лазарус я тут практически ни разу не ругал.

[Vladimir3621]

Понятно, очередной пост ни о чем. Сплошное цежение через губу "у делфи мелкий и короткий!, формошлепство!, VB!, т.п.!, т.п.!, т.п.! и т.п.!..". Про це и це-плюс-плюс в этот раз забыли А, еще забыли пнуть php, мимоходом скользнуть по питону и небрежно упомянуть го с жабой В общем, вопросы "вы сюда вообще для чего пришли?" и "а по делу есть что сказать?" остается открытым - тема называется "Изучаю Паскаль. Присоединяйтесь."

Коммерческой разработкой я занимаюсь с 90-х

Без обид - не верю, разработчика видно сразу. Возможно вы и пробовали что-то разрабатывать, но не срослось, и вы подались в кодеры. Что, честно говоря, тоже сомнительно. Хотя с чем-то в общих чертах вы сталкивались и несомненно знакомы, конечно.

[yacc]

Без обид - не верю, разработчика видно сразу.

Странно слышать от человека, который привел геймера в пример, что "разработчика видно сразу"
( вот тут https://astronomy.ru/forum/index.php/topic,205286.msg6469222.html#msg6469222 )

А что это геймер, который просто по верхам прошелся по вики - видно сразу по его статьям
https://overclockers.ru/blog/Beltar

"вы сюда вообще для чего пришли?"

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

Но тут мне начали доказывать как "крута" именно дельфи.
Я и объяснил - для энтрепрайза - нет, не крута.

[Vladimir3621]

Не было такого, вам показалось - перечитайте.

Странно слышать от человека, который привел геймера в пример, что "разработчика видно сразу"

Я вам всего один простой пример приведу, а вы уже сами думайте, стоит продолжать или нет. Вы тут последние несколько постов непрерывно про формошлепство пишете, но человек, который хоть раз занимался разработкой гуевых приложений обязательно так или иначе формошлепал. Либо вручную, либо используя ту или иную RAD-систему. Т.е. для него это рядовой и даже тривиальный момент обычного рабочего процесса. Как репу почесать или там на другой бок перевернуться. Электрики не обсуждают (тем более не чморят) чужие пассатижи, сантехники - газовые ключи, а офисный планктон - скоросшиватели. Если вы матерый разработчик серверного ПО или хотя бы утилит командной строки, то вам все эти формы до одного места, т.к. с ними вы имеете дело только в телефоне и в домашнем компе, когда поиграться садитесь. По той же аналогии, сантехники протонные скальпели не обсуждают и, тем более, не чморят безостановочно. А хирургам, например, плевать на термоформовочные пластавтоматы. Они не будут на тематическом форуме или в профильной теме садоводов-любителей поливать их неделями всем, что придет в голову, мотивируя свои посты тем, что пластавтоматы фирмы Бррррр имеют ручки того же цвета, что любимый чайник главврача фирмы Хрррр