tag:blogger.com,1999:blog-17087850.post3242780893093529342..comments2023-10-31T06:50:41.697-04:00Comments on Factor: a practical stack language: Faster performance on the reverse-complement benchmarkSlava Pestovhttp://www.blogger.com/profile/02768382790667979877noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-17087850.post-91712093637261462362007-01-19T12:39:00.000-05:002007-01-19T12:39:00.000-05:00Dan, like I said I/O only accounts for about 5 sec...Dan, like I said I/O only accounts for about 5 seconds of the total runtime of the benchmark. So readln is not a performance problem at all. The slowdown comes from the actual processing done by the benchmark, and this is something I'm going to address over time as the code generator improves and sequence operations become more efficient.Slava Pestovhttps://www.blogger.com/profile/02768382790667979877noreply@blogger.comtag:blogger.com,1999:blog-17087850.post-75343936002705363082007-01-19T11:52:00.000-05:002007-01-19T11:52:00.000-05:00What's going on in the fast bigForth implementatio...What's going on in the fast bigForth implementation is a reimplementation of line reading, using buffers. The slow one uses a word called read-line, which, I'm guessing, is responsible for the slowness. This is gonna be tough, getting good performace for factor while maintaining the use of readln.Anonymoushttps://www.blogger.com/profile/00902922561603041049noreply@blogger.comtag:blogger.com,1999:blog-17087850.post-54609613595981018592007-01-19T09:41:00.000-05:002007-01-19T09:41:00.000-05:00The difference in performance could be because the...The difference in performance could be because the second Forth implementation allocates the entire space for the buffer before anything actually gets run. The other version looks like it doesn't do this.<br /><br />btw, congrats on fixing up IO performance, seems like that's been bugging you lately. :)Anonymousnoreply@blogger.com