Factor is pretty fast already, but there are also some pretty low-hanging
fruit like these:

* Lift generic dispatch out of loops, for example this 30% win for
iterating over slices:

    https://github.com/slavapestov/factor/issues/1213

    https://github.com/slavapestov/factor/issues/839

* Fixnum specialization for loops, big win but has some bootstrap-time and
image-size implications:

    https://github.com/slavapestov/factor/issues/788

* Possible improvements to class? checks:

    https://github.com/slavapestov/factor/issues/806

I know Alex Vondrak has looked at a couple of these and it would be nice to
get some more eyes on them.  It's unfortunate that we rely so heavily on
inlining for performance, better would be to implement some kind of simple
JIT dispatch based on known or observed types.  You can see some evidence
of hard-coding for performance here where a compiler improvement would be
better:


https://github.com/slavapestov/factor/blob/master/core/math/order/order.factor#L22


https://github.com/slavapestov/factor/blob/master/basis/math/combinatorics/combinatorics.factor#L14

Best,
John.


On Sat, Jan 17, 2015 at 4:30 PM, Björn Lindqvist <bjou...@gmail.com> wrote:

> Hello all,
>
> Someone made a benchmark on github to compare performance of different
> languages on a simple pathfinding problem:
>
> https://github.com/logicchains/LPATHBench/blob/master/writeup.md
>
> It's getting popular and people are quoting the results they get from
> it to show that a language is really fast. Factor wasn't represented
> to I wrote an implementation of the algorithm here:
>
> https://github.com/bjourne/playground-factor/blob/master/lpath/lpath.factor
>
> Performance is pretty good I think. Factor runs in ~1340 ms while the
> Java version runs in ~1030 ms on my machine. And it wasn't that hard
> to get that speed -- you just replace safe generic words like nth with
> unsafe specialized ones like array-nth. Though I wonder if anyone has
> any ideas on how to make the Factor code run even faster?
>
> One idea I toyed with was making a non-recursive variant of the
> (longest-path) word. Right now it is co-recursive, (longest-path)
> calls ((longest-path)) which calls (longest-path). I think that if you
> can get rid of the co-recursion it would easily become as fast as the
> Java version.
>
>
> --
> mvh/best regards Björn Lindqvist
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to