C vs Haskell: сравнение скорости на простом примере

Ранее мы сравнивали одни программы на Си с другими программами на Си, которые отличаются от первых характерными для Хаскелла приёмами. А теперь сравним программу на Си и программу на Хаскелле. Выберем простейшую задачу прочитать содержимое файла и просуммировать 32-битных слов в нём.

Ниже — программа, решающая её на Хаскелле. Насколько правильно, насколько эффективно — судить не берусь. Но раз не побоялись выложить код на всеобщее обозрение, значит он приемлем для программистов на Хаскелле.

import System.Environment
import Data.Binary
import qualified Data.ByteString as B
import qualified Data.ByteString.Lazy.Internal as L
import System.IO
import qualified Data.ByteString.Lazy as L
import Data.Binary.Get
import Data.Word
 
main::IO()
main = do
  args <- getArgs
  a <- (calculateSumInFile (head args))
  print a
 
calculateSumInFile:: FilePath->IO Word32
calculateSumInFile path =
    withBinaryFile path ReadMode $ \h ->
        let byWords s = do
                w <- L.hGet h 4
                if L.length w == 4 then
                    byWords $ s + runGet getWord32host w
                else return s
        in byWords 0

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

. . .
fread(буфер, длина, 1, файл откуда);
. . .
_31  x = 0;
_31  i = 0;
_31*  очередное слово = (_31*) буфер;
for (; i < длина; i += 4, ++очередное слово)
	x += *очередное слово;
printf( "Результат: %d\n", x); 

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

Для тестирования использовались те же компьютеры, что и в предыдущих тестах. А вот размер файла менялся от 1Мб до 256 Мб. Опять замер проводился на компьютерах A, B и C, для каждого из них измерялось время прохождения теста на Си (первая колонка), Хаскелл (вторая) и соотношение времени, затраченное программой на Хаскелл ко времени, затраченном программой на Си. Вот полученные результаты:

Вынесем соотношения в отдельную табличку:

И построим график:

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

В логарифмическом масштабе график более нагляден:

Выводы

Если размер файла небольшой (1 Мб), то разница между программками на Хаскелле и Си — в разы. С возрастанием размера файла разница становится чудовищной, в несколько порядков. Так что программирование на Хаскелл требует внимательности и аккуратности, не все его средства одинаково полезны.

Ещё одно любопытное наблюдение: компилятор Tiny CC для программки на Си подготовил исполняемый файл размером 3584 байтов. А вот компилятор GHC «выдал на гора» 15Мб. Почувствуйте разницу. Оптимизировали, оптимизировали GHC, да так и не дооптимизировали.

Вывод Филипа Уодлера, одного из соавторов Хаскелла, о двухкратной разнице по скорости Си и Хаскелла, легко опровергается простым примером. Это один из ответов на вопрос, почему Хаскелл так мало используется в отрасли.

Post Scriptum

Д.Ю.Караваев прислал мне программку, делающую то же самое, но на PL/1. Запустил программку на компьютере конфигурации A, получил следующие результаты (время исполнения в процентах от программы на Си):

• 1 Мб — 98%
• 4 Мб — 91%
• 16 Мб — 94%
• 64 Мб — 85%
• 256 Мб — 86%

Post Post Scriptum

Нашёл задачку вычисления определителя квадратной матрицы на Хаскелле. Автор — Борис Файфель, кандидат физико-математических наук, доцент Института прикладных информационных технологий и коммуникаций в Саратове. Известен как разработчик HomeLisp.

Решил написать программку на Си, которая вычисляет то же самое, чтобы увидеть разницу в скорости работы массивов на Си и списков на Хаскелле. Чтобы была возможность сравнить, необходимо увеличить размерность матрицы. Для начала выбрал размер матрицы 512 на 512. Сгенерировал случайные числа в количестве 512 на 512. Но если компилятор TinyCC отработал благополучно, то с Хаскеллем возникли проблемы. Компилятор GHC выдал сообщение:

Попытка выделить более 129024 байт. В настоящее время это невозможно из-за ограничений генератора кода GHC. Предложение: читайте данные из файла вместо больших статических структур данных в коде.

Вот это да! На что ещё годен Хаскелл, кроме защиты диссертаций?! Десятки британских учёных защитили на нём учёные степени, а довести до ума компилятор — руки не дошли. А между тем, компилятор TinyCC написал одиночка и проблем с объёмом статических данных в нём не наблюдается.

Опустился до матрицы 128x128, тогда компиляция прошла успешно. Но после запуска программка выдала: «Infinity». На этом желание сравнивать иссякло.

Опубликовано: 2022.01.01, последняя правка: 2022.02.10    20:49

✅  2022/05/14 13:13, MihalNik          #0 

Но раз не побоялись выложить код на всеобщее обозрение, значит он приемлем для программистов на Хаскелле.

кандидат физико-математических наук, доцент

✅  2022/05/14 19:29, Автор сайта          #1 

Или для галочки по требованию образовательного учреждения.

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

✅  2022/05/15 08:55, MihalNik          #2 

Ну что Вы. В этом трудно заподозрить человека

в целом отечественный компилятор PL/1 выглядит достойно на импортном фоне

✅  2022/05/15 14:50, Автор сайта          #3 

Было бы очень здорово провести более глубокое сравнение с разными компиляторами языка C на разных машинах

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su