Переписать Fortran на Rust или оставить за оберткой?

Ядро на Fortran, которое двадцать лет выдает надежные результаты, не становится плохим кодом только потому, что работать с окружающим приложением стало неудобно. Если у ядра узкий интерфейс, воспроизводимая сборка и есть человек, способный найти причину сбоя, обертка с современным интерфейсом обычно обходится дешевле и несет меньше риска. Один лишь язык исходного кода не дает повода переписывать работающую математику.

Решение меняется, когда старое ядро диктует способ развертывания, ограничивает выбор оборудования, скрывает изменяемое состояние или требует знаний, которых в организации больше нет. За сохранение такого кода приходится платить постоянно. Перенос на Rust может оказаться дешевле очередного цикла со специальными компиляторами, устаревшими хостами, ручными релизами и сбоями, которые понимает только ушедший на пенсию инженер. Сложность в том, чтобы честно сопоставить расходы, не считать возраст дефектом и не принимать прошлую корректность за доказательство будущей пригодности к эксплуатации.

Отделите ценность алгоритма от цены его оболочки

Проверенный алгоритм и его реализация на Fortran связаны, но это разные активы. Уравнения, коэффициенты, правила сходимости и принятое поведение в крайних случаях могут требовать сохранения, даже если систему сборки и предположения о среде выполнения пора заменить.

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

До выбора решения запишите, ради чего ядро стоит сохранить. Полезная опись должна быть конкретной:

• Математическая модель и ее версия, принятая бизнесом
• Диапазоны входных данных из продакшена, включая недопустимые и вырожденные случаи
• Требуемая точность, правила округления и допуски сходимости
• Ограничения времени и памяти, влияющие на реальную пакетную задачу или запрос
• Флаги компилятора, связанные библиотеки, файлы данных и порядок инициализации

Такая опись выявляет важное различие. Численный паритет означает, что результат нового выполнения укладывается в согласованный допуск. Поведенческий паритет охватывает ошибки, предупреждения, число итераций, порядок результатов, обработку NaN, тайм-ауты и побочные эффекты. Перенос может соответствовать первому определению и сломать приложение по второму. Обертка способна сохранить оба вида паритета, но только если ее граница незаметно не меняет представление данных или жизненный цикл.

Возраст исходного кода должен находиться ближе к концу документа с обоснованием решения. Наблюдаемые обязательства ставьте в начало. Если их никто не может сформулировать, ни обертка, ни новая реализация еще не готовы. Сначала восстановите контракт по коду и данным из продакшена.

Узкая и стабильная граница говорит в пользу обертки

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

Считайте элементы границы, а не строки Fortran. Решатель на 300 000 строк, открытый через шесть стабильных операций, может быть проще изолировать, чем процедуру на 6 000 строк, которая читает глобальные файлы, меняет блоки COMMON, пишет отчеты и делает обратные вызовы в пользовательский интерфейс. У второй программы больше поверхность поведения, хотя исходного кода меньше.

Обертка подходит, когда выполнены все условия:

• Поддерживаемый компилятор воспроизводит двоичный файл на целевых хостах
• У ядра есть тесты или записанные случаи с доверенными результатами
• Вызовы не зависят от скрытого состояния процесса либо это состояние можно изолировать
• Затраты на преобразование данных малы по сравнению со временем расчета
• Исправления безопасности и диагностика доходят до границы без правки математики

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

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

Сделайте C ABI маленьким и скучным стыком

Fortran и Rust могут надежно взаимодействовать через двоичный интерфейс C, если сторона Fortran использует ISO_C_BINDING вместо соглашений об именах конкретного компилятора. На стыке нужны числовые типы фиксированной ширины, явные длины массивов, плоские буферы и целочисленные коды состояния.

Эта точка входа Fortran явно показывает представление данных:

module kernel_api
  use, intrinsic :: iso_c_binding
  implicit none
contains
  subroutine evaluate(n, x, scale, y, status) bind(C, name="kernel_evaluate")
    integer(c_int), value :: n
    real(c_double), intent(in) :: x(n)
    real(c_double), value :: scale
    real(c_double), intent(out) :: y(n)
    integer(c_int), intent(out) :: status

    if (n < 1 .or. scale <= 0.0_c_double) then
      status = 1_c_int
      return
    end if

    call legacy_evaluate(n, x, scale, y)
    status = 0_c_int
  end subroutine evaluate
end module kernel_api

