From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Thu, 03 Feb 2011 13:54:05 EST." <05360a88f7a0cd797278d6bd6a3ae73f@ladd.quanstro.net> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> <20110203174129.C984D5B91@mail.bitblocks.com> <20110203183304.648355B91@mail.bitblocks.com> <05360a88f7a0cd797278d6bd6a3ae73f@ladd.quanstro.net> From: Bakul Shah Date: Thu, 3 Feb 2011 11:40:58 -0800 Message-Id: <20110203194058.8F4B55B91@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: abb9c6f4-ead6-11e9-9d60-3106f5b1d025 On Thu, 03 Feb 2011 13:54:05 EST erik quanstrom wrote: > On Thu Feb 3 13:33:52 EST 2011, bakul+plan9@bitblocks.com wrote: > > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom wr > ote: > > > > I agree with their goal but not its execution. I think a > > > > toolkit for manipulating graph based program representations > > > > to build optimizing compilers is a great idea but did they > > > > do it in C++? > > > > > > are you sure that the problem isn't the graph representation? > > > gcc also takes a graph-based approach. > > > > What problem? > > the problem you yourself mentioned. gcc/llvm/etc have seem > to have produced monsterously huge piles of code, out of all > proportion to the problem at hand. > > i believe you're putting forth the theory that llvm is huge > because it's c++. and i'm not so sure. I must also say llvm has a lot of functionality. But even so there is a lot of bloat. Let me just say the bloat is due to many factors but it has far *less* to do with graphs. Download llvm and take a peek. I think the chosen language and the habits it promotes and the "impedance match" with the problem domain does play a significant role. At any rate, a graph representation would have `data' bloat if any, but not so much code bloat! > > All programs are graphs in any case. Optimizations in effect > > replace one subgraph with another that has better properties. > > Global optimizers need to keep many more graphs in memory. > > But you can take short cuts when not optimizing -- if you > > know a graph is not going to change under you, you can > > generate code incrementally and may not even need to keep all > > subgraphs in memory. > > all programs are graphs implies that we should represent them > as graphs? Or something equivalent. Example: How do you know moving an expression out of a for loop is valid? The optimizer needs to understand the control flow. The _model_ is graph based. But if you look at c/c++ code, typically the "graphiness" is hidden in a mess of ptrs. Which makes equivalent xforms on the representation harder. > seem to get by fine using pseudoassembler instead of a graph. > they are also quite a bit faster and smaller than their graph-based > counterparts.