It used to be.
When we introduced the package system, it sounded like we were going to
split the distribution into multiple repositories (and have the main
distribution pulled from those multiple repositories). Optimization
Coach is one of the few packages that did the switch. The rest never
follo
Why isn't Optimization Coach one of the automatically-installed packages?
Racket Users list:
http://lists.racket-lang.org/users
FWIW, the optimization coach confirms both unrollings, and the fact that
neither `build-string1` nor `test1` (you wrote `test2`, was that a
mistake?) are ever inlined.
Reaching out for the decompiler would not have been necessary. :)
Vincent
At Mon, 4 Aug 2014 06:47:34 +0100,
Matthew Flatt wro
I made another test, using begin-encourage-inlining. I copied the
definition of build-string and compare the "normal" version with the
"inlined" version in Racket 6.1
"racket" version:
cpu time: 1326 real time: 1334 gc time: 78
cpu time: 1248 real time: 1262 gc time: 31
cpu time: 1264 real time: 1
Thank you! Now it's rather clear for me.
Mon, 4 Aug 2014 06:47:34 +0100 от Matthew Flatt :
>Well... a function call is expensive relative to some things, such as
>adding fixnums to produce a fixnum.
>
>
>My read of your initial results is that calling an unknown function is
>similar to the cost
Well... a function call is expensive relative to some things, such as
adding fixnums to produce a fixnum.
My read of your initial results is that calling an unknown function is
similar to the cost of one iteration in a loop that sets a character in
a string.
More precisely, decompiling the progr
> unknown function call is expensive
So, higher order function always slow.
Thus, to improve performance, one should use for/fold, for/list, ... and never
use map, foldl, build-string, ... with lambda.
Is it correct?
Sun, 3 Aug 2014 13:15:57 -0400 от Matthias Felleisen :
>
>Because build-strin
On Aug 3, 2014, at 6:29 PM, Richard Cleis wrote:
> 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
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 gav
Because build-string calls an unknown function 1000 x 10 times, and an
unknown function call is expensive.
Racket could possible collapse all modules and perform additional in-lining
optimizations eventually, which may help here. But it doesn't yet.
-- Matthias
On Aug 3, 2014, at 5:15
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)])
(stri
11 matches
Mail list logo
