LINUX.ORG.RU

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

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

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

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

vzzo ★★★ ()
Последнее исправление: vzzo (всего исправлений: 2)

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

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

Deleted ()

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

dikiy ★★☆☆☆ ()

Кто быстрее?

#!/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

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

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

x3al ★★★★★ ()
Ответ на: комментарий от shell-script

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

bormant ★★★★★ ()
Ответ на: комментарий от x3al

У меня гента. Я итак уже 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

shell-script ★★★★★ ()

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

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

dexpl ★★★★★ ()
Ответ на: комментарий от bormant

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

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

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

#!/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

shell-script ★★★★★ ()
Ответ на: комментарий от vzzo

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

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

PaRuSoft ★★★★ ()
Ответ на: комментарий от vzzo

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

onon ★★★ ()

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

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

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от onon

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

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

Napilnik ★★★★★ ()

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

Quasar ★★★★★ ()
Ответ на: комментарий от Quasar

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

Quasar ★★★★★ ()

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

iZEN ★★★★★ ()
Ответ на: комментарий от vzzo

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

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

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

grem ★★★★★ ()

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

Zhbert ★★★★★ ()
Ответ на: комментарий от iZEN

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

grem ★★★★★ ()

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

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

redgremlin ★★★★★ ()
Ответ на: комментарий от Zhbert

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

iZEN ★★★★★ ()

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

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

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

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

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

grem ★★★★★ ()
Ответ на: комментарий от vzzo

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

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

unC0Rr ★★★★★ ()
Ответ на: комментарий от shell-script

time python hello.py > /dev/null

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

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

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

Deleted ()
Ответ на: комментарий от unC0Rr

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от shell-script

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

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
Deleted ()
Ответ на: комментарий от Napilnik

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

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

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

unC0Rr ★★★★★ ()
Ответ на: комментарий от Napilnik

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

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

unC0Rr ★★★★★ ()
Последнее исправление: unC0Rr (всего исправлений: 1)
Ответ на: комментарий от unC0Rr

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

Harald ★★★★★ ()
Ответ на: комментарий от Harald

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

unC0Rr ★★★★★ ()
Последнее исправление: unC0Rr (всего исправлений: 1)
Ответ на: комментарий от Miguel

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

grem ★★★★★ ()
Ответ на: комментарий от grem

pascal.abc

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

bormant ★★★★★ ()
Ответ на: комментарий от grem

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

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.

grem ★★★★★ ()
Ответ на: комментарий от bormant

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

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

grem ★★★★★ ()

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

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

grem ★★★★★ ()
Ответ на: комментарий от unC0Rr

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от unC0Rr

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от grem

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

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

bormant ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.