На стороне Rust небезопасная операция остается в небольшом модуле, а остальное приложение получает проверенный API для срезов:

unsafe extern "C" {
    fn kernel_evaluate(
        n: i32,
        x: *const f64,
        scale: f64,
        y: *mut f64,
        status: *mut i32,
    );
}

pub fn evaluate(x: &[f64], scale: f64) -> Result<Vec<f64>, KernelError> {
    let n = i32::try_from(x.len()).map_err(|_| KernelError::InputTooLarge)?;
    if x.is_empty() || !scale.is_finite() || scale <= 0.0 {
        return Err(KernelError::InvalidInput);
    }

    let mut y = vec![0.0_f64; x.len()];
    let mut status = 0_i32;
    unsafe {
        kernel_evaluate(n, x.as_ptr(), scale, y.as_mut_ptr(), &mut status);
    }

    match status {
        0 => Ok(y),
        code => Err(KernelError::Fortran(code)),
    }
}

Код намеренно выглядит невыразительно. На границе языков это достоинство. Rust Nomicon относит вызовы внешних функций к unsafe, поскольку компилятор не может проверить контракт другого языка. Оставьте блок unsafe достаточно маленьким для аудита и явно проверьте каждое предусловие до вызова.

Руководство GNU Fortran по совместимости объясняет, как совместимые процедуры и типы отображаются через BIND(C) и ISO_C_BINDING. Пользуйтесь этим механизмом, а не обычным для конкретного компилятора преобразованием имен. Экспортированный символ, найденный инструментом проверки двоичных файлов, подтверждает устройство сегодняшней сборки, но не создает стабильный интерфейс для завтрашнего компилятора.

В первой версии стыка не передавайте структуры Rust, производные типы Fortran, размещаемые массивы или собственные строки языков. Превратите их в плоские данные. Для матриц документируйте размеры, ведущий размер и порядок хранения. Текст передавайте как буфер байтов с явной длиной и правилом кодировки. Простые представления не оставляют места для дорогой неоднозначности.

Скрытое состояние ломает обертки

Обертка ломается, когда программа с состоянием выглядит как чистая функция, но никто не контролирует ее состояние. Переменные SAVE, блоки COMMON, кэшированные рабочие массивы, переменные среды, номера устройств, файлы рабочего каталога и режим вычислений с плавающей точкой могут изменить результат внешне одинакового вызова.

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

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

Составьте карту полного жизненного цикла вызова:

1. Запустите новый процесс и запишите каждый загруженный файл, значение среды и библиотеку.
2. Проследите инициализацию до момента, когда можно выполнить первую численную операцию.
3. Дважды вызовите один и тот же случай и сравните все результаты и коды состояния.
4. Чередуйте два разных случая, затем повторите их в отдельных процессах.
5. Вызовите недопустимый вход, по возможности ошибку выделения памяти и отсутствие сходимости.

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

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

Докажите паритет на данных, похожих на продакшен

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

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

Полезный стенд выдает для каждого вызова такую запись:

{
  "case_id": "settlement-004812",
  "operation": "evaluate",
  "input_digest": "sha256:...",
  "old": {"status": 0, "iterations": 7, "output": [1.25, 3.5]},
  "candidate": {"status": 0, "iterations": 7, "output": [1.25, 3.5]},
  "comparison": {"max_abs": 0.0, "max_rel": 0.0, "accepted": true}
}

Не выбирайте один глобальный эпсилон только ради удобства. Абсолютный допуск работает около нуля, относительный подходит при росте величин, некоторым результатам нужны границы в предметных единицах, а точным целым числам и статусам требуется точное равенство. Для NaN задайте явную политику, потому что обычное равенство обрабатывает его не так, как конечные значения. Знак нуля иногда важен, если последующая операция его проверяет.

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

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

Переписывайте, когда расходы на владение повторяются

Переносите ядро, если его сохранение создает постоянные эксплуатационные расходы, которые обертка не убирает. Самые веские причины связаны с владением и развертыванием, а не с предпочтениями в языках.

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

Состав команды имеет значение, но фраза «мы не нанимаем разработчиков Fortran» сама по себе слишком слаба. Стабильное ядро за оберткой может почти не требовать работы с языком. Измерьте настоящий спрос: как часто меняется алгоритм, сколько инцидентов требуют диагностики исходного кода, кто проверяет обновления компилятора и что происходит при отсутствии нынешнего владельца? Перенос только ради совпадения с основным языком способен поглотить большой бюджет, не снизив эти нагрузки.

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

