Похоже, можно ставить точку попыткам еще выдавить скорость из "нашего тестового примера".
Потестировал на других машинах. Увы, линуксовых. Но тенденция проглядывается.
Вот что получилось в итоге.
Intel Core I5-2450M, двухядерка с гипертредингом, 64х Windows 7, RAM 6G:
(на этой изначально тренировались)
C# - 21.4 сек. 
Java - 28 сек.
fp - 80 сек.
Visual C++ (fgets/fprintf) - 64 сек.
Intel Atom 540 - двухъядерка с гипертредингом, 1.6 GHz, RAM 2Gb, Debian Linux, 32x:
C# (тот же файл под mono): 247 сек.
Java: 114 сек.
fp: 108 сек.
GCC (fgets/fprintf): 183 сек.
Intel Celeron D, 2.4 GHz, Одноядерник без гипертрединга, RAM 2Gb, Debian Linux 32x:
C# (mono): 285 сек.
Java: 199 сек.
fp: 100 сек.
GCC: 156 сек.
То есть, тотальный выброс производительности на C# и JAVA получается только на многоядерных процессорах. Отсюда подозрение, что .net и виртуальная машина жабки в процессе работы распараллеливают какие-то операции - либо I/O, либо сами вычисления, либо копирование блоков памяти. Ибо C# под неполноценной средой исполнения сдулась сразу, а жабка - на чисто одноядерном процессоре ушла на показатели, где ее обычно привыкли позиционировать.
К приложению fpc для парсинга файлов из одного в другой, получаются две важные детали:
1. Обязательно поставить должное значение буферизации SetTextBuffer для открытых файлов, иначе производительность падает очень заметно
2. Транслировать все собственные функции (коды) обработки строк  в ассемблер и внимательно смотреть, чтобы не появлялись фантомные присваивания и выделения памяти под промежуточные строки, иначе опять же производительность резко деградирует. Выбор между двумя полюсами - катастрофически медленная работа со строками - либо весьма плохо анализируемый и запутанный код работы с ними через указатели, с привязкой к внутреннему представлению.
Ну, и мы работаем на одном ядре. Всегда.  

  Потому сишарп на некоторых машинах не обогнать в принципе. Ну, или ценой усилий, не стоящих того. Как то так.
Добавлено спустя 6 минут 13 секунд:Да, полный оутсайд у строково-потоковой реализации на С++ STL, 236 секунд на первой машине
(на g++ даже откомпилировать не удалось, лезут ошибки макроопределений библиотек iostream)
и у fpc, стоит заменить ему строки на UnicodeString - 819 секунд.
Если поменять функции POS/RPOS на самописные - 297 секунд.
Жабка, кстати при работе со строками получается в некоторых случаях необчно привлекательной. Не забываем, с _какими_ она строками работает, это не жалкие байты. Получается, что шустро работает, зараза.