From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3d6e49d9bcfa43f526b52309c7dfa7ee@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat, 18 Mar 2006 08:03:22 -0600
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ports from GPL
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 189c752e-ead1-11e9-9d60-3106f5b1d025

hey, i don't think that old assumptions about inline are the
reason that gcc is slow and large.

the major reason is design. gcc takes many passes over the data,
transforming it first into a parse tree, then into rtl and then
optimizes the rtl. (i think they do strength reduction, &c
in rtl, using some arch-specific tables to compute costs.)

the problem is that rtl must handle every arch and every
language that gcc supports, making it slow and cumbersome.

actually i think rtl ends up doing this: (quoted from tom duff's
sillysort)

/*
 * The time complexity of this thing is O(n^(a log n))
 * for some constant a. This is a multiply and surrender
 * algorithm: one that continues multiplying subproblems
 * as long as possible until their solution can no longer
 * be postponed.
 */

- erik

On Sat Mar 18 07:32:05 CST 2006, brantley@coraid.com wrote:
> > their major mistake, apart from not thinking before coding, is that all
> > of those stupid inlines blow your cache and ken is clever.
>
> This is a big deal.  Assumptions learned early in our careers had very
> hard to change.  A few years back I wrote a DES implementaiton that on
> 0 loops.  Ran like a dog because it pretty much filled the cache.  Hard
> to stop thinking that memory isn't flat.
>