[Factor-talk] UI worlds and printing question
Hi, Thanks. I hadn't considered that the UI was setting the input stream to something else! On the pop-ups - ok, fair enough, but is there then a good way to open a popup that is not constrained to the borders of the parent window to get around issue #1268? (Actually, where is the code that opens the error list? I did have a look but I had assumed it was : debugger-window but I now see I was wrong..) Mark -- 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
Re: [Factor-talk] Google+ Factor community and first question
Great initiative, I subscribed! 2015-01-16 9:46 GMT+00:00 Marc Hanisch : > Hell list, > > I've discovered Factor some days ago and am really impressed! On the search > for more information I couldn't believe that there is no community / forum / > whatever - except this mailinglist - where users can exchange. So I've > created a Google+ community for the Factor programming language. I don't > include a link here, please search for "Factor Language" in Google+ and you > will find it. I would be glad if some users join. -- 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
[Factor-talk] A performance challenge
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
Re: [Factor-talk] A performance challenge
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 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
Re: [Factor-talk] A performance challenge
Also, minor comment, instead of:
length [ 0 ] { } replicate-as ;
You can just do:
length 0
And instead of the array-nth stuff, you can just do some type declarations
and the compiler should make it the same as your array words:
{ fixnum array } declare nth-unsafe ;
{ array } declare first2-unsafe ;
I recommend using TYPED: or TYPED:: declarations to specify neighbors is an
array and normal sequence words?
Best,
John.
On Sat, Jan 17, 2015 at 4:30 PM, Björn Lindqvist 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