Есть отдельный довод в пользу безопасности и изоляции. Если ядро принимает недоверенные файлы, использует индексы без проверки или работает в одном процессе с открытым сервисом, изоляция может понадобиться еще до переноса. Пока идет новая реализация, запускайте ядро в ограниченном процессе-обработчике и задайте пределы для входных данных. Rust уменьшает число многих ошибок памяти в переписанном коде, но не доказывает математику, не предотвращает исчерпание ресурсов и не делает безопасными внешние небезопасные библиотеки.

Хороший документ с обоснованием переводит повторяющиеся проблемы в годовые трудозатраты инженеров и расходы на инфраструктуру. Включите лицензии компилятора, специальные хосты сборки, работу над релизами, зависимость от отдельных людей при сбоях, простаивающие из-за сериализации мощности и заблокированные изменения платформы. Не назначайте выдуманную цену «современности». Оценивайте работу, которую организация действительно выполняет.

Настройки компилятора входят в контракт поведения

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

Восстановите точную сборку до оценки обертки или переноса. Сохраните название и версию компилятора, все флаги компиляции и компоновки, определения препроцессора, версии библиотек и переменные среды сборки. Получите команды из системы сборки, а не из комментария в старой инструкции для операторов. Затем выполните сборку в чистой среде и сравните эталонные случаи. Если чистая сборка уже отличается, у команды есть проблема воспроизводимости еще до начала миграции.

Агрессивная оптимизация вычислений с плавающей точкой требует особого внимания. При разрешающих математических флагах компилятор может менять группировку операций, объединять умножение и сложение, считать NaN невозможным или предполагать, что знак нуля не имеет смысла. Эти преобразования ускоряют код, но способны изменить сходимость около порога. Вопрос не в том, соответствует ли параметр строгому стандарту в отрыве от системы. Спросите, допускает ли контракт продакшена такое изменение, и докажите ответ на стенде.

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

Создавайте рядом с каждым кандидатом простой манифест сборки:

kernel_version=2026.08
compiler=gfortran
compiler_version=<captured from build>
compile_flags=<captured from build>
blas_implementation=<name and version>
target_cpu=<declared target>
source_digest=<repository revision>
test_corpus=<immutable corpus revision>

Угловые скобки отмечают поля для заполнения, а не разрешение оставить данные неизвестными. Система сборки должна создавать манифест автоматически, а операция версии или журнал запуска должны его показывать. Если результат изменится после развертывания, операторы смогут определить, что именно поменялось: код, компилятор, библиотека или набор входов.

При обертке такая дисциплина превращает двоичный файл Fortran в управляемый компонент вместо необъяснимого файла, который копируют между серверами. При переносе она дает инженерам Rust реальное поведение, с которым нужно совпасть. Сборки Rust требуют такого же подхода: фиксируйте версии зависимостей, записывайте инструментарий компилятора, объявляйте возможности целевого процессора и держите флаги производительности отдельно от флагов паритета, пока их влияние не измерено.

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

Последняя ловушка заключается в сравнении старой консервативной сборки с кандидатом, где включили все доступные оптимизации, а затем в приписывании результата языку. Запустите матрицу, которая разделяет реализацию и настройки: исходные настройки Fortran, оптимизированный Fortran, консервативный Rust и оптимизированный Rust. Сравнение покажет, дает ли экономию перенос, обновление компилятора или разрешение иного численного контракта.

Цена оборудования может перечеркнуть правильную обертку

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

Не исходите из того, что Rust будет быстрее. Зрелые компиляторы Fortran создают отличный численный код, а давно работающие ядра могут уже вызывать настроенные процедуры BLAS или LAPACK. Буквальный перенос способен потерять векторизацию, чаще выделять память или заменить оптимизированный вызов библиотеки обычным циклом. Выбор языка не отменяет пропускную способность памяти и сложность алгоритма.

Экономическое давление обычно возникает в другом месте. Ядро может собираться только для старой архитектуры, зависеть от среды выполнения поставщика, ограничивающей развертывание, или сериализовать работу через глобальное состояние. Возможно, оно несколько раз копирует большие массивы ради новой сервисной границы. Тогда облачные экземпляры простаивают, пока запросы ждут за единственным вычислительным каналом. Эти системные расходы можно измерить, и они способны оправдать перенос, даже если один изолированный вызов Fortran остается быстрым.

