Компилятор Intel Fortran с большим размером файла

У меня есть большой фрагмент устаревшего кода, написанного на Fortran 77. Я компилирую его и запускаю с помощью компилятора Intel Fortran (версия 11?). Недавно я столкнулся с проблемой, когда размер выходного файла достигал чуть меньше 2 ГБ, и выходные данные перестали записываться на диск.

Я искал, чтобы увидеть, является ли это частью стандарта Fortran 77, или мне просто не хватает флага компилятора или чего-то еще, но не нашел ничего, что указывало бы на мою проблему.

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


fortran intel-fortran fortran77
person Godric Seer    schedule 18.12.2012    source источник
comment
Последующие стандарты Фортрана почти не признают существование файлов (или компьютеров, если уж на то пошло), не говоря уже об установлении для них ограничений. Стандарты отмечают, что такие вещи, как взаимодействие с окружением, зависят от реализации. Я не знаю, что компилятор Intel, который я активно использую, устанавливает ограничения на размер выходного файла. Ваше указание верхнего предела в 2 ГБ заставляет меня подозревать, что это предел o/s; возможно, вы работаете в 32-битной системе Windows?   -  person High Performance Mark    schedule 18.12.2012
comment
Я использую 64-битную версию Scientific Linux 6.3, которая является клоном RedHat. Я проверю свой тип файловой системы, чтобы увидеть, может ли это быть проблемой. Изменить: все мои разделы ext4, так что это тоже не должно быть проблемой.   -  person Godric Seer    schedule 18.12.2012
comment
Всегда используйте тег fortran и добавляйте версию только при необходимости, чтобы отличить конкретный вопрос. Например, что вы не можете использовать Fortran 2008, а только Fortran 90.   -  person Vladimir F    schedule 17.12.2015

Ответы (1)


arrow_upward
3
arrow_downward

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

  • Модель small — адресация, связанная с RIP, используется для всего, от вызова функций до доступа к данным. RIP — это 64-битный регистр указателя инструкций x64 (64-битное расширение EIP), но относительный адрес может быть только 32-битным числом со знаком (и существуют некоторые ограничения, препятствующие использованию полного диапазона целых чисел со знаком). ), поэтому размер объединенного кода и статических данных ограничен примерно 2 ГиБ.
  • Модель medium — программный код ограничен 2 ГиБ, следовательно, вызовы функций, связанные с RIP, но символы данных разделены на два типа. Малые символы данных — это символы, которые соответствуют коду в первых 2 ГиБ, и к ним обращаются с использованием того же RIP-относительного метода, что и в малой модели. Доступ к большим символам данных осуществляется с использованием регистровой адресации с абсолютным адресом символа, загруженного в регистр, что медленнее, но нет ограничений на адресуемую память.
  • Модель large - доступ ко всем символам осуществляется по абсолютной адресации. Ограничений по коду или размеру данных нет.

Большинство компиляторов, ориентированных на x64, включая ifort, принимают параметр --mcmodel=model, позволяющий управлять используемой моделью памяти. Модель по умолчанию — small. Размер вашего объектного файла означает, что существует огромное количество инициализированных статических данных, возможно, несколько очень больших инициализированных массивов (например, DATA или BLOCK DATA операторов) или множество меньших массивов (я сомневаюсь, что даже 1 миллион операторов кода сгенерирует 2 ГиБ инструкций). код). Компиляция с --mcmodel=medium или --mcmodel=large должна решить проблему с большим размером объектного файла.

Обратите внимание, что связывание вместе объектных кодов, использующих разные модели памяти, ведет к катастрофе — все приложение должно быть скомпилировано с одной и той же моделью памяти.

person Hristo Iliev    schedule 05.01.2013