Почему у языка Pascal низкая производительность?

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

Никому не интересно даже писать паскалевский фронтенд для LLVM, чтобы получить халявные оптимизации от LLVM.

Единственные два компилятора паскаля, которые бывают под линукс — это freepascal, который пишут люди, не имеющие никаких знаний о современных компиляторах, и блоб kylix, последний раз релизнувшийся в ранних нулевых.

Но, вообще, да, при должном старании он вполне мог бы догнать фортран по производительности.

У языков нет производительности, язык - абстракция, теория.

А по теме - у FreePascal было неплохо, когда пробовал (если собирать с нормальными флагами, конечно).

Для какой задачи нужно-то хоть?

А по теме - у FreePascal было неплохо, когда пробовал (если собирать с нормальными флагами, конечно).

Но да, пробовал лет 10 назад. С тех пор GCC и Clang пошли далеко вперед, а FreePascal - наверное, нет.

Толсто.

а в каком месте она низкая?

Кто быстрее?

#!/usr/bin/python

for i in range(1000000):
  print('i: %d' % i)

program hello;

var
        i: longint;

begin
        for i := 1 to 1000000 do
        begin
                WriteLn('i=', i);
        end;
end.

└─> time python hello.py > /dev/null 

real    0m1,549s
user    0m1,535s
sys     0m0,005s

└─> time ./hello > /dev/null 

real    0m0,095s
user    0m0,093s
sys     0m0,001s

Добавь pypy и не забудь его прогреть.

Тестировать на консольном выводе — зело дурная затея.

У меня гента. Я итак уже fpc ради этого «эксперимента» скомпилял. Компилить ещё и pypy лень. :)

Могу добавить из того, что есть.

#!/usr/bin/perl
#

for (my $i=0; $i<1000000; $i++) {
        print("i= $i\n");
}

package main

import "fmt"

func main() {
        for i:=0;i<1000000;i++ {
                fmt.Println("i= ", i)
        }
}

#include <stdio.h>

void main() {
        int i;
        for (i = 0; i < 1000000; i++) {
                printf("i= %d\n", i);
        }
}

└─> time perl helo.pl > /dev/null 

real    0m0,203s
user    0m0,200s
sys     0m0,001s

└─> time ./helogo > /dev/null

real    0m0,509s
user    0m0,391s
sys     0m0,112s

└─> time ./a.out > /dev/null 

real    0m0,098s
user    0m0,096s
sys     0m0,000s

Почему у языка Pascal низкая производительность?

По сравнению с чем?

Для этого я всё в /dev/null шлю. Ну и я не претендую на какую-то особую объективность моих тестов. Так, хелловордами балуюсь. :)

И да, я же протупил.

#!/bin/bash

for ((i=0;i<1000000;i++))
do
        echo "i= $i"
done

└─> time bash hello.sh > /dev/null

real    0m5,925s
user    0m5,779s
sys     0m0,134s

Единственные два компилятора паскаля, которые бывают под линукс

RAD Studio, начиная с 10.2.2 умеет и дли линукса бинари компилировать, но разработка все равно прибита к винде, ибо IDE никуда не портировали.

gnu pascal был когда-то. Кажется сдох он после kylix

Почему у языка Pascal низкая производительность?

Нормальна производительность у паскаля. Тестировал на нём игрушку - >700 фпс на средних настройках.

И есть ли для него какие-нибудь быстрые компиляторы?

Конечно есть - https://www.freepascal.org/download.var компилирует быстро, скорости у собранной программы хватает, если напишешь правильно. Конечно же таким «мелочам» на информатике тебя не учили, вместо этого изучали решение математических задач при помощи паскаля, скорее всего 16 битного, под дос, запускаемого из 64 битной винды.

gnu pascal был когда-то. Кажется сдох он после kylix

Это потому что на gcc компилялся - кому надо в чужом компиляторе ковыряться каждую неделю чтобы починить то, что поломали при обновлениях, а при реализации своих новых фич иметь все чужие ограничения.

Потому, что у Pascal производительность высокая.

Если что, GCC тоже умеет Pascal.

Похоже, что GPC для GCC загнулся ещё в конце нулевых. Ну значит FPC остаётся.

Где головой об косяки стукаешься.

Однопроходной компилятор TurboPascal 5.5-7.0 рвал как тузег грелку Borland C++ по скорости компиляции и получения бинарника. Разница видна невооружённым глазом. Вообще, компиляция C++ - тяжлый процесс во всех смыслах и проблемы раздельной компиляции из-за отсутствия модулей-независимых единиц компиляции, и необходимость многопроходной компиляции с разрешением динамических ссылок на этапе компиляции, и поддержка ООП в режиме частичной эмуляции - чтобы оно не тормозило в рантайме.

Вообще-то ещё есть pascal.abc и delphi в новых версиях тоже позволяет что-то собирать для линукс (как раз их новые компиляторы связаны с llvm).

вполне мог бы догнать фортран по производительности

То есть и C++, так как при включенных оптимизация они одинаково быстрые в числодробилках (в C++ работа со строками побыстрее).

Делфи вполне себе нормально работает.

не надо тестировать на скорости выхлопа в stdin

Именно из-за скорости компиляции программисты на дельфях могли позволить себе запускать компиляцию хоть после написания каждой строчки и практически мгновенно получать информацию об ошибках. Сейчас это не обязательно, так как и так во время написания кода ошибки синтаксиса «реальном времени» отлавливаются (кажется как раз за счёт llvm, а может и раньше свои фичи в этом плане были).

