Re: profiles of gcc available

Toon Moene (toon@moene.indiv.nluug.nl)
Wed, 13 Nov 96 17:41:37 +0100

> The thing is, see, is gcc really doesn't spend that much
> time playing with the bytes. According to Jim's profiles,
> 4.5% of the time is spent playing with incoming bytes
> (yylex); after that we always play with tokens (ints).
> Unfortunately there is no single output function making
> it hard to say exactly how much time is spent that way,
> but I don't think I'm off in saying it isn't much.

Agree with that - I didn't realise this would put yylex on top of
the list if byte manipulations were the real problem; my language of
choice predates automatic lexers by two decades, and I didn't
really kept up with the field after the card readers were scrapped
around here :-)

>> Now neither bytes,
>> nor the members of the various structures used in gcc internally,
>> are necessarily long- or quadwords (i.e. 32 or 64 bit quantities).

> I suppose they needn't have been but they are. Virtually
> everything done inside of gcc once things are parsed are
> with pointers and longs.

Well, I don't mean to argue this to death, but in _my_ copy of gcc,
the first two fields in the RTX structure are 16 and 8 bits wide,
followed by 7 one bit flags.

> No, the thing to do to make gcc faster is not to worry
> about the I/O, but to improve the algorithms used in the
> optimization phases.

Sure, but I hoped to pinpoint a *common* cause for the difference
between gcc on the Alpha and on the i386, given that Jim's
experiment shows that no *single* routine is responsible.

Cheers,
Toon.

--
To unsubscribe: send e-mail to axp-list-request@redhat.com with
'unsubscribe' as the subject.  Do not send it to axp-list@redhat.com



Feedback | Store | News | Support | Product Errata | About Us | Linux Info | Search | JumpWords
No Frames | Show Frames

Copyright © 1995-1997 Red Hat Software. Legal notices