Intel Fortran и gFortran

[pphantom]

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

Интеловский компилятор не умеет нормально обрабатывать рекурсию. Хвостовую - еще более-менее нормально, а вот в общем случае код получается весьма неэффективным. Правда, в вычислительных задачах рекурсия не особо нужна (и при необходимости ее обычно можно легко убрать), но все-таки печально.

Comments

[dair-targ-one.livejournal.com]

Ну просто насколько осмысленно на таком уровне оптимизировать. То есть это явно должно быть что-то (библиотека/приложение), что работает постоянно.

[pphantom.livejournal.com]

Не обязательно. Собственно, этот пост появился под впечатлением от свеженаписанного модуля (правда, "теоретического" - мне нужно было протестировать учебную задачу, испольщующую заведомо неэффективный вычислительный метод), для которого IFC при любых играх с ключами генерировал код, сжиравший всю оперативную память за несколько минут, в отличие от GNU'сного компилятора (который рекурсию корректно развернул).

Впрочем, и менее существенная разница тоже бывает важной. Улучшение быстродействия на 10% - не такая уж мелочь, если один прогон программы занимает неделю.

[dair-targ-one.livejournal.com]

Тогда да. Я-то просто привык за последние полтора года, что back-end уже написан кем-то ещё (всё украдено до нас!), а мне нужно решать именно задачу используя уже реализованные алгоритмы. Вот и удивляюсь -- откуда такая оптимизация.

[pphantom.livejournal.com]

Ну так этот back-end все-таки кто-то когда должен написать. :) К тому же он иногда бывает так написан, что хочется найти автора и помочь ему хирургически - оторвать руки, растущие из неправильного места.