И есть ли для него какие-нибудь быстрые компиляторы?

Лазарус целиком со всеми компонентами компилится меньше минуты, куда тебе ещё быстрее.

выхлопа в stdin

Оксюморон получился.

А по сути: несколько выше уже об этом говорил, ТС свою позицию по вопросу высказал:
Почему у языка Pascal низкая производительность? (комментарий)

Может еще джингу станцевать?

Компилятор Delphi 2.0/3.0 в своё время был самым быстрым компилятором среди компилируемых языков программирвоания - 300 тысяч текстовых строк в минуту на Pentium-100.

Потому что язычок посредственный. Дженериков, по сути, нет, вывода типов нет, ничего современного нет.

Или ты про производительность скомпилированных программ?

Дженериков, по сути, нет, вывода типов нет, ничего современного нет.

тебе точно нужен pascal.abc - там новые плюшки любят добавлять и всё перечисленное реализовано, только для linux у них только консольный компилятор и всё (требует mono).

никому не интересно писать оптимизирующий компилятор для паскаля.

Плюсую. Простой пример: движок игрушки hedgewars. Для портирования на веб был написан транслятор pascal->c для используемого подмножества паскаля. Так вот, тот же самый код, просто автоматически переведённый на си и скомпиленный gcc даёт 20% прироста скорости.

time python hello.py > /dev/null

Так не очень честно. python3.5 hello.pyc > /dev/null

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

Алсо почему range, а не xrange?

Алсо почему range, а не xrange?

Потому что я не пишу на питоне без очень крайней необходимости. :)

Я немного ступил, xrange нет в третьем питоне если что...

Так вот, тот же самый код, просто автоматически переведённый на си и скомпиленный gcc даёт 20% прироста скорости.

Поотключали проверки, заменили менеджер памяти, напихали инструкций, которые есть только в самом свежем gcc, не на шестом центосе ведь компилировали, пока транслировали, оптимизировали исходный код и получили ажно 20% прироста скорости для 2Д игры. И это притом что в играх замена мелкой обоины на простыню может уменьшить fps в разы, а скорость выполнения на разных ПК тоже отличается в разы. Скорости в играх обычно хватает или не хватает, эти показатели важны. В модной 3Д игре на плюсах скорости может не хватать, а в 2Д ёжиках её хоть жопой ешь. Паскалю движков и русской документации по ним не хватает а не нескольких процентов прироста скорости, их можно где-нибудь сэкономить, если не хватит такой малости.

Впрочем, скомпиленный питон всего в два раза быстрее:

brainfucker@FuckingComputer:$ time python3.5 /tmp/__pycache__/rangetst.cpython-35.pyc > /dev/null

real    0m0.805s
user    0m0.800s
sys     0m0.000s


brainfucker@FuckingComputer:$ time python2.7 /tmp/rangetest2.7.pyo > /dev/null

real    0m0.709s
user    0m0.704s
sys     0m0.004s

Глянем для смеху, спасибо.

напихали инструкций, которые есть только в самом свежем gcc

пока транслировали, оптимизировали исходный код

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

Скорости в играх обычно хватает или не хватает, эти показатели важны.

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

это что, йожики в браузере будут? Или речь про серверную часть?

Раньше шли, был proof-of-concept где-то в 2012-13 году, но дальше дело заглохло, разработчик, занимавшийся этим, ушёл. По-моему уже и та демка не существует. Движок транслировали в си, потом emscripten, и в браузер, и оно даже работало!

а чего там смотреть, считай, что фактически это реализация Pascal.NET (практически C# и VisualBasic.NET)

pascal.abc

Судя по перечисленным возможностям, речь все-таки о PascalABC.NET.
Кстати, его исходники на C# открыты.

Функциональщину добавили, например, в одной из тем есть пример для задачи о сдаче:

begin
  var k:=Arr(1000,100,50,10); // массив с достоинствами купюр
  var s:=ReadInteger('Введите сумму:'); // сумма к оплате
  Writeln('Уплатить:');

  var i:=0;
  while s>0 do begin
    var p:=s div k[i];
    if p>0 then Writeln(p,' шт. достоинством ',k[i],' руб.');
    s:=s mod k[i]; i+=1
    end;
end.

который можно переписать так, используя свёртку:

  k.Aggregate(s, (t, n) -> 
  begin 
    var p := t div n;
    if p > 0 then Writeln(p,' шт. достоинством ',n,' руб.');
    result := t mod n;
  end);
end.

Угу, он самый, неправильно название вспомнил.

Только уж очень они его позиционируют исключительно для целей обучения - крепко занять хотя бы эту нишу для них было бы уже неплохо, но каких-либо приложений написанных на нём (кроме него самого?) я не знаю.

должен быть быстрее чем Python

а что, он медленнее, чем python?

просто теперь есть возможность компилировать как при помощи fpc, так и любым компилятором Си.

Кто бы обратный транслятор написал.

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

Разрешать в игре 1000 (разницу между кадрами меньше 1/1000 секунды уже делать коряво) фпс путём отмены вертикальной синхронизации в видеодрайвере и отмены синхронизации графики с частотой обновления монитора, чтобы наблюдать скачки производительности прямо в игре, не пробовали?

приложений написанных на нём (кроме него самого?)

Написан на C#, не на паскале, выше уже об этом писал, внимательнее...