Почему gccgo медленнее, чем gc в этом конкретном случае?

Question

Я уверен, что все знают golang знает этот пост здесь.

Читая это снова, я задавался вопросом, если использовать gccgo вместо go build увеличит скорость немного больше. В моем типичном случае использования (научные вычисления), gccgoсгенерированный двоичный файл всегда быстрее, чем go buildсгенерированный один.

Итак, просто возьмите этот файл: havlak6.go и скомпилируйте его:

go build havlak6.go -O havlak6_go
gccgo -o havlak6_gccgo -march=native -Ofast havlak6.go

Сюрприз!

$/usr/bin/time ./havlak6_go
5.45user 0.06system 0:05.54elapsed 99%CPU

$/usr/bin/time ./havlak6_gccgo
11.38user 0.16system 0:11.74elapsed 98%CPU

Мне любопытно, и я хочу знать, почему "оптимизирующий" компилятор генерирует более медленный код.

Я пытался использовать gprof на gccgo сгенерированный двоичный файл:

gccgo -pg -march=native -Ofast havlak6.go
./a.out
gprof a.out gmon.out

без удачи

Flat profile:

Each sample counts as 0.01 seconds.
 no time accumulated

Как видите, код на самом деле не был профилирован.

Конечно, я читал это, но, как вы можете видеть, выполнение программы занимает более 10 секунд... Количество сэмплов должно быть> 1000.

Я также попробовал:

rm a.out gmon.out
LDFLAGS='-g -pg' gccgo -g -pg -march=native -Ofast havlak6.go
./a.out
gprof

Никакого успеха тоже нет.

Вы знаете, что не так? У вас есть представление о том, почему gccgoсо всеми его процедурами оптимизации не может быть быстрее, чем gc в этом случае?

go версия: 1.0.2gcc версия: 4.7.2

РЕДАКТИРОВАТЬ:

О, я совсем забыл упомянуть... Я, очевидно, попробовал pprof на gccgoсгенерированный двоичный файл... Вот top10:

Welcome to pprof!  For help, type 'help'.
(pprof) top10
Total: 1143 samples
    1143 100.0% 100.0%     1143 100.0% 0x00007fbfb04cf1f4
       0   0.0% 100.0%      890  77.9% 0x00007fbfaf81101e
       0   0.0% 100.0%        4   0.3% 0x00007fbfaf8deb64
       0   0.0% 100.0%        1   0.1% 0x00007fbfaf8f2faf
       0   0.0% 100.0%        3   0.3% 0x00007fbfaf8f2fc5
       0   0.0% 100.0%        1   0.1% 0x00007fbfaf8f2fc9
       0   0.0% 100.0%        1   0.1% 0x00007fbfaf8f2fd6
       0   0.0% 100.0%        1   0.1% 0x00007fbfaf8f2fdf
       0   0.0% 100.0%        2   0.2% 0x00007fbfaf8f4a2f
       0   0.0% 100.0%        1   0.1% 0x00007fbfaf8f4a33

И именно поэтому я ищу что-то еще.

EDIT2:

Поскольку кажется, что кто-то хочет, чтобы мой вопрос был закрыт, я не пытался использовать gprof неожиданно: https://groups.google.com/d/msg/golang-nuts/1xESoT5Xcd0/bpMvxQeJguMJ

Answer 1

Запуск сгенерированного gccgo двоичного файла под Valgrind, кажется, указывает на то, что gccgo имеет неэффективный распределитель памяти. Это может быть одной из причин, почему gccgo 4.7.2 медленнее, чем go 1.0.2. Невозможно запустить двоичный файл, сгенерированный go 1.0.2 под Valgrind, поэтому трудно с уверенностью подтвердить, является ли выделение памяти основной проблемой производительности gccgo в этом случае.

Answer 2

Помните go build также по умолчанию статическое связывание, так что для сравнения яблок с яблоками вы должны дать gccgo -static или же -static-libgo вариант.