flang компилятор доказывает, что программа не зациклится 0.6.2 GitHub

Игры и обработка видео — не наш случай, и причин ровно три

  1. Бюджет кадра. 60 кадров в секунду — 16 миллисекунд на кадр. Пауза сборщика в 50 мс — три пропущенных кадра, видимый рывок. Регионы эту причину убирают — memory-per-category-is-regions.
  2. Копирование больших буферов. Кадр Full HD — около 8 МБ. Чистое ФП говорит «не меняй, создай новый»; гигабайты в секунду впустую. Нужна оптимизация, замечающая, что старый буфер никому не нужен, и меняющая его на месте (linear / uniqueness types). В flang её нет.
  3. Упаковка чисел. Каждое значение лежит в структуре с тегом. В тесном цикле по миллиону пикселей это 10–50 раз.

Все три чинятся, ни одна не чинится дёшево.

Оценка скорости была такой: «реалистичный потолок — уровень хорошей JVM или Go, но не C; этого хватит для сервисов, расчётов, разбора данных».

Замер её опроверг, и не в ту сторону: мы медленнее Python в 1,4 раза, а компиляция не окупается никогда — slower-than-python-by-1-4. Про Python я не сказал вовсе, хотя должен был. Исходная оценка оставлена, чтобы видно было, чем она была неверна.

Что при этом подтвердилось: причина не в гарантиях. Цена доказуемости — 2,5 % (provability-costs-2-5-percent), остальное — неоптимизированный генератор, и первые две правки дают 1,8 раза (biggest-win-for-least-work).

Связано: purity-is-not-zero-allocation, arena-never-releases