Как разогнать FreePascal

[Slavikk]

Был я давеча тут - http://shootout.alioth.debian.org/. Как видно из тестов на одно ядерных машинах (one core) отставание от GCC не более чем в 2 раза, а вот на четырёх ядерных (quad-core) в четыре раза. В тестах участвует FPC 2.2.2. В связи с этим два вопроса:

1. Сравнивал кто нибудь по скорости 2.2.2 и 2.2.4?
2. Можно ли как то ускорить FPC? Я как понимаю на самой последней стадии код скармливается интерпретатору от gcc, а можно ли от последних версий gcc чего нибудь приделать для ускорения. И вопрос про Intel С++ он тоже вроде код gcc c++ понимает, может чего оттуда взять можно?

Мне просто интересно.

[Sergei I. Gorelkin]

1. FPC 2.2.4 еще не вышел, хотя ожидается вот уже совсем скоро. Если он будет быстрее 2.2.2, то результаты тестов обновят- команда вовлечена в этот процесс.
2. Интерпретатора от gcc не существует (существует только компилятор), и код ему не скармливается (этим занимается GNU Pascal, совершенно отдельный проект). На основных платформах (Windows, Linux) FPC сразу выдает исполняемый код, на менее распространенных он выдает ассемблерный исходник, который затем обрабатывается ассемблером и линкером. На скорость это не влияет, т.к. ассемблер транслирует команды один в один. Из Intel C++ едва ли можно что-то взять, потому что исходники закрыты. Ускорить FPC можно, поле деятельности просто огромно, просто нужно сидеть, писать и тестировать...

[Logo]

Какое-то неопределенное чувство и ничего не могу сказать так сразу. Возможно да, GCC лучше оптимизирует код, ведь над ним гораздо больше людей работают и тестируют, но действительно ли это так??? GCC автоматом создает код, который оптимально распределяется между процессами, процессорами, а в FPC это нужно делать своей головой, поэтому и отставание в многоядерном процессоре. Недостаток ли это? Наверное да, ведь для быстрого написания программ излишне уделять внимание правильному распределению процессов, а для специальных программ и в GCC и в FPC работать нужно головой.

Из практики могу привести пример. В прошлом году попробовал переписать программку из С на Паскаль. Это несложная программка для снятия сетевого трафика с сокета. Вышла немного больше по размеру но по скорости идентична. Затем специально распределил в четыре процесса, для четырех ядер, скорость возросла, пропадание пакетов не обнаружено, никаких заторов при нагрузке. Что еще интересно, скорость многих функций, чисто паскалевских, оказалась на много выше чем GLIBC, многие функции к тому времени, были еще в разработке. Короче что-то трудно сказать. Правильно сказал Sergei I. Gorelkin "...просто нужно сидеть, писать и тестировать..."
Удобство же FPC/Lazarus во много раз превышает все остальное, ну Ява, конечно, удобная, но и тормознутая соответственно.

[Sergei I. Gorelkin]

Ну вот, например, один из тестов на gcc, пресловутый фрактал: http://shootout.alioth.debian.org/u32q/ ... g=gcc&id=6
Там просто ручками создается восемь потоков. Никакой автоматики.
Автоматика есть в других тестах (в g++ встроена поддержка openmp), но, глядя на исходники, не получается сказать, помогает оно или больше мешает.

Кроме того, обратите внимание на __builtin_ia32_cmplepd() и подобные вещи. Народ просто втянул SIMD инструкции процессора в компилятор в виде встроенных ф-ций. Пользоваться ассемблерными вставками не разрешено правилами теста, а так - вроде бы все в порядке...

[Slavikk]

Интерпретатора от gcc не существует (существует только компилятор), и код ему не скармливается (этим занимается GNU Pascal, совершенно отдельный проект).

Спасибо, что пояснили. Просто меня смутило в Ubuntu, что изначально после установки Lazarus, ссылка на нахождение запускаемого файла FPC в нём, вела не в каталог FPC. Я по наивности подумал, что FPC в некоторых случаях может переводить код в код (без привязки к языку) который может быть скомпилированн GCC. От этого и возник вопрос про GCC и Intel C++.

