From: Bakul Shah <bakul+plan9@bitblocks.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
Date: Thu, 3 Feb 2011 11:40:58 -0800 [thread overview]
Message-ID: <20110203194058.8F4B55B91@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Thu, 03 Feb 2011 13:54:05 EST." <05360a88f7a0cd797278d6bd6a3ae73f@ladd.quanstro.net>
On Thu, 03 Feb 2011 13:54:05 EST erik quanstrom <quanstro@quanstro.net> 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 <quanstro@quanstro.net> 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.
next prev parent reply other threads:[~2011-02-03 19:40 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-02 6:56 Jacob Todd
2011-02-02 7:06 ` ron minnich
2011-02-02 7:25 ` Bakul Shah
2011-02-02 7:25 ` Lucio De Re
2011-02-02 7:35 ` Nick LaForge
2011-02-02 17:45 ` David Leimbach
2011-02-02 19:19 ` Bakul Shah
2011-02-03 0:30 ` Charles Forsyth
2011-02-03 0:21 ` erik quanstrom
2011-02-03 0:52 ` Charles Forsyth
2011-02-03 0:50 ` ron minnich
2011-02-03 2:16 ` Bakul Shah
2011-02-03 2:25 ` David Leimbach
2011-02-03 2:26 ` erik quanstrom
2011-02-03 15:08 ` David Leimbach
2011-02-03 16:19 ` Eugene Gorodinsky
2011-02-03 17:41 ` Bakul Shah
2011-02-03 18:11 ` erik quanstrom
2011-02-03 18:33 ` Bakul Shah
2011-02-03 18:54 ` erik quanstrom
2011-02-03 19:40 ` Bakul Shah [this message]
2011-02-03 20:33 ` erik quanstrom
2011-02-04 7:16 ` Bakul Shah
2011-02-04 14:38 ` erik quanstrom
2011-02-03 18:29 ` Joseph Stewart
2011-02-03 8:35 ` Charles Forsyth
2011-02-03 8:56 ` EBo
2011-02-03 9:46 ` Charles Forsyth
2011-02-03 9:47 ` EBo
2011-02-03 9:50 ` Lucio De Re
2011-02-03 10:38 ` C H Forsyth
2011-02-03 12:07 ` EBo
2011-02-03 20:49 ` Federico G. Benavento
2011-02-03 21:07 ` ron minnich
2011-02-03 21:32 ` Steve Simon
2011-02-03 23:19 ` EBo
2011-02-03 18:21 ` smiley
2011-02-03 18:50 ` John Floren
2011-02-03 19:09 ` [9fans] FORTRAN and tools [was: Modern development language for Plan 9 EBo
2011-02-03 23:08 ` John Stalker
2011-02-03 23:12 ` EBo
2011-02-05 19:54 ` Lyndon Nerenberg
2011-02-05 20:32 ` Benjamin Huntsman
2011-02-05 21:17 ` EBo
2011-02-05 21:49 ` ron minnich
2011-02-05 23:12 ` Benjamin Huntsman
2011-02-06 0:25 ` EBo
2011-02-04 5:54 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely andrey mirtchovski
-- strict thread matches above, loose matches on Subject: below --
2011-01-31 22:12 [9fans] " Steve Simon
2011-02-01 6:02 ` smiley
2011-02-01 6:45 ` ron minnich
2011-02-01 17:51 ` smiley
2011-02-01 18:33 ` ron minnich
2011-02-02 0:28 ` smiley
2011-02-02 0:47 ` ron minnich
2011-02-02 5:14 ` [9fans] Modern development language for Plan 9, WAS: " smiley
2011-02-02 5:37 ` Scott Sullivan
2011-02-02 5:38 ` EBo
2011-02-02 15:54 ` Anthony Sorace
2011-02-02 12:54 ` erik quanstrom
2011-02-02 13:48 ` Devon H. O'Dell
2011-02-02 17:47 ` David Leimbach
2011-02-02 17:53 ` erik quanstrom
2011-02-02 18:07 ` tlaronde
2011-02-02 18:26 ` David Leimbach
2011-02-02 18:48 ` tlaronde
2011-02-02 19:26 ` Nick LaForge
2011-02-03 0:39 ` Charles Forsyth
2011-02-02 17:44 ` David Leimbach
2011-02-02 17:50 ` erik quanstrom
2011-02-02 18:15 ` Jonathan Cast
2011-02-02 18:21 ` erik quanstrom
2011-02-02 18:36 ` David Leimbach
2011-02-02 18:38 ` erik quanstrom
2011-02-02 18:46 ` David Leimbach
2011-02-02 19:15 ` Jonathan Cast
2011-02-02 19:31 ` erik quanstrom
2011-02-02 19:48 ` Jeff Sickel
2011-02-02 20:07 ` Jonathan Cast
2011-02-02 20:11 ` erik quanstrom
2011-02-02 20:22 ` Jonathan Cast
2011-02-02 18:21 ` David Leimbach
2011-02-02 18:03 ` erik quanstrom
2011-02-02 18:30 ` David Leimbach
2011-02-18 5:23 ` ron minnich
2011-02-18 5:34 ` Paul Lalonde
2011-02-18 13:29 ` erik quanstrom
2011-02-18 13:45 ` dexen deVries
2011-02-18 14:54 ` David Leimbach
2011-02-18 15:15 ` Devon H. O'Dell
2011-02-18 16:11 ` erik quanstrom
2011-02-18 16:28 ` Devon H. O'Dell
2011-02-18 16:49 ` erik quanstrom
2011-02-18 17:10 ` Devon H. O'Dell
2011-02-18 17:32 ` erik quanstrom
2011-02-18 17:44 ` ron minnich
2011-02-18 19:28 ` Devon H. O'Dell
2011-02-18 19:33 ` erik quanstrom
2011-02-18 19:49 ` Devon H. O'Dell
2011-02-18 18:43 ` Joseph Stewart
2011-02-18 17:05 ` andrey mirtchovski
2011-02-18 17:12 ` Devon H. O'Dell
2011-02-18 16:53 ` dexen deVries
2011-02-18 16:59 ` Devon H. O'Dell
2011-02-18 17:07 ` erik quanstrom
2011-02-18 17:11 ` Devon H. O'Dell
2011-02-18 17:21 ` erik quanstrom
2011-02-18 17:52 ` John Floren
2011-02-18 18:46 ` Rob Pike
2011-02-18 19:15 ` Bakul Shah
2011-02-18 19:26 ` erik quanstrom
2011-02-18 19:46 ` Bakul Shah
2011-02-18 20:15 ` erik quanstrom
2011-02-18 21:06 ` John Floren
2011-02-18 22:21 ` Bakul Shah
2011-02-19 10:26 ` Steve Simon
2011-02-19 15:09 ` erik quanstrom
2011-02-19 20:09 ` Bakul Shah
2011-02-19 21:15 ` erik quanstrom
2011-02-20 23:49 ` Bakul Shah
2011-02-21 14:47 ` erik quanstrom
2011-02-19 16:57 ` Skip Tavakkolian
2011-02-19 15:36 ` erik quanstrom
2011-02-18 19:35 ` David Leimbach
2011-02-18 20:10 ` Bakul Shah
2011-02-18 21:03 ` ron minnich
2011-02-18 23:55 ` Federico G. Benavento
2011-02-18 19:15 ` Devon H. O'Dell
2011-02-21 5:08 ` smiley
2011-02-18 17:16 ` Russ Cox
2011-02-18 17:12 ` andrey mirtchovski
2011-02-19 10:34 ` Steve Simon
2011-02-19 17:25 ` dexen deVries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110203194058.8F4B55B91@mail.bitblocks.com \
--to=bakul+plan9@bitblocks.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).