Проверяйте репрезентативные распределения, а не один удобный случай. Записывайте как минимум пропускную способность, хвостовую задержку, пиковый объем резидентной памяти, число байтов, скопированных на границе, и время ожидания сериализованного участка. Если инициализация заметна, запускайте прогретые и холодные случаи. Зафиксируйте в результате версии и флаги компилятора, чтобы другой инженер мог повторить замер.

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

Перенос на Rust должен сохранять поведение, а не синтаксис Fortran

Успешный перенос переводит вычислительную модель, а затем дает ей структуру, за которую могут отвечать инженеры Rust. Транслитерация сохраняет старый поток управления, глобальные массивы, сигнальные значения и привычки индексации, добавляя к ним борьбу с borrow checker. Итог сложнее проверять, чем любую исходную версию.

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

Разделите перенос по математическим границам, наблюдаемым стендом паритета. Подходящие единицы: предварительная обработка, выбор коэффициентов, одна итерация решателя, проверка сходимости и форматирование результата. Перенесите одну единицу, по возможности вызовите ее из существующего пути и сравните промежуточные значения. Так расхождение останется в пределах одного этапа, и инженерам не придется исследовать весь решатель.

Явно зафиксируйте численные решения в Rust. Укажите, имеют ли значения тип f32 или f64, как целочисленное преобразование обрабатывает переполнение, какой порядок редукции допустим и может ли объединенное умножение со сложением менять округление. Сначала сохраните принятый алгоритм. Улучшайте его позже отдельным изменением с самостоятельной проверкой, потому что одновременная миграция языка и ревизия модели уничтожают чистый эталон.

Представляйте сбои типизированными результатами вместо магических значений, но сохраняйте прежнее внешнее поведение, пока вызывающий код осознанно не примет новый контракт. Если путь Fortran выдает предупреждение и пригодное приближение, первый релиз Rust не должен молча превращать этот случай в фатальную ошибку. Улучшенный API приносит пользу, только когда окружающая система меняется вместе с ним.

Оставляйте unsafe Rust на внешних границах и в проверенных вызовах библиотек. Чистый Rust все еще может вызвать panic при индексации, выделить память без практического предела или получить NaN из допустимых операций с плавающей точкой. Установите ограничения и возвращайте ошибки на границе сервиса. Безопасность памяти устраняет класс дефектов, но не определяет эксплуатационный контракт.

Сохраняйте обратимость решения, пока проверка не даст ответ

Самая безопасная программа откладывает необратимый выбор и одновременно улучшает оба варианта. Сначала создайте воспроизводимую сборку Fortran и стенд паритета. Затем поместите существующее ядро за интерфейсом, который хотели бы иметь даже при замене реализации. Эта работа нужна качественной обертке и пригодится при переносе.

Запустите версию с оберткой под репрезентативной нагрузкой. Теперь есть доказательства стоимости преобразований, поведения при параллельных вызовах, изоляции сбоев и эксплуатационного владения. Если она выполняет требования сервиса, а команда умеет поддерживать сборку, остановитесь. Сохранение хорошего Fortran остается инженерным решением, а не недостатком амбиций.

Если требования не выполнены, тот же интерфейс станет границей замены на Rust, а те же записанные случаи оценят каждую перенесенную единицу. Там, где среда позволяет, разверните теневое сравнение: выполняйте кандидата, не отдавая ему управление ответом, записывайте ограниченные различия и изучайте случаи вне допуска. Защищайте чувствительные входы и ограничивайте дополнительную вычислительную нагрузку. Теневое выполнение служит методом проверки и не дает права небрежно копировать данные.

Установите критерии выхода до того, как перенос наберет собственную инерцию. Они должны включать принятый паритет, производительность на целевых хостах, поведение при сбоях, эксплуатационную диагностику и удаление зависимости от старой среды выполнения. Также задайте окно отката и доказательства, после которых эталон можно вывести из эксплуатации. Без таких условий команды бессрочно поддерживают две реализации и несут обе стоимости владения.

Теперь решение можно сформулировать без идеологии. Оставляйте обертку, когда расчет стабилен, граница узкая, а инструментарий пригоден к эксплуатации. Переписывайте, когда повторяющиеся ограничения владения или оборудования обходятся дороже измеренного переноса и организация способна проверить новую реализацию по старой. Если ни одно утверждение пока не доказано, потратьте следующий инженерный день на стенд, а не на перевод цикла.