Добавлено спустя 4 минуты 45 секунд:

Народ просто втянул SIMD инструкции процессора в компилятор в виде встроенных ф-ций.

Понял Вас. В Delphi часть VCL переписана на чистом ассемблере, тут ребята пошли дальше . Это удобно, но при переносе с платформу на платформу - весь код нужно переписывать заново. Спасибо за разъяснения.

[скалогрыз]

На основных платформах (Windows, Linux) FPC сразу выдает исполняемый код...

по-моему, тут приукрашено насчёт Linux-а.
встроенный code-writer есть только под Windows?! и у него были некоторые проблемы с dwarf debug-info.

[Sergei I. Gorelkin]

Линкера для Linux нет, а встроенный elf object writer - есть.

[Mirage]

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

[Logo]

Я что-то пропустил и разработчики gcc решили задачу автоматического распараллеливания?
Судя по исходнику, не решили.

В GCC 4.4. вроде с 1, распараллеливание автоматизировано и дает ощутимый прирост производительности на многоядерных процессорах. Кроме того с 4.4.0 циклы оптимизируются автоматом(и еще тыкают пальцами, что не Сишники - быдлокодкры ) и много другого делается без ума программиста для хорошего показателя откомпилированного кода.

А почему этот же фрактал, скомпилированный FPC только один проц нагружает?

Очевидно он в одном процессе работает.

Там однопоточный код? И где смысл сравнивать многопоточный и однопоточный?

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

В тесте почти четырехкратное отставание FPC на четырехядерном процессоре, это и наталкивает на мысль, что был использован GCC 4.4.x, кстати именно его сейчас во всех тестах и применяют, но это некоторого рода лукавство, хотя смотря с какой стороны смотреть.

[Sergei I. Gorelkin]

Судя по этому: http://shootout.alioth.debian.org/u32q/ ... &lang2=gcc там используется gcc 4.2.3.

[Logo]

Судя по этому: http://shootout.alioth.debian.org/u32q/ ... &lang2=gcc там используется gcc 4.2.3.

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

[Mirage]

В GCC 4.4. вроде с 1, распараллеливание автоматизировано и дает ощутимый прирост производительности на многоядерных процессорах. Кроме того с 4.4.0 циклы оптимизируются автоматом(и еще тыкают пальцами, что не Сишники - быдлокодкры ) и много другого делается без ума программиста для хорошего показателя откомпилированного кода.

Во-первых про автораспараллеливание в сколько-нибудь нетривиальных случаях не верю.
Во-вторых в исходнике
http://shootout.alioth.debian.org/u32q/ ... g=gcc&id=6
распараллеливание сделано вручную, отсюда загрузка всех 4 процессоров, отсюда четырехкратное преимущество на FPC кодом, который не распараллелен и выполняется одним процессором. Смысла это сравнивать все еще не улавливаю.

[Logo]

В GCC 4.4. вроде с 1, распараллеливание автоматизировано и дает ощутимый прирост производительности на многоядерных процессорах. Кроме того с 4.4.0 циклы оптимизируются автоматом(и еще тыкают пальцами, что не Сишники - быдлокодкры ) и много другого делается без ума программиста для хорошего показателя откомпилированного кода.

Во-первых про автораспараллеливание в сколько-нибудь нетривиальных случаях не верю.

Не знаю, сам не пробовал. Заявлено, что повышает производительность, поэтому и верю, а при необходимости реально распределить, всеравно на автоматику не понадеюсь.

Во-вторых в исходнике
http://shootout.alioth.debian.org/u32q/ ... g=gcc&id=6
распараллеливание сделано вручную, отсюда загрузка всех 4 процессоров, отсюда четырехкратное преимущество на FPC кодом, который не распараллелен и выполняется одним процессором. Смысла это сравнивать все еще не улавливаю.

Сам не проверял, верю тебе. Спасибо, что проверил. В таком случае сравнение явно не корректное.