On Mon, May 14, 2012 at 9:12 PM, Adrian Thurston <[email protected]>wrote:
> Hi Victor, I haven't looked at the patch yet, I'll hopefully do that > tonight. It sounds similar to the 'split goto' mode I had worked on some > years back but is now unmaintained. The machine was partitioned naively -- > psuedo optimally requires advanced heuristics. Between partitions, tables > were used. Within a partition, directly executable was used. That sound the > same? > Well, the implementations are kind-of similar, but the end goals are different. In "split goto" mode you have few functions which call each other which of course makes compiler happier, but does not help us because we really want to convince compiler to keep some critical information on registers (in our case actions fire once per 2-3 bytes, function calls or lack of them really do a world of difference in such a case) - this is only possible if we keep everything in one large functions (plus may be some inlined functions which does not help the compiler at all). My patch replaces large switches with table which contains the next state and then does jump to _again label.This reduces number of basic blocks about 5-7 times and makes compiler much happier and the cost is small: I just add one table and one unconditional goto (which is easy for the CPU to predict). Of course I remove a lot of conditional jumps which makes it harder for the CPU to keep track of things - I think this is where 20% slowdown comes from. I can send you example of our .rl file and test-driver if you want to experiment (it's open-source projects, there are nothing secret here), but it's huge (about 3MB .rl file and 1MB test file) and the problem only happens on Windows thus it's not very hack-friendly case. > -----Original Message----- > From: Victor Khimenko <[email protected]> > Sender: [email protected] > Date: Sun, 13 May 2012 16:35:35 > To: <[email protected]> > Reply-To: [email protected] > Subject: [ragel-users] MSVC-friendly -GT2 mode > > _______________________________________________ > ragel-users mailing list > [email protected] > http://www.complang.org/mailman/listinfo/ragel-users > > > _______________________________________________ > ragel-users mailing list > [email protected] > http://www.complang.org/mailman/listinfo/ragel-users >
_______________________________________________ ragel-users mailing list [email protected] http://www.complang.org/mailman/listinfo/ragel-users
