AFAIK,

fpc - самый говеный компилятор из всех существующих в мире за последние надцать лет

кто хочет - может оспорить с тестами и примерами кодогенерации

ДокSiemarglfpc - самый говеный компилятор из всех существующих в мире за последние надцать лет
было бы интересно послушать твои аргументы :)
ужасное качество кодогенерации и соответствующий результат, например 19539233

defecatorSiemarglпропущено...

ужасное качество кодогенерации и соответствующий результат, например 19539233
тебя никто не заставляет,
пользуйся какашкой за две тыщи баксов
А ты столько стоишь? Шутка за 300 по нику.

Собственно, чтобы сгладить резкость - даже примитивный компилятор имеет офигенную фору перед любыми xVM - потому проигрыш в 2-3х раза в тестовых задачах может оказаться в плюсе в реальных.

Но в достижения 2017 я бы такое как FPC постеснялся записывать.

P.S. В работе я использую как сравнимую по фичам студию за 500$, так и спец.IDE за 10k EU. Но негатива к Борланду как к конторе не испытываю - нормальный софт, не чета опенсурсу в 97%

defecator,

и это, я видел твой код....

ДокSiemarglужасное качество кодогенерации и соответствующий результат, например 19539233
си-шарп еще хужее, начни с него
mono убогая опенсорподелка, в .днекоре уже получше, хотя на мой взгляд тоже будет выкидыш

вот результаты на родной винде 18160939

defecatorSiemargldefecator,

и это, я видел твой код....

Я надеюсь, ты упал в обморок или долго рыдал ?
Или твой код - идеал ?


Да нет, не все так плохо, в обоих случаях.

Но это однозначный повод быть потерпимее к людям

kealon(Ruslan)Siemarglпропущено...

ужасное качество кодогенерации и соответствующий результат, например 19539233 тут видишь в чём проблема, большинство оптимизаций в современных компиляторах построены на, мягко скажем, рисковых оптимизациях.
Из-за них, иногда абсолютно валидный С++ код, просто не работает в релизе. Либо на уровне языка приходится ставить ограничения (а-ля Rust).
Кроме того fpc не использует команды новых процессоров, зато работает практически везде - для массовой разработки это самое то.
Первое положение полностью неверно - оптимизации используют безопасные преобразования. Но ошибок программера при этом вылазит больше, да.
Новые команды - это только SIMD разных вариантов.
makhaonSiemargl,

Для реальных применений существуют параллельные вычисления и ассемблерные вставки со всяким-разным simd, если ограничиваться intel only. Узкое место легко и просто оптимизируется. На остальных 99.9% кода реальных 10-20% отставания не влияет никак от слова совсем. Опять же, если действительно huge вычисления нужны - то дорога в gpu, на cpu это баловство с современных реалиях.
Ну а если пофлудить на форуме, или потроллить надо - то да - компилятор медленнее.
Ты не теоретизируй, особенно если про вычисления на gpu только краем уха. Да и отставание там 100-150%.

Kazantsev AlexeyПортировал этот код на delphi. В результате, win64 на 14% быстрее чем fpc, а вот lin_x64 ровно в два раза медленнее. Так что итоги 2017 у дельфей пожиже.
Однако покрутил по быстрому сейчас fpc 3.04 - сначала надо разобраться в параметрах, потом уже вердикт перепроверить.
По крайней мере, в SSE2 он с опцией у меня смог (по умолчанию не используются) - а это много дает в плавающей точке.
И по дефолту для -Px86_64 - SSE2 включены, чем может объясняться результ.