[racket] Performance. Higher-order function

From: Richard Cleis (rcleis at me.com)
Date: Sun Aug 3 18:29:24 EDT 2014

If I (define i->c integer->char), and use it in your test1, it becomes the slowest.
That might mean that the "unknown function" response from Dr F applies to your function, too.
In other words, I think this is another example of drawing ambiguous conclusions from tests that are too simple.
I gave up on benchmarks long ago, because there are too many people outsmarting too many other people. 

Interesting, though (uh oh, I am getting sucked in): 
In v5.3.1 all of your tests are the same speed.
I even added some tests that use 'currying' to perhaps prevent the conversion function from being "inspected" on every call, and those are the same speed, too.

So it seems that the outsmarting peeps who wrote v6.1 optimized your first test, somehow, to make it twice as fast when it uses a "known function".

I am somehow reminded of the Fortran days and "intrinsic functions", but don't know if that is the same issue as this one.

rac


On Aug 3, 2014, at 3:15 AM, Roman Klochkov wrote:

> Are higher order function always slow?
> 
> Made small test:
> test1 -- unfamous set-in-the-loop accumulating
> test2 -- built-in build-string
> test3 -- manually written build-string with the same code as in test1
> ----
> (define (test1 n)
> (define res (make-string n))
>     (for ([i (in-range n)])
>         (string-set! res i (integer->char i)))
> res)
> 
> (define (test2 n)
>     (build-string n integer->char))
> 
> (define (build-string1 n proc)
>     (define res (make-string n))
>     (for ([i (in-range n)])
>         (string-set! res i (proc i)))
>     res)
> 
> (define (test3 n)
>     (build-string1 n integer->char))
> 
> (time (for ([i 100000]) (test1 100)))
> (time (for ([i 100000]) (test1 100)))
> (time (for ([i 100000]) (test1 100)))
> (displayln "")
> (time (for ([i 100000]) (test2 100)))
> (time (for ([i 100000]) (test2 100)))
> (time (for ([i 100000]) (test2 100)))
> (displayln "")
> (time (for ([i 100000]) (test3 100)))
> (time (for ([i 100000]) (test3 100)))
> (time (for ([i 100000]) (test3 100)))
> ----
> Tested on Linux x32
> 
> $ /usr/racket/bin/racket 
> Welcome to Racket v6.1.
> > (enter! "test") 
> cpu time: 360 real time: 469 gc time: 64
> cpu time: 212 real time: 209 gc time: 0
> cpu time: 208 real time: 208 gc time: 0
> 
> cpu time: 400 real time: 402 gc time: 0
> cpu time: 380 real time: 382 gc time: 4
> cpu time: 384 real time: 383 gc time: 0
> 
> cpu time: 524 real time: 529 gc time: 4
> cpu time: 468 real time: 470 gc time: 8
> cpu time: 412 real time: 414 gc time: 12
> 
> ---
> 
> So I see, that build-string version is about two times slower, than set-in-the-loop. Why so much? I expected about 10-20% difference.
> 
> -- 
> Roman Klochkov
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140803/11f66c5e/attachment.html>

Posted on the users mailing list.