LINUX.ORG.RU

ФВП и производительность

 , , ,


2

7

Провёл тест на скорость работы одной и той же функции, написанной нормально и через ФВП. Получил потерю производительности в полтора раза:

SBCL:

(declaim (optimize (speed 3) (safety 0)))

(asdf:oos 'asdf:load-op :alexandria)

(defun f (x)
  (+ (+ (+ x 1) 2) 1))

(let ((f-comp
          (alexandria:compose
            (lambda (x) (+ x 1))
            (lambda (x) (+ x 2))
            (lambda (x) (+ x 1)))))
  (defun f-comp (x)
     (funcall f-comp x)))

(defconstant iter 10000000)

(time
 (dotimes (i iter)
   (f i)))

(time
 (dotimes (i iter)
   (f-comp i)))


Evaluation took:
  0.181 seconds of real time
  0.180000 seconds of total run time (0.180000 user, 0.000000 system)
  99.45% CPU
  325,363,554 processor cycles
  0 bytes consed

Evaluation took:
  0.296 seconds of real time
  0.296000 seconds of total run time (0.296000 user, 0.000000 system)
  100.00% CPU
  530,610,480 processor cycles
  0 bytes consed

Racket:

#lang racket
(define (f x)
  (+ (+ (+ x 1) 2) 1))

(define f-comp
  (compose
   (lambda (x) (+ x 1))
   (lambda (x) (+ x 2))
   (lambda (x) (+ x 1))))

(define iter 1000000)

(time 
 (for ([i iter])
   (f i)))

(time 
 (for ([i iter])
   (f-comp i)))

cpu time: 728 real time: 726 gc time: 0
cpu time: 1244 real time: 1244 gc time: 0

Получается, функции высшего порядка лучше не использовать? А как с этим борются в Haskell, если там без них почти ничего написать нельзя (точнее не принято рекомендуемым стилем программирования)?

★★★★★

Ответ на: комментарий от sf

Без rewrite rules он «в рантайме строится».

Он, еще раз, вообще должен сфолдиться в константу. Без всяких rewrite rules. Так что имеет смысл рассматривать только тот случай, где фолдинга не будет.

anonymous
()
Ответ на: комментарий от anonymous

В рассматриваемом случае это ни на что не влияет.

Влияет. Порядок

- inline arg в compose_rr

- применение rewrite rule в compose_rr

позволит избавиться от списка в runtime, а

- попытка применить rewrite rule в compose_rr

- inline arg в compose_rr

не позволит.

Я бы сказал что не может, а должен. По-этому рассматриват ьподобные случаи вообще не имеет смысла.

Это было бы плохим свойством библиотеки бенчмарков :)

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

О том, что HOF не обязательно вносят overhead?

sf ★★★
()
Ответ на: комментарий от anonymous

> Без rewrite rules он «в рантайме строится».

Он, еще раз, вообще должен сфолдиться в константу. Без всяких rewrite rules. Так что имеет смысл рассматривать только тот случай, где фолдинга не будет.

Предметно. По твоему мнению что и во что должно фолдиться?

sf ★★★
()
Ответ на: комментарий от sf

О том, что HOF не обязательно вносят overhead?

Когда у тебя код фолдится в константу то вообще ничего оверхеда не вносит.

Это бессмысленный в рассмотрении случай. На практике такая оптимизация невозможна, зачем ее рассматривать?

позволит избавиться от списка в runtime, а

Нет, не позволит.

Это было бы плохим свойством библиотеки бенчмарков :)

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

anonymous
()
Ответ на: комментарий от sf

Предметно. По твоему мнению что и во что должно фолдиться?

В константу, результат данного выражения.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.