On Fri, 2009-09-11 at 05:01 -0700, Derick Eddington wrote: > On Fri, 2009-09-11 at 03:42 -0700, Derick Eddington wrote: > > On Thu, 2009-09-10 at 22:53 -0700, Derick Eddington wrote: > > > Darn, my stack-lang implementation sucks: > > > > > > [...] > > > > > > As you can see, the same algorithm took mine 7.2 seconds and took Factor > > > only 0.6 second. > > > > > > I'm not sure why mine is so slow. I suspect it's because my data stack > > > is an SRFI-39 parameter and it is used heavily. I'm going to change my > > > implementation to pass and return the data stack through "word" > > > procedure calls, to see if that helps. > > > > I did that and it brought the time down to 3.3 seconds, but it's still > > allocating 1.4 GB. > > > > [...] > > > > But I think I'll try making a pre-allocated > > block-allocated stack using a linked list of vectors and make convenient > > abstractions for working with it. Does that seem worthwhile? > > Actually, I'm not so sure that would be faster than a list. But I don't > know. Cons'ing is pretty darn fast and minimal instructions, right? -- > versus vector index-marker checking and arithmetic and vector accessing > and mutating. Is there a more efficient representation than a list...?
Well, I tried the vectors representation. It makes that (S 34 fib) take 8.1 seconds, even with using "unsafe" operators wherever possible. So, I won't be keeping it. Now I'm going to check-out that Dominikus guy's expand-time rewriting stack-lang kernel (posted on comp.lang.scheme) and see if I can adopt it for increasing the speed of my system while still retaining the full integration with R6RS Scheme I want. -- : Derick ----------------------------------------------